Dashboard Port Decoder
 

Hello!

I am new to Cheif Delphi, and am a sophomore in high school, so please bear with me if I sound like a fool :D.

I am looking to design a control unit to attach to the operator controler that can interpret data from the robot and display it on 7-segment displays. At first I was thinking of using a CPLD, but when I realized that the signal is asyncronus and that there are multiple bytes of data, I quickly eliminated that option alone. I am thinking more along the lines of a microprocessor that could decode the information coming from the Dashboard port. Maybe it could take that data and decode it to a usable form to send to a CPLD which could drive many 7-segment displays. I'm not quite sure how to get a microprocessor to decode the data. I have been working with CPLDs for a while now, and I can code them and use them, so I'm not quite sure how different microprocessors are. If anyone has any suggestions about ideas or methods or have links to pages on tutorials for microprocessors or to purchase parts or just about anything that could help me, that would be great. Again, I am just getting started with microprocessors, so bear with me while I learn the new system.

New Cheif Delphi member,
Jacob Komar

--

-There are 10 types of people in this world; Those who understand binary, and those who don't.

Re: Dashboard Port Decoder
 

If your team has any leftover PBASIC robot controllers, it would be pretty simple to program one of them to interpret the datastream. Couple that with a couple of discrete multiplexing LED driver chips, and you'd be in business!

Just a thought... :)

Re: Dashboard Port Decoder
 

if you dont have any pbasic chips and have to get new one might I suguest the Z8 from zilog . . its only $40 for a dev kit(chip + board + C compiler)

Re: Dashboard Port Decoder
 

Thats a great idea. How would I convert the data stream from the dashboard port to something usable in PBASIC? We have some of those old robot controllers, but they couldn't be directly compatible with today's data stream. The LED chip drivers would be easy to obtain, so that wouldn't be a problem.

Again, Thanks for the Idea,

Jacob Komar

--

-There are 10 types of people in this world; Those who understand binary, and those who don't.

Re: Dashboard Port Decoder
 

My PBASIC is a little rusty, but isn't there a SERIN command?
It should be a simple matter of parsing the datastream for the flag bytes (255,255), and then loading the packet bytes into a buffer.

The dashboard datastream isn't anything special, just a bunch of characters sent at 19200 baud.
See the specification here: http://robotics.dyndns.org/DATASHEET...BOARD_SPEC.pdf

Hope this helps!

Re: Dashboard Port Decoder
 

