Weird Output from Dashboard Port

[Ian W.]

A bit of an update...

After playing around with the program a bit, I managed to get it to read in correct streams. There's some weird glitches though.

1) It doesn't seem to read in every packet, it likes to just completely ignore the third packet, like it never existed. According to my Dashboard (which I hope is reporting incorrectly), the first packet is received almost three times as much as the second, and the third is only received 79 times before it just stops coming up. Another test resulted in similar figures for the first two packets, but only 9 hits on the third.

2) The dashboard program does not read in the packets correctly until after I hit the "Pause/Break" button on the computer, and then the carriage return key. After pressing that, it usually seems to work fine, but there's no logic behind when it fails.

3) This is the part that makes me think the packets are not being read correctly, which should help solve problem #1. I tried to read individual bytes, and output their data, but it makes no sense and it's simply garbage.

I wish I had the 2003 controls so I could test and see what was wrong, but I have no idea as this same program worked perfectly fine last year .

[Astronouth7303]

DID YOU READ THE DOC? The bytes aren't ASCII, That's for the Prog port on the bot. I would try outputting the bytes (Translate to Hex string) as which # in the packet. That may solve problems. And what language are you using?

[Astronouth7303]

Something else: How do we know OI packets from RC packets? Or the beggining from 2 high user bytes? (Frame 2)
And I belive that you only get frame 3 20 times a second; the info is unlikely to change that quickly (Except pwm 15 & 16, but those are covered by frame 2).

[Ian W.]

Originally Posted by Astronouth7303

Something else: How do we know OI packets from RC packets? Or the beggining from 2 high user bytes? (Frame 2)
And I belive that you only get frame 3 20 times a second; the info is unlikely to change that quickly (Except pwm 15 & 16, but those are covered by frame 2).

Did you read the documentation?

Page 2, under notes...

"1. The IFI Dashboard Viewer now interprets the incoming data and changes the display window depending on the OI/RC jumper setting (located on the OI)."

Says right there how you know what packet (or packets) you're receiving, I'm sure you can find something in the packet stream to do it in software, but why bother when you can see it with your own eyes right on the OI?

You can tell the start of each frame by the two "flag" bytes. The first two bytes of each packet is 0xff,0xff while no where else in a packet can two consecutive bytes reach 0xff. That makes it very simple to find the beginning of a packet and keep yourself synchronized.

Infomation in Frame 3 is very important, actually. Two PWMs, the User Byte, the Battery Voltages (main and backup), and all the error codes (mostly in the Aux_Byte). Those are all pretty important, even if some is redundant. Plus, if I did infact create a bug that didn't display Frame 3 as much as the others, there'd be a problem, because what if next year Frame 3 was important? Just because something works now, doesn't mean you should leave it, make it work right. Also, if you get about 40 packets a second from the OI, it'd be more around 13 times a second to receive Frame 3, but that's a minor technical detail. Although, you receive Frame 3 just as many times as you receive the other frames in the stream, which I'm not sure you understood from the documentation that you obviously read.

[Ian W.]

Originally Posted by Astronouth7303

DID YOU READ THE DOC? The bytes aren't ASCII, That's for the Prog port on the bot. I would try outputting the bytes (Translate to Hex string) as which # in the packet. That may solve problems. And what language are you using?

Yes, I've read the documents, I've read all of them, actually, from 2000 to 2004, in hopes of finding answers. In fact, none of the ports on the OI or RC talk in ASCII, they all talk in hex. It'd make no sense for computers to talk using ASCII, as ASCII was made for displaying characters and such for humans to understand, not microprocessors.

I'm using C/C++ with VS.net.

As for the problems I was having, I actually found the solution by accident.

Apparently I had done something bad with the serial port, forgot to close it, I think, or closed the program incorrectly so it didn't get a chance to close. Due to this, I was unable to correctly reopen it, and that created garbage data. A simple reboot, while 5 minutes long (I'm using an old PII laptop trying to run Win2k), fixed the problem.

