[ale] [Almost totally OT] Rotating hardware interface.

[John Mills]

Joe -

On 3 Dec 2004, Joe Knapka wrote:

> John Mills <johnmills at speakeasy.net> writes:
 ...
> > You can assign some microcontroller [think PIC?] to handle the signals and
> > use some simple byte protocol over its serial I/O.
 
> That is a really good idea, which hadn't occurred to me. In fact,
> pretty much everything the PC software is doing could as well be done
> by an MCU mounted on the rotor. It would have to be a very compact MCU
> package, though, since the rotor is only about 1.5" in diameter; maybe
> something like a STAMP 1 would be suitable. Such an arrangement would
> necessitate only intermittent instruction from the PC (perhaps
> once/minute instead of several hundred times per second). Undoubtedly
> simpler to implement and more reliable. Looks like 2005 is going to be
> a year of getting familiar with hardware and MCUs -- cool!

Sounds like an altogether better solution. I mentioned the PIC because it
has a FLASH-PROM model in a DIP - 16, 18, or twenty-something pins I
remember not. (This part is actually deprecated for production designs,
but _very_ handy for prototyping compared with the surface-mount versions.  
It can be programmed, erased, reprogrammed and debugged in-place via a
special serial connection. Very handy once you accept PIC assembly 
language.

> BTW in case it isn't obvious, my hardware-fu is not very good at
> the moment. I'm working my way through the Horowitz & Hill book
> "The Art of Electronics", but it's pretty slow going. Building a
> serial interface from discrete components would be beyond me
> at this point, though I'm eager to learn.

I grew up on manufacturer's product manuals - National Semi, Motorola, and 
G.E. were all pretty good about this (and Intel, et.al.).

> > You probably[!!] need some filtering/debouncing/conditioning if you go
> > through spinning mechanical contacts. Modulation, filtering, or digital
> > shift/sum registers can do this, or use latches with large hysteresis on
> > their inputs. (See someone's design manual on linear and/or interface
> > i.c.s.) The parallel/serial/parallel components usually make some
> > provision for this; if you code up some kind of 'bit-banger' port [think
> > PIC?], the filtering can also be coded-in.
> 
> I looked at some liquid-interface sliprings, from Mercotac, and at
> some more traditional slip ring assemblies; but they're all way
> too big. The shaft I need to mount the slip ring on is less than
> 1cm in diameter, but there don't seem to be standard slip rings
> with less than a one-inch or so bore :-(  Maybe I'm looking in
> the wrong places.
> 
> > You may find some optical couplers -- that would reduce or eliminate the
> > bounce and wear problems. I'ld give this a _serious_ shot [maybe
> > Digi-Key??]. Then you only have to get power through the rings, and DC
> > power is [relatively] easy to filter.
> 
> The notion of an axis-mounted IR interface is appealing, if I'm
> going to have an MCU available to decode the IR data. And as you
> say, getting DC onto the rotor is not difficult. This project
> is based on a child's toy that already supplies DC to some
> fairly stupid electronics on the rotor, so adding some smarts
> in the form of an MCU and some kind of serial interface (ideally
> wireless) would be WAY more straightforward than my current
> approach.

There must be some clever way to position an IR-transistor so it's in the
beam of a broad-beam LED spinning on the rotor, and the reverse at the
other end if you need data back off the platform. Note the spectral peaks
of the LED and phototransistor need to be in the same ballpark - again,
the manufacturers' app notes are your friend in this - they often
recommend by pairs (TX and RX).

IR is more immune to ambient light than is visible, expecially when
matched with some simple modulation (i.e., square-wave) - hence the
remarkable effectiveness of TV remote controls. (I bounce the beam off our
ceiling lamp's globe in order to hit the VCR. Sometimes I just point at
the opposite wall. Again, think 'reflection' when you lay out the optic
paths.)

> Thanks very much, you have already inspired some more productive
> thinking on my part.

_Lots_ easier to suggest these things than to make them work! #8-)

Keep us posted.

 - John Mills
   john.m.mills at alum.mit.edu