Subject:
|
Re: Electrical Data Link between 2 RCXs
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Tue, 3 Apr 2001 08:59:55 GMT
|
Viewed:
|
2147 times
|
| |
|
|
In lugnet.robotics.rcx.nqc, Dean Hystad writes:
> 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 convey
> any information.
Hi Dean,
meanwhile I followed your suggestions and implemented a scheme that uses a
pulse scheme like this:
______ ______ ______
__ ______ ______ __________
Start Bit3 Bit2 Bit1 Bit0
A bit value of 1 results in a long pulse, a bit value of 0 in a short pulse.
Hence, a "9" (binary 1001) would result in
_____ ___ ______
__ _____ ___ _________
Start 1 0 0 1
> The start pulse also conveys little information. I imagine it is required
> to trigger the start of your message receiving routine. Would it work code
> the first bit into the start pulse? A long start pulse is a 1, and a short
> start pulse a 0.
If the message consists of an even number of bits, a start bit is needed, in
order to have a default condition (i.e. the same condition before the
transmission started, here: low) after transmitting the bits. If the number of
bits is odd, your proposal would work.
Regarding the timing, I found out that with a 30 ms pulse for a one and a 10 ms
for a zero, the program works fine. Usually, you will have "Very Fast Timer"
values (in fact variables, which are incremented during a pulse until the next
edge) of 0 or 1 for a zero and 4 or 5 for a one. If you reduce the duration for
a one to 20 ms, the distance in the values for a one resp. zero will be too low
(typically 0 or 1 for zero, 1 to 3 for a one).
However, there is a strange effect:
When I start the program, the first message that is sent is corrupted, i.e.
wrong pulses are created. E.g., if I send a "0" (binary 0000), I measured the
following duration for the pulses (value of "very fast timer variables"):
start: 2500 - 3600
bit 3: 94
bit 2: 4
bit 1: 0
bit 0: 1
So a value of "12" was received. This effect always happens.
After this, everything is fine. It seems that the RCX needs some time to adjust
his output procedures ... (Anyone got an explanation for this ?)
Of course, I can send a dummy, throw it away in the receiver and after this the
communication will work.
For those who are interested in the whole subject, here the programs for cut
and paste:
TRANSMITTER:
int num = 0;
task main ()
{
CreateDatalog (100);
SetUserDisplay (num, 0);
Float (OUT_B); // default condition (low)
while (true)
{
num = 0;
repeat (16)
{
Wait (20);
PlayTone(2000, 5);
send ();
num ++;
}
}
}
sub send ()
{
#define _one 3
#define _zero 1
int _bit3 = _zero;
int _bit2 = _zero;
int _bit1 = _zero;
int _bit0 = _zero;
if ((num & 0x08) == 0x08) _bit3 = _one;
if ((num & 0x04) == 0x04) _bit2 = _one;
if ((num & 0x02) == 0x02) _bit1 = _one;
if ((num & 0x01) == 0x01) _bit0 = _one;
Off (OUT_B); Wait (_one); // Startbit (high)
Float (OUT_B); Wait (_bit3); // Bit 3 (low)
Off (OUT_B); Wait (_bit2); // Bit 2 (high)
Float (OUT_B); Wait (_bit1); // Bit 1 (low)
Off (OUT_B); Wait (_bit0); // Bit 0 (high)
Float (OUT_B); // default (low)
}
RECEIVER:
#define _threshold 3
int _bit3;
int _bit2;
int _bit1;
int _bit0;
int _start;
int num;
int display = 0;
task main ()
{
SetSensor (SENSOR_1, SENSOR_TOUCH);
SetUserDisplay (display, 0);
CreateDatalog (1000);
ClearSensor (SENSOR_1);
while (true)
{
num = 0;
_bit3 = 0;
_bit2 = 0;
_bit1 = 0;
_bit0 = 0;
_start = 0;
until (SENSOR_1 == 1); // wait for Startbit
until (SENSOR_1 == 0) _start ++; // pulse length of Startbit
until (SENSOR_1 == 1) _bit3 ++; // pulse length of bit 3
until (SENSOR_1 == 0) _bit2 ++; // pulse length of bit 2
until (SENSOR_1 == 1) _bit1 ++; // pulse length of bit 1
until (SENSOR_1 == 0) _bit0 ++; // pulse length of bit 0
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;
}
}
Best regards
Bernd Frassek
|
|
Message has 1 Reply:
 | | Re: Electrical Data Link between 2 RCXs
|
| (...) My guess is that SENSOR_1 in your receiving RCX is getting a 1 when your program starts. I imagine that OFF is the default state for OUT_B in your transmitter RCX, and that the receiver is seeing this before OUT_B is switched to FLOAT. This is (...) (23 years ago, 3-Apr-01, to lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
| | 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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
