I’m playing around with BLE connection, and I can scan, find devices, and then connect. But afterwards, any use of the BLE transmit or receive causes the Thunkable app on my phone to “reset” (using a Pixel 6).
I’ve tried all combinations on the UIUD string (dashes included, lower-case, upper-case). I’ve also tried byte-array TX, and receive, but it crashes.
Does the receive string - send the read request, and then wait for the return packet? Any problems with BTLE read response? I’m at a loss.
Interesting, so I’ve had multiple things going wrong:
First, my experiments weren’t updating the live app (I had to start changing a label on the designer screen to get code changes). So I was making changes, but not testing new code.
Second, it now appears it crashes using either Transmit/Receive with the byte array format, and it works with the String format
I can create the HEX byte array using the list field and integers. I.e. it now send 0x0602 over the air.
When using Thunkable mobile app you need to keep the app open with your project loaded and the mobile does not go in sleep mode (display off). You will notice whatever changes you do in the project will cause the project to reload inside the Thunkable app. This becomes more apparent in design changes but the same goes for coding changes. The changes may take few seconds to take effect.
If your project has more than one screen and you are trying to test any screen other than the first screen then you will notice just few seconds after your changes, the app reloads and goes back to the first screen.
The block says data (string) which means it expects text not an array (list). Just try with text string instead of list of numbers.
If the receiving device expects HEX then you might see this example to help you convert your input.
is the characteristic UUID a 128-bit one? Not sure if this is mandatory, but my working example used this. Again, check things like dashes are in the right places etc. (not being patronising, just things to double check).
Is the characteristic EXCLUSIVELY READ, or does it just include READ? I’ve only tested on the former.
This characteristic is just a READ (no notify or indication possible either). Of course once this works, I want to move onto notifications for another UUID, but baby steps for now.
Okay, well that’s not the issue then (could be good or bad news). My next thinking is what is the data type is the thing you’re reading? I can’t remember if I tested sending numbers as part of the receive string demo that I got working. Even if I did, it might be encoded differently (i.e. as ASCII characters rather than direct values).
You could try using the receive byte array example that I posted later on in the previously linked thread, but that is an untested example and may need some modification to work (assuming that block even does in the first place, of course). This might work better for reading actual numbers directly, although I have no idea of its limitations (only values 0-255 etc.).
If you do decide to experiment with that, remember that it will only work if it’s initially treated as a list, even if that list only ends up containing one element.
Thanks, I’m got a picture from your post on building a list from the output. In my case, the “Receive Byte Array” is throwing out an error before I can even get to the data.
That is unfortunate, if I remember correctly, the error messages (for the BLE blocks at least) are uninformative at best?
Do you have any control over what’s stored in the characteristic? If so, then you could try changing it to an ASCII string on the device side so that the app can read the string. If not, then I’m not sure what to suggest.
Thanks, it looks like the issue now resolved with the June 2022 Live App update! You can directly read “Receive Byte Array” with the BTLE components and receive the correct bytes.
