BLE extension with ASCII encoding

I am using the BLE extension from MIT App Inventor + Internet of Things
and the encoding used is UTF-8 while I want it to be ASCII , is there any other similar extensions(BLE) that allows changing the encoding?
Or is there anyway I could adjust this extension to allow changing the encoding to ASCII?
Thank you in advance.

Every valid ASCII string is also a valid UTF-8 string with the same exact characters. Unless you are referring to extended ASCII (char codes > 127)?

Yes, I am referring to extended ASCII sorry I should have mentioned that.

The BLE extension only supports a subset of the datatypes as defined in the Bluetooth Core Specification 4.2 §, which itself limits its strings to UTF-8 and UTF-16. Likely the easiest thing to do would be to represent your content as a list of numbers in the 0-255 range and then use the WriteBytes method to send the "string" to the device as it will give the most flexibility. If you are reading strings from a file or something, then you'll want to probably use a WebViewer with JavaScript to convert from the string representation to a byte array.

Alright, I got your point. By referring to the table you mentioned in 4.2 §, do you think the "0x04" format (which is unsigned 8 bit integer) would solve the issue?(Especially since extended ASCII could be represented with unsigned 8 bit integer).
Moreover, if the "0x04" format is feasible do you think it would be possible to modify the extension to include the above mentioned encoding.
For context, I have a BLE device connected to a microcontroller(stm32) so I am working at the byte level, and on the other hand, from the mobile app using UTF-8 with char codes>127 results in sending 2 bytes instead of 1(noting that usage of libraries for data conversion in embedded systems is a bit limited).
Thank you for the help, really appreciate it.

What code page is your microcontroller targeting, and what does the data need to look like from the client side? For example, if you want to send a string like ¥200 where the number value changes but the ¥ symbol is fixed, then you have a few options. If you want to send arbitrary strings, like niños, where the characters are user-provided and can appear anywhere in the string, that's a bit harder.

There is a test version of the BLE extension that allows for mixing strings and integers in the WriteBytes value list. Strings are still sent as UTF-8, but if you know content at the beginning or end should be encoded with a different charset then it should provide a workable solution by letting you specify the integer values for the code points separately from the ASCII content (which is also valid 1-byte-wide UTF-8).

1 Like

The microcontroller is not targeting a specific code page. From the client side the data being sent are json packets. Now, the json packets(initially set as string arrays) are filled at specific indexes by specific data(ex. place value 0 (ascii code 0x00) at index 5). if I would need to display that string in MIT, the index 5 won't show up on the app since it's not a character(NULL character). When the microcontroller receives the json packet at the index 5 the memory's content will be 0x00 which could be directly processed. Now if I would have sent the value as a character (0 would be 0x30 in hex ascii) ,that would require 2 places in the json packet for values >9, and 3 places for values >99. which will be more complex to process on both sides client/mirco. Note that the values I am filling in the json packet range from 0-255(1 byte) that's why extended ascii fits well to send the json packets from the client side.
I just tried the WriteBytes with an integer value of 255 and received 0xFF which is quite the result needed. But using WriteBytes induces additional delay(and additional blocks configuration to switch between json characters and the integer values at the specific indexes) which is not desirable.
If you think there's any alternative to this please let me know otherwise I will consider the case as solved(and mark it).
Thank you for your time and consideration.