To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcxOpen lugnet.robotics.rcx in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / 2736
2735  |  2737
Subject: 
RE: RCX to RCX NQC
Newsgroups: 
lugnet.robotics.rcx
Date: 
Thu, 15 Sep 2005 01:44:11 GMT
Viewed: 
4372 times
  
There's another little problem that you may need to program
around. There's a bug in the ROM firmware that could end up
requiring a 30-millisecond delay between when a RCX sends
out a message and when you should start sending the first
character of the next message to the RCX.

The bug is that the ROM firmware puts the RCX into "start
looking for new message" just after it starts sending the
last byte of an outgoing message.  Now each transmitted byte
is also reflected back on the IR receiver so that when the
RCX "receives" this byte it thinks it is the start of the
opcode byte for a new message rather than the reflection of
the last transmitted byte. So now the RCX goes into the
"I've got the opcode, now look for its complement byte" that
it just received. Now if a new message starts to come in at
this point, the message reception state machine is in the
wrong state.

Fortunately most messages are preceded by the optional 55 FF
00 "preamble bytes". So the 55 is improperly treated as a
opcode complement and the state machine resets. The FF and
00 are then treated as preamble bytes. The state machine
doesn't care how many preamble bytes it receives. However,
when you're using RCX to build custom message you can turn
preamble bytes off. I didn't look at your code to see if you
have the proper flag set.

But, if you're using fast firmware download, complement
bytes are turned off. And message corruption results.

The 30-milliseconds delay is for timeout of the
inter-character software reception timer that will reset the
state machine.

There's a patch in the Swan firmware for this problem.



-----Original Message-----
From: news-gateway@lugnet.com
[mailto:news-gateway@lugnet.com]On Behalf Of Brian Davis
Sent: Wednesday, September 14, 2005 3:15 PM
To: lugnet.robotics.rcx@lugnet.com
Subject: Re: RCX to RCX NQC

In lugnet.robotics.rcx, Steve Hassenplug wrote:

Somewhere in there [pg5], it tells you the RCX will
not accept the same command twice in a row.

   Ahh, now I understand why it is called a "toggle bit" - I
somehow
misinterpreted this to mean a new command had the toggle bit
set (to 1), and if
the sending unit doesn't recieve a reply it should
re-transmit the command with
the toggle bit "un-set" (equal to zero, I mistakenly
assumed). Thanks for
clearing that up, it makes more more sense now.
   Except...
   How does the remote get around this? Or does it? It seems
to imply that
commanding a pBrick with the computer IR link or a remote at
the same time would
lead to a loss of commands (same if two remotes try to
command a pBrick). Say
remote-A sends a "beep" command with toggle=1 (and the RCX
responds, so it's
going to wait for a toggle-0 command next), then if remote-B
sends a "beep"
command, it may or may not be executed by the RCX (remote-B
having no way to
know weather to set the toggle bit equal to 1 or 0). that's
not what I saw, in
that the remote always seemed to work. Did I just get lucky?
Or is there
something about the way the remote sends commands I'm still
missing?
   Now, back to getting the pesky LCD set to show the
battery voltage remotely.
Anybody?

--
Brian Davis



  Each command has two op codes that are 8 digits apart.  So
(I think) for
SetWatch you should be able to use command 0x22 and/or • 0x2a

That's exactly what I had to do for my battery tester.

Steve



Message has 1 Reply:
  Re: RCX to RCX NQC
 
(...) And that explains why I was having so much trouble with my custom Tcl based uploader in high speed mode. I fixed it a while ago by adding a slight bit of extra time between messages, but never got to the root of the problem. Thanks Dick! (...) (19 years ago, 15-Sep-05, to lugnet.robotics.rcx)

Message is in Reply To:
  Re: RCX to RCX NQC
 
(...) Ahh, now I understand why it is called a "toggle bit" - I somehow misinterpreted this to mean a new command had the toggle bit set (to 1), and if the sending unit doesn't recieve a reply it should re-transmit the command with the toggle bit (...) (19 years ago, 14-Sep-05, to lugnet.robotics.rcx)

8 Messages in This Thread:



Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR