Subject:
|
RE: Electrical Data Link between 2 RCXs
|
Newsgroups:
|
lugnet.robotics.rcx.nqc, lugnet.robotics
|
Date:
|
Wed, 28 Mar 2001 15:20:56 GMT
|
Reply-To:
|
<marco@soporcel.STOPSPAMMERSpt>
|
Viewed:
|
2091 times
|
| |
|
|
> From: Bernd Frassek
> Hi Marco,
Hi :)
> Sometimes I had the feeling that I dealt with "exotic" problems
> but then I realized that other "Mindstormers" had similiar
> questions.
Heheh, my feelings exactly before "bumping" into LUGnet community almost a
year and a half ago ;)
Ok, now, about the way I use Timer() and will try to use FastTimer() or
counter loop if proven more effective.
I have no need to get *precise* timings because the input routine isn't
waiting for X ms or Y ms
I don't have my source code right here, but I'll try to do my best to
explain how I do it.
VLL protocol is based on barcode reading. By the way, because of this, I
finally understood how a barcode worked :>
So, because of this, a BIT is represented by a ON (light presence) *AND* a
OFF (light absence) pair. Time difference between ON and OFF is what gives
the BIT state.
So, I simply have to measure the time it's ON and the time it's OFF and then
do a comparison like: if (t1>t2) {bit=0} else {bit=1};
As I explained earlier on lugnet.robotics "CM-RCX" thread, this is an
example of how I send a BIT (this complete sequence requires Start,
Checksums and Stop bits of course)
On(); Wait(20); Off(); Wait(10); -> detected as a BIT=0
On(); Wait(10); Off(); Wait(20); -> detected as a BIT=1
As you can see, this is SlowVLL timings, using 200ms/100ms sequences, that
can be measured by Timer()
The correct timings for Standard VLL are 40ms/20ms (BIT=0) or 20ms/40ms
(BIT=1) sequences.
So, I only have sure that the ON/OFF timings are different enough to be
detected correctly and not be confused with one another.
I think that for 100ms resolution, I can use that close timings (200/100)
because the pBrick is fast enough to give accurate Timer() values.
When I get the change to play with FastTimer() (or even with n++ loop
counters) I have to be more careful to maintain a better difference between
the High/Low values.
> Even when having a very simple loop like:
> ClearTimer(0);
> until (FastTimer(0) == 5) statement;
hmmm... I don't use Timers this way, I do something like this:
(lets see if I remember this correctly)
ClearTimer(n);
until (VLLinputPORT==1) {timeout code placed here};
t1=Timer(n)
ClearTimer(n);
until (VLLinputPORT==0) {timeout code placed here};
t2=Timer(n)
After getting t1 and t2 I can decide if BIT is 1 or 0
> > 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)
Yes, I'm trying to use something as open as VLL, so I can use the same
library for bi-directional comms in various combinations, like:
CyberMaster <-electrical or light-> CyberMaster or RCX or Scout
CyberMaster or RCX --light-> MicroScout or CodePilot
Using any of the OUT or Active IN ports
One of my next projects (after this comms thing) will involve something like
this:
PC <-radiolink-> CyberMaster <-electrical link-> RCX <-light link->
MicroScout (and a CodePilot if I ever get one for a low price)
This gives me access through radio to:
2 Cybermaster motors (the only out port used for electrical comms to RCX)
2 RCX motors (the 3rd used for electrical comms to Cybermaster)
1 MicroScout motor (linked to LightSensor LED RCX IN port 1)
1 CodePilot motor (linked to LightSensor LED RCX IN port 2)
Total 6 motors with 4 pBricks (two of them semi-dumb pBricks ;)
2 CyberMaster touch sensors (3rd used for electric comms input with RCX)
0 RCX sensors (because the 3rd used for electrical comms with Cybermaster)
phew... ok, I think this is enough talk... er... I won't mention another way
to control multi (I think 8) MicroScout/CodePilot through the use of a
motor, a rotation sensor and a VOS Light set :>
> I wrote a VLL interface for the Microscout, adapting some
> technique of a
> Japanese guy, that worked brilliant
AH! So you're familiar with the VLL protocol and the way it transmits a BIT.
You understand that a VLL input routine can have some degree of flexibility
to accepted timing problems :) (CodePilot barcode reading heritage)
> (besides the fact that the Microscout is a really "stupid" unit).
> What I found out is that the transmission could not be
> speeded up. The reason - as far as I think - is that the
> toggling of the light sensor could not be made faster.
hmmm.. I think it's may got to do with the timeout settings that must be
present in the input routine, so the unit can abort a false VLL sequence,
and reset the input sequence to become ready for the next sequence.
My routine does this, and these time limits (if fixed, like in the
MicroScout case) can limit the top speed of the transmition.
> I will continue with tuning the interface.
Me too ! And I'll keep posting my progress.
Sorry for the long msg :)
mc.
|
|
Message is in Reply To:
11 Messages in This Thread:
 
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
