|Parish | Peculiar | Pedantry | Personal | Photos | Plateways | Positronics | Post | Professional | Programme | Programming | Places|
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.
You cannot do electronics without components, so here's a list of suppliers that I use: (Current needs are shown at TOBUY)
Now has its own page at Arduino
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.
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.
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.
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.
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.
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!
|This page is copyright, and maintained by John Hurst.||6900 accesses all since
17 Nov 2022
(accessible only on local network.)