BLE WriteStringswithResponse adds byte to end of string?

[Don Richardson]

Hi,

I am working on a app that connects to a BLE device, and sends strings over the nordic uart UUID. So far, I can successfully connect to my BLE device, and send a string of less than 20 characters, that follows the format that the device is expecting. This string is accepted by the device and acts as expected.

What I am attempting to do (and where my problem lives) is sending a string that is far longer than 20 characters. This is supported by the device and using nrf connect, sending this string in 20 character chunks, successfully sends the command and the device acts as expected. For testing I have manually broken the string down into 20 character strings and have attempted to send those multiple different ways using the writestringswithresponse. I have gone so far as to assign each of those 20 character stings to a individual button that uses writestringswithresponse and pressing them in order attempting to complete the command. I have also tried using lists, the string in a single line, and a list that sends a string once a second. No luck, and a lot of frustration.

Here is a example of the longer string:

$WEAP,0,,100,0,3,18,0,,,,,,,,360,850,14,56,1400,0,7,100,100,,0,,,S07,D20,D19,,D04,D03,D21,D18,,,,,14,28,75,,*

Each character including the commas need to be sent. 

From hci_snoop logs, when I send the first 20 character string using nrf connect it shows the packet as 32 bytes captured (256 bits). However, when I attempt to send the same string through the AI2 app the hci_snoop log shows 33 bytes captured (264 bits). I'll be honest here and admit that I really don't understand what all is going on when things get to this level, (actually this is all fairly new to me) but I know that the two things don't match up. Wireshark shows an additional 00 at the end of the packet sent by AI2.

Is there a way to ensure that the string is sent at only 20 characters, or a way to ensure that the packet sent does not exceed 32 bytes? Is this a bug? Is this working as intended? 

Im out of hair to pull.

[Chris Ward]

Hello Don

Short answer is - I don't know, perhaps the last character is used to elicit a response. Since you have success sending strings of less than 20 characters, can you send strings of 19 characters rather than 20? Ensure the string format matches your BLE device - this would normally be UTF8, so the utf16 option on the WriteStringsWithResponse Block should be False. 

Checking the Bytesize is an interesting point because UTF8 characters can be 1 to 4 bytes in size (8 bits per byte). However, the first 128 characters match ASCII and they are all 1 byte. So unless your string contain something exotic, you should be able to send 31 bytes (= 31 characters) if my logic is correct...... 

On the other hand, if your devices expects UTF16, regular characters are 2 bytes, others are 4 bytes. 

Concerning the BLE packet size, this is always greater than the String size. The String is the packet "payload". The packet has a prefix and postfix too, hence the difference in size.

To help you to chop your strings up, it would be good to have a sample string or two.

[Don Richardson]

I did attempt modifying the strings to be less than 20 character, I think I took it down to 18 per string but it was still unsuccessful. I know the device is expecting UTF8 and 20 characters if the command exceeds 20. I do have the utf16 option set to false.

Yes what I was trying to convey there was that the "payload" in the packet shows the string I send, but had the extra 00 at the end of it when AI2 sends the packet. nRF uart does not have that extra 00. 

Here is a example of how I am breaking up the string:

$WEAP,0,,100,0,3,18,

0,,,,,,,,360,850,14,

56,1400,0,7,100,100,

,0,,,S07,D20,D19,,D0

4,D03,D21,D18,,,,,14

,28,75,,*

Thanks for your help

[Don Richardson]

Attempting to attach screenshots of the two different packets

[Chris Ward]

Hi Don

Well, I'm even more confused now :)

You have successfully sent a string of less than 20 characters, but a string of 18 characters fails?

What do you do with the Device response?

I think we need to see your blocks:

https://www.professorcad.co.uk/appinventortips#TipsBlocks          How to create an image of your Blocks and add it to your Forum Post

[Evan Patton]

We are sending a NULL-terminated string, so that is where the 0 byte comes from. It shouldn't be too difficult to add an option to forgo sending the NULL byte at the end of the string.

Regards,

Evan

[Don Richardson]

Ok that makes sense. 

I assume that is a update that I will need to wait for, or is there something I should change on my side?

[Chris Ward]

Hi Don

That will be an option, added to the BLE library in the future. 

We don't know anything about your Device - how does it concatenate the strings? Is it programmable such that a script can remove the NULL byte?

[Don Richardson]

I'm not entirely sure. I don't have the ability to modify it, so Im at its mercy.

By my observation it seems to add each chunk until it has the entire command and then applies it. 

[Chris Ward]

Hi again

The asterix (*) at the end of your example string, is that always required? Perhaps telling the device "end-of-string" ?

[Don Richardson]

Yes that is my understanding. The $ is the "header" and the * is the "footer". 

Thanks again for everyones help, I was starting to go a bit crazy working on this.

[Chris Ward]

So, you haven't uploaded your Blocks. Here is a snippet using a Procedure to send the string in chunks:

[Don Richardson]

Wow ok that is way beyond what I was working on. Here is all my experimentation, in whatever state it was in when I decided to reach out here for help. Be gentle.

[Don Richardson]

Is this something that I should add to issues in GitHub? I don't know what proper etiquette is for something like this. 

[Chris Ward]

Hello Don

No. Your report here is sufficient. It should not be an issue, most devices are expecting to receive null terminated strings, hence it being the AI default. Evan will introduce the option of omitting the null in the future - there is always a lot to do in terms of improvements and of course, they are all urgent.

By the way, if your Bluetooth device is capable of receiving "long" strings, you could try sending the whole string. What is possible and what is not we cannot say because we have no information about the device you are using.

[Don Richardson]

Understood. My use case should only be considered urgent to me so Im grateful that I might get the option added.

I did try sending the entire string, it didn't like that either.