Ah ok, apologies for braking your well made procedure!
I’ll try to send in the bytesList leaving your procedure to apply ‘list to csv row’ and find the 2 header bytes / dump bytes preceding them
I’ll post the end solution if I get it working here.
yes , grinding down those caps to fit the pcb in the box
was a bit brutal , all the electrons fell out 
now 0x08 , 0x08 is packet arrived marker , the 3rd byte is either 0x01 or 0x02 which labels the packet either audio meter values or file name bytes in ascii hex code.
For some reason I still cannot display the text from ascii hex code.
Which device are you sending this data from? Is the data always the same length? Is the data sent cyclically, automatically from the device? Or maybe on demand?
it's my own design based around stm32h7 micro. It's a multichannel audio mixer recorder.
The app requests the bytes that are ascii values that represent text ( recorded audio file names ) each file name is comma separated.
The device repeatedly streams out audio levels ( 8 bytes in the packer , 1 byte per audio channel level ) unless the app requests the bytes for file names.
There are 11 bytes in total in a packet.
2 x 0x08 byte packet begin marker
1 x 0x00 or 0x01 byte to determine what the packet is for.
so a 3 byte header I suppose you could call it.
The bluetooth receive part in the app is being triggered by a clock set to 30 in appinventor.. 30ms? I'm not sure..
when looking at the file browser screen there is no need for audio levels but no audio packets are sent while the device sends the audio file name ascii byte code. those packets are the same length , 11 bytes.
I was hoping to load the file names into a list picker so the user can select a file and play it on the device. I would only need to send back the list ID number for the device to know which file to play.
I don't as of yet have an end of filenames byte sent in the last header. I'll do that if I can get the text converted and separated out from the commas
I think i'm doing something wrong with the chr function , asci code -> text ? maybe the chr function needs to return to a string ? or is list ok ?
The audio level data is working well and staying in sync before and after going into the audio file menu.
so the packets seam to align correctly.
OK, no , I think I see the problem.
I'm using the dataByte 'create empty list' so the meters work.
If I take that away the app slows down can't process the incoming bytes fast enough because the clock is set to 30 ( 30ms? )
either way the bytes values in the packet are't what i'm sending. there are many null byte values , so it seams like the meter values are getting through somehow.
I slow down the meter values being sent right down and see if that stops the buffer filling up.
basically the only reason the meter values are working is because i am throwing away tons of byte packets !
ok, yes , I printed out size of dataByte in the audio meters function and it gets to 30,000 bytes in seconds!!
mmm the 'remove list item' doesn't appear to get rid of the bytes quick enough because of the clock timer.
Don't mess with the chr function. It's a violation of the KISS principle.
If you want to be selective in use of the chr() function, wrap the call chr() block(s) with whatever test(s) you want.
Your for each loop was already giving you each ascii_value byte one at a time to be converted and JOINed into the cumulative global variable (which you will have to find a place to clear at run time.) Using them as indices into the packet makes no sense.
I slowed down the packets right down from the device so that the dataByte list doesn't keep growing
in size. There seams to be to many bytes coming into the getWavNamePackets function and when I call chr with the byte directly I get the error screen in the photo. I'll get the device to just send one 8 byte word today and see what happens.
I will keep other ideas outside of chr function call and stick to the KISS protocol!
It's time you renamed the dataByte global variable to dataByteList, to avoid confusing the entire list with any individual item from that list.
The chr function is built to accept only a single byte value, not an entire list.
Go and read the article How to Work With Lists at
I called it bufferBytesBt now so I don't make the same mistake again !
I slowed the audio meter bytes right down and I disable them before the filename packets are sent.
I am getting the 0x08 0x08 0x254 packet header in the displayed text although I think I am deleting them before calling getWavNamePackets. just tried increasing the timer to 5ms but the same. will try 1ms !
Relying on a fixed length file name sounds presumptious.
Maybe send a hex 00 after the file name, like in C strings, or \n to mark end of text?
The file names are comma separated ( not fixed length filenames , only fixed length packet size )
I was thinking of splitting the file names ( and removing the comma ) in app Inventor. I would place the file names into a list picker. I only need to send back the index number of the file to play the correct file on the device.
If I can get rid of those packet header bytes showing up in the file name byte packets it should work ok. just cannot think how they get there right now!
I can send spaces in the last packet so the data aligns properly although the packet scan for 0x08 0x08 and should align the packet for when the audio meter packets start again.
My device also sends data and text together. I don't use a text receiver, I get everything as bytes. That's why I made an extension to convert data to text. The table you are using works for ascii characters, so English will be ok. There are a lot of ascii characters in my language, so I had to implement utf8. For me it looks like this, that before sending the data, the data type byte is sent first, then the data length in bytes. Then I know how much data to receive.
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.
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!