If anyone knows how to close an opened serial port after the program that opened it has aborted, can you please share? That would save me, and probably plenty of others, a bunch of time in the pits .

And, as a message of help to everyone, if you ever have strange problems with your serial port, just reboot, don't waste an entire day on it .

[Astronouth7303]

Oh, I use the MSCOMM control with VB6. Very, very useful. And I know comps don't use ASCII. That's why IO asked (If you were outputting like it was, it would be garbage)

Do have answers to my other questions?

[Ian W.]

Originally Posted by Astronouth7303

Oh, I use the MSCOMM control with VB6. Very, very useful. And I know comps don't use ASCII. That's why IO asked (If you were outputting like it was, it would be garbage)

Do have answers to my other questions?

Originally Posted by Ian W.

Yes, I've read the documents, I've read all of them, actually, from 2000 to 2004, in hopes of finding answers. In fact, none of the ports on the OI or RC talk in ASCII, they all talk in hex. It'd make no sense for computers to talk using ASCII, as ASCII was made for displaying characters and such for humans to understand, not microprocessors.

I'm using C/C++ with VS.net.

As for the problems I was having, I actually found the solution by accident.

Apparently I had done something bad with the serial port, forgot to close it, I think, or closed the program incorrectly so it didn't get a chance to close. Due to this, I was unable to correctly reopen it, and that created garbage data. A simple reboot, while 5 minutes long (I'm using an old PII laptop trying to run Win2k), fixed the problem.

If anyone knows how to close an opened serial port after the program that opened it has aborted, can you please share? That would save me, and probably plenty of others, a bunch of time in the pits .

And, as a message of help to everyone, if you ever have strange problems with your serial port, just reboot, don't waste an entire day on it .

Yes.

[Astronouth7303]

Originally Posted by Ian W.

Yes.

Originally Posted by Astronouth7303

How do we know OI packets from RC packets? Or the beggining from 2 high user bytes? (Frame 2)

1. If you look in the doc, there does not appear to be a 'signature' in the OI packet or any of the 3 RC packets. I think all 4 are transmitted (Switch the jumper). But how does the software know this?

2. If you set user bytes 2 and 3 to 0xFF, some software might confuse this with a beggining of a new packet.

So quoting yourself did not answer my questions/concerns. Again, I am suggesting posibilities which may (Or may not) need to be acounted for.

[Ian W.]

Originally Posted by Astronouth7303

1. If you look in the doc, there does not appear to be a 'signature' in the OI packet or any of the 3 RC packets. I think all 4 are transmitted (Switch the jumper). But how does the software know this?

2. If you set user bytes 2 and 3 to 0xFF, some software might confuse this with a beggining of a new packet.

So quoting yourself did not answer my questions/concerns. Again, I am suggesting posibilities which may (Or may not) need to be acounted for.

No, I didn't answer these, as they are in a different thread, look in the hybrid or threaded view, you'll understand why I haven't been talking about your other questions. I answered your questions in your original post, twice now, but since you've asked for answers to questions in the other thread you made, here you go.

For the first, I already answered, there's the jumper on the OI, use that, manually switch the program to reflect the jumper being switched, it's not that hard. Otherwise, you can do what I suspect IFI has done and try to reverse engineer their Checksum Bytes, but seeing as I have no need to see what I'm sending to the RC, and if I did I'd do it the easy way, I can't answer this question with any more detail. Try contacting IFI if you feel you absolutely need to do that automatically in software, but don't expect a response, they don't have the manpower.

Two I already alluded to this answer as well, although I'll now make myself as clear as I can. To do this, you have two choices. The smart way, don't let the bytes both be 0xff. There is a reason they're called user bytes, the user controls them, IFI has taken the assumption that the user is smart enough to read the documentation and read between the lines and realize that they cannot use those two user bytes for 0xff as well as have a working dashboard. The stupid way is to let the two user bytes be 255 at some points, and hope you designed you dashboard to skip that "flag" (as it has now become a flag). If you take the stupid way, please don't come crying to anyone on CD that your RC/OI/dashboard program exploded.