Subject:
|
RE: Electrical Data Link between 2 RCXs
|
Newsgroups:
|
lugnet.robotics.rcx.nqc, lugnet.robotics
|
Date:
|
Tue, 27 Mar 2001 17:37:19 GMT
|
Reply-To:
|
<marco@soporcel.pt#stopspammers#>
|
Viewed:
|
87 times
|
| |
|
|
Hi Bernd :)
I see we're working in the same subject here :) *great*
If you care to browse lugnet.robotics old thread
"VLL *input* for RCX/CyberMaster (in NQC) ?"
or the newer one, starting with "CM-RCX" (the subject had some variations)
Your problem: Speedy 4bit comms between RCX's
My problem: Do both output and input that fits in little CyberMaster RAM
I think you can solve your problem using legOS. It's faster than RCX
firmware based interpreter.
I would use legOS *IF* it could be used in Cybermaster, but, because it's
firmware's in ROM I'll have to stick to the standard firmware through NQC
(or whatever)
'til now, I had the same speed problem as you. For now, as I was eager to do
something that really worked and because I wanted to try to implement VLL
(or a version of it) I had to create SlowVLL to cope with the slower CM's
Timer()
It works. It's slow, but works.
It sends Start bit, 3 CheckSum bits, 7 Data bits and the Stop bits as the
Standard VLL protocol, but 10 times slower (well, not 10 times, because I
did some tuning and optimizations in the Start, Stop and in the 1/0 trigger
timmings, I think it's about 8 times slower now)
As I said, I'm now working in (Step 2) a way to get both input and output
routines at the same time in CM's RAM
After this, I'll try to do standard VLL input with RCX2 firmware using
FastTimer(). Because Standard VLL needs 10ms resolution, I think it'll work.
After all this was done and working I was thinking to have a go at making
CyberMaster Standard VLL input capable, by using n++ counter loops instead
or Timer() (like you have done).
I predicted that this would be more error prone, because the speed of the
loop will vary depending on the CPU ticks available at that time.
I think this is the main problem with this approach.
But, after checking my input routine, and because it relies on differencial
timmings to detect a 1 and a 0, I think I'll be robust enough to deal with
this.
When I say VLL, I include the direct electrical connection, using the
Off()/Float() technique, along with the other light emission through OUT
ports or through active IN ports (example: using the LightSensor LED)
I'll keep posting my progress at lugnet.robotics, and I'll keep an eye on
your progress here at lugnet.robotics.rcx.nqc :)
mc.
> -----Original Message-----
> From: news-gateway@lugnet.com
> [mailto:news-gateway@lugnet.com]On Behalf
> Of Bernd Frassek
> Sent: Monday, March 26, 2001 11:23 AM
> To: lugnet.robotics.rcx.nqc@lugnet.com
> Subject: Electrical Data Link between 2 RCXs
>
>
> 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 1 Reply:
Message is in Reply To:
 | | Electrical Data Link between 2 RCXs
|
| 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 (...) (24 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
|
|
|
|
