 | | Re: IR header how optional
|
|
(...) Whether serial transmission is as simple as start:data:parity:stop repeated, or not, I still have no idea. But I'm posting again to say in those calculations I was off a whole order of magnitude, sorry. I imagine the calculator I used reported (...) (22 years ago, 2-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: IR header how optional
|
|
(...) I doubt anything (short of a 2MV Lightning Flash) will warm anything in 1 msec. ;) Also, the receiver won't warm up until the header has been read in completion and decoded. So I doubt it's used for that. Normally, in any communication, you'd (...) (22 years ago, 2-Feb-03, to lugnet.robotics.rcx)
|
| |
| | IR header how optional
|
|
(...) Yep. But via our solid new reply framing code, thanks again, now I can see ... (...) Nope. At least not here: now that I look, I see my RCX often doesn't require the PC to send x 55:FF:00. IR command packets like x 10:FE 10:FE PBAliveOrNot and (...) (22 years ago, 2-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 (...) (22 years ago, 2-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 (...) (22 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 (...) (22 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 (...) (22 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 (...) (22 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: (...) (22 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 (...) (22 years ago, 1-Feb-03, to lugnet.robotics.rcx)
|