We're actually toying with the idea of using the LabVIEW Dashboard reader on a Laptop during competition - that way we can have our secondary drivers look at the screen for updated information about what's happening on the robot. We can also record the activity of the robot during the competition match and replay the match once we get back to the pits to determine areas we need to tweak on the robot. We're also toying with using an additional serial port to have LabVIEW output a signal to a 7-segment display that will always be in the driver's vision (so he/she doesn't have to look away).

-Danny

Re: Dashboard Port Decoder
 

I think that using the SERIN command would work. What is the deal?; In the new dashboard specifications, it shows three different pages for serial in from the RC. There are control bits. How does this work and how could you get PBASIC to compensate?

Jacob Komar

Re: Dashboard Port Decoder
 

There are actually 3 different types of data frames that come from the RC, and you're guaranteed to get all 3 of them before repeating (i.e. no 2 frames of the same type will come in back-to-back). From looking at old source code provided by teams, it looked as if the old systems only had one RC data frame. :confused: The control bits will tell you which data frame it is (check out the data frame control bits in the documentation) and as long as the control bits change from frame to frame you know you're dealing with RC frames. If the frame control bits do not change, you know you're dealing with OI frames (selectable based on the jumper on the OI). So what you will need to do is have your code read the data frames, look at the control bits, and if they're the right control bits then pick off the byte(s) you want to be viewing.

-Danny

Re: Dashboard Port Decoder
 

How could you get PBASIC to look at the control bits? Would it be able to look at them fast enough to check and then comprehend the data? If anyone has specifics (i.e. code) that could help me, that would be great.

Update on the project:
I am going to use the output of the PBASIC computer and connect it to a CPLD to decipher the code and send the output to the 7-segment displays.

Jacob Komar

Re: Dashboard Port Decoder
 

I don't know that you will be able to use one of the old pbasic controllers without it's associated OI and radio modem. Unlike the current controller it does not have any general purpose IO lines that can be used for what you need. I think your idea of a microcontroller and a cpld to drive the LEDs is a good idea and will teach you alot about microcontrollers.

the SERIN command is exactly what you need.


I'm not sure whether or not it would be legal, but you could attach to the LED outs and use them to transmit parallel data. You would have to use one pin as a double edge triggered(rising and falling) clock. You would probably have to interleave data, so you would also need a start of packet signal line. The rest of the line could be used for data. I drew out a schematic one time. I will see if i can find it. Its probably gone. This would likely have too low of a data rate to be useful and has no advantages over reading the dashboard serial stream other than novelty.

I can't find the dashboard protocol spec anywhere on the IFI website anymore.

Re: Dashboard Port Decoder
 

I think that a PBASIC controller might work without an operator interface because you are using the data from the dashboard port AS an operator interface. You can use the SERIN command to assign each byte to a variable. You could then have a simple IF/THEN statement to check which packet it is, and then send bytes to an encoder to send a 16 bit binary number out of the 16 I/O ports. From the I/O ports, you could hook a CPLD to transate the encoded nibble into 7seg displays and the likes. Do you see any major flaws in my plan?

Thank you,

Jacob Komar

Re: Dashboard Port Decoder
 

I fogot to mention,

If you go to IFIs website and click on Dashboard Viewer, you can download the ZIP file with the Viewer. Inside that ZIP file is a PDF with the packet specifications. From there you can see that you can write an IF/THEN statement to check to see which control bits are enabled.


Jacob Komar

Re: Dashboard Port Decoder
 

Unfortunately the "I/O" ports on the pbasic rc are not actually IO. They are input only. :( . The only outputs available are the serial port itself, relay outputs and PWM outputs. The relay and pwm outputs are proxied through the master processor and are only enabled if the RC is linked to a real OI. Also, just sending the data from the dashboard port to the serial port on the pbasic RC would not work :(

If you have one of the PIC based edu-RCs, they have general purpose IO, a serial port and don't require an OI at all. I think one of those would be a better option than a pbasic rc (although the pbasic RC would be alot easier to program).

Just to be clear, i am talking about this one: http://www.ifirobotics.com/edu-rc.shtml

Re: Dashboard Port Decoder
 

An EDU-BOT RC is a great Idea. Our team has an older one, I'm not quite sure what it could do (Maybe PBASIC!) Before I completely scrap the 2003 FRC idea, I have a couple of questions. Could you set the FRC into autonumous mode so that it wouldn't need the OI? What would it take to get the FRC to interface with the Dashboard port? How would you get the EDU-BOT RC to interface with the Dashboard port? Is there any way of getting the Digital Inputs to become outputs on the FRC (I mean, they are just I/O pins on the chip, right?) I'm up for anything at this point, so any help would be greatly appreciated.

Thank you,
Jacob Komar

Revised Comments:
We have the Issac16 Edu-bot RC controller, which is programmed in PBASIC. This is perfect for what we are looking to do, because we can use the tether/program port as an input, and use the relay/pwm output ports as outputs. Does anyone have an opinon on this? The information on the controller can be found in IFIs website under legacy docs.

JK

Re: Dashboard Port Decoder
 

There are two version of the EDU controller. One is based around a BASIC stamp, has an internal radio modem and requires an OI. The current version of the EDU is based off of a PIC, programmed in C and does not need an OI. It can operate completely on its own.

Even in auton mode, the old (PBASIC) RCs need an oi. :( There is really no(practical) way i can think of to get around needing an OI on the old style FRC.

In both cases, you need to build a serial crossover cable. By this i mean a cable with the transmit pin of one end of the cable connected to the receive pin of the other end and vice versa. Occasionally i have seen these on sale in computer stores labeled "null modem cables". I have also sometimes seen null modem adapters which you affix to one end of a normal serial cable. you can easily take a standard serial cable and reverse the two wires. Besides ground, the only two wires that are used in our case are receive and transmit.

Not so easily. The inputs are actually connected to another microcontroller called the "master processor" You have no control over this chip. The master proc communicates what it seas on these inputs through another serial link inside the controller to the "user processor" (the one you program).

On the new EDU controller as well as the new (2004 and up) full size RC, the IO pins are directly connected to the user processor and can be used however you want to use them.

If you do not have a new style EDU, you could use a new(2004 and up) full size RC. Without an OI, you will get scary error lights but the user processor will still function and have access to the serial port and IO ports. Thats all you need. You will have to program it in C.

To sum things up, if you want to get around needing an RC and need digital output, you need to use either a new style EDU or a new style full size controller.