 | | frame RCX reply how
|
|
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 (...) (21 years ago, 31-Jan-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
You might take apart javastorms: http:/www.javastorms.org They've implemented LNP using javax.comm. (...) (21 years ago, 31-Jan-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
(...) Thanks for the link, but I meant only to be asking: How do I make sense of RCX replies ... ... when the RCX is first powered and after I download Lego firmware. Help? Curiously, cluelessly, thankfully yours, Pat LaVarre P.S. Do we have no (...) (21 years ago, 31-Jan-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
I wish I could give you a direct answer, but I don't know. However, I suspect (as I'm sure you do) that what you are looking for has already been done. Below are three possible sources which you can adopt, co-opt, or reverse-engineer to get where (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | 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)
|
| |
| | framing RCX LNP replies in Java
|
|
(...) Thanks I reached: src/org/javastorms/lnp/IR.java (...) I think I see ... readMsg accepts what it likes else dies after reading the first distasteful byte. readMsg likes either of xF0 or xF1, then a length byte, then that many bytes, then a (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx.java)
|
| |
| | Re: frame RCX reply how
|
|
(...) Bingo! I reached the bricktools/ of the frame-free: (URL) bytes At a glance, I missed how bricxcc toggles x08 in the command op to let command ops be repeated, but I'd now guess the bricxcc algorithm for framing standard RCX replies is: 1) (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
(...) Ah, thanks. Can we therefore conclude 45.8 ms/byte = 11/2400 s/byte for each byte of a burst? (...) Tell me more? Do we mean to say RCX in the middle of a football field echoes less well? Should I discard the echo, rather than checking it for (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
(...) Anyone know more specifically where to read how Lejos frames standard RCX IR replies? Does Lejos even include any .java code that runs on the PC? I mean to be asking how a PC should frame the standard replies from Lego RCX fimware, not how a (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx.java)
|
| |
| | 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
|
|
(...) can be (...) This is the PBAliveOrNot (or ping) packet type. It has the side- effect of reinitializing the toggle bit used to determine repeat packets. Do you have the Minsdstorms SDK? It covers all the standard LEGO packet types in detail: (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
(...) Ouch, we may be framing the hex differently here, sorry. The only x10 Ping known to me is the x10/18 command op that gets embedded inside of a packet like x 55 FF 00 10 EF 10 EF to provoke a reply packet like x 55 FF 00 18 E7 18 E7, or vice (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
(...) ... (...) Corrected/ elaborated in [square brackets]. I found my error by comparing bricxcc to a delightfully inaccurate summary of ~kekoa on replies that I built some time ago. Except again, op 63/6B UploadRam I find only in in "LASM Byte (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
Concerning the parsing of LEGO packets, I've found these bits to be useful in coming up with a parsing algorithm: * Packets start with 0x55 * Individual bytes of a packet are sent with little or no delay in between bytes * Packets may or may not (...) (21 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: frame RCX reply how
|
|
"Pat LaVarre" <ppaatt@aol.com> wrote in message news:H9nAFD.7v@lugnet.com... (...) like x (...) byte x (...) course (...) the 4 (...) find (...) 10 EF? I follow you now (helps to look at the actual code ;-)... I would expect that raw byte sequence (...) (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)
|
