To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 2326
2325  |  2327
Subject: 
Re: reliability of quad speed LNP
Newsgroups: 
lugnet.robotics.rcx.legos
Date: 
Wed, 27 Feb 2002 04:10:02 GMT
Reply-To: 
Dick Swan <dickswa@SPAMCAKEsbcglobal.net>
Viewed: 
1977 times
  
"Mark Falco" <falcom@onebox.com> wrote in message news:Gs44C0.MGL@lugnet.com...
Does anyone have any data on the reliability of quad speed LNP?
<<snip>>

I'm not familiar with LNP but I have also experienced similar messaging problems. I have an old RCX 1.0 (S/N 22751) with serial
tower and a newer RCX 2.0 (S/N 591822) with USB tower. Not a large population, but here's what I've observed.

The newer 2.0 hardware - both RCX and USB tower - are more sensitive than the older 1.0 to errors. With only a single RCX of each,
this is more conjecture than fact. I could be downloading to new hardware and get continual aborts part way through but when I
swapped to old RCXit worked OK.

The newer hardware seems to be more sensitive to errors when [1] the units are really close to the front of my computer monitor, and
[2] the units [tower + RCX]are really close together. When I diddled with the spacing and location things would work better. And
yes, this is all with fresh batteries.

Both hardware versions work well when using standard speed protocols. In my case this is "standard" Lego firmware signaling protocol
at 2400 baud with complement byte enabled. [i.e. single speed].

At quad speed [4800 baud, no complement bytes], I get corrupted messaging when the message contains lots of consecutive zeros or
lots of consecutive bytes with a very sparse ones density. The hard limit seems to be just over 20 consecutive bytes. At dual speed
[2400 baud, no complement bytes], the performance is better but I still see corrupted messages. My fix was to split large sparse
messages into smaller messages. A subsequent fix was to invert every second message byte, but not the header bytes, during
transmission and then re-invert after reception; this has worked beautifically.

Anybody else have similar collaborating [or conflicting] experience?



Message has 1 Reply:
  Re: reliability of quad speed LNP
 
So with inverting every other message byte were you able to work at 4x? Were you then also able to work at close range at 4x? It would seem easy to patch LNP to automatically do this inversion. I'll have to give this a try. thanks, mark (23 years ago, 28-Feb-02, to lugnet.robotics.rcx.legos)

Message is in Reply To:
  reliability of quad speed LNP
 
Does anyone have any data on the reliability of quad speed LNP? I've been using quad speed LNP for downloading programs to my 1.0 RCX for some time, and never had a problem. Recently I'd bowored a friends 1.0 RCX so that my bot could have two RCXs. (...) (23 years ago, 25-Feb-02, to lugnet.robotics.rcx.legos)

5 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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR