How to send a 4 x int16_t structure on bluetooth

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.


BT.SendByte num_of_bytes (specific to serial transmission)

... That's why the values have to be encoded.

Indeed they are. What is preventing the receipt of each value in a separate packet? Are you programming it with the Arduino IDE?

Also, why is the target 8 bytes?

567 / 5.000

Rezultatele traducerii

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.

Hi ABG

Is it possible to send the values as JSON (including check sum)?

Why shouldn't it be modified? Can you up load it here?

The checksum is the hard part.
Reviewing my binary ...

We will have to get down and binary for this.

Here is my first step, working from the bottom up ...


bin16_test

More to come...

1 Like

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)
ByteListTest



bin16_test

I notice you mentioned both xor and CRC in your posts.
Please note that they are different.

Let us know how this works for you?

1 Like

Text sursă

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.

1 Like

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.

The solution is almost good.

  1. 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)
  2. 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:
  3. In the serial package there is a bit separator. On Arduino it appears every 2 bytes. On BT it appears after every byte.
  4. 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!
1 Like

Two possible solutions

  1. An extension that adds BluetoothClient Send2ByteNumber List
  2. Send the encoded data as a string (requiring an edit of the STM32 script)
  1. 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.
  2. The code on STM is open source can be modified but will create incompatibilities with future versions that are not created by me.
  3. 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