Forum >Bluno BLE serial comms opens only when USB port opens comms
Bluno BLE serial comms opens only when USB port opens comms

Hello,
I have used the "BlunoTest" IOS xcode and the below analog voltage reader "ReadAnalogVoltage" example and the only time the app receives the information is when I start a USB serial connection with the BLUNO. Then the data shows up in the "received message" section of the BlunoTest code.
What am I doing wrong?
/*
ReadAnalogVoltage
Reads an analog input on pin 0, converts it to voltage, and prints the result to the serial monitor.
Graphical representation is available using serial plotter (Tools > Serial Plotter menu)
Attach the center pin of a potentiometer to pin A0, and the outside pins to +5V and ground.
This example code is in the public domain.
*/
// the setup routine runs once when you press reset:
void setup() {
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
}
// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
int sensorValue = analogRead(A0);
// Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
float voltage = sensorValue * (5.0 / 1023.0);
// print out the value you read:
Serial.print(voltage);
Serial.print("V ");
delay(1000);
}
Regards,
I have used the "BlunoTest" IOS xcode and the below analog voltage reader "ReadAnalogVoltage" example and the only time the app receives the information is when I start a USB serial connection with the BLUNO. Then the data shows up in the "received message" section of the BlunoTest code.
What am I doing wrong?
/*
ReadAnalogVoltage
Reads an analog input on pin 0, converts it to voltage, and prints the result to the serial monitor.
Graphical representation is available using serial plotter (Tools > Serial Plotter menu)
Attach the center pin of a potentiometer to pin A0, and the outside pins to +5V and ground.
This example code is in the public domain.
*/
// the setup routine runs once when you press reset:
void setup() {
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
}
// the loop routine runs over and over again forever:
void loop() {
// read the input on analog pin 0:
int sensorValue = analogRead(A0);
// Convert the analog reading (which goes from 0 - 1023) to a voltage (0 - 5V):
float voltage = sensorValue * (5.0 / 1023.0);
// print out the value you read:
Serial.print(voltage);
Serial.print("V ");
delay(1000);
}
Regards,

2019-01-03 22:45:43 Hi, just came across your thread and am experiencing the same issue with a Bluno Beetle (acting as PERIHERAL) sending Lidar data to a Bluno (set as CENTRAL). The Bluno has some Lixie's attached to display the data and is battery powered. I have modified both boards to various baud rates with no success in solving this issue, i.e. the beetle must be connected to a serial monitor on a PC (iMac) for the serial BLE to function. Did you have any more feedback to add to this thread?
dan.perren

2017-03-19 13:35:00 Update
Hi,
Found the issue. Baudrate does matter. The BLE Demo sets a baudrate of 115200. When I send with a baudrate of 9600 the BLE Demo does not understand what I am sending, so does not show data.
I have changed the sketch in the Bluno that it reads the timestamp from the sports timing clock on 9600 baud, and writes the timestamp with 115200 baud to the BLE. In this mode it works as intended. The Bluno works stand alone, powered from the clock device, and forwards timestamps to the BLE Demo app.
Postscript.
It is still unclear why in the test sequence, the connection of the serial monitor made the data appear on the Demo app.In the test situation the baudrate of the BLE uart and of the serial monitor were set to 9600 baud. Did the connection of the serial monitor communicate the baudrate to the BLE Demo ? I do not see anything about that in the BLE Demo code.
gerrit
Hi,
Found the issue. Baudrate does matter. The BLE Demo sets a baudrate of 115200. When I send with a baudrate of 9600 the BLE Demo does not understand what I am sending, so does not show data.
I have changed the sketch in the Bluno that it reads the timestamp from the sports timing clock on 9600 baud, and writes the timestamp with 115200 baud to the BLE. In this mode it works as intended. The Bluno works stand alone, powered from the clock device, and forwards timestamps to the BLE Demo app.
Postscript.
It is still unclear why in the test sequence, the connection of the serial monitor made the data appear on the Demo app.In the test situation the baudrate of the BLE uart and of the serial monitor were set to 9600 baud. Did the connection of the serial monitor communicate the baudrate to the BLE Demo ? I do not see anything about that in the BLE Demo code.

2017-03-19 02:40:35 Hi,
We work on a project to forward timestamps from a sports timing clock to and Android and IOS app. The aim is to use a Bluno Nano (v1.3, BLE v1.97). We offer a timestamp string on the Bluno D0RX (read) pin, and have a sketch that does a serial write.
This works fine. We receive the timestamps on the BLE demo app, but under the condition that the serial monitor via the usb must have been connected for a moment. Ref the next test sequence:
1. start Bluno on external power supply (no usb)
2. connect Demo app, send timestamp: no show on demo app
3. connect usb cable to PC, and disconnect external power without interruption
4. send timestamp: no show on demo app
5. open Arduino IDE, send timestamp: no show on demo app
6. open Serial monitor, send timestamp: showing on demo app
7. close Serial monitor, send timestamp: still showing on demo app
8. close Arduino IDE,
9. connect external power, disconnect usb without interruption
10. send timestamp: still showing on demo app
So the serial monitor on usb must have been connected for a moment in order to start forwarding serial writes via the BLE.
This looks as an initialization problem in the BLE firmware.
On the forum I found three posts reporting this issue, that you need a serial usb connection in order to get data forwarded via the BLE channel to the demo app. No solutions were presented to this issue.
Without solving this issue, you cannot use the Bluno stand alone to forward data to a smartphone app. A baud rate of 9600 is not a problem, it works fine once you activated the serial monitor.
Please confirm my test observation. As the BLE firmware is not open source, I cannot analyse the code to see if my suspicion holds.
Cheers !
gerrit
We work on a project to forward timestamps from a sports timing clock to and Android and IOS app. The aim is to use a Bluno Nano (v1.3, BLE v1.97). We offer a timestamp string on the Bluno D0RX (read) pin, and have a sketch that does a serial write.
This works fine. We receive the timestamps on the BLE demo app, but under the condition that the serial monitor via the usb must have been connected for a moment. Ref the next test sequence:
1. start Bluno on external power supply (no usb)
2. connect Demo app, send timestamp: no show on demo app
3. connect usb cable to PC, and disconnect external power without interruption
4. send timestamp: no show on demo app
5. open Arduino IDE, send timestamp: no show on demo app
6. open Serial monitor, send timestamp: showing on demo app
7. close Serial monitor, send timestamp: still showing on demo app
8. close Arduino IDE,
9. connect external power, disconnect usb without interruption
10. send timestamp: still showing on demo app
So the serial monitor on usb must have been connected for a moment in order to start forwarding serial writes via the BLE.
This looks as an initialization problem in the BLE firmware.
On the forum I found three posts reporting this issue, that you need a serial usb connection in order to get data forwarded via the BLE channel to the demo app. No solutions were presented to this issue.
Without solving this issue, you cannot use the Bluno stand alone to forward data to a smartphone app. A baud rate of 9600 is not a problem, it works fine once you activated the serial monitor.
Please confirm my test observation. As the BLE firmware is not open source, I cannot analyse the code to see if my suspicion holds.
Cheers !
