Subject:
|
RE: Custom Firmware, IR Problems, and Dead RCXs (long)
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 28 May 2001 11:19:10 GMT
|
Viewed:
|
560 times
|
| |
|
|
Jim Lee wrote:
> Just a couple a quick comments on this thread - I'm a
> firmware design
> engineer who's done lots of work with IrDA. I don't, however, have any
> experience with the internals of the RCX or the IR Tower, other
> than owning
> them and reading this list. I think that putting a 50 ohm resistor in
> series with the IR LEDs will limit you to something less than "near-mode"
> permanently. The IR circuitry is *designed* to pump as much current as
> possible/available through the IR LEDs, far exceeding their "rated"
> capacity. They are kept from being destroyed by limiting the duty cycle.
You are right, but the RCX and the tower are right at the hairy edge. The
additional 50R impedance will leave the near mode essentially unchanged
and I'll sacrifice on the high range.
Start with the tower. If you use a 9V battery, the IR circuit is
basically two IREDs, a limit resistor, and an NPN switching transistor.
Assuming Vf of 1.2V for the IREDs, and a Vcesat of .2V for the transistor,
you end up with 6.4V across the limit resistor.
In near mode (which has a range of a few feet) the limit resistor is
1K, which results in a DC current of about 6.4mA - no problem even in
straight 100% duty cycle.
In far mode, the limit resistor is 5.6Ohms, which lets 1.14A through the
IREDs, which are (usualy) rated at 100mA constinuous. Even accounting
for a 50% duty cycle on the bits due to the inversion of every byte
and another 50% due to the carrier, you still have about 280mA through the
IRED on average in the very worst case!
> Say you have an LED rated at 20mA forward current, and you're
> pumping 1000mA
> through it. If you keep the duty cycle at 1/50, everything works
> fine, and
> you gain about a 7x increase in range (inverse square law - sqrt(50)).
> You're trading bandwidth for range. Higher current = lower duty cycle =
> longer range = lower bandwidth. Lower current = higher duty
> cycle = shorter
> range = higher bandwidth. Now, what everyone in the Lego world calls
> "firmware", isn't. It's the operating system. The real
> "firmware" is what
> is permanently stored in the Hitachi processor's ROM (or Flash). What you
> are calling firmware gets loaded into volatile RAM, so
> technically it is not
> firmware, but software. So, given that the duty cycle of the IR LEDs is
> controlled by software that can be changed easily by the user,
> then yes, it
> is very possible to destroy the RCX by running bad code.
Yes, that distinction has been made in the book I co-authored with several
other experts on this group...see the sigline for details.
A safer design
> would have been to put the low level IR code into callable subroutines in
> the RCX's "real" firmware, the ROM. I don't know about the issue with the
> IR tower, but I suspect that it has more to do with using an unregulated
> wall wart with too high a voltage. Just my two cents,
The low-level routines are in the ROM on the chip, but they are not
optimised for our evil purposes :-)
I think the RCX IREDs are under a lot of strain too, in a calculation
similar to the one for the tower.
As far as the limit resistor goes, I've added the 50R in series with the
IREDs on the RCX and I still get about 6 feet in near mode. I'll post
on the range in far mode.
Ralph Hempel
--------------------------------------------------------------------
Check out pbFORTH for LEGO Mindstorms at:
<http://www.hempeldesigngroup.com/lego/pbForth>
Buy "Extreme Mindstorms: an Advanced Guide to Lego Mindstorms"
<http://www.amazon.com/exec/obidos/ASIN/1893115844/hempeldesigngrou>
--------------------------------------------------------------------
Reply to: rhempel at bmts dot com
--------------------------------------------------------------------
|
|
Message has 2 Replies:
 | | RE: Custom Firmware, IR Problems, and Dead RCXs
|
| Ralph, Thank you for painting a much clearer picture of the internal design of the IR Tower. I agree with your observations, but have a question: Is the processor in the IR Tower controllable (i.e. downloadable, like the RCX)? If it is, then there's (...) (23 years ago, 28-May-01, to lugnet.robotics)
| | | Re: Custom Firmware, IR Problems, and Dead RCXs (long)
|
| (...) For what it's worth, it's not actually that bad. I don't know the specs on the NPN transistor, but I suspect 1.14A would kill it almost instantaneously. One important factor you've left out of this equation is the 9V battery itself. We often (...) (23 years ago, 29-May-01, to lugnet.robotics)
|
Message is in Reply To:
| | RE: Custom Firmware, IR Problems, and Dead RCXs (long)
|
| Hi all, Just a couple a quick comments on this thread - I'm a firmware design engineer who's done lots of work with IrDA. I don't, however, have any experience with the internals of the RCX or the IR Tower, other than owning them and reading this (...) (23 years ago, 27-May-01, to lugnet.robotics)
|
17 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
|
|
|
|
