From your blocks, i see the need for more reading on your part …
http://www.appinventor.org/bookChapters/chapter21.pdf
http://www.appinventor.org/bookChapters/chapter19.pdf
To help cure you of your habit of dropping lists into text contexts willy nilly,
here is a tiny project to try.
Take a good look at the resulting list.
do you mind explaining in what is happening in the area ringed by green?
I tried to simplify but don’t think i managed to convert the CSV list to bytes list.
I pretty sure I’m not getting the length ringed by red correct. it was reporting number of characters in CSV
This all seams quite complex to find 2 bytes in a buffer and report index position in the array. maybe I’m just not used to looking at blocks yet !
error…
The area you asked me to inspect is in a hacked up copy of a procedure I sent you.
It’s time to discuss packaged procedure etiquette.
I gave you a working general purpose procedure and a test bed for it.
It is equivalent to handing you a circuit board like an Arduino, or a Raspberry Pi.
Such boards have well defined interfaces on their edges, and are not meant to be modified internally. What you did was the equivalent of grind down a Pi’s electrolytic capacitors halfway down, to fit it into a project case. Do you expect the board maker to support that?
I coded the original procedure for a specific use, finding which of several possible packet headers are in a bytestream, and identifying their positions so that they can be traversed in order. You need to know which header (or trailer) is first (lowest index), and where, so you can trim leading garbage bytes, then (for packets needing a trailer) locate the index of the trailer so you can use the indices and header length to isolate the packet body.
The procedure I gave you is fully parameterized, to make it general purpose, like any decent procedure.
Use that concept to go further in your project.
P.S. Study www.json.org as a model for how to send complex data in text packets.
AI2 is fully equipped for that.
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.
2 Likes