I would like to look for an array of bytes that is an acknowledgement packet and if seen at the beginning of the data I want to discard it and immediately use the data that comes after it.I was thinking that stream.findUntil(target, terminal) might be a method to initially look for it. I belive byte discard is the proper method to dispose of it but I didn't find a-lot of info on how to use it. How would I indicate the number of bytes and where they are to discard.
Example: This data is read, I want to discard the portion in RED and then use the rest.
24 01 80 F3 98 03 24 06 81 2E 05 05 95 95 59 66 03
You need to read and store those bytes in an array, so that you can compare the array with a standard response array. If they match, then what? Why is starting, then, to store data in a (different or reinitialized) array a problem?
OK, I think see what you are getting at. I guess I was thinking somewhat along that same line. Store it in an array then discard or dead end it and do nothing with that data right?
It's a pain in the ass because most all of the data plays nice but for some reason there is this one packet that for some reason it prefixes with an ACK packet. Because of that it throws all the offsets off that I'm pointing to so I have to make a duplicate loop and set of pointers and operations for that packet to handle it when it's encountered. Keeping all the data perfectly justified by all interesting packets starting at offset 0x00 it would make things much easier, if that makes any sense as to why I'm wanting to do this.
One more quick question and I think my project will be done. Thanks for all of your help. Without it I wouldn't have been anywhere near this far.
The last hurdle is the scan channel indicator. Normally all data is sent as ASCII equivalent in hex so is directly displayed properly when printed to the lcd directly. However, the channel scan is sent as 0x01 for channel one and 0x02 for ch 2 etc... instead of 0x31, 0x32 etc... I know this should be a simple task but for some reason I can't seem to get it to display properly. I have tried the various format extensions such as DEC etc...
For a single digit you can just add 0x30 to get an ASCII character ‘0’ thru ‘9’.
Thanks I will try that.
What do you think about something like this then?
ale = buffer;
Yep, that worked for the single digit as you said, thanks. Just trying now to get the double digits going.
Top hex digit is (0xnn >> 4)
Lower hex digit is (0xnn & 0xF)
Once you have the number as above you can display it as decimal (0-15) or hex (0-F) in the print() statement.
I'm working with data that streams in and changes at a certain spot in the buffer. That's what has me confused. I'ts not static.
I am sure that you know this, but you must have certain points in the data that you know where you are. Most protocols have a start and a stop indicator in the packet (or a start and a a length). What is the protocol definition (ie, what does the documentation say you should be getting?)
Also your example ale+0x30 - does that even compile?
if (buffer == 0x07 && buffer == 0x0D)
ale = buffer;
chan = (ale + 0x30);
Yes, it works up to 9 as you stated.
What this code does is point to offsets in an array named buffer that is filled from a loop that pulls from the serial read when the radio transmits a data packet to the Arduino. I flag for start of line 0x24 and know the max packet length will not exceed 34 bytes. When this certain data packet with that 07 and 0D in those spaces is seen I know it's what is called an ALE scan packet. Each time the radio changes to the next channel that data at offset  in the buffer is the only thing that changes. It increments from 0x00 to 0xC8 to represent the channel 0 through 200 that it's on. I am wanting to zero in on just that data and display it on that spot on the LCD.
When I exit that mode (say I go to free tuning mode) the op codes and other data in the incoming data packets change and this IF statement is no longer valid. Another similar IF statement below flags for their corresponding "identificatin", for lack of better term, bytes then it processes and displays interesting data from those packets, etc... and so forth. It's all working and all other packets are already formatted as ASCII but for whatever reason that one above ( the ALE scan) I initially mentioned is presenting the channel data as raw hex.
I hope that makes a bit more sense.
Yes, makes more sense.
As you only have 3 digits to worry about this is how you extract the:
- Highest digit (hundreds) is ale/100
- Middle digit (tens) is (ale/10)%10
- Lowest digit (units) is ale%10
Addiing 0x30 will convert to ascii character