Encode an UTF8 String into characteristic

RE: Encode an UTF8 String into characteristic

daubsi — Fri, 15 Jan 2021 16:37:24 GMT

Thanks for seeking clarification on this one!

RE: Encode an UTF8 String into characteristic

tesc — Fri, 15 Jan 2021 14:14:03 GMT

Hi,

I can confirm that the byte order that you have, is the intended byte order: First one byte "flags", then one byte "training status", then n bytes UTF-8 encoded string. For increasing memory addresses. When stored as data for the characteristic.

Other implementations, and/or byte order physically sent over the air, may differ, but apart from that: This is the byte order to use with our SDK / SoftDevice API, yes.

Regards,
Terje

RE: Encode an UTF8 String into characteristic

daubsi — Mon, 11 Jan 2021 16:48:50 GMT

Thanks Terje, appreciate! I was confused because of the explicit mentioning of MSB/LSB order in the spec and thought I might reverse the byte order therefore. I am actually printing only 8 bytes in the end. The screenshot just shows the SES IDE where I had it print 32 bytes for an easier oversight. Looking forward to your response!

RE: Encode an UTF8 String into characteristic

tesc — Mon, 11 Jan 2021 15:19:26 GMT

Hi,

From what I can figure out, it should be a UTF-8 encoded string, without any additional metadata, and in the "normal" byte order for such a string (e.g. no reversing of the bytes.)

I.e. the same byte ordering and formatting as the Device Name characteristic of the GAP service, which also holds a UTF-8 encoded string. The only difference being that for the Training Status characteristic there are two octets containing "Flags" and "Training Status" in addition to the string.

Which means your characteristic value data looks correct as is, with the exception that you are printing 32 bytes and the actual contents of the characteristic should be only the first 8 of those bytes.

I am reaching out internally, to see if I can confirm this is indeed how it is supposed to work.

Regards,
Terje