 | | Re: IR header how optional
|
|
(...) Yes, I misspoke, indeed from a place of incomplete understanding, sorry, thanks for helping. I did mean to say x 10:EF 10:EF works fine. Like you, if I try x 10:FE 10:FE, I see it echoed but then I see no further reply. And yes x 10:FE 10:FE (...) (22 years ago, 3-Feb-03, to lugnet.robotics.rcx)
|
| |
| | JoyBricx is released
|
|
Hi, all, I make the program named JoyBricx for remote control Spybot and RC Fighter (#8539 Manas.) using USB LEGO Tower. You can remote control the robots, playback, save and load operation by this program. Before, I made the LTremo76, but it was (...) (22 years ago, 3-Feb-03, to lugnet.robotics, lugnet.robotics.rcx, lugnet.robotics.spybotics, lugnet.technic.bionicle)
|
| |
| | Re: IR header how optional -- And Infrared "Warm Up"
|
|
Regarding "Henrik Erlandsson" <e.henrik@telia.com> wrote in message news:H9orqL.M9v@lugnet.com.. and others about "warming up" the serial infra-red link electronics. (...) the web (...) does, and if (...) both. (...) I believe the "warm up" concept (...) (22 years ago, 3-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: IR header - A Detailed Explanation
|
|
Several posts have speculated about the use and necessity of the "header" bytes used by standard RCX messaging. Hopefully this post provides definitive information on the topic. The ROM firmware uses a 30 milli-second inter-character timer. If if is (...) (22 years ago, 3-Feb-03, to lugnet.robotics.rcx)
|
| |
| | Re: IR header how optional
|
|
(...) see ... (...) require (...) That's very interesting. And, I've managed to get replies to "headerless" packets as you describe, however... (...) with (...) I still don't see any response to 0x10 0xFE 0x10 0xFE. The even bytes (0xFE) are not the (...) (22 years ago, 2-Feb-03, to lugnet.robotics.rcx)
|
| |
| | 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)
|
