...an LED has been used in place of the diode...

I think sometimes people forget that LED is an acronym for "Light Emitting DIODE"...

...an LED has been used in place of the diode...

Typical forward voltage on an LED 1.5V, can be higher. Typical forward voltage on a signal or rectifier diode is 0.7V. This may make a difference in some circuits.

LED:                                                                               Signal diode:

Hi Michael,

The 1N4148 wll work just fine.. Remember that the 1N4148 's purpose to to protect  (read limit) the reverse voltage of the Optocoupler diode. This happens because when the Optocoupler LED is reverse biased the 1N4148 is forward biased limiting the voltage across it and the Optocoupler LED to about 0.6 Volts. A visible LED will likely work here too. The Optocoupler LED will protect the visible LED in similar fashion.

Best regards,

Geoff Bunza

... but why is it more codey?

Michael,

For a good (but a little technical) explanation of the LocoNet bus operation see the CML Electronics Limited page on DCC Command Buses. The simple answer is that a lot of devices may be connected to the bidirectional bus (every device has to receive and send commands and data), and as all of these devices try to use the bus there are electrical (collisions) and software conflicts. Every device on the bus has to monitor (additional software) the bus and has to have the software to respond appropriately and resolve conflicts (arbitration software). There are also a lot more things a LocoNet device can do, and have to support (with additional software) like sensing a switch input or track occupancy, taking control of the bus (arbitration again), sending commands and or the sensed information to other devices on the bus, potentially waiting for a response, etc.

A Digitrax DCC system, except when Transponding is enabled, is a simplex bus (unidirectional) with commands passing from the command station through the booster(s) to the track. DCC decoders only have to receive incoming messages. They do not even have to respond to any messages.

thanks

JohnHi

has anyone undertaken construction on strip/perfboard. If so does any one have a diagram they could share please?

Geoff,

Early on in this discussion, you mentioned using fascia mounted switches and teeny relays to control 5 servos.  I assume toggle switches would allow control from one location and that using pushbuttons would allow operations from two or more locations, such as Inside and Outside the layout.

In some locations, servos are paired, such as crossovers.  In other locations they would be sequenced, such as selecting yard tracks.  How difficult would it be to delay the relay so that it throws in the center(ish) of the servo travel to avoid shorts as the points are powered from the frog?  

Once upon a time I was an equipment engineer at a large semiconductor manufacturer.  I then had a difficult to diagnose heart aliment (been fixed) that caused atoxia that caused me to lose a lot of skills and knowlage. In some cases I just need to be reminded and some needs to be relearned from scratch.  Ohms law was an 'Oh, Duh' moment just a few days ago.  Programming? No idea.

You Geoff, and Ken and others who are willing to share and teach and answer noob questions help me enormously to move forward and feel less like a mental cripple and relearn stuff that I once enjoyed.

So, Think you

Michael Duckett

Hi Michael,

you mentioned using fascia mounted switches and teeny relays to control 5 servos.  I assume toggle switches would allow control from one location and that using pushbuttons would allow operations from two or more locations, such as Inside and Outside the layout

Yes, sort of-- This was a comment to another question I think. Without regard to using the Pro Mini as a decoder, The Arduino Pro Mini can easily be used to read pushbuttons and/or switches, and certainly these can activate servos used to throw switches, directly controlled by a Pro Mini pin-- as with the decoder project. It could easily read pushbuttons and/or switches from different locations and act on their setting/condition. There is a servo library that is included with the basic Arduino package that includes their editor. If you look in Examples >> Servo >> Sweep it will give you an example of controlling one servo and moving the servo arm back and forth (sweeping it). With one switch/pushbutton you could set up a "route"-- that is some combination of track switch settings (controlled by multiple servos). One could build the routes into the Pro Mini in many ways, including a route table that listed the servos and their settings needed to set the correct route. Or one could just set the right code that read each switch in turn and acted appropriately if it found a switch set or a pushbutton pushed.

