<< return to Pixycam.com

Reading from serial stream, sometimes offset by a byte?

Pixy Software
#1

We are reading the serial stream with I2C. We’ve got the serial protocol figured out and have been able to decode the object data, most of the time. But sometimes it seems like the bytes in the data stream are offset by a byte. We could deal with it, if they were offset to the right. Then we could just skip the first byte. But it’s the other way around. It looks like the first byte we read is the sync word, but truncated.

For example, in a correct stream, we see the following:

0xaa55,0xaa55,checksum,signature, etc

But instead we see

0x55aa,0x55-then first byte of checksum

Yes we know about the little-endian-ness and are reading that correctly.

Any suggestions?

#2

Hello Brian,
Since the object data is 16-bit aligned, it’s possible to get off by 1 byte. To deal with this, you’ll need to detect (for example by reading a 0x55aa instead of a 0xaa55) and then read an odd byte. You will then be re-aligned. You should then be be able to read the correct sync word.

Hope this helps!

Edward

#3

Hi Edward,

Thanks for responding. I thought of doing that, reading the odd byte if I detect we’re off by 1 byte, or if we read 0x55aa. But then I was worried that I would be missing the first sync word, and then I wouldn’t know if I was at the beginning of a frame, or just the next object in a frame I’m already processing. Does that make sense?

Also, how do you determine how many bytes you should read at a time? Last year we were only looking for one object, so we were reading 32 bytes. There was only one object there, 16 bytes, so the rest were 0s. We’ve been trying to update it to be able to read 2 objects this time. We’ve tried reading 32, 64, and 128 bytes in different runs. For some reason, when we read 128 bytes, it was coming back all zeros.

When we read 64 bytes, we thought it was working for awhile, but then we ran into this offset problem. After more testing tonight, I think that was because we were reading into the next frame, located in the latter part of those 64 bytes, after reading our first frame in the first part of the 64 bytes.

We eventually got it to work, meaning not getting those offset bytes in later reads, by reading 30 bytes. I guess because this is the size of a frame with 2 objects?

I’m glad we got that to work, but it does seem inflexible, in that it seems like you need to know how many objects you are expecting to see, in order to know how many bytes to read to keep the byte stream aligned in subsequent reads. We were trying to design a system that would work when you don’t know how many objects you’re going to see.

It seems like to do that, you’d have to read 64 bytes, for example, process 1 frame, and if you see a partial 2nd frame, you have to store that, read another 64 bytes, piece those pieces of the frame together, etc. I guess I was thinking of a single read per frame.

Sorry if that got to rambling. Kinda brain dumping, we did a lot of testing earlier tonight. I’m mentoring a first robotics team for the first time. I wasn’t there when they got the pixy processing working last year, but we’re working from that code, trying to improve it to read 2 (or more) objects.

#4

Hmmm,
The Arduino code might help:

In general, 2 bytes are read at a time, unless it detects an out-of-sync condition, then it reads a bytes to get re-sync’ed. If you read 2 bytes at a time you don’t make any assumptions about how many objects have been detected.

Is there a performance reason you want to read more bytes?

Edward