Two possible solutions
- An extension that adds BluetoothClient Send2ByteNumber List
- Send the encoded data as a string (requiring an edit of the STM32 script)
- The solution does not depend on me and only solves the problem of those who will send x2Bytes packages, probably a small group of programmers. Ideally I could build structures of 1,2, ...n in bytes and send them by Cal.BT.SendData.
- The code on STM is open source can be modified but will create incompatibilities with future versions that are not created by me.
- Additional arduino hardware interposed between HC-05 and STM.
HC-05 sends 4 packets of 2bytes of type Dir, value / Speed, value arduino separates the values for Dir and Speed packs them in the structure known for STM and sends them on the serial interface to it. Then it receives the fedback from STM and sends it to HC-05 to get to AppInventor.
Until new components appear in AppInventor, I think I will choose solution 3. I wish you a wonderful day.
Solution 3?
Additional arduino hardware interposed between HC-05 and STM.
1 Like
I have no guesses for what's happening in the BlueTooth layer, but if you post Download Blocks Images of your copies of the conversion procedures, I can double check those.
Thank you for looking at my code.
After reviewing your test results, I suspect you are relying on the AI2 CONVERT BASE 10 TO BINARY block to inspect bit patterns.
Unfortunately, that block has a 'helpful' feature where it removes leading 0's from its output. I can't blame it, because it is meant to work with non-negative integers of unlimited size, so it has no concept of byte boundaries that would be needed to do left padding with 0's.
Using that block to generate your bit level dumps would cause the shortening of bit strings that you report.
After sleeping on your problem, I see how to calculate Most Significant Byte (MSB) and Least Significant Byte (LSB) of an integer in the range -(2^15) to +(2^15) without using AI2 base 10 to binary conversion, using the trick of adding 2^16 to the input and masking (bitwise AND) and shifting (QUOTIENT/256). Code....
math.aia (38.2 KB)
2 Likes
Outstanding ABG. It should avoid the need to add more hardware.
... actually, not out of the woods on the BT side of things:
SendBytes(list)
Takes each element from the given list, converts it to a String, decodes the String to an integer, and writes it as one byte to the output stream.*
If an element could not be decoded to an integer, or the integer would not fit in one byte, then the Form’s Error Occurred event is triggered and this method returns without writing any bytes to the output stream.
Prof_Info needs all the values to be delivered in one BT packet (max 20bytes).
So we need an extension to send a list of 2 Byte numbers.
The byteList value procedure returns a list of 8 bytes, all ready to be fed to the BT SendBytes block.
What am I missing here?
SendBytes does it's own conversion of the list of values.
What about using SendText?
SendText(text)
Converts the given text to bytes and writes them to the output stream.
A lot depends on the STM32 script, which we have not seen.
We need to see the STM32 Script!
Hi, the project for STM is here https://github.com/EFeru/hoverboard-firmware-hack-FOC. (USART) Let me tell you something about my project. I am studying the possibility of making a wireless remote controllable vehicle using the platform of a hoverboard .
The aim of the project is to learn and understand more about electric vehicles and to share these with groups of students in STEM classes. I managed for the moment to send text (Dir200Speed500) with AppInventor via BT. This text is taken over by arduino and processed with Dir = BTSerial.parseInt (), Speed = BTSerial.parseInt () which extracts the 2 values and sends them serially to STM.Robo now executes commands to change the direction of direction and speed but is far from being able to be controlled. Carefully code inside the STM to use gyroscopic sensors in position and distance control possibly adding new sensors. There is much to study and learn from here. I was very pleased with the ease with which you can work with AppInventor to have a lot of knowledge about the soft implementation of hardware components. It is a wonderful thing especially for beginners (students) but I accidentally discovered some limitations. Last night I tried to use a Slider I couldn't manage to position it vertically. All this should be pointed out somewhere to make AppInventor better. It would be interesting to have an AppInventor that works locally without a Scratch-like internet connection. I solved my problem with Robo. The topic can remain open only for the initial discussion how we can control the data sent through BT.
There are 3rd party versions made from the App Inventor open source.
.... since it is not a MIT product, we do not offer our technical support.
You can build your own with a Canvas component and either a sprite or a 'ball'. Some people favour this simply for customisation.
It would be possible to ditch the STM and just use an Arduino.......
Edit: I see that 'hoverserial.ino' is designed to control the hover board directly using an Arduino Nano.
Vertical slider with extension, search here:
slider
A howerboard contains 3 modules with STM one for central control and motors and 2 for reading gyroscopic sensors. The attached project is for the first STM, arduino sends serial commands to this STM. It cannot be replaced by arduino.