Since you're not dealing with character data, I don't think that discussing the StringBuilder class is really useful here. I admit I haven't used it a lot, but I suspect it is not real useful for dealing with collecting and decoding the numeric bytes and discrete bits necessary when dealing with a hardware interface protocol.
Since the hardware will most likely be already transmitting when you start your application, you may start receiving data in the middle of the stream (as your dump indicates), and data can be corrupted, so you pretty much have to continually verify that you are sync'd to the packets and have verified they are complete and correct before processing them. If a check fails, you ignore that packet and move on to the next.
This is especially important since your SOF value AA, could appear in the data payload as well as your EOF value of AB, so you can't just assume that because you found an AA and an AB, that they do frame a valid packet.
The task of dealing with a serial stream of interface packets like this I usually divided into at least two parts (but more likely into several parts to handle decoding the packets at various levels of detail, i.e. a task to receive and buffer the incoming stream, a task to identify, verify and perhaps extract a complete packet, a task to parse the given packet, and a task to process the parse data and act on it).
But, at the highest level, the two parts would be:
1. Buffer the incoming data, identify and verify a proper packet structure, and
2. call a parser to process the packet.
Once you get in sync with the packet traffic, there is the chance that there may be sufficient time between messages that you can safely clear a buffer and start receiving a new packet at the beginning of a new packet, but usually this is not something to count on when dealing with a serial interface. My preference is to use a ring buffer so that the receiver is adding bytes to the buffer, and the packet processor is removing bytes from the buffer in a simple to implement cycle, rather than using multiple buffers to copy and shuffle bytes around.
Since your dump is showing an extra four (unidentified at this point) bytes between packets that you'll probably ignore at this point, is all the more reason to find and verify the packets that you are interested in and ignore the rest.
Given what you have, you should do the following to identify and verify you have a properly formatted packet.
1. Find the AA byte. (Note what offset in your buffer you find the AA)
2. Verify you have at least 5 bytes after the AA (the shortest packet you can have would be 6 bytes, including the SOF and EOF. If you don't have at least five bytes after the AA, you can't possibly have a full packet so it is a waste to verify anything now, leave a "pointer", i.e. index pointing to your AA, and when you receive more data, start again from 1 (your code will find the AA at the first byte pointed to)
3. You have enough bytes, so read the fifth byte (fourth after the AA) to get the length of the packet. Add that number to your pointer and if you have enough bytes in your buffer, read the byte from that location. If you don't have enough bytes in the buffer, just leave and try again after you've received more data.
4. The byte read in step 3 (AA + len) should be your EOF byte AB. If it is not, then this is not a proper frame. Increment the pointer pointing to the AA byte to advance to the next byte and start at step 1, searching for the next AA byte in your buffer.
5. Once you've found the AA byte, and the AB byte at the proper offset specified in the packet, then if this packet has a checksum byte (determined from the packet ID), you can loop through bytes generate the checksum and compare it to the one from the packet. If they agree you can process the packet, otherwise increment you pointer and start searching again.
Now since whether there is a checksum or not depends on the packet ID, you may not want to have that information at this level of the process, i.e. you want the packet finder/verifier to know about SOF, EOF, and where to find the length of the packet, but not have to know the details of which packet formats have checksums, and which don't.
You may just want to send the "packet" as verified by SOF,EOF and length to a routine that handles processing the packet id, and selecting the decoding processor. That task can do the checksum calculation and choose to process the packet (checksum matches), or drop it.
I edited your post above to separate the stream into sections, mostly so we don't have a tremendously long line to make the web page harder to deal with, but also it kind of represents what you will need to do in code, and that is to identify the packets in the stream.
Since you printed the values in hex, we can fairly easily hand decode a packet to see what it is. The process used to hand decode the packet should give you insight into what you need your code to do to parse the packet.
Code:
&H7F &H0F
&HAA SOF (Start of Frame)
&HD8 Destination ID: 8 (General Broadcast)
&HEA Originator ID: 10 (Valentine One with checksums)
&H31 Packet Identifier: 0x31 (InfDisplayData) "all the information needed to rebuild thr front panel display. plus status bytes"
&H09 Payload Length: 9 bytes
&H00 Bogey Counter Image 1 : bits to drive 7 segement display
&H00 Bogey Counter Image 2 : bits to drive 7 segement display
&H00 Signal Strength Bar : bits drive 8 block bar graph
&H00 Band and Arrow Image 1: bits represent discretes to drive various indicators
&H00 Band and Arrow Image 2: same bit definition as image1
&H0A Aux0 : 0X0A decoded bits: Display On, TS Holdoff
&H00 Aux1 : Reserved for futurer use
&H00 Aux2 : Reserved for futurer use
&HB0 Checksum
&HAB EOF
&H1A &H7F &H7F &H0F
&HAA &HD8 &HEA &H31 &H09 &H00 &H00 &H00 &H00 &H00 &H0A &H00 &H00 &HB0 &HAB
&H1A &H7F &H7F &H0F
'.....
' Here you see the two 7 segment display drivers
' now have the value 0x73 in them. If 7 segment drive bits are fairly standard
' then I would interpret the display to be like "PP", see attached png file.
&HAA &HD8 &HEA &H31 &H09 &H73 &H73 &H00 &H00 &H00 &H0A &H00 &H00 &H96 &HAB
The bits from 0 to 7 represent segments A - G and dp
'0X73 = 01110011 binary
' dGFEDCBA segments
' p
Serial port (com port) reading data
Linear Mode
