Checking 4 bytes to mark beginning and end of a data packet on incoming bluetooth data

Typical communication stacks follow a design pattern of progressively unwrapping a data sandwich, where each software layer eats only the bread, and passes the contents to the next software layer.

1 Like

That's a great idea to send the byte length. I'm in Japan and would love to support the kanji , hiragana alphabets & chinese characters ... for now i'd be happy with receiving wavesound1.wav,anothersound.wav,arecording.wav, and so on ... in your application , what speed are you sending the bytes over bluetooth ? i'm using 57600bps , do you think that's to fast for appinventor ?

With my data length, I use 9600. Unfortunately, at higher speeds I couldn't control losing my data. At 9600 everything is always stable. The time difference in transmission is not so visible. I also implemented communication via usb. And here it successfully uses the speed of 500kbps.

You can also use another way. My data is mixed up, I am sending everything in one go. In your case, you can do such a trick. Use your first byte to recognize whether you are receiving data or text. If the data then you read it with the block "receive bytes". If text, then use "receive text". At the end of each name, insert byte10 (println). Then the transmission will be easier and faster.

I increased the header to 12 bytes.. 2 for packet start marker and 2 for packet type. 8 bytes data in the packet.

I changed the packet type code for audio meter type to 0x254 and then noticed the meters display the packet type codes as well as coming through to the text file names. see video.

Since the 0x08 packet start codes are also coming through to the audio file names I think they are being drawn in the meter windows. 0x08 is a small number so less noticeable in the audio meters!

There must be something wrong with the way I delete the carrot codes and the packet ID codes.

this solved the packet headers and the packet type ID in the wav file name text BUT not in the meters.

nearly there

Patryk_F I did try change the HC-05 BT module to 9600bps but everything seamed to slow down. not sure why as 9600bps is 9580 bytes more than I need a second!! maybe it effects the speed of the appinventor clocks , not sure yet. thanks for the insert byte10 (println) tip , i'll definitely try it!