dashboard protocol

[sciguy125]

I'm working on a dashboard program and I need some more info about the protocol (the documentation isn't very detailed and I don't have access to the controller right now).

The data sent out the Dashboard port is a stream of bytes. There are 26 bytes in a packet. The packets are transmitted approximately 40 times per second.

I got the part about 26 bytes in a packet. However, it takes 3 packets to get all the data. So, how many packets are sent each loop (main program loop)? Is it just one packet at a time, or all 3? The reason I ask is that I want to encode some extra data into the user bytes, but I need more than the 6 byes available. My plan is to send some of the data the first time around, then the rest of it in another packet (or set of packets).

The firmware in the Robot Controller (2004 or later) interlaces data packets.

Is this the to answer my above question (sending one packet at a time) or does it mean that the packets don't come in order?

Lastly, the documentation keeps refering to specific bits within certain bytes. But is bit 0 the LSB or the MSB?

Edit: One more thing: there's a byte called USER CMD, but I couldn't figure out what it is. Is it an extra "user byte" that I can play with, or does it actually do something important?

[Rickertsen2]

If this is not something you will be using during competition you might consider getting an RS-232<->802.11 converter and connecting it to the program port. Its alot simpler, higher bandwidthm, and has the advantage of being bi-directional. There is a good chance you will be able to upload programs remotely.

[Pat Fairbank]

The controller only sends one packet every program loop, which means you only get all three roughly 13 times a second.

The interlacing means that although each packet is received the same way, the data it contains could be that of any of the three data frames described. The only way to figure out which information the packet contains is to read the control bytes.

Lastly, bit 7 is the MSB and bit 0 is the LSB.

Hope that answers your questions.

[sciguy125]

Is there any way for the code on the RC to know what data frame is about to go out? I was just rumaging through the code, but I couldn't find anything. It seems that the functions that handle the radio communications are distributed in binary form. Knowing what paricular frame is going out would make it easier to write the complementary RC code and also free up 2 more bytes to send data.

[Pat Fairbank]

Nope, there's no way to tell what frame is being sent, since it's a function of the master microprocessor, not the user.

However, you might have noticed that all 16 PWM outputs are also sent out the dashboard, so if haven't got any Victors hooked up to some of those, you can use them to pass extra bytes.

If you need even more bandwidth, you could probably set up some interlacing of your own (e.g. use one of the user bytes to describe what data is in the other five).

[Greg Marra]

My brother was working on some Dashboard code last year, but it being his first forray into the world of programming, he didn't meet much success. He ran into the problem of deciphering which data packet was the A, B, and C packets and couldn't figure it out in time for the season.

[Billfred]

Originally Posted by Pat Fairbank

Nope, there's no way to tell what frame is being sent

Not quite.

Look at http://www.innovationfirst.com/FIRST...2004-01-07.pdf at the data frames. CTRL_A and CTRL_C both have information in them that differentiates the frames.

(Now, how do you read that and get something useful from it? I'm not entirely sure...I'm no programmer.)

[Pat Fairbank]

Originally Posted by Billfred

Not quite.

Look at http://www.innovationfirst.com/FIRST...2004-01-07.pdf at the data frames. CTRL_A and CTRL_C both have information in them that differentiates the frames.

(Now, how do you read that and get something useful from it? I'm not entirely sure...I'm no programmer.)

Sorry for the confusion, Billfred - I meant that you can't tell which frame is being sent from the RC code (the sending side), but you're right in that you can tell which one it is on the receiving side by looking at CTRL_A and CTRL_C.

[Billfred]

Originally Posted by Pat Fairbank

Sorry for the confusion, Billfred - I meant that you can't tell which frame is being sent from the RC code (the sending side), but you're right in that you can tell which one it is on the receiving side by looking at CTRL_A and CTRL_C.

Ah. Confusion abated.

[sciguy125]

Originally Posted by Pat Fairbank

If you need even more bandwidth, you could probably set up some interlacing of your own (e.g. use one of the user bytes to describe what data is in the other five).

That's what I was planning LED Byte 2 has 5 unused bits. That gives me 6 bytes, and 5 bits to describe what they are. I'm trying to stay away from the PWMs because I want it to be as modular as possible. My goal is to just get all the ports through the dashboard interface then figure out how to interpret that information in my dashboard program. So far, I've figured that 6 bytes can get me all of the digital ports and the relay ports. I'm still trying to decide on how to handle the analog ports because each of the 16 would take a full byte. Does anyone know of any interesting encoding/compression algorithms?

Originally Posted by Billfred

CTRL_A and CTRL_C both have information in them that differentiates the frames.

Well, that only gives me the information on my dashboard program. It doesn't tell me which packet is being sent during this given program loop on the RC, so that I can encode the correct data into the packet. As far as I can tell, they accessible to the user on the RC. EDIT: Oops, they are NOT accessible to the user on the RC.