Pixy2 serial protocol

Alright, let’s dive into the world of serial protocols! Before we get started, just a heads-up—this discussion assumes you’re already familiar with some interface details from earlier sessions.
First off, we’ll take a closer look at the various serial protocols, particularly focusing on the request packet structure.
It’s made up of four crucial bytes.
The first two are fixed at A2 and C1 in hexadecimal, while the third byte represents the version, fixed at 2 in hexadecimal (which is 14 in decimal).
Once we send out a request, we get a response back from Pixy, starting with the first two bytes AF and C1, then we see the response type byte F, and finishing up with checksum bytes that help ensure our data’s integrity..

Let’s break down firmware data a bit.
First off, the first two bytes are all about the hardware version.
Next up, you’ve got two bytes that tell you the firmware version, followed by another two that indicate the firmware build number.
Pretty neat, right? This firmware info is in ASCII format, so it’s super easy to convert it into a string.
When you send a request, the first two bytes are fixed, and a type decimal value of 10 lets you know there’s a data length of one.
This means you can use any value or even a zero as a placeholder until the manufacturer rolls out future updates.
After you send five bytes, expect a response with a type decimal value of 13 and a data length of four, plus don’t forget to check that checksum for accuracy!.

So, let’s talk about some cool technical specs! First up, we’ve got the checksum , which gets a quick mention, and the frame width and height can actually stretch from 0 to 510.
When it comes to camera brightness, the type is designated as 17 in decimal, and you’re able to set it anywhere between 0 and 250.
Just a heads up, the response you’ll get shows if your adjustment was a success or failure, and it’s sent back as four bytes.
On the servo motor side of things, the type for control is 18, and just like the camera, you can set the angles for the fan and tilt servos from 0 to 510.
And remember, when you send a request, the response will also be of type one, totaling four bytes for the result check!.

When diving into LED control protocols, there are a few key things to get straight.
First off, if you’re working with type 20, you’ll want to stick with a data length of three—yeah, that’s hex value 14, not four like some might have thought.
Also, RGB values? Those should be entered anywhere from 0 to 255, and once again, we’re talking a data length of three, not four.
Now, when you’re requesting responses, just remember that type one and a 32-bit result value use four bytes to confirm whether things went smoothly or not.
Lastly, for lighting control, type 16 shows up as 22 in hexadecimal and has a data length of two, which clears up the earlier mix-up about it being four..

Controlling those white LEDs above your Pixy is super easy! Just remember, if you want them off, you use ‘zero’, and if you want them on, you use ‘one’.
For the RGB LEDs at the bottom, it’s the same deal—‘one’ turns them all on, and ‘zero’ turns them all off.
Just keep in mind that the data length here is ‘two’, so you’ll input ‘two’ for that.
When you send the command, the lighting control will respond with a type of ‘one’ and a data length of ‘four’, which is sent as a 32-bit value for verification.
And if you’re curious about the FPS, just shoot over ‘24’ in decimal or ‘18’ in hex, with a data length of ‘zero’!.

Let’s dive into the basics of response types and requests! So, the current response type is noted as response type one , which comes with a data length of four bytes.
For all the gamers out there, the FPS is sent as a 32-bit value , making it super easy to keep an eye on performance.
When you want to request block information, you simply use the command in HEX, which is 32 —that equals decimal 50 .
The data length for this request is just two bytes, and you can throw in a signature to specify the mode you want.
For example, a signature of zero means you’re operating in no mode, while using a value of 255 lets you set modes, like adjusting all blocks to 255.
This setup is pretty flexible, allowing you to retrieve all the blocks whenever you need!.

Hey there! Let’s dive into the block information response.
This type is tagged as 33 in decimal and 21 in hexadecimal, with a data length of 14 .
You can simply enter 14 as a hex value, which makes things a bit easier.
Just after that, we’ve got the checksum, which comes right after those first two bytes, showing the signature.
The following byte tells us the x-coordinate of the block center, while the next two bytes are all about the y-coordinate.
Not to forget, we have two bytes indicating the block’s width based on a 16-bit standard , and finally, two more bytes that show the block’s height..

Understanding color code angles can be a bit tricky, but let’s break it down.
If a value isn’t a color code, it just shows zero.
On the flip side, if it is a color code, it actually gives you the current angle of that code! To really get a grip on whether the angle is between -180 and 180 or if it’s not a color code at all, you’ll need to convert that value to a signed 16-bit number.
There’s also some mention of the index and block index value, which helps show how long a specific block has been exposed.
The video touches on line tracking protocol and RGB value retrieval too, but we won’t dive into that since there’s no hardware demo to showcase it.
If you’re curious for more, definitely check out the links provided!.