I have implemented BLE functionality in my app. To communicate with the external BLE device, I have implemented “Transmit hexadecimal block” It is working fine for the only one command, which starts with 2020. however the other command which starts with CEC1 is not working. these commands are working commands tested in nRF connect app. in fact I am getting response in the Thunkable app for the commands that I sent in nRF connect, which has not worked in Thunkable transmit hexadecimal block. it looks to be a some bug. Can you please check and if you could provide a solution, it will be greatly helpful. Please see the images below.
Following the topic above, I tried to debug what was happening to the data sent over the BLE block.
I decided to send the commands in byte array format and to debug, I programmed an nRF device using the UART example code, which receives data from an app on the serial terminal. I then sent the same data back from the terminal to the app — essentially performing a loopback test.
What I observed is that when we try to transmit decimal values above 127 in byte array format, they are sent in two bytes. Values up to 127 are transmitted as a single byte, but from 128 onwards, the transmitted values appear as two bytes.
To investigate further, I directly transmitted text data equivalent to the decimal values of 128 and above, and observed the same conversion into two bytes. From this, I figured out that although BLE transmission accepts a byte array, it actually converts the data into text before sending it. It does not transmit the raw byte array values directly. As long as the values you send are less than or equal to 127, you won’t notice any discrepancy.
I think the transmit hex block is not working just because of this reason.
I kindly request Thunkable team to provide a solution to this limitation/bug.
- I tested sending {7F,OC,12,00,00,00,00,00,00,00,00,00,00}
here is the response.
0A is the newline added by the nRF device.
2.. I tested sending (80,OC,12,00,00,00,00,00,00,00,00,00,00}
0A is newline added by the nRF device.
I request the Thunkable team to acknowledge the reported bug. I understand it may take time to resolve, but a reply indicating that you are reviewing and working on a solution would help us understand that the issue has been taken up.
Thank you in advance
Hello @senthilkumaranms724i
I am sorry to hear about your issue and thank you for investigating it and sharing more information.
As it is mentioned in our docs, by design on BLE blocks, all values (string, HEX, Byte array, Base64) are being converted to a byte array before sending.
I hope that it helps.
In my BLE application, I am receiving data in notification mode. I have implemented the characteristic changed block to handle incoming data. Since the data is not plain text, reading it as a byte array is the more appropriate method.
I used the value returned by the “data (byte array)” output, expecting it to be a standard 8-bit byte array. However, to my surprise, it returned a 6-bit encoded array, which was actually Base64-encoded.
For example, when I sent the string “1” followed by a newline character, the expected byte array was 0x31 0A. I anticipated receiving the raw byte values 31 and 0A. Instead, I received the Base64 string “MQo=”. Similarly, for the string “11”, which should be 0x31 31 0A, I received “MTEK”.
Initially, this behavior was confusing. I later realized that the byte array is being converted to a Base64 string, which is not suitable for applications requiring direct access to raw byte data.
I kindly request the Thunkable team to address this issue. The current BLE block implementation shows this kind of mismatch in multiple areas. BLE is a highly useful feature, especially in IoT applications, and deserves a more accurate and robust implementation.
Please consider fixing these inconsistencies and adding more advanced BLE features. This will make Thunkable a more reliable and preferred platform for BLE app development.
I request the Thunkable team to acknowledge the reported bug. I understand it may take time to resolve, but a reply indicating that you are reviewing and working on a solution would help us understand that the issue has been taken up.
Hi @senthilkumaranms724i, we hear you and acknowledge the issue but we don’t have any timeline or plans for a fix yet. I’ll have to update you here if I receive any news.
1 Like
Yeah. it is converting in to byte array, but it is not a raw byte array. instead ASCII equivalent byte array. you can see the difference in the byte array values for the value of 127 and 128.