That shouldn't happen, but the connection problem is the issue of interest. Your Sketch code is in fact similar to other sketches I have seen, the difference is that you are using a Nano 33 BLE, a relatively new board (2018) with a different architecture to the more common boards such as the Uno. I assume you are an experienced User of Arduino as the differences between this board and the others is rather stark.
Is there a hardware issue? Is the Ardunio disconnecting because it is overheating for example? You could temporarily cool it with a desktop fan and see if that makes a difference.
I tested the same Arduino code and board with the nRF Connect app, and it was successfully able to make the BLE connection and update the data values on the mobile app. For this reason, I do not believe there is a hardware issue.
Right, that is good news. One thing I haven't asked is what phone are you using? Make/Model/Bluetooth Version.
Also, what version of the MIT BLE Extension are you using?
I have asked Evan Patton to take a look at your Topic. I'm sure he would like to see your Project File. Can you export the Project as an .aia file and upload it here.
Although we are confident there isn't a hardware problem causing the connection issue, it is wise to take good care of your hardware. The most common ways to destroy a board are wrong voltage and overheating. The Nano33 BLE is much smaller than other boards and stacked with heat emitting components - you really do need to deal with that (RIP my little UNO). If it was mounted in a box, it would most likely require it's own fan, similar to any computer.
I'm using a Galaxy A20s, which has slightly different specs than the A20. I installed the latest BLE Extension and placed a fan near the Nano33 BLE, but I'm still facing the same issue. The only difference I notice is that the BLE connection does not break in the Arduino code once I select my Arduino from the App's list view. Previously, the Arduino would disconnect after a few seconds of transmitting data, but now it remains connected and continuously transmits, which ideally is what I want. The App, however, does not indicate that a connection has been made, even though the Arduino no longer shows up in the list view after it is selected.
My project file with the updated Extension is attached below. BLE.aia (200.9 KB)
Yali, are you setting your phone to "fine location" before starting the BLE Scan?
Although I can't see anything particularly wrong with your Block code, we can see that when you run it, Register For Floats apparently never happens.
The App can be given a bit more time at each stage of the process to ensure everything is the best it can be. No doubt the nRF App does so. Attached is a basic Project that receives Strings via BLE. The principle is the same for receiving any data type.
It seems like I'm facing the same issue when running the BLE_RECEIVE_STRINGS project. I tested the project with my current Arduino code just to see if it could make the connection, and although the Arduino Serial Monitor indicates that the connection is made and data is being transmitted, the App remains in the "connecting" state, just like it does in my App project. Could it be a problem with the particular Android device I'm using? I'm unfamiliar with the Android OS and don't know how to set the phone to "fine location". However, I did configure the location service's settings to improve its accuracy as much as possible.
A screenshot of the device list before picking the Nano is attached below.
Even after improving the location service's accuracy and ensuring that my device's location is switched on, I still obtain the same results.
Can you test whether my Arduino code and App design can make a proper connection using your device? The fact that I'm also having trouble connecting using the BLE_RECEIVE_STRINGS project tells me that perhaps the Android device I'm currently using is causing the problem. You can find both the App and Arduino files in the previous posts of this thread.
Also, if I'm not mistaken, the BLE extension is incompatible with the iOS version of the App, correct?
It still works with the nRF Connect app, so I guess you're right, unless the MIT App is not compatible with my device's Bluetooth version.
What else could the problem be? You are able to make the connection using the BLE_RECEIVE_STRINGS project, right? If so, it must be a localized issue, but I'm not quite sure what.
That's a basic file I made and many people have used it successfully. You do have to change the UUIDs to your own, and it requires a String Characteristic of course, not a Float.
What if you remove the name of the device from your Sketch so that only the MAC address is displayed in the device list? Not sure but maybe the name length has a limit (really clutching at straws here).
The other item of interest is Location. It's clear that the nrf App can set that automatically. Your manual setting may not be quiet right - with the App running, go to the phone settings and check to see if the App is on the Location Permitted List (the title of this list will no doubt be different on your phone).
One final thought - you are building and installing an APK right?
Here is a slightly updated version of my basic Project - updates not tested. The App, having confirmed Bluetooth is switched on, should open the Location Screen for the User to switch Location on. Give it a try.
I removed the line of code that sets the device's name, but it stills displays the previously set name, even though I uploaded a new Arduino file to the Nano33. To fix this, I set the name to be two letters long to ensure the length does not reach the limit. I also made sure that the App is given location permissions. However, still no luck.
Yes, I am installing an APK by building the QR code and scanning the code with my device's camera. I tried to use the updated version of your project, but I am stuck in the Location screen.
Hmm, if Activity Starter got you to the Location Screen, you should be able to switch Location on and dismiss the screen - but I know this just doesn't happen on all phones. If you have access to a different phone, that would certainly be worth testing.
