Subject:
|
Re: Firmware download troubles
|
Newsgroups:
|
lugnet.robotics.rcx
|
Date:
|
Tue, 10 Dec 2002 04:06:07 GMT
|
Reply-To:
|
Dick Swan <dickswa@sbcglobal.SAYNOTOSPAMnet>
|
Viewed:
|
4488 times
|
| |
|
|
A likely explanation for your downloading problem is the following.
Standard Lego software uses 2400 baud data rate and a protocol that
sends "double" bytes. The "double" byte is that each data byte is
followed by its complement. Alternative development systems use a quad
speed downloader that operates at 4800 baud and eliminates the
complement data bytes.
Message transmission in quad speed is not reliable when there is a
large block of consecutive zeros in the message data. I have found
that it is not robust when more than 25+ consecutive zeros are
transmitted.
Unfortunately the 2.0 firmware (i.e. 0328) has a couple of large
blocks of consecutive zero bytes at about 73-80% and 88-90% of the
downloading.
There are no significant blocks of consecutive zeros in the 1.0
firmware (i.e. 0309) which is why it works reliably.
One solution is to disable the quad speed downloader.
Another solution is to dynamically adjust the size of a download
packet based on whether it contains a string of zeros; this is the
technique that I use -- I shorten packet size to ensure no more than
20 consecutive zeros. I think most downloading programs simply always
use a default size of 200 bytes except for the last packet.
There are two possible sources of the poor performance. One is that
the serial link needs to recover clock from the data stream and it
can't do that when there are inadequate quantity of ones in the
transmission. Another is that the AGC (Auto Gain Control) circuitry
may get out of whack when the data is mostly zeros.
According to some of the original RCX "hacking", the IR AGC circuitry
assumes an even balance of ones and zeros in the serial stream. This
balance is "guaranteed" as a byproduct of the "double" byte
transmission. And if we assume a random distribution of the data
content, it should also happen.
Each download message starts with the header bytes of 0x55, OxFF, 0x00
and the opcode. This is enough to allow the RCX to re-sync the serial
link clock and/or the AGC circuitry which is why using shorter
messages with quad speed works.
"Matt White" <mwhite@silenus.com> wrote in message
news:H6vDuD.52K@lugnet.com...
> Hi All,
>
> I have pulled my RCX out of summer storage and I am trying to bring • it to
> life. I have tried to download the 2.0 Firmware (firm0328.lgo) • dozens of
> times with no success. It starts to download, then somewhere in the • middle,
> or very close to the end (it varies), I get a "Firmware download • failed. Put
> the RCX closer and try again." message. I am using the Bricx Command • Center
> to do this.
>
> I can successfully dowload the "original" firmware that came with my • set. I
> have RCX 1.0.
>
> I have replaced all the batteries - no change.
>
> Any help?
>
> Matt
|
|
Message has 1 Reply:
 | | Re: Firmware download troubles
|
| (...) ... (...) Dick and others, Thanks - this helped. What I did to solve this was run the NCQ command-line download at "normal" speed. This worked the first time. Interestingly, I am not sure that the Bricx (v3.3) download was running quad speed (...) (22 years ago, 10-Dec-02, to lugnet.robotics.rcx)
|
Message is in Reply To:
| | Firmware download troubles
|
| Hi All, I have pulled my RCX out of summer storage and I am trying to bring it to life. I have tried to download the 2.0 Firmware (firm0328.lgo) dozens of times with no success. It starts to download, then somewhere in the middle, or very close to (...) (22 years ago, 9-Dec-02, to lugnet.robotics.rcx)
|
10 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
|
|
|
|
