Subject:
|
RE: IR Problems
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Mon, 2 Apr 2007 19:16:39 GMT
|
Reply-To:
|
<dickswan@sbcglobal.netSTOPSPAM>
|
Viewed:
|
11126 times
|
| |
|
|
Elizabeth is quite right. It's easy to get collisions on the IR "bus" if
two devices are sending (or replying) simultaneously.
What I've done in the past with two RCXs is define one RCX as primary
that is periodically (every 100 to 250 milliseconds or so) sending a
message to the secondary device. The secondary device only sends
messages immediately after it has received a message from the primary.
The time between primary polling is chosen to be long enough to ensure
the primary message, and the optional secondary reply are both complete
before the next poll starts.
Above has proven to be very robust and easily accommodates and recovers
from lost messages.
If you're planning on upgrading to Robolab 2.9 you'll get more reliable
IR messaging. The Robolab 2.9 firmware fixes a number of bugs found in
earlier firmware. The two most prominent ones that I remember are:
1. Earlier firmware required 30 milliseconds between transmit and
receive messages. Robolab 2.9 does not. The reason for the 30-msec
interval is that it will force the message receive state machine to
reset and the bug is that the last echoed character of the last
transmitted message was being interpreted as the first character of the
next message.
2. Better handling of errors in the protocol header bytes (55 FF 00).
An enhanced version of the Robolab firmware is used in RobotC for RCX.
In addition to the above two features, it adds several more:
3. Legacy firmware only allowed a single byte of data in messages.
RobotC firmware adds up to 3 x 16-bit words of optional parameters. So
messages can contain up to 7 bytes of data. Messsages are variable
length so that the minimum length necessary is transmitted.
4. Protocol bytes are totally optional.
5. You can reconfigure "normal" baud rate to 4800 baud. Legacy firmware
is 2400 baud only.
6. You can enable or disable the "double byte" transmission of each
character. Normally, each message byte is transmitted followed by a
second byte containing the complement value. In RobotC firmware, this
complement byte can be optionally disabled.
The impact of previous three items is about five times faster IR
transmission. As far as I know, items 5 and 6 and unique to RobotC for
normal firmware operation.
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com] On Behalf
Of Elizabeth Mabrey
Sent: Monday, April 02, 2007 1:16 PM
To: lugnet.robotics.rcx@lugnet.com
Subject: RE: IR Problems
IR communication is no where near the reliability like a tcp/ip. You can
easily lose a message ... so program must be either extremely simple one
way
communication. The sender should be programmed to handle message loss.
What I had the kids done was to push the same sending msg for a lot of
times
if it is a simple one way communication. Or, it should keep sending
until
receiving a recv msg from the receiver(s)... then other actions
follow...
If your two RCXs need to get messages from each other or from the
computer,
you will need to incorporate more sophisticated synchronization.
Otherwise,
you can easily deadlock yourself. A lot of kids did that.
--E
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com] On Behalf
Of
Tom Lohre
Sent: Monday, April 02, 2007 11:03 AM
To: lugnet.robotics.rcx@lugnet.com
Subject: Re: IR Problems
In lugnet.robotics.rcx, <dickswan@sbcglobal.net> wrote:
>
> Are you sure your problem isn't interference? How did you "lock out" • the
> RCS 1.0 from receiving (and responding) to the direct commands? You • have
> two RCXs turned on and sending direct commands from the PC. They will
> both try to respond to the direct commands!
Thanks for your reply. I had to return the 1.0 RCX and motor back to
school
today. Those things are like gold. The 1.0 faces the 2.0 and is not in
direct
line of sight of the tower. The 1.0 is just to the side of the tower. I
think my
problem is that I did not include a "wait for mail" after the "send
mail" in
the
program running on the 2.0. That would reinitialize the 2.0 to listen
which
would mean go back to listening for the next command from the tower.
The
2.0
tells the 1.0 when to act via mail. The tower sends data every 13
seconds to
the
2.0. Tom http://tomlohre.com/lego.htm
|
|
Message has 1 Reply:
 | | Re: IR Problems
|
| (...) Thank you for the excellent information concerning communication with more than one RCX. Last night in a dream I realized that I could just bypass communication placing two push button sensors where needed driving the additional RCX. The (...) (17 years ago, 13-Apr-07, to lugnet.robotics.rcx)
|
Message is in Reply To:
| | RE: IR Problems
|
| IR communication is no where near the reliability like a tcp/ip. You can easily lose a message ... so program must be either extremely simple one way communication. The sender should be programmed to handle message loss. What I had the kids done was (...) (17 years ago, 2-Apr-07, to lugnet.robotics.rcx)
|
10 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
|
|
|
|
