When I write from a microcontroller to an app inventor app's label, I'm seeing a decimal array instead of alpha numeric characters.
So instead of setting "setting=123" in the label, I'm seeing
[115, 101, 116, 116, 105, 110, 103, 61, 49, 50, 51, 13, 10]
What is causing this?
We would need to see your microcontroller code to know what was being sent to the app via Bluetooth.
Also export your .aia file and post that.
I do see a possible way a piece of text could be split into separate characters, if a text split at ' ' were really just a text split at '' (the empty zero length text block.)
AI2 gives you an empty text block instead of a blank (length 1) text block by default, unless you go back and re-insert a space into it.
Splitting at a zero length string breaks up text between all characters.
Hi, I don't have access to the aia file until tomorrow, however the uC code is
Serial.print("setting="); Serial.println("123"); so I believe I'm sending a terminating character. I've also configured the Bluetooth object in AI to use "10" as a terminating character.
The problem is not with the split text at the first space for local variable bluetoothConnectionNameTemp, it's with the last if/then condition in the after picking event, using local variable "message".
Export your .aia file and upload it here for whoever will be awake.
If this returns as a search result, the problem was two fold, I had a BluetoothClient1.ReceiveSignedBytes.numberOfBytes trampling on my AfterPicking bluetooth receiveBytes code and apparently the ddlBTConnections.AfterPicking event can send a bluetooth text, but cannot receive it OR cannot receive it quick enough and my clock is on a separate thread and is randomly getting the received bluetooth bytes before the AfterPicking event bluetooth call can receive them?
Thanks for the help ABG, this post pushed me to dig deeper.
Aww, I was just about to say that!
P.S. I also wanted to ask if you had a Clock Timer where you test AVailable Bytes and if so, do your Receives.
It looks like it was a race condition, as when I disable the loop/clock BluetoothClient1.ReceiveText.numberOfBytes -1, the AfterPicking .ReceiveText.numberOfBytes -1 will pick up the data.
So presumably they are on different threads?
Uh oh, you aren't trying to loop instead of using a Clock Timer, are you?
Since you won't show me yours, I'll have to show you mine:
Here is a simple BlueTooth text receiver sample, for single value per line:
Timers are good.
They don't send the phone into a coma, like loops do.
We occasionally get hardware programmers who try to loop for timing, like they owned the hardware on the phone, operating system to be damned.
P.S. Your Clock Timer looks fine.
There are learned discussions on this at
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
