Subject:
|
frame RCX reply how
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Fri, 31 Jan 2003 13:20:39 GMT
|
Viewed:
|
4142 times
|
| |
|
|
Anybody know how to divide the bytes incoming from the RCX IR replies into
correct frames, preferably using javax.comm on a Linux/Windows PC?
I'm told I might want to:
1) Expect first an exact echo of the command packet.
2) Expect the reply code to be the op complemented [even bit 3?].
3) Expect the bytes of the reply to arrive one after another, with no
appreciable delay in between [up to how many bytes?].
Anybody know more? If noone does, then I'll have to decipher code on the web
that purportedly works, such as:
http://graphics.stanford.edu/~kekoa/rcx/tools.html#Firmdl
> > one after another
I wonder what the arrival rate actually is. Could it be:
(8 data + 1 parity + 1 stop bit) /byte / 2400 Hz = 1/240 s/byte = 4.167ms/byte.
> > [up to how many bytes?]
Searching here for "framing RCX replies" quotes the immortal Kekoa P: "In
request/reply mode, a good practical cap on the max number of data bytes to
transfer from RCX to PC in one go is 256 (does not include header, complements,
or checksum) ... to avoid losing data to the tower shutting off."
I presume the standard RCX byte codes somehow make it practical to limit
replies to 256 payload bytes each. I imagine the checksum also becomes less
useful as the payload increases.
> > I wonder
I'm having a hard time experimenting: seemingly I keep exhausting my 9V
battery. I have little to zero experience of running the Lego RIS software, so
I can't know if running my own software exhausts the 9V more quickly than
normal or not.
Pat LaVarre
|
|
Message has 4 Replies:
 | | Re: frame RCX reply how
|
| Hi pat, (...) This is what you send reflected by the walls, I think. (...) Bits 0-2 of the opcode tells you the number, with 6 meaning 0 and 7 meaning 1. For some special opcodes it is longer. (...) + 1 start bit I think there's some Java code for (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
| | | Re: frame RCX reply how
|
| (...) (URL) bytes Accordingly I'd now guess the firmdl3/rcx_comm.c algorithm for framing standard RCX replies is: (...) 1) Send the bytes of the command packet. 2) Loop to receive up to equally many bytes echoed. If 100ms elapses twice without (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
| | | Re: frame RCX reply how
|
| (...) Yes helpful framing rules thanks. (...) Thanks in particular for pointing out the before & after rubbish. Me, just now I began quoting this rule in a fog, somehow not immediately appreciating that: The receive framing in bricxcc withstands (...) (21 years ago, 2-Feb-03, to lugnet.robotics.rcx)
|
16 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
