Electronics
Introduction
At last! An electronics page is now added to my collection of
web pages. There is a certain irony here, since electronics was
one of my first loves (preceded only by meccano and trains), yet
is the last to be added. As a teenager, I dismantled countless
radio sets to find out how they worked, and to rebuild them in
all sorts of other guises. These were vacuum tube jobs, and in
my repertoire I made radios, amplifiers, signal generators,
oscilloscopes, power supplies, etc., etc.. Not many (none?) of
these have survived, but amongst my personal effects I have a
lab book with the results of an experiment to measure the speed
of sound using (one of) my oscilloscopes.
My interest in electronics paid off in that I was awarded the
Philips Industries prize for electronics in my final year, the
result of which was a cheque for $100 and a trip to the Philips
factory in Adelaide, where they made radios, TVs and other
consumer items, together with blowing their own vacuum tubes.
Now that was fascinating! I have had a soft spot for
Philips ever since.
Anyway, enough blurb. Now for some real stuff.
Suppliers
You cannot do electronics without components, so here's a list
of suppliers that I use:
Current needs shown at TOBUY
USB
Confused over the different sorts of USB cables? They seem to
multiply without limit, and I have found
this page
useful in sorting them out.
Beaglebone
It is a moot point as to whether this should be in my
electronics page, or in my
computing page.
Given how much it relates to hardware, I decided to put it
here.
I have reinstated a BeagleBone as the
general house automation server (as opposed to the house server,
a much bigger system!), which runs continously, and manages the
various house automation operations. Currently, this is only
the chookdoor system,
but will expand to include many of the things previously done by
the old system, decommissioned in the house renovations.
One very useful webpage I found was that by
Derek Molloy
on how to use
GPIOs and Device Trees
.
I refer to this page frequently.
Model Railway Control
I have a long standing love affair with
Trains and Railways. That, together with a lifelong
fascination with computers, and an adolescent dalliance with
electronics, means that a three-way marriage of computers,
electronics and trains was pretty much a given for my retirement
interests. This section describes the consummation of that
marriage.
Point Motors
Any model railway will have more points than it knows how to
deal with, and mine is no exception. Although not large by
model railway standards, it still has close on 100 point motors
to control. My first attempt at this was the classic schematic,
together with push buttons to set the route via each point.
Somewhere I still have the schematic, I must dig it out.
But as outlined above, the real challenge is to marry my love
of computers, electronics and trains. This started with
familiar territory, i.e., the software to drive it all. You
can see what I have done in my
Railway Pages.
First, a caveat for American readers. I am using
Australian/British terminology to describe my system, and
hence I talk about "points" rather than the American
equivalent of "turnouts". Of course, I also refer to
the system as a "Model Railway", rather than a
"Model Railroad". I hope you will bear with me.
single level drivers
The next stage of development was to build an eight way
solid state driver. This uses a single NPN power transistor
to drive each point motor, and the transistors are driven
from an I2C bus through a PCF8574 I/O expander.
Here's the circuit for a single stage of the system. The
other end of the point motor solenoid goes to +16v.
The base of the BC557 is driven from the data line outputs
of the PCF8574. There are 8 such outputs, and 8 such
transistor stages, thus giving the capacity to drive 4
points, since each point motor has two solenoids, one for
straight ahead, and one for diverging.
A big disadvantage of this circuit is that it needs a
driver circuit for every solenoid in the system. With over
50 points in my layout, that's over 100 drivers! Just the
thought of wiring all these up and testing them made me
think about other ways to do the same job.
crossbar switching
The crossbar switch is a strategy to reduce the number of
point motor drivers from order(n) to order(n1/2),
i.e., square root of n. In other words, instead of needing
64 drivers to drive 32 points, we only need 8+8=16, a 4-fold
reduction (the formula is actually 2*n1/2), since
switches are needed for both sides of the crossbar. Here's
the circuit for a 16-point system (32 solenoids).
It needs 12 driver (high power) transistors, because one
side of the crossbar is only 4 switches long, and thus is
not optimum. On the other hand, if this were implemented as
a single level driver system, it would require 32 driver
transistors, and thus still has a significant advantage over
the single level design. I settled on this design however,
because no section of my railway has more than 16 points to
a region, and using a single design for each region makes
the point motor circuitry interchangeable. If you want a
larger or smaller design, you can easily adapt this circuit.
The top transistors are actually N-channel MOSFETs, since
these were more readily available. The circuit could also
be implemented with PNP transistors in common emitter mode
(a mirror image of the NPN side), but I have not tested
this. The diodes are need to stop pseudo back paths through
other solenoids. For example, when solenoid b2 is selected,
without the diodes, current could also flow through b0-d0-d2
(as well as other similar paths) thus creating potential
false switching. Although these would draw less current and
be less likely to throw, they drain the power available for
switching, and this needs to be avoided. More to the point,
you don't want other points being thrown falsely!
The Arduino Controller
The Arduino that I am using is the
Duemilanove. Analog pins 4 and 5 are the SDA and SCL
lines to the I2C bus, going to pins 15 and 14 respectively
on the
PCF8574 I/O expander.
Useful Links
