Processor Control of Lineside Items
#251448 (In Topic #13813)
How to automate and control signals, level crossing gates, etc.This will become an occasional series of items that will concentrate more on the method by which I have - and still intend to automate certain aspects of my John Street layout (http://yourmodelrailway.net/view_topic.php?id=14501&forum_id=21&page=1) so that in a running session I can concentrate on actually driving the trains around the layout and not have to worry about which signal needs to be changed and whether it can even be legitimately changed to a proceed aspect and to automatically open/close the Level Crossing gates. I like to see a lot of animation on the layout other than the trains moving around.
To supplement the John Street layout topic, this will be somewhat more technical in nature and it'll leave the main topic as to how the layout itself is being built up and run.
Up to press I've automated a Home signal and Theatre Display on the approach to the Terminus and installed a number of Uncoupling Ramps for the tension lock type of couplings within the Terminus, and I'm almost there with a Level Crossing controller as well as progressing the signalling project for the entire layout; the Terminus area has been more-or-less completed (but not yet installed) with the remainder of the layout not far behind.
There are numerous methodologies of controlling signals, etc. from shop-bought items from the likes of TrainTech - to mention just one (apologies to other companies for not mentioning you [my mind has gone totally blank on it at the moment!]) but this topic is to concentrate on MY methodology of DIY. Personally, I get far more satisfaction from building something myself rather than going out and buying a ready built unit (which may/may not do what you might want to achieve on your layout).
Even on the DIY front there are various ways of automating signalling. My first layout - a rather simplistic layout - simply used a number of 1N4148 diodes and biasing them either "on" or "off" via switches and point voltages to achieve a given signal aspect. It was a bit clunky, but on that rather simplistic layout, it worked fine.
From here on in, I'd like to state that I am not an authority on any of the following bits of kit or technologies other than to say I know of their existence and in the case of the PICAXE range of processors how I have got them to do what I want them to do.
Moving along, hardware-wise, other than numerous diodes or, maybe, even relays, on the electronics front there is the Arduino Uno (and other types of boards from Arduino - the Nano, the Mega and others - not to mention the cheaper clones of them). Personally, I'm not particularly versed in what this series of boards can and cannot do but essentially they are built onto a ready-made circuit board and can be easily expanded by what is known as "shields" (add-on boards) which plug onto the Arduino pcbs to give some versatility and expansion of functionality. I think they can be made to do pretty much the same as I've managed with the PICAXE series of processors. But you do need a knowledge of the C++ language in order to program the Arduino series.
That is not where I'm coming from - I know absolutely nothing about C++. My knowledge only stretches to the BASIC language in one form or another and dates way back to the days of the Sinclair Spectrum (that's showing my age!). Whatever language you might choose to work with, it's only a matter of learning the syntax relative to that language and then using the right hardware for it.
The programming software used has the built-in capabilities of converting (or compiling) your code, whether you program in BASIC or C++, into the language that the processor understands - more easily understood as the "machine code". I once tried to directly program the Z80 processor of the Spectrum (in machine code) in order to gain additional memory space - not easy - and I still ran out of memory! 48k of memory is miniscule by today's standards.
Getting back to the subject of hardware for my layout. My criteria was to keep costs down and the learning curve short. Hence I decided to continue with the BASIC language together with the relative cheapness of the PICAXE chips. OK, so the whole PICAXE system was designed more as an educational system for schools. But, in my mind and those of many others, it can be so much more. Also needed is (as I build the kits) a piece of stripboard and a few other small/cheap components like resistors, capacitors and +5volt regulators - these PICAXE devices, like most logic chips, only run with a well regulated +4.5 to +5v supply.
Hence I have gone for (and I hasten to add, I have no connection to this company other than as a user) the Revolution Education series of PICAXE chips. These are standard PIC chips from Microchip Technology but with a pre-programmed on-board bootstrap interpreter that enables the use of the BASIC programming language.
That's a very brief introduction to making a start on automating various aspects of a layout. Incidentally, both the PICAXE and Arduino can be programmed from a PC or Laptop without anything more than a USB port and a cable - all software to do the programming is either supplied or free to download.
A couple of links for those that might be interested in looking deeper into this area of possibilities:
Coming up next….. My projects, either working or in the planning/build stage.
I first mooted the idea of using the PICAXE microprocessors to automate some aspect of John Street way back in Sept 2016 (see my 2nd post). And following on from this first success, decided to take it a whole lot further rather than simply dream about what might be do-able.
If the option of using the basic Revolution Technology PIC processors are used, they can hold around twice the program size of the equivalent PICAXE and the programming itself can be more involved, more complex. Thus is the simplicity of the BASIC language as opposed to the rather more complex C++ command set. The number of input/output ports is the same which ever option is chosen, PIC or PICAXE, it's the same basic chip. I should mention that the PICAXE chips come in a variety of pinouts versions, from 8-pin, 18-pin, 20-pin, 28-pin and 40-pin varieties. Anyway for what we, as model railway enthusiasts require, complexity I don't think really comes into it. Although that just depends on what you might want to achieve.
Each port of these processors can only source/sink a maximum of 25mA with an overall capacity of 185mA/200mA or so per chip (chip type dependant). Therefore, if more than one LED needs to be driven per port (such as the signal itself and a mimic board LED) or if the overall chip current capacity is likely to be exceeded then the use of a driver chip such as the ULN2003a or ULN2803a (or even a basic transistor) can be used to increase the current capacity of each output port to approaching 500mA - more than enough for driving any peripheral, even DC motors. Not that the driver chip will be capable of driving all 7 or 8 ports at 500mA each - the datasheet does specify a maximum current at a certain duty cycle. Driving 3 LEDs on each output at 15mA per LED still only comes in at 350mA (for the 8-port ULN2803a) but at a possible 100% duty cycle. So this needs to be bourne in mind.
My first project was to make a Theatre-type display on the approach to the Terminus together with the Home Signal controlling the access. As the Terminus has six roads/platforms to arrive into, I also needed to have inputs from each of the numerous points so that I would only get a green aspect when a correct path had been set and when nothing was likely to cross the path of the incoming train, i.e. by a shunt movement.
This involved the 10 points of the Terminus, a red/green Home Signal, a couple of sensors and 4 outputs for the display - i.e. 18 input/output ports. This decided the chip version I needed to use - a 28-pin PICAXE 28X2 has a possible 21 input/output ports. The other pins are for programming, supply rails, an external resonator to provide for other than the pre-programmed speed of operation and a reset pin.
The programming was created to keep prototypical signalling schemes as far as possible and this involved keeping the Home Signal at danger until a train was on close approach (this is to ensure it slowed down sufficiently prior to access to the Terminus and to allow for the train to stop prior to the signal should access to the Terminus not be available at that time) before turning to a green aspect and only then if there was a valid path for it to arrive at a platform. Along with the green aspect, the 7-segment display would then also show the platform number. At the time of building, designing a fibre-lit theatre display was not realistically possible.
The programming was relatively straight forward, mostly IF (this condition)..THEN (do this) command strings: so we wait for the approaching train sensor, then checking a series of points and if a valid path was available, give a green aspect and display the appropriate platform number on the 7-segment display, then wait for the train passing the next sensor and turn off the theatre display and go back to a red aspect, then await the next approaching train. If access was not possible, due to a points conflict, then the danger aspect would remain until the line did become clear to enter the Terminus.
The programming editor features a "simulator" mode so that the program can be stepped through command by command before programming the PICAXE itself. Make a mistake and on the layout it doesn't do quite what you thought it would? no worries. Correct the program and re-program. Simple.
As probably noted on the John Street pages, the project involves:
the PICAXE 28X2 processor driving a
4511B BCD decoder - 4 control lines in from the processor : 7 lines out to the
7-segment display LuckyLight 1202 KW1-321CWB-JY - a 8mm (0.32") high display.
The processor also drives 2 outputs for the Home Signal via a
ULN2003a (7-port) driver for the
Red and Green LED aspects (copied to the Mimic display),
two RPR-220 in-track sensors and
10 inputs from the various points.
One processor port could have been used to combine the Home signal Red and Green outputs. This could have been achieved with the addition of a 7404 inverter chip: the signal output would then be routed direct to one port of the ULN2003a to provide (say) the Red aspect and also via one 7404 port to invert the signal and then be passed to a second ULN2003a port to provide the Green aspect. So that if the Red aspect is set to be a "high/1" output it would switch on the ULN2003a and pull the supply via the LED to ground, thus lighting the Red aspect, while via the 7404 the output here would become a "low/0" signal and the ULN2003a would be inactive and the Green LED remain off. If the signal output on the processor went "low/0" then the direct line to the ULN2003a would also be "low/0" and the Red LED would remain off, whereas the signal via the 7404 would be inverted and become a "high/1" and turn on the Green LED. Easier to work it through on paper than it is to describe in words! If a Yellow aspect is also required, then the processor still only needs to output the Red and the Green signals. This time both would be passed direct to the ULN2003a and again both would be passed via a 7402 NOR gate so that if both Red and Green signals were at a "low/0" level the output would be a "high/1" and would drive another ULN2003a output producing the Yellow aspect. I've not delved into the Double Yellow scenario just yet but should be simple enough with a bit of logic fiddling to make it light correctly - unless your processor has enough ports to drive each LED separately of course.
But, in this case of only needing a Red and a Green aspect, and as I had sufficient ports available to me, I left them as separate outputs from the processor. But the above idea of producing a Yellow does come into its own further down the projects.
Next up……servos and a working set of Uncoupling Ramps.
The next working project has been to make and semi-automate a number of Uncoupling Ramps using miniature SG90 servos for the tension type of couplings. The size of these servos: 32.2mm long, 11.8mm wide, 31mm high (including the arm) and only 9gm in weight. The SG90 servo cable has wires coloured Orange for Data, Red for +5v and Brown for 0v/ground. Other colours may be seen depending on the manufacturer of the servo - always wise to check the spec sheet.
For those not familiar with servos, they (generally) operate/move an arm (known as "horns") over about 180 degrees, have 3 wires to operate them: a +5v supply, a ground (0v) connection and a Data line. Some servos can be modified to produce a 360 degree rotation of the arm. But we'll be concentrating on the normal (unmodified) servo with the 180 degree movement.
One problem with servos is that they have a tendency to generate a lot of electrical "noise", both on to the supply wires and also to a degree in a radiated form. As far as the supply wires are concerned, a decent amount of decoupling capacitance is required - a small 0.1uF ceramic capacitor to reduce any high frequency noise and some large decoupling capacitors to keep the output from the +5v regulator smooth and free of voltage/power "brown-outs" as some of these servos can take quite a hefty amount of current, sometimes in excess of an amp. Just using a normal 7805 regulator on its own might not give sufficient regulation without the addition of the reservoir/decoupling capacitors or if the supply to the regulator doesn't have enough headroom.
It should be noted not to use the same +5v supply for both servo and processor due to the electrical noise coming from the servo on the supply cables. Keep the supplies on separate +5v regulators (but keeping the 0v rails tied together). It's also a good idea to keep the cable away from other sources of electrical interference, such as the DCC wires and mains supply cables as the servo's Data cable acts as an aerial and any interference introduced onto this cable might be interpreted as a valid signal to move the arm.
Servos seem to be prone to jitter and twitching of the arm and, in this case at least, it was not fixable by the addition of supply line decoupling, etc. when using the 'normal' commands to move the servo arm. Some additions to the normal circuit that feed servos might include, as noted above, one or more 0.1uF ceramic capacitors and up to 6800uF of electrolytic capacitors (rated 15v min) and a 10k resistor in line with the data feed from the processor. Some comments I've seen mention a 330R resistor (which I tried) without much success. Also it has been suggested to lightly twist the cable between the processor and servo to try to eliminate stray noise or to pass the cable though a ferrite ring a couple of turns to introduce a bit of inductance to help stop noise and interference or even to add a 0.1uF capacitor between the Data cable and either the +5v or ground wires. It seems to be a different set of circumstances and fixes required dependant upon all manner of things, such as circuit board layout, positioning of the servo in respect to its surroundings and how the cable runs between the processor board and the servo.
As far as the "data" required for the servo is concerned, the servo likes to have a regular series of pulses 20mS apart with a positive pulse of between 0.75mS and 2.25mS - with 1.50mS representing a central position for the arm (some variation of these figures is servo dependent).
The PICAXE series of processors can very kindly produce a continuous series of 20mS pulses using the SERVO command and upon this is added the required positioning pulses using the SERVOPOS command. The SERVO command starts the timing of pulses while SERVOPOS inserts the required positioning pulse length. The syntax for the commands are:
SERVO B.4, 75 ; start the 20mS pulses on port B.4 and move the arm to the left-most (-90 deg) position - every 20mS a 0.75mS pulse will be added and this will hold the servo arm steady at that point
SERVOPOS B.4, 150 ; move the arm on port B.4 to the central (0 deg) position and that 1.50mS pulse will be output every 20mS (until the next SERVOPOS command)
From my experience, if you try to slow the servo down too much by adding PAUSE commands between each SERVOPOS command, it can lead to some arm jitter which is nigh-on impossible to get rid of no matter how much decoupling, etc. is thrown at the circuit. I may be wrong here, but that's my experience of trying to get a smooth operating speed for my level crossing gates which require moving at a slow speed (more on this in the next article). A servo normally takes less than 0.5 second to swing the arm through 180 degrees, so to slow it down to swing 90 degrees in maybe 5 seconds or so is quite a slowing-down of the servo. Also, I have issues of where the gate suddenly flies off to the servo end-stop (I presume that's where it goes) before flying back to continue its intended movement. I feel that this has something to do with a timing issue between the commands, but I could be wrong. But the level crossing is for another day.
Yet in my program the PULSOUT command still uses the same PAUSE command (as with the SERVOPOS command)….and the servo seems to work much smoother. The syntax for this command is:
PULSOUT B.4, 150 ; send a pulse on port B.4 to move the arm to the centre (0 deg) position
PAUSE 20 ; wait 20mS before looping back to the next PULSOUT command (as part of a FOR…NEXT loop) - this pause can be any suitable length to make the movement of the arm as slow as you would like it to be.
The pulse shown here is for a 1mS to 2mS pulse, whereas it might normally be 0.75mS to 2.25mS as noted above
The difference, as I see it, is the SERVO command sets up a continuous series of timing intervals as required by the servo and the SERVOPOS command sets the length of the pulse that governs where the servo moves to. Whereas the PULSOUT command simply puts out a single pulse to control where the servo moves to one step at a time and so long as the minimum required interval between pulses is maintained there can be no timing errors. The timing of the next pulse by using PULSOUT is controlled by taking into account the length of time any intervening commands take together with any pause command to pad out the timing to get the right speed of movement. That's my theory of it anyway, rightly or wrongly. I stand to be corrected here.
Components used for the Uncoupling Ramps:
PICAXE 18M2+ processor,
a rotary switch to select the ramp to be raised
a push button to activate the raising of the selected ramp.
The program was written such that a servo once selected would slowly raise a short length of plastic, about 35mm in length (taken from an old VHS cassette case - the same thickness of the track sleepers - I said earlier, cheapness and DIY! - laid between cut-away sleepers to disengage the tension hook couplings, wait for around 10 seconds to allow the rake of trucks or coaches to move away and then slowly lower the ramp again back to its resting position.
Two thin nails were put through this "ramp" and glued in place and allowed to freely pass through the baseboard - these nails are to keep the ramp aligned and central within the track. The actuator used on this design was a short length of 3.5mm OD pvc tube (to allow for flexibility in movement/alignment) inserted and glued into the ramp and connected at the other end via a short pin through the servo arm itself. The servo being mounted, in this case, on another offcut from the VHS tape cassette (other methods of mounting these servos are available!).
Initially while testing, I found that with the SERVO/SRVOPOS commands being used that the small 7805 +5v regulator got impossibly hot due to each servo being constantly powered with the 20mS pulses. Changing to the PULSOUT command reduced the current consumption to acceptable levels. At the time of building and testing I was not aware of the amount of current these servos can take - something in the order of up to, and sometimes in excess of, 1 amp - not a widely publicised fact, a fact I found to be strange given these servos can be used on battery powered equipment, such as model aircraft. And not all SG90 servos are equal in respect of how much current they take!
The end result is that the Uncoupling Ramps raise (and lower) nice and slowly so there is no chance of sending a truck or loco sky high at a rapid rate of knots if the positioning of the coupling between trucks is not correctly aligned before the ramp is raised. Some careful adjustment of SERVOPOS figures is required so not to try to pull the ramp down through the baseboard on lowering the ramp or to raise it too high so as to lift a truck off the rails, just enough to disengage the couplings.
That's the Uncoupling Ramps about covered for now. Next time I'll take a look at the Level Crossing Gates - work is still in progress here, so maybe a few days or so before posting this next item. Bare with me.
I'm bearing with you. Definitely not baring with you though.
Â©Nigel C. Phillips
T'was early this morning I twiped the item up with eyelids wide shut at the time. Shame the auto corrector didn't pick it up (but I guess it was a valid spelling, although not necessarily in this context!). Memories of Morecambe and Wise with Andre Previn…… classic sketch. That's my excuse.
Last edit: by Dave C
or suggestions as to how to make any of these projects better or in a different way,
or suggestions as to other subjects I could cover,
do please contribute.
It's all about learning. And I'm always keen to learn - keeps the grey cell active!
Other items on my list to complete and then write up over the coming months:
1. coming up, end of next week hopefully - automatic train-activated Level Crossing Gates using Wills SS56 kit (across a single track line); followed by….
2. automatic colour light signalling, using Eckon signals - this is mostly related to linking processors, together with….
3. automatic semaphore signals using Ratio kit 486, LNER upper quadrant signal (if my fingers are supple enough!).
Most of these have been covered before in one form or another, mostly as standalone items and/or as manually operated, but my idea is to link them together using the PICAXE series of processors so that they all form part of the overall track plan.
There's been a bit of a delay in getting this next topic sorted due to problems with linking the servo to the level crossing gate itself. So, apologies for that. More on the gates in a moment.
Moving on and yet keeping on the subject of servos, this item is about automating Level Crossing Gates so that they will open with an approaching train (hopefully in plenty of time) and then close again once the train has passed - with the proviso that if a train needs to reverse into the siding, the gates need to remain open until that movement is complete. It also needs to recognise when a second train is approaching and to keep the gates open until the second train has passed. It's all in the software!
This kit is built up using a pair of
Wills SS56 Level Crossing Gates (4mm OO gauge) and again a pair of
SG90 servos across a single track line (and with adjacent access to a siding) together with a
PICAXE 18M2 to control it all and
2 RPR-220 infra red in-track sensors and
LM339 voltage comparator and
1 infra-red separate transmitter and receiver (across-the-track sensing) and
1 point for access to the siding.
First things first - the automation bit. Train detection. For this I have opted for Infra-Red transmitters and receivers/sensors.
The RPR-220 Infra-Red transmitter and receiver pair can be regarded in exactly the same way as normal, individual transmitter and sensor items except that it is packaged as a single item and is suitably sized so as to be buried into the baseboard, which will sit nicely between the tracks and fit between two sleepers (hardly visible). The Tx/Rx pair measures just 4.9mm x 6.4mm x 6.5mm high. Forward current to the transmitter is to a maximum of 50mA with a forward voltage of 1.34v - generally, the current taken should be around 17mA. The receiver collector needs to be fed via a 470k resistor (from a +12v supply) or 10k (from a +5v supply) and this will give a good degree of sensitivity. As the output from the collector of the receiver can vary with the amount of reflected (Ir) light, it is advised to feed that output into an LM339 comparator - this is a 4-port device so is expandable for other sensors on the layout. This will give a clean change (no bounce) in voltage levels to be applied to the input of the processor. The point at which that changeover takes place can be varied by means of a 22k pre-set resistor on the associated port of the LM339 so is relatively independent of the reflected light.
I had emailed/requested Rob Paisley for permission to include the (copyrighted) circuit here, but at the time of posting this, I have received no reply. So below is the web link to the page - the circuit is the last one on the page entitled "4 - INFRARED PHOTO-DETECTORS USING AN LM339". If permission comes through at a later date, the circuit will be included at that time.
http://www.circuitous.ca/ATDetIR.html (the web page has changed from that shown in the actual circuit diagram).
Also see http://www.circuitous.ca/Comparators.html for a complete write-up on voltage comparators. Overall, this is an excellent website for all things electronic, quite a lot railway related or adaptable for it.
Using another port of the LM339, I also used Ir Tx/Rx separates as individual items as an across-the-track sensor pair set at an angle across the track such that there would be no gap sensed between trucks and therefore the gates would not be closed against the train prematurely.
In the circuit noted above, when the sensor (receiver) becomes blocked, i.e. no train passing over, the LED lights. Or to put it another way, the output goes low. This state can then be sensed by the processor and action taken as appropriate. If there is a need for the LED to be off, i.e. the output voltage to be high, when the sensor is blocked, simply swap the two inputs over. Incidentally, to cater for differences in sensor components or positioning, each mid point pre-set voltage level can be individually set rather than using the same voltage level across all ports, as shown in the circuit by using the two fixed 10k resistors.
Now moving on to getting the level crossing gates themselves working.
EDIT: As noted above, permission from Rob Paisley has now been received for me to reproduce the circuit diagram indicated above. For this, see my post #16 further down the page.
Last edit: by Dave C
The problem here, yet again, like the uncoupling ramps, is getting a smooth operation/swing of the gates. It was thought the ideal time taken to swing one gate would be around 5 or 6 seconds. Any jitter on either servo would be wildly exaggerated due to the length of each gate and the rather flimsy structure of the gates themselves. So getting a 'smooooooth' servo operation is of the utmost importance. So that effectively ruled out using the SERVO/SERVOPOS command pairing and making use of the PULSOUT command. But I did try using the twin commands just in case - no, jittery.
I was able to get the right speed of swing but there was still quite a lot of flapping about of each gate which got worse as the gate swung through its 90 degree swing. As mentioned in the previous post, copious amounts of capacitance was added across the +5v supply rail but this made no real difference. But this wasn't simply just servo jitter - as I later found!
The level crossing gates themselves each have a length of wire inserted and glued into a hole drilled (very carefully!) into the gate post. This provides the gate pivot pin.
One thing I did notice on the original setup, and more by accident than anything, was that the servos were not exactly aligned underneath the gate pivot pin which passes through the baseboard and then connected directly above the centre of the servo arm through a choc-bloc connector - see the photo above. This was most likely due to a misaligned mounting and/or non-alignment of the servo arm wire. Neither wouldn't have helped keep the movement smooth.
Alignment of the servo to the gates seemed to be a huge problem in trying to get it all aligned correctly so that not only did the gates swing through the 90 degrees - that was simple enough once the PULSOUT figures in the program were sorted, but also that they swung horizontally and not either scraped the road surface or rose into the air - namely that the gate (hinge) post needed to be truly vertical.
So the initial arrangement (in the picture above) was eventually scrapped as being too difficult in the space available to me to make the adjustments so I opted for a remote servo with a linkage to the gate pivot pin.
This new arrangement involved having the servo moved away from under the gate pivot pin and using a couple of linkage wires to link between the servo arm and the gate pivot pin. I can't claim any originality for this method, but it would appear to be easier to setup - certainly in places where there is little wriggle room for arms/fingers/screwdrivers/you-name-it!
The above is a test mock-up of the actuator to make sure I could get enough "swing" on the gate with the servo and arm at the top (just held in place with a screw) and the linkage to the level crossing gate at the bottom. With this arrangement I can get around 105+ degree swing - more than enough.
If you're anything like me, I couldn't drill a truly vertical hole if I tried. To overcome this shortcoming in dexterity with a drill I initially drilled a larger hole through the baseboard than was required then glued a small square of relatively thin plastic (part an old credit card would be ideal) with a hole very slightly larger than the gate pivot pin to pass through in the correct place on the top of the baseboard. Then once the glue was fully dry, glue a similar piece of card under the baseboard and, before the glue had set, it was adjusted to obtain the correct alignment of the gate such that it wouldn't scrape the road surface nor would it ride high as it swung. Then once that glue was dried and set solid, the linkage arms were fitted along with the servo sitting between blocks of wood (about 18mm - 25mm high) - or in my case, on a short length of angled wood moulding.
In the mock-up (just the servo arm, linkages and dummy pivot pin - just to test to see if it worked) the linkage arm from the gate pivot pin is about 15mm in length (about the same length as the servo arm). The length of the adjoining link can be any length that suits the space available. Some old Twin&Earth house wiring was used here, but any suitable stiff solid core wire that comes to hand would most likely be usable. Some positioning adjustments can be made using the choc-bloc connector (or within the servo program) and by altering the length of the shorter linkage arm if the full 90degrees (or thereabouts) cannot be obtained. It's very much trial and error to adjust. But this mock-up largely worked and was hugely better than the direct-drive from the original servo version (above).
Final installation of the servos and linkage arms - the small pieces of plastic card can be seen where the pivot pin emerges from the layout side of the baseboard.
So to recap, as this series is about automation. The whole module is controlled by an 18M2 PICAXE processor as described earlier. The adjacent Halt Home signal is normally showing a red aspect (the gates being held closed to trains). A train is detected some distance away in its movement towards the level crossing as it crosses an in-track "approach" sensor. The gates then swing open and this in turn triggers a signal to the signalling processor to change the Home signal to a green (or a yellow) aspect for the train to pass - provided of course this next "block" is known to be clear. The train gets detected as it passes over the in-track sensor shortly after the Home signal. This is again then passed back to the signalling processor to put the signal back to a red aspect, the preceding signal to a yellow aspect and to flag the next "block" as now being occupied. Once the train has cleared the across-the-track sensor beyond the gates, the gates then close to trains. And we await the next train to cross the "approach" sensor. In the case of a train requiring to reverse into the siding, the across-the-track sensor remains blocked, the gates remain open and once the in-track sensor again detects a train (with the point noted as being set for the siding) and the processor will then wait until that sensor is again cleared as well as the across-the-track sensor before opening the gates.
I should point out that servos are not the only method of activating Level Crossing Gates. There is also the option of Stepper Motors - but these also require processor control to move the motor rotor and to count how far the rotor has moved - and straight DC Motors with low reduction gearing to reduce the speed to an acceptable level. Also needed here would be some form of method of stopping the gates in the correct position, either with microswitches or Hall Effect switches (little solid state devices that react to the effects of a magnetic field) and with a small magnet mounted on the gate or on an arm mounted under the baseboard.
That's about it for the Level Crossing. Next up will be the automatic signalling.
I'll re-read it to see if anything sinks in ….. :roll:
Apologies if I make it sound like you may know very little about electronics - and you may in fact know more than I do in some areas, but I need to pitch the answer at some level where anyone call understand it.
Essentially a voltage comparator is a device that compares one voltage coming from a circuit that has a variable output voltage - such as a light sensor that gives an output voltage dependant upon the amount of light falling on it - and at some pre-determined voltage which has already been set it will switch on a light (for example).
i.e. bright sunlight = no switching on of light - input being, let's say, 4.5v
cloudy daylight = no switching on of light - input being 3.4v
darkness falls = light is switched on - input being 1.2v
The preset voltage level being set at 2.0v.
So once the light dims down, at 2.0v from the sensor, the light will switch on.
The device that does this is a voltage comparator - in the case of the circuitry already described - the LM339.
Input1 = variable voltage from the infra-red sensor
Input2 = a pre-set voltage
Output = either light on or light off
The circuit above is 1/4 of an LM339 and the output (Vout) will either be an inverted input or a non-inverted input - the input (Vin) being applied to either the + or to the - input with the preset voltage set by the two resistors R1/R2 on the other input to that used for the input. Generally used with a +5v or +12v supply to V+ and a ground (0v) connection to V-.
Hope this makes sense and I've not complicated it.
Just a quick update on the progress on this subject from this end's perspective. But just to whet your appetite……
I've been working on the software for some months - on and off (life has a habit of getting in the way) - with many restarts due to re-thinking the most effective way of achieving it all. The most difficult part (for me) has been the learning curve of getting to grips with the inter-processor communications protocol - I2C - and the rather difficult part of getting the grey cell round the various commands and which part of each command on one processor does exactly what to or from the other processor(s).
To achieve what I'm wanting to do, I'm needing to use four processors - one to handle a few sensor state readings, one to control the Terminus signalling and one to control the rest of the layout. There's also a fourth processor that is already controlling the home signal and its theatre display. This last processor needs its software updating to make it "talk" to the other units.
For those wanting to get into this side of things, as before I'm using the PICAXE series of processors and the I2C commands involved are hi2csetup, hi2cout, hi2cin together with a few others associated with how the data is handled. Regrettably, the write-up on the commands do not make it particularly clear quite what is happening and what and where is being affected. The number of times I've read and re-read the paperwork and I'm still not 100% clear in my mind. Putting a whole load of examples together in combination with the write-ups, I think I've about got it to a level that I can make it work.
And to prove it, a couple of the processors were put onto a breadboard (not overly happy with the thin, poorly connecting linkage pins), a couple of small tester programs were written up and with a couple of flashing LEDs added, it proved to actually work. So that was a surprise if nothing else!
So I'm back to continuing with the software writing - a further update with more detail will appear in due course.
So. Going back to post #9, this was all about how I used Rob's circuit to interface between the sensors (receiver) and the PICAXE processors I use. The LM339 was used to give a "clean" switchover between being either ON or OFF, (this is what processors like) - no dithering or varying levels if the light or surroundings change slightly.
The following circuit is the basic setup, and can be found at http://www.circuitous.ca/ATDetIR.html
There's loads of information on this page regarding across the tracks sensors.
The only difference between these circuits shown and that used on my layout is that instead of where the LED and resistor is shown a direct connection to the PICAXE processor input is made. Take no notice of the web address shown on the diagrams themselves - this is no longer applicable - use that web link above shown in the text.
To make better use of the LM339 - a four channel device - the circuit shown below can be found further down the web page indicated earlier.
The sensitivity of the sensor receivers is determined by the values of R1, R2, R3 and R4. I tend to use 470k as indicated in the parts list; this seems to work well for me. The arrangement on these circuits is such that when a train breaks the beam between the emmiter LED and the sensor receiver, the LED turns on. If your preference is for the LED to turn off under these conditions, simply swap the input from the minus (-) to the positive (+) and the "reference voltage" goes to the negative input. A variable resistor in place of R5 and R6 (or one for each input) can be used to set the "reference" to suit conditions, such as the distance between emitter and receiver and, maybe, what ambient light is falling on the receiver; adjust it to suit your conditions.
I hope the wait has been worth it and you can take home some more information on this subject. The entire site is a minefield of useful circuits for all sorts of projects - not just for model railway folk; just go to the home page at http://www.circuitous.ca/CircuitIndex.html
EDIT: just found the first link doesn't work - there's nothing wrong with it, just gives a "Page not found" error and the second link gives a "placeholder" message. Weird, both are correct. I've taken out the full stops at the end of each link/end of sentence. Think the second link (to the home page) should now work, not sure about the first link to the correct page. Checking it out.
EDIT #2: the links still don't seem to work correctly - I know not why! Just copy and paste into another browser tab, it'll work fine then. Sorry about that guys. The links on post #9 work correctly - maybe it's an update/timing thing and perhaps it'll work fine tomorrow.
EDIT #3: How awkward can inserting a link be? Hopefully, got it sorted this time! Seems like an errant 'full stop' was being put at the end of the link address. Apologies for those who found it not working.
Last edit: by Dave C
Not sure what to say Dave - so I'll just say nice drawings. :cheers
For me, the arrangement of "across the track sensors" - and the circuits above form an integral part of it - is a good way of train detection for times when the track has been laid and ballasted and, due to the forethough of making a plan (what plan?! was I supposed to make a plan? oh, come on, get real!), train detection by current sensing, i.e. the need to break the track into sections so that current taken by a loco can be sensed is not a real possibility. So this arrangement has been very useful as it easily detects the entire train, not just the loco.
There are times and locations where an across the track sensor is not possible without it being very visible and obvious. It's times like this that the small "in track" sensors have been used that sit nicely between the track sleepers - far less noticable and just as effective. The only downside being that they tend to sense the inter truck/coach spacing (the couplings). But even this can be worked around.
Anyway, it's all part of this DIY automation and this electonic wizardry is part and parcel of it. Give me a soldering iron, a circuit diagram and a few components and I'm happy!
More to come of the signalling side of things (as promised earlier) as and when I get the time to finish the project off - it's a bit bigger and more complex than I thought it might have been. I'm getting close, so it shouldn't be too long before the next installment appears. Hopefully not quite a techy as the circuity shown above.
Cheers for now - and where'd I put that reel of solder……
That looked familiar. Basically an updated version of the reed magnet detection system described by Roger Amos back in 1990 using the 555 timer.
Â©Nigel C. Phillips
Iâ€™ve only just found your thread, it was a good interesting read. Automation is on my list of activities at some point!
I went down the Arduino route, at the moment it simply takes commands from USB and turns lights on and off.. so itâ€™s basically a glorified light switch! I have some of the infra-red sensors you mentioned above but have not experimented with them yet.
Your signals and crossings looked amazing. It would be great to see some videos of them working!
1 guest and 0 members have just viewed this.