Error 513 :Could not decode element 1 as an integer!
Element 1 is "ABCD"
It must be a list of byte elements. Values greater than 255 are converted to 2 bytes and are not accepted. Likewise, byte CRC 7 and byte 8 are associated with element 7 but the value exceeds one byte and returns error 51x. I need a function to extract each byte from a 2-byte argument or cal.BT.send2byte List or cal.
HC-05 is connected to an ARM STM32xxxx that receives commands through the serial interface. Each command must be sent packaged with the structure described to be able to be verified CRC. If I send 4 packets they do not correspond to the protocol and are ignored. On ARM STM32xxx is a complicated project in VSC and platform.io that should not be modified. Another solution would be to put an arduino between HC-05 and ARM STM32xxx to receive generic commands from HC-05 to associate them with values, to pack them and send them to ARM STM32xxx. Obviously I would like to avoid that.
Error 513 is given by AppInventor when it tries to associate "ABCD" the first item in the list with a byte (the type of data that the items in the SendByte.List list must have)
... that is only a requirement because of the code in the script? You could send the values as a CSV ASCII string, 17 bytes. BT packet payload is 20 bytes.
I just got here, but I see something off the top of my head.
You are using sendbytes.
Is there a sendUnsignedBytes block you could use instead?
(Apparently not - ABG)
P.S. There is a nice Do It debugging facility that you can use in the Blocks Editor to see values of blocks at run time. The SendUnsignedBytes block expects a list of decimal values 0-255 each.
You would be surprised to see some of those conversion results.
For example AI2's idea of binary is a text string of 1's and 0's, nice for educational purposes but not good for sending encoded data.
P.P.S. Considering the input ranges (-1000,1000) this will require some bit-diddling to force negative numbers into 16 bits.
Here is a set of value procedures you can use and customize.
The result is a list of decimal values you can send using the BT SendBytes block.
Test procedures are included. math.aia (36.7 KB)
Hello, thank you for your attention to this topic. I need some time to study and test the ones presented here. I want to ask you how I can use the math.aia file in AppInventor? I can attach the code used in arduino that sends correctly data to STM32. I want to replace arduino with a HC-05 bluetooth module for wireless communication. In HC-05 I can't change the code. HC-05 will take the packets from BT and send them on the serial interface to STM, these packets must be similar to those sent by arduino on the serial. P.S. CRC in the sense of checksum arduino send serial.txt (672 Bytes)
The blocks I posted are draggable directly into the blocks editor, all except the screen clips. Or you can find them in my math project and copy them through the back pack.
HC-05 is simply a Bluetooth module for communication of data between devices. The STM32 receives the BT data packets via the HC-05. The STM32 needs a script to define how to receive and interpret the data (and what to do with it, such as trigger an event).
There is also the possibility to change the code in STM32 but then I will have to take into account these changes when I change the firmware versions on STM32. And I don't want that.
There is a small bug in negative numbers (-200 Segment: Start (1) + length (8) -1 exceeds text lenght (4)) Here I tried to modify get8BitsAsDecimal to use at min length (0, length-index) but there are still some issues (negative index, "" not decimal value for length 0)
I built test applications on arduino and compared the 2 Arduino / AppInventor BT streams
Remarks:
A.
On the Arduino
-if Dir / Speed = 0 is sent bit_4 / bit_6 = 0
1010101111001101, 0, 0, 1010101111001101
-if Dir = 30 / Speed = 50
1010101111001101, 11110, 110010, 1010101111100001
-for values 255 bit_3 / bit _5 are 0 and do not need to be sent
1010101111001101, 11111111, 11111111, 1010101111001101
-for values 256 bit_3 / bit _5 are 1
1010101111001101, 100000000, 100000000, 1010101111001101
-for values 511/512
1010101111001101, 111111111, 1000000000, 1010100000110010
On BT
-if Dir / Speed = 0
1010101111001101, 0, 0, 0, 0, 1010101111001101
-for values 255 bit_3 / bit _5 are 0
1010101111001101, 0, 11111111, 0, 11111111, 1010101111001101
B.
There are some differences at bit_7, bit_8
for dir = 200 and speed = 30 arduino calculates checksum
1010101100011011
and the AppInventor application sends via BT
1010101111011
I noticed differences at bit_8
00011011 arduino vs
11011 AppInventor
Conclusions:
In the serial package there is a bit separator. On Arduino it appears every 2 bytes. On BT it appears after every byte.
I filled each bit in the list with a binary value (00101011). If it starts with 0 bits 0 in front are not sent, and when bit_7 is soldered with bit_8 0 is lost in the middle.
For my problem I need Cal.BT.Send2bytes.List otherwise even if I build a dynamic list with separator every 2 bytes I don't have a component to send it to BT (Set.BT.BufferSize, Cal.BT.SendData).
Practically now the problem is unresolved with AppInventor in its current form.
It's 2.10 AM, thank you for your help and I wish you a good night's sleep!
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.