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.

Re: Dashboard Port Decoder
 

If I had a 2003 OI hooked to the 2003 FRC, could I still have data in from the 2006 dashboard port? Wouldn't the OI be taking the tether port which is where i would have data coming in? Could I take the data from the dashboard port on the 2006 OI and send it to a digital input on the 2003 FRC? Why does the 2003 FRC require a OI if I am using the other data as an "OI"? I guess I am just clinging on to hopeless thoughts here. I am probably going to have to get an EDU-BOT PIC controller. If I got one, how would I interface the data from the dashboard port in C (there is no SERIN in C, at least not that I know of.)

Jacob Komar

Revised Comments:
I guess I overlooked part of your previous post. If I used a previous years FRC, that would be all that I need. How would I specify what I want the input to be on the serial port though, if I'm programming it in C? That would be easy in PBASIC, because I could specify it using SERIN. I am not greatly familiar with C, so maybe there is a way to port the bytes to variables.

Re: Dashboard Port Decoder
 

You would have the data from the dashboard port coming into the "program" port. There are a number of reasons you can't hook the data from the dashboard port into the "tether" port.

No. If the pins were directly connected to the user processor, you could do this. They are not. They are connected to the master processor which this relays this info the the user processor. This happens far too slowly to be able to read the data stream. Also the signal coming out of the dashboard port is RS232. It uses -10v to signal a 1 and +10v to signal a 0. You would have to convert this to a TTL level signal (0/5v)

the 2003 OIs are incompatible with the new OIs. This would also not be competition legal. There are other complications too.

I think this is your best option. Things in C are a bit more complicated. Ther learning curve is streep, but once you learn it you would never go back to basic. The people around these forums can help you out with the code.

Re: Dashboard Port Decoder
 

If I use the program port to the dashboard port, could I have two SERIN commands? Also, the computer does not have enough storage for 2*26 varible bytes.

Jacob Komar

Re: Dashboard Port Decoder
 

yes you can...... sad sad basic stamp.....

Re: Dashboard Port Decoder
 

Would my input in the SERIN command be 1/0 instead of COMA/COMB?

When I do this, I get the Basic Run Err on the OI.

Jacob Komar

Re: Dashboard Port Decoder
 

Sorry but i havn't done pBASIC in a long time. If you post your code, i will dig our the pBASIC manual and have a look at it when i get home. Also, how do you have things connected.

basic run error means your code is getting stuck.

Re: Dashboard Port Decoder
 

Here is the BASIC code. I added the SERIN after the one that is already there. I have the dashboard port hooked to the Program port via a null modem cable. I have also tried it with a direct serial. The null gives me basic run err and the direct gives me basic init err.

Thank you,
Jacob Komar

I attached the file. get rid of the .txt to get the bsx.

Re: Dashboard Port Decoder
 

The problem is that in your second serin, you are reading from the wrong pin (should be 16 not 1/0), at the wrong baud rate.

