I am trying to get a Nano 33 BLE Sense to send accelerometer data over BLE to a Nano 33 IoT board. I made a sketch that makes them connect, download the three axes of data values and then disconnect, then repeat this process. This was very slow and I was getting values every second or so instead of the 100Hz rate the sensors can provide. I have now created a sketch for the receiver which should keep the two boards connected and just update the values. When I upload the receiver code to the 33 IoT, the board becomes invisible to the PC and I have to turn on the bootloader to get my PC to see it again and upload something else. If I use a different sketch, then this problem does not happen so the problem must lie in my code I guess? Any insight would be appreciated.
BLE_Receiver.ino (6.4 KB)
Why do you play with float pointers if there is a BLEFloatCharacteristic which handles that for you without the many memcpy calls you have?
Generally: you should check return values.
As the symptom you describe usually happens when you access wrong memory regions and overwrite important USB variables there, the memcpy() calls are subject to be responsible.
I have tried making them BLEFloatCharacteristics, however, peripheral.characteristic(UUID_HERE) will return a BLECharacteristic type and not a float type so I haven't found a way to not have to use the memcpy's. I shouldn't be overwriting any important data though because I am only writing the number of bytes in a float to a float block so I don't see how I am corrupting important serial data.
I have since tried to take your advice and move away from memcpy so I am trying to use the readValue method for BLECharacteristic (although this seems like the same thing so maybe this changes nothing). It does not solve my issue.
if (accelService.characteristic(i).uuid() == X_ACCEL_UUID) {
This will never match! Hint: the '==' operator will compare the numerical value of the pointers.
You're right, the typed classes are missing the necessary constructor unfortunately.
You should check the size of the value before you copy a fixed number of bytes.
You don't check if the peripheral is still connected.
You are probably right. I forgot to mention I am using strcmp on the UUIDs now.
You are correct that I make several assumptions in the code like the devices will never disconnect and I will always read 12 bytes (which is because I'm only going to read floats), but again I can make it work more correctly later I just want the code to work in principal. Right now it still does not allow me to serially talk to the board after I upload the sketch... I have to double click the button on the board force it to reset itself I guess so my PC can see it.
Debugging is the only way to get that. Comment out all BLE stuff. Insert many Serial.print()s in the code. Add one line/block after the other with the BLE code and check when the board starts to disappear.
Figured out that it's the initialization of the BLECharacteristics causing the weird behavior.
Just declaring the characteristics instead of initializing them allows me to see the board after uploading again. Now I am having a problem where my receiver can see the BLE signal but fails when trying to connect?
My Code is now this:
BLE_Receiver.ino (6.0 KB)
I'm not sure if that may be involved but your UUIDs are not UUIDs but simple 4 digit hex numbers.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.