Subject:
|
Electrical Data Link between 2 RCXs
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Mon, 26 Mar 2001 11:22:45 GMT
|
Viewed:
|
2160 times
|
| |
|
|
It's me again with the subject "electrical datalink between 2 RCXs" (I posted
some articles a couple of weeks ago).
This subject may seem trivial but in fact it is not. Dealing with it, I
discovered some "unpleasanties" in the general execution of programs by the
RCX.
Once again the task:
- an electrical datalink between 2 RCXs (one direction) that allows sending a 4
bit number (0 ... 15)
- it should be as fast as possible.
Once you know the trick (thanks to Dean Husby), the electrical part is easy:
use a motor output at the transmitting robot and toggle between Float and Off.
At the receiving robot use a sensor input set to Touch. A Float will result in
a sensor readings of 0, an Off in a 1.
Now, the protocol. I used a start-bit followed by the four bits of the number
to be transmitted. Up to now I tried several schemes, using equidistant time
periods for the 5 bits. Since the datalink should be fast I couldn't use timers
or fast timers, instead of this I used Waits.
The summary of all investigations:
1. The RCX is slower than I thought. Simple statements need about 3 - 8
milliseconds.
2. The execution of statements is "unstable", i.e. the duration for a statement
is not constant.
If you do something like this:
While (true) {
Off (OUT_B);
Wait (2);
Float (OUT_B);
Wait (2); }
the result should be a nice square waveform, admitting that after the last Wait
a little bit more time is needed for the "long jump statement" of the loop.
In fact it is not. There is a "jitter" of a couple of milliseconds. Especially
during the start of the sequence, the duration of a pulse is sometimes more
than double (!) than it should be. I could prove this with a very nice signal
analyzer we have in the company.
For a "normal" program the above is not disturbing. For the above scheme with
equidistant pulses and both RCXs "free running", the strongly varying pulses
are killing the concept.
So, I tried another approach where the individual bits are represented by
different pulse length.
I used a long pulse - in NQC: Wait (4) - if a bit is one and a short pulse - in
NQC: Wait (1) - if the bit is zero. The pause between the pulses is short. The
transmission starts with a start-bit (one / long). E.g. transmitting a "9"
(binary eqivalent: 1001) would result in a pulse scheme like this
____ ____ __ __ ____
_____| |__| |__| |__| |__| |_____
In the receiving routine the lengths of the pulses are measured. I used
variables which are incremented in a loop as "very fast" timers since the
internal fast timers are not fast enough.
The scheme is as follows: as soon as a pulse starts (sensor input changes to
1), the corresponding variable (_bit3 ... _bit0) is incremented continuously
until the pulse ends (sensor input changes to 0). After this the time periods
for the pulses are checked: a short pulse is represented by a value of 0 ...
2, a long pulse is typically 5 ... 7.
The transmission of a 4-bit number (value 0 to 15) needs at minimum about 110
milliseconds, at maximum (all bits set) about 190 milliseconds.
TRANSMITTER program:
#define _one 4 // Note: a "3" would also work but in a series of 100
#define _zero 1 // 100 transmissions I had errors sometimes
#define _brk 1
int num;
task main ()
{
Float (OUT_B);
while (true) {
ClearMessage ();
until (Message() != 0);
num = Message ();
SetUserDisplay (num, 0);
PlayTone(2000, 5);
Off (OUT_B);
if ((num & 0x08) == 0x08) { Wait (_one); } else { Wait (_zero); }
Float (OUT_B);
Wait (_brk);
Off (OUT_B);
if ((num & 0x04) == 0x04) { Wait (_one); } else { Wait (_zero); }
Float (OUT_B);
Wait (_brk);
Off (OUT_B);
if ((num & 0x02) == 0x02) { Wait (_one); } else { Wait (_zero); }
Float (OUT_B);
Wait (_brk);
Off (OUT_B);
if ((num & 0x01) == 0x01) { Wait (_one); } else { Wait (_zero); }
Float (OUT_B);
Wait (_brk);
Off (OUT_B);
Wait (_one);
Float (OUT_B);
}
}
RECEIVER Program:
#define _threshold 3
int _bit3; // "very fast" timmers
int _bit2;
int _bit1;
int _bit0;
int _start;
int num;
int display = 0;
task main ()
{
SetSensor (SENSOR_1, SENSOR_TOUCH);
SetUserDisplay (display, 0);
while (true)
{
num = 0;
_bit3 = 0;
_bit2 = 0;
_bit1 = 0;
_bit0 = 0;
ClearSensor (SENSOR_1);
until (SENSOR_1 == 1);
until (SENSOR_1 == 0);
until (SENSOR_1 == 1);
until (SENSOR_1 == 0) _bit3 ++;
until (SENSOR_1 == 1);
until (SENSOR_1 == 0) _bit2 ++;
until (SENSOR_1 == 1);
until (SENSOR_1 == 0) _bit1 ++;
until (SENSOR_1 == 1);
until (SENSOR_1 == 0) _bit0 ++;
if (_bit3 >= _threshold) num = num + 8;
if (_bit2 >= _threshold) num = num + 4;
if (_bit1 >= _threshold) num = num + 2;
if (_bit0 >= _threshold) num = num + 1;
PlayTone(4000, 5);
display = num;
}
}
The electrical data link is especially needed if the 2 RCXs cannot "see" each
other due to the individual construction, so that IR messages would not be
received.
Best regards and always "good connections"
Bernd Frassek
|
|
Message has 4 Replies:
 | | Re: Electrical Data Link between 2 RCXs
|
| Hi Bernd, When you need it really fast, you sholud use legOS instead of NQC. A program written with NQC uses the LEGO firmware, which is a ByteCode Interpreter. This pogram is interpreted Byte after Byte from firmaware. The firmware executes the (...) (23 years ago, 26-Mar-01, to lugnet.robotics.rcx.nqc)
| | | Re: Electrical Data Link between 2 RCXs
|
| I am not positive about this, but some of the jitter may be due to the mode in which the motor outputs work. They are PWM at 125 Hz, so I am wondering if, when the byte code to change an output setting is executed, the new state setting is placed (...) (23 years ago, 26-Mar-01, to lugnet.robotics.rcx.nqc)
| | | Re: Electrical Data Link between 2 RCXs
|
| Thanks for the info on the electric datalink. It's a clever idea that I never would have thought of myself. It seems to me that you could cut down on your transmission time if you changed the shape of your pulse train. The pauses between bits don't (...) (23 years ago, 26-Mar-01, to lugnet.robotics.rcx.nqc)
|
11 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
