To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 15522
15521  |  15523
Subject: 
Re: Custom Firmware, IR Problems, and Dead RCXs
Newsgroups: 
lugnet.robotics
Date: 
Wed, 30 May 2001 05:34:13 GMT
Viewed: 
840 times
  
Well, no. The RCX receiver is a standard IR unit tuned to the
carrier frequency. when I look a the signal on my scope, I get
a nice square-shaped wave that is the same as the data byte (with
start and stop bits) that I sent out. There is a standard UART
in the H8/300 micro that uses mid-point sampling like all the rest.

To summarize, the RCX does not simulate a UART by random samples, it
has a built-in UART.

Gee, could you tell I don't have a block diagram of the innards of the
RCX?

95% of the work I've done with microcontrollers has been based on the
MC68HC705J1A, J2A and K1 series (mainly because that's what I have the
development tools for). Neither of these has an SPI, much less a full
blown UART. Unfortunately this has meant that those projects that have
involved multiple microcontrollers have required the functions of a
UART to be simulated in software. This has meant:
- rapid sampling of an IR receiver so as not to miss any data
thus tying up considerable amounts of cpu time

-  I used cheaper ceramic resonators (instead of crystals). I
learned very quickly from this that any given pair of units will not
stay in synch for very long so you can't depend on the internal timer
(over long periods of time) to find the center of a bit.
- the processors had to do other things (motor control, IR
detection and "accessory" switching) and this really screwed up
communications. This alone was probably the single biggest cause of
data loss.
- In addition to slave units communicating with the central
controller, slave units had to listen for each other so as not to talk
over one-another. This turned out to be the hurdle that killed the
project.

Anyway, try doing this without a UART and it should be easy to see why
my thoughts on the RCX's IR communications (not realizing it *had* a
UARt) were so convoluted.

Matthias Jetleb
VA3-MWJ

P.S.: I suppose I should explain what the project was: It was part of
a model railroad. The idea was to have engines that would respond to a
central controller (similar to DCC) but which could also report back
when they had passed trackside markers (the need for IR) as well as
report on the degree to which each motor is being loaded. The problem
with standard DCC is that while it gives a command to an engine to run
at , say, 75% of maximum speed, there's no way to tell if it is
actually doing that (say - when it's climbing a hill). Hence the need
for some feedback from the engine(s). This system worked reasonably
well with a single engine (although I significantly underestimated the
electrical noise produce by model trains), was flaky with two engines,
and died completely with three. Trying to get a 4MHz MCU to do all
this without the aid of a UART turned out to be more trouble than it
was worth.



Message is in Reply To:
  RE: Custom Firmware, IR Problems, and Dead RCXs
 
(...) <snip> (...) <snipped more> Well, no. The RCX receiver is a standard IR unit tuned to the carrier frequency. when I look a the signal on my scope, I get a nice square-shaped wave that is the same as the data byte (with start and stop bits) (...) (23 years ago, 29-May-01, to lugnet.robotics)

17 Messages in This Thread:







Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    
Active threads in Robotics

 
Verified and Trusted Team of Hackers
11 hours ago
Custom Search

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