the line should read
Serin 16, 110, [oi_sw...

Pin 16 is connected to the input pin of the program port. You need to use a baud rate of 19,200. 110 instructs a baud of 19,200 (as calculated from the formula in the basic stamp manual). This might not work. The datasheet strongly cautions against using a baud higher that 4800 or the stamp might not be able to keep up.

Re: Dashboard Port Decoder
 

After changing the code, I still get the Basic Run Err light. I tried disabling the Serin COMA/COMB and it still sees the operator interface and runs without it. I still get the Basic Run Err though. I also tried toning the Baud rate down.

Jacob Komar

Revised Comments:
If I remove ALL of the serin commands, I also get the Basic Run Err. Could this mean that it doesn't see the serin 16 as a valid command?

Re: Dashboard Port Decoder
 

You are probably having the problem of trying to receive data faster than the stamp can handle. There is no way around this. I am pretty sure that 16 is right but there is a chance i could be wrong. It has been a long time since i have dealt with the old controllers of basic stamps at all.

BTW: you cannot "tone down" the baud rate or the communication will become totally corrupted. You will be listening at a different rate than data is being sent by the dashboard.

Also it is essentially receiving "BS" data. Data from the dashboard port is not in the format that is expected. This may be causing some later piece of code to screw up.

Re: Dashboard Port Decoder
 

I removed all of the code afterward, so it's not hanging up there. Even if the baud rate is wrong, shouldn't it still try to recieve data? If I unplug the dashboard cable going to the program port, it still gives me the error. Should it do this? Where can I find out about that port 16 thing?

Jacob Komar

Re: Dashboard Port Decoder
 

the port 16 thing is mentioned in the serin section of the basic stamp manual. 16 is a special number that actually means pin 2 which is the pin used for programming the stamp. This should be the one connected to the "program" port. The manual is vague, but apparently 16 also offers some sort of enhanced hardware support for receiving serial data.

Re: Dashboard Port Decoder
 

I just obtained a VEX computer, which has a com port adapter and digital I/Os. It can be programmed in C. What C code would I use to interpret the data stream from the dashboard port through the built in com connector thingy?

Jacob Komar

Re: Dashboard Port Decoder
 

I have never messed with a vex controller and don't much of anything about them.


-------------- edit ---------------
I downloaded the default VEX code and documentation. The VEX controller looks to be almost identical to the EDU and full size RC. This is a good thing. I will give you some example code sometime tomorrow.

Re: Dashboard Port Decoder
 

That would be great. I was sucessfully able to download to the computer using the IFI loader, so now its just a matter of writing the code. If you could give me some sample input code, that would be great.


Jacob Komar

Re: Dashboard Port Decoder
 

I just obtained an old basic stamp that can be programmed using basic stamp. Right now it can obtain data from an old FRC, but just simple stuff. I am expanding it to work with the real FRC.

If you have that C code, that would still be helpful I think.

Thank you,
Jacob Komar

Re: Dashboard Port Decoder
 

After a day's work on this, this is how far I got.

The Basic Stamp can see the dashboard port, because it doesn't get hung on the 255,255. My problem now is capturing the correct packets. Do I need to name the input varibles the same as they are in the specification sheet? Even if they do, the one that I care about, Switches_A, doesn't pass bit0, which is just p1_trig. Does anyone see any syntax errors?

Just remove the .txt at the end of the file name to get the bs2.

Jacob Komar

Re: Dashboard Port Decoder
 

OK!

I got the stamp to read values from the OI packet, so when I press the trigger, I can make the logic value of a pin high; when I let go, it will go to low. As soon as I move the jumper over to RC next to the dashboard port, and write my code to check the ctrl_a, b and c to suck a certain byte (PWM 1, for instance,) it isn't reading properly. For some bytes, only the lows will work, but when i try to switch it to a high, i get a 2.7 voltage, and other bytes are just 0 all the time. Any suggestions?


Jacob Komar

Re: Dashboard Port Decoder
 

glad to hear it's working... at least a little bit

post the most recent code. I might have an idea about why it might not work

You seem to be on a good track with the BASIC stamp, so i'm not going to bother with the C code.

Re: Dashboard Port Decoder
 

Here is the latest code. Right now its written to capture the first Packet of the RC code and the 3rd byte, which is PWM 1. When PWM 1 is 0, the output 7 is 0 V, but when it gets above 150 (or whatever it is), it jumps all around.


Remember to remove the .txt

Thanks,
Jacob Komar

Re: Dashboard Port Decoder
 

Sorry i took so long to respond. In the version you posted above, there is an extra endif on line 76. It shouldn't even even let you compile that. It won't let me.

Re: Dashboard Port Decoder
 

Oh, I'm sorry about that. I had adjusted the code for the OI, and I readjusted it for the RC so I could post it. I must have uncommented too many things. The version that I used yesterday for the RC decoder compiled properly. I tried multiple ways of using if statements to check those control bits, so I had ifs all over the place. I must have uncommented it by accident.

Jacob Komar

Re: Dashboard Port Decoder
 

I GOT IT!!!!!!!!!

I don't know how I did it, but I got it. I updated the code, (not much of a difference,) but now it works. I also attached the code I downloaded to the FRC (I did it in easyC so that I knew it wasn't my crappy C coding that was the problem :o ). YAYAYAYAYAYAYAY!!!!!!!

My xilinx board is currently on the truck to my house, so later on I can work on the xilinx code for decoding the stuff that comes out of my stamp.

I'll keep you guys updated!!!

Jacob Komar

Re: Dashboard Port Decoder
 

I lied. Only PWM 1 works, and only a little bit at that. Sometimes, the light stays solid at 5 Volts, but sometimes it blinks (between 0 and 30 V.) Its very confusing. Any other byte from the packet produces no output. Any assistence is greatly appreciated.

Jacob Komar

Re: Dashboard Port Decoder
 

As i understand things, you have a Basic stamp connected to the OI. The Basic stamp is also connected to an LED. Is this correct?

How does a ligh blink at 30v? do you mean 30hz? What is it that you wrote in easy C? I thought you were using a Basic Stamp? I'm confused.