Subject:
|
Re: CM-RCX comm
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 31 Jan 2001 10:15:29 GMT
|
Original-From:
|
Marco C. <MARCO@SOPORCEL.PTspamless>
|
Viewed:
|
776 times
|
| |
|
|
At 22:30 30-01-2001 -0600, Steve Baker wrote:
> "Marco C." wrote:
> >
> > 2) My first tests with the two pBricks (CyberMaster and RCX) prove that
> > it's possible to communicate using a (ten times) slower version of VLL
> > protocol (I call it SlowVLL for short). *It works*, and it transmits data
> > very accuratly (I'd thought it would suffer some variations in timmings but
> > no, the Wait() value on the OUTPUT pBrick is exactly the measured Timer()
> > value on the INPUT pBrick.
>
> Wooaahhh! That can't be true. Both machines are running some kind of
> (hopefully) crystal oscillator to generate the clock that drives the
> Timer() and Wait() commands. No two cystal oscillators generate the
> *exact* same timing - so your two clock could easily differ by one
> part per million or so. Hence, once in a while, you'll find that
> you either miss a bit or drop a bit. That may be quite rarely or
> quite frequently depending on the quality of the oscillators that
> Lego used for the RCX.
That's exactly what my common sense made me believe.
But various tests I did, using a dump of a Datalog with the timmings
measured by the RCX, proved me wrong.
Every Wait(10) was correctly measured as a Timer(3)==1, and every Wait(50)
as a Timer(3)==5 and so on...
This is one of many datalog's I've taken, from my first tests. I was
sending a a VLLcode010 (Motor Stop) from CyberMaster to the RCX, that's a
011 0001010 bit sequence:
Timer 3 21
Timer 3 1 Start bit
Timer 3 5
Timer 3 1 checksum bit3=0
Timer 3 2
Timer 3 4 checksum bit2=1
Timer 3 2
Timer 3 4 checksum bit1=1
Timer 3 5
Timer 3 1 data bit7=0
Timer 3 5
Timer 3 1 data bit6=0
Timer 3 5
Timer 3 1 data bit5=0
Timer 3 2
Timer 3 4 data bit4=1
Timer 3 5
Timer 3 1 data bit3=0
Timer 3 2
Timer 3 4 data bit2=1
Timer 3 5
Timer 3 1 data bit1=0
Timer 3 1
Timer 3 8
Timer 3 30 Stop bit
> You may be able to tolerate that - but you *do* need to be aware that
> the error rate won't ever be zero.
Yes, I know. After my first tests, I made a SlowVLLinput() routine that
uses a "if (timesample1>timesample2) then bit=0 else bit=1" approach. This
way it works with possible small variations.
I'm now trying to speed up as much as possible the SlowVLL protocol, using
Wait(10)/Wait(20) combinations for ZERO and the opposite,
Wait(20)/Wait(10), for ONE. I've shortened also the timmings in the start
bit and end bit sequence to speed up the all thing. All this was done
using direct electric connection. I haven't done any Light->LightSensor
testings yet, because my main objective is CyberMaster<->RCX comms.
This "faster" version of SlowVLLinput is more prone to bit missing, so I'll
have to work out the best solution to this. Another thing that I have to
test is the efficiency of SlowVLLinput() on a real life situation, with
many CPU ticks being used for normal robot control.
I'm also perfecting a timeout feature I've implemented, so that any random
"spike" bit's that may start a VLL input sequence by mistake, or any
interrupted VLL sequence, doesn't "freeze" the input routine, making it
give up that sequence and wait for a fresh new one.
After this, and time permitting, I'll try to do a StandardVLLinput for the
RCX2 using FastTimer()... or better still, an all purpose, general VLLinput
that copes with both versions, the custom slower version of VLL, and the
standard VLL one.
All comments are welcome :)
mc.
PS: This work made me understand, for the first time, how a barcode works :>
|
|
Message has 2 Replies:
 | | Re: CM-RCX comm
|
| (...) Well, yes - but then crystal oscillators are quite accurate (but crucially, not 100% accurate). You might have to run as long as one or two MILLION attempts before you see an error - but you *will* see an error if you do it for long enough. If (...) (23 years ago, 31-Jan-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: CM-RCX comm
|
| Status Report: 1) Ok, just got my RIS 1.0 set (AT LAST! ;) 2) My first tests with the two pBricks (CyberMaster and RCX) prove that it's possible to communicate using a (ten times) slower version of VLL protocol (I call it SlowVLL for short). *It (...) (23 years ago, 30-Jan-01, to lugnet.robotics)
|
20 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
|
|
|
|
