Weird Output from Dashboard Port

[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.