Hello,
I added delay(2000) after while (central.connected()) {delay(2000); ....} in the BatteryMonitor example and upload the example to a Nano 33 BLE Sense board.
However, it needs about 30 seconds to connect it via the APP (Bluefruit Connect or nRF Connect). After I remove delay(2000), it only needs about 2 seconds to connect it.
Does anybody know why it needs so long time to connect? Thank you very much in advance.
Hello tangtangdn,
It is not typically recommended to use delay() functions, in this situation I am guessing that the dealy is causing communication issues with the app, but the app keeps trying and gets through eventual. What is the purpose of delaying the board within the while loop?
Thanks,
Matt
matt_lee_smith:
Hello tangtangdn,It is not typically recommended to use delay() functions, in this situation I am guessing that the dealy is causing communication issues with the app, but the app keeps trying and gets through eventual. What is the purpose of delaying the board within the while loop?
Thanks,
Matt
Hello Matt,
Thank you very much for your help. Actually, I want to save about 2 seconds or more IMU data and then send them out via Bluetooth. So I used delay 2s to instead. You are right, delay too long time does cause communication problem. Do you have any solution to solve this problem? Thank you.
Tang
Hello Tang,
Is there a reason you want to save two or more seconds and then send it or do you want a constant stream of data to the app?
It is doable, but there are a few other factors you will need to consider, for example:
If you are just sending one number every two seconds then you can just read a characteristic.
If you are sending lots of data every two seconds, your solution can come in many forms, one way would be to dump all the data into a larger buffer array (you can separate it with commas or other makers if you wanted) and then you can send all the raw data through one Bluetooth characteristic using the fact that you can send up to approx 230 bytes packets per characteristic (it should be 512 bytes but I haven't had the work yet and maybe a bug). This way the "app" could read the characteristic and trigger the next packet until the buffer is finished. This is probably the fastest way of doing it but it would require more data handling.
Another option is to break the data out into different arrays and characteristics (so one array and Bluetooth characteristic for the accelerometer, then one for the gyroscope, etc.). This is a bit easier for the human to understand but a bit slower for the nano because it has to read multiple characteristics (although it might not be that slow).
It is worth noting that the nRF Connect app won't handle getting all the data automatically.
As for the delay of two seconds, you can simply use a millis() timer to detect when two seconds have passed (collecting data during this time) then begin advertising the BLE. However, you will also need to know if you want to collect IMU data whilst you are sending the data across to the app. If that is the case you need to be aware that if you use a while (central.connected()) loop then the board won't collect the IMU data until the app had disconnected unless you tell it to!
I hope this is enough to get you started!
Matt
matt_lee_smith:
Hello Tang,Is there a reason you want to save two or more seconds and then send it or do you want a constant stream of data to the app?
It is doable, but there are a few other factors you will need to consider, for example:
- How often per second are you collecting the IMU data?
- Are you sending all the data or just averages?
- How are you planning on storing the data on the Nano?
- How many "parts" of the IMU are you using (accelerometer, gyroscope, and magnetometer)?
If you are just sending one number every two seconds then you can just read a characteristic.
If you are sending lots of data every two seconds, your solution can come in many forms, one way would be to dump all the data into a larger buffer array (you can separate it with commas or other makers if you wanted) and then you can send all the raw data through one Bluetooth characteristic using the fact that you can send up to approx 230 bytes packets per characteristic (it should be 512 bytes but I haven't had the work yet and maybe a bug). This way the "app" could read the characteristic and trigger the next packet until the buffer is finished. This is probably the fastest way of doing it but it would require more data handling.
Another option is to break the data out into different arrays and characteristics (so one array and Bluetooth characteristic for the accelerometer, then one for the gyroscope, etc.). This is a bit easier for the human to understand but a bit slower for the nano because it has to read multiple characteristics (although it might not be that slow).
It is worth noting that the nRF Connect app won't handle getting all the data automatically.
As for the delay of two seconds, you can simply use a millis() timer to detect when two seconds have passed (collecting data during this time) then begin advertising the BLE. However, you will also need to know if you want to collect IMU data whilst you are sending the data across to the app. If that is the case you need to be aware that if you use a while (central.connected()) loop then the board won't collect the IMU data until the app had disconnected unless you tell it to!
I hope this is enough to get you started!
Matt
Hi Matt,
Thank you so much for your kind help. It is really helpful. Actually, I want to collect 2s raw accelerometer data with the sampling rate of 952Hz and store them temporarily, then transmit them via BLE. I also found that 240 bytes packet will make the transmission not unreliable. Many thanks.
Kind regards,
Tang