This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Getting hex values for entering numeric values

Hi all, I'm working on nrf52832 in segger embedded studio. Using ble scanner app, I'm entering some random values. So when i enter a value, I'm adding them to watch and checking out the value. I entered an integer value of 10, i'm expecting the same value to come in watch, but I'm getting the value as hex. For example if i enter 10, I'm getting it as 0x10.

  • Hi,

    Nirupama said:

    Example, in BLE scanner app, i write data as ka6574 , While reading i get as ka6574?!

    In nRF connect app, i write data as ka6574, it reads the hex values of ka6574 along with junk data.

    That means that in both cases you get junk data appended to the string when you print it? It would be interesting to see how you have implemented this in your firmware. Could it for instance be that you print a string which is not null-terminated, and therefore you print random junk until there is ransom zero in memory?

  • Hi,

    Yes i  get junk data in both cases. Here before writing into that characteristics, I will be doing a memset with Zero value. So if the characteristic size is 10 bytes and i enter only 5 bytes, when i read it, I get 10 bytes with first 5 bytes is my data  followed by junk data of 5 bytes.

  • Can you show us your firmware code, how do you handle the data starting with when you receive it until you print it? Do you make sure to only print the correct length, and is it null-terminated?

  • 7888.ble_peripheral.zip

    Hi, Yes, Please find the zip file attached.

    Thanks,

    Nirupama.T

  • Most apps it will use a C type null terminated string and they will not overwrite old data in the characteristic beyond the string termination point.

    Remember that the minimum characteristic size if 20 bytes of data.

    In all cases the full amount of data will be transmitted for a characteristic.

    This means that if you send "hello" as ASCII in your 10 byte characteristic you will find 10 bytes of junk data tagged on the end even if you send 5 null bytes after the 'o'.

    If you wish to ensure that your characteristic always has null characters beyond the end of your string then you will need to ensure that you treat all data written to the characteristic as a binary array of the full characteristic size.

    The onus is on you to know how to interpret your characteristic data when read. If it is always a null terminated string then just read back the data until the null character is found.

    As a final point are no power savings to be made by sending null characters.

Related