If you are asking for help, I recommend you to make it as easy for others to be able to help you …
You probably will get more feedback then…
which means in your case post a screenshot of your relevant blocks…
To download the aia file, upload it to App Inventor, open it, do some bug hunting for you, etc… this takes time, and most people will not do that…
Thank you.
Yes agreed, I’m limited to one attachment per post as a new user so forgot to do that.
Can you see anything wrong with the way I’m passing the bytes list ‘packet’ to the TO-RESULT ‘bytes_to_text’ block ? the byte values are ASCII and start with I’d like to just convert them and print them in the app. later I’ll need to split them at ‘|’ into an index-able list.
Also , I’m trying to find a simple way to look for 2 x incoming bytes as a packet header ( id ) I would prefer 3 or 4 byte header to be sure there isn’t by coincidence 2 values the same in the data stream. possible.
My hardware just has one UART IO stream of data ( no BT TCP/IP stack etc ) Its just an HC-06 connected to other hardware.
No, except you could have skipped creating that extra value procedure getAscii and just fed the guts of that procedure into the place you call it. That would have the readability benefit of showing where the Ascii text is coming from.
stream of 8 bytes of audio meter values with 2 bytes 0x08,0x08 header
press button and ascii byte values of 8 bytes with 2 bytes header of 0x07,0x07 header
I’m not sure about how I’m testing getHeaderStart != 0
does a TO-RESULT block return 0 if it has nothing ?
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.
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.
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 !
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!
Taifun.
representations of the byte lists, which I hope you have learned by now.