The small relays I alluded to could control the polarity to the corresponding frogs to "juice" them appropriately. One wouldn't really need a relay to control the servos. The small relays could also operate nearby signals too.

Handling delays (usually in millisecond resolution, but one can even set delays in microseconds) is easy-- yes easy-- using delay( xxxx);  where xxxx is a number representing the delay time in milliseconds (e.g. delay(500); delays 1/2 second). This is fundamentally important to me dealing with animations.

As an aside, don't tackle the whole problem right away. Control a smaller situation first, perhaps a siding with 2 or 3 switches. Get the feel of what you're able to control, and then embellish it-- add switches at multiple sites (I would use pushbuttons by the way), add delays sequencing each switch in a combination, maybe even set up a pair of LEDs as a Signal mock-up. Along the way you'll get a better idea of what you'll need for the bigger problem. Divide and conquer the larger problem-- fundamental approach to system design.

Remember 2 VERY important things: Ask questions along the way and Have Fun!  :-)

Best Regards,

Geoff Bunza

People have mentioned servos used to throw turnouts, which I'm trying to achieve. What I've found is that when you first apply power to an analog servo, it will go through an initial period of uncontrolled motion, which can have very bad results, possibly overloading the mechanical linkage. I made some experiments where the applied voltage would ramp up slowly, or there wouldn't be a digital signal at turn-on, but I never solved the problem. 

Then I tried a couple of digital servos and they seem to eliminate this bad behavior, but I don't have total confidence yet. In your 17-servo demo, your captions said that you start them one at a time to avoid a power surge, and I certainly saw no sign of any initial lurch. Can it be that your servos are the digital type, and they all get the power supply at turn-on, but the digital signal doesn't appear until the processor's program gets going, and then you're able to start them one at a time, as you show? That would be a fine thing. But maybe for both analog and digital types, the behavior varies between manufacturers and models, so what happens with yours might not work with mine. I've bought cheap little things and maybe I'm suffering accordingly!

Also, I saw a product that Tam Valley makes which detects stall conditions of a servo. Using this, they can make servos self-program the end points of their travel--that's assuming that something mechanical limits the motion, as a turnout would. And once it's set up, I assume they can detect that the servo has hit an obstruction between its normal end points, and it can protect itself and maybe sound an alarm. Have you ever tried this, and what do you think about such a thing as an add-on to a servo controller?

Analog servos are pretty much a legacy item now in the RC field. All the radios and receivers use digital and have for several years.

Hi John,

All the servos I use are relatively cheap analog servos. The reported wild start up behavior may speak to an uncontrolled signal being fed to the servo while the electronics is powering on.

I really haven't thought of detecting a stall condition. This is why I provided for setting the endpoints of the throw via CV control for each servo-- much simpler. It is an elegant and intriguing idea though. Perhaps some other modeler will try to tackle that problem-- maybe even me someday if I get the time. I suspect that one might well have to gut the electronic feedback circuit inside the servo to do it though, since there is actually no direct connection to the motor via the 3 servo control leads. For my own needs I don't think it would be worth it.

As an aside, there were two high current conditions I was trying to avoid: the first was all servos initially moving at max speed at the same time while powering up, and the second was to allow stopping the servo transit before it hit its maximum and minimum limits of travel (setting this condition would draw much current). The former forced me to look to sequencing the power on reset of all the servos. I actually didn't like the idea of doing this, as I would have preferred not to force them all to a known power on state, but it seemed the best solution for my need, after looking at other alternatives. The latter problem was solved by using CV values to set throw limits. I didn't really like that solution either, but I found that these cheap servos had inconsistent travel traverses, and I couldn't rely on anything but conservative stop and start limits-- which is where the 28 and 140 numbers come from. Fooling around setting these limits needed to be done for each servo I had tried. ...And yes, I still think it was worth it in order to keep the costs down.

I do not have great experience with the name brand commercial servos to see if they are any better. The two I tried seemed to be much more consistent.

Best regards,

Geoff Bunza