Subject:
|
Re: CM-RCX comm
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 30 Jan 2001 13:16:47 GMT
|
Original-From:
|
Marco C. <MARCO@spamcakeSOPORCEL.PT>
|
Viewed:
|
785 times
|
| |
|
|
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 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. This was done using the OUTport of the
CyberMaster connected directly to an INport of the RCX and using the
Off()/Float() technic to simulate the ON/OFF state of a TouchSensor.
3) This is a good sign for my next step: Try to implement on RCX2 a
standard speed VLL protocol input, using FastTimer() to measure the
timmings between signals.
4) I'll try to make SlowVLL as fast as standard CyberMaster firmware let me.
5) I'm still waiting for my MicroScout to do the final checkings and
calibrations on the standard VLL output.
6) After all this is done, I'll restructure my mcVLLlib.ncq so it supports
both VLL output/*input (if possible)* and SlowVLL output/input and these
possible connection combinations:
SlowVLL->
->CyberMaster/RCX/RCX2 OUTport + direct electric connection->
->INport of CyberMaster/RCX
->CyberMaster OUTport + LegoLight/FibreOpticRedLED->
->INport + LightSensor RCX
VLL->
->CyberMaster OUTport + direct electric connection->
->INport of RCX2
->CyberMaster OUTport + LegoLight/FibreOpticRedLED->
->INport + LightSensor of RCX2
->CyberMaster/RCX/RCX2 OUTport + LegoLight/FibreOpticRedLED->
->CodePilot/MicroScout
->RCX/RCX2 INport + LightSensorLED->
->CodePilot/MicroScout
Note: This lib only makes sense in these situations:
CyberMaster->CyberMaster/RCX/RCX2/Scout/MicroScout/CodePilot,
RCX/RCX2->CyberMaster/MicroScout/CodePilot or
Scout->CyberMaster communication.
That's all folks :)
mc.
|
|
Message has 3 Replies:
 | | Re: CM-RCX comm
|
| (...) 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 (...) (23 years ago, 31-Jan-01, to lugnet.robotics)
| | | Re: CM-RCX comm
|
| (...) 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 (...) (23 years ago, 31-Jan-01, to lugnet.robotics)
| | | Re: CM-RCX comm
|
| (...) oops, it's the other way around: Wait(20)/Wait(10) combinations for ZERO and Wait(10)/Wait(20) for ONE. mc. (23 years ago, 31-Jan-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: CM-RCX comm
|
| (...) Yes, the Off() does a shortcircuit simulating a ON state from a TouchSensor point of view. The Float() does the oposite, getting a OFF state this way. (...) I'm using NQC, because all this has to run on a CyberMaster, with it's fixed standard (...) (23 years ago, 10-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
|
|
|
|
