 | | Re: CM-RCX comm —Marco C.
|
| | | (...) 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)
|
| | | |
| | | | | Re: CM-RCX comm —Marco C.
|
| | | | | (...) errr... well, I really don't know. I (unfortunatly) don't own neither a MicroScout nor a CodePilot so I too have some question about the real behavior of these sets when receiving VLL codes. (but I keep watching eBay because I'm always (...) (23 years ago, 11-Jan-01, to lugnet.robotics)
|
| | | | | |
| | | | | Re: CM-RCX comm —Marco C.
|
| | | | | "What's new": 1) I'm still waiting for my RIS 1.0 (hopefully +2 weeks) + Update to 1.5 so, everything I do still uses the Out<->In of a CyberMaster, comunicating with itself (the poor thing). 2) I ordered also a Dark Side MicroScout, for VLL output (...) (23 years ago, 23-Jan-01, to lugnet.robotics)
|
| | | | | |
| | | | | Re: CM-RCX comm —Marco C.
|
| | | | | (...) Ok, one of many possible examples (we're talking about Lego, where your imagination is your limit... err... well, almost ;) I could use an input port of a RCX as a 4th motor controller, using VLL through the LED of a LightSensor connected to (...) (23 years ago, 25-Jan-01, to lugnet.robotics)
|
| | | | | |
| | | | | Re: CM-RCX comm —Marco C.
|
| | | | | 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)
|
| | | | | |
| | | | | | | Re: CM-RCX comm —Steve Baker
|
| | | | | | | (...) 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 —Marco C.
|
| | | | | | | (...) 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 —Steve Baker
|
| | | | | | | | | (...) 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)
|
| | | | | | | | | |
| | | | | | | | | Re: CM-RCX comm (Anyone using Scout->MicroScout/CodePilot ?) —Marco C.
|
| | | | | | | | (...) Yes, I understand. Lego created VLL for barcode reading (CodePilot, and then MicroScout). Barcode reading is error prone, so are other forms of serial communication. Through the use of the VLL Checksum bits and timeouts, one can invalidate bad (...) (23 years ago, 31-Jan-01, to lugnet.robotics)
|
| | | | | | | | |
| | | | | | | Re: CM-RCX comm —Marco C.
|
| | | | | | (...) 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)
|
| | | | | | |
| | | | | Re: CM-RCX comm —Marco C.
|
| | | | (...) make (...) Would make (...) used (...) Yes of course I will :) Because I'm still in the early stages of this, I decided to use all my small spare time to this project, and only in the end, after having my mcVLLlib.ncq the way I want it, I'll (...) (23 years ago, 31-Jan-01, to lugnet.robotics)
|
| | | | |
