Why does BLE Receive String work, and BLE Receive Byte Array not work

So I’ve faced some issues with a BLE read, and here is the best summary I have:

  • “Receive String” works on a READ characteristic
  • “Receive Byte Array” returns on error on the exact same characteristic.

Here is my case, I can connect to a BLE device, and then read on a button click. Using a counter, I can alternative between the two reads. The read string version returns the data, but the Receive Byte array always flags an error. Ultimately, I need the Read Byte Array for my application, but I haven’t been able to debug the error difference between the calls.

1 Like

In your blocks, you are displaying a static message for the error. You should display the error green block to see what information it gives.

Thanks, I didn’t realize “error” was actually text.

Here is what it says: c is not a function. (ln 'c(void 0,l.t0.message)', 'c' is undefined)


Dear @jared @wei @paulmw @cassandra

Can you look into this as it seems not part of the user error messages.

BLE receive byte array function can only use a specific device address
BLE Receive String can use both a specific device address and a bluetooth name
BLE Receive String works better than BLE Receive Bytes
BLE Receive Bytes has a different structure from BLE Send String
BLE Receive ByteArray cannot send data but it can receive data
BLE Receive String is faster than BLE Receive bytes
Check out


Thanks, but what exactly does this mean “BLE receive byte array function can only use a specific device address”? I have a specific device that is already connected.

1 Like

@jared @wei @paulmw @cassandra

Just wanted to follow-up, any thoughts on an ETA to look at this problem? If you DM me, I’m happy to dive deeper into the problem, or even send you our HEYKUBE BLE connected device to recreate the problem.

Hey @davew3q

Sending a device would be immensely helpful I would think. I’d be happy to ship it back when we’re all done too. One of the main issues we have with troubleshooting BLE stuff is that all devices are slightly different and we don’t actually have any.

That said, before we do anything like that, let me check in with the team and see what they think.

I need to ask: are you sure that your device sends a byte array and if so can you point me towards any docs? For full transparency here. I’m not familiar enough with BLE since I’ve never used it. It’s probably the only thing I’m not terribly familiar with. :frowning:


Great, let me know. And yes, I’m confident on the byte-array format – it’s from a BLE toy that I design the BTLE structure.

In the case I’m testing, I’m reading a 2-byte characteristic from the device that encodes the battery voltage, and the charging status. I need to doing something like this code to extract what I need.

uint8_t val[2];
uint16_t voltage_int;
float voltage;
uint8_t charging;

// recover data
voltage_int =  ((val[1] << 8) | val[0]) & 0x7ff;
voltage = ((float)voltage_int) / 512.0;
charging = (val[1] >> 3) & 0x1;

Hi all,

Thanks to Thunkable!! They just fixed this feature in the June 2022 Live App update for Android! Now you can directly read a “Receive Byte Array” on BTLE and I’m getting the correct bytes on the function.


Hi @davew3q,

Can you please share your Arduino code?
I struggle with receiving Strings and want to double-check my code.


Hi @aspras01gt10bm - in my case I have custom embedded C using Infineon’s PSOC4 chipsets, so I can’t share the Arduino code for BTLE

So what device are you receiving data from? So if you read a BTLE characteristic from a device, it will return a list of bytes. Under the “Receive String”, think of it as just a char array, and the underlying bytes are converted into ASCII characters provided to you in Thunkable.

So for my device, it’s returning arbitrary uint8 values in the range 0-255, so the not all the characters map to valid ASCII codes. I’m using the Receive Bytes to create a list of integers that I can process.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.