I beleive that FIRST wouldn't like you messing with the basic run LED. They use that as one of the indications that the program is functioning correctly. I would contact them before I start using the Basic Run bit for anything, at least on a competition robot.

While Joe is right on this(check with FIRST before doing anything like this), it seems like I remember hearing of this being done before, with no objections from FIRST...if nothing else, have a switch connected to your OI that would let you switch between a "normal" Basic Run LED, and the value communication mode.

well, think of it this way...

if the LED is toggled on and off in the code, shouldn't we be able to use it how ever we want? if they really wanted to, they could code it in to the master chip, so that only when the pbasic chip ran the code the LED went on/off, but they decided to use the code. so, we should be able to use it for our own purposes.

also, you could aways just use it as an alternator. when out7 (the basic run LED) = 1, the basic byte equals pwm output 1, when out7 = 0, basic byte equals pwm output2. anything like that would work fine, and not interfere with how the LED runs.

i just wish that next year, they gave us more control over what is outputed. could they possibly give us another 'Serout' statement, that sent a stream of no more than 26 bytes out to the dashboard. of course, some would be used, and you can't change that, but if at least a few could be changed...

It's unlikely that we will ever get to send back more data than we're currently able to, even if Innovation First and/or FIRST wanted to give us the ability. This is because the radio modems are transmitting at their maximum data rate (about 9600bps). Thus if it was somehow set up so that you could send another 26 byte packet of your own, you would have to send this packet instead of a normal robot feedback packet. Also, the firmware which runs on the two other processors in the RC and the firmware in the OI would obviously need to change, which means that someone has to write it, and test it, etc. which is very time-consuming.

I just wish FIRST gave us some more control over what was sent back. I'm fine with like, 5 or 6 bytes being taken up by competition important things, but if you only have 1 analog input, why should you have to waste 6 bytes on nothing? same goes for joystick feedbacks. why waste so many bytes on something that many people might never use? i find it a little silly, but oh well. maybe next year... :D

I like what i hear
 

Can anyone point me to the source code of a dashboard viewer that already works? I need to see how the structure is set up before i can program it. A nice VC++ app would be nice. I sort of new to the c++ language, but i am caching on fast, so even uncommented code would be of some help. Thanks

i have what seems to be the actual code from Matt Leese's Firestorm Dashboard. from what i can tell, it's an MFC built with VC++ (an old verison of it, like 4.something). i can't get the source code to run though, cause i don't have all the resource files. i do have the library which grabs the packet though, so if you do need that, i can give it to you.

Actually, the resource files are in there, just not in the right directory. When you unzipped it there should be a folder called "MSDEV". Goto "MSDEV/projects/Firestorm Dashboard" and move the "res" folder into the folder with all the source files. Then you can run it in VC++.

Work My Minions, WORK!
 

Some one should really cobble together some form of how to. I am getting lazy in my old age. What with all this opengl stuff that is being shoved down my naive throat, no more code is fitting anymore.

What would you like a how-to on? I just posted one on serial ports, but would be happy to write another if people would find it useful.

Alright, so there was a call for me above and I hadn't gotten around to answering yet. I was planning on annotating the packet.c file (I started, I swear!) but the whole starting a new job thing has made it rather difficult to get it done. That said, I hopefully will be able to finish that in the near future but I have several other projects I'd also like to work on in my spare time (everyone remember that emulator everyone always wants ;) ).

Anyway, if you'd like to see the dashboard viewer I wrote which is partly written in C and partly written in C++ and runs in Microsoft Windows 95, 98, ME (unfortunately because of a small bug it doesn't run in Windows 2000 or Windows XP; yes I know what the bug is and I may correct it at some point but the dashboard viewer hasn't been of particular interest to me recently; not least of reasons because I don't actually have anything to interface with) it is available at http://www.bcpl.net/~mleese/dashboard.html
I would like to say that this location will be moving after any changes I make (it's an old-dialup account that I have trouble getting access to).

As far as sending data back to the dashboard port, it isn't the easiest thing in the world but, you do get 11-bits and not just a single byte (8 bits). There hasn't been a particular good use that I've seen but that doesn't mean it's not out there.

If you have any questions about the dashboard port or programming in general, feel free to contact me (private message, email, IM, whatever).

Matt

Matt, what type of emulator are you working on? I'm in the middle of one too, and was wondering if you might want to collaborate a bit... anyway, just offering. PM/email/ICQ me if you are interested.

Ian,

A very important part of dashboard port data handling is the implementation of a "state machine" to keep track of where you are in the telemetry data stream. I've placed an example application, written in C, that illustrates the idea here:

http://www.cvhsrobotics.org/resources.htm

Look for dashbd.c and dashbd.h. If you have questions, feel free to fire-off an e-mail in my direction.

Kevin

the way that you read in data, is it byte by byte? from what i could tell, it seems that way, but i wasn't sure. which way is better, this way, or to read in entire packets at once? there's way to many ways to do this :p.

Ian,

Yes, this example assumes that data is read from the computer's UART one byte at a time. From a software standpoint, this is the easiest case to deal with. If your computer's UART has a FIFO buffer on the output, and you get packets larger than one byte, the code (state machine) gets just a little more complicated.

Kevin