Design Critic (updated schematic attached)

[rrinker]

   Updated Schematic addressing the issues raised posted below

With great trepidation I am posting the first version of my servo turnout controller so I can find out what I am doing wrong.
Some background: The two RJ45's in the upper left will go to fascia mounted buttons and LEDs, 2 buttons and 2 LEDs. Each gets a pair - signal and ground, if I got the pinout right. Next across the top are the connections for the two servos. I suspect 470uF caps there might not be enough. Then there is the board power input. P-MOSFET reverse polarity protection and some filter caps (probably not enough - also yes, I am that guy who draws the power legs all together instead of putting the caps next to the device). Top right is the feed from the master controller, which has 4 signals, all active low, for remote control of each servo and remote locking out of the pushbuttons. All inputs on the Arduino will have pullups enabled. Lower right is the connector for track power and the two switch frogs. This ties to the pair of relays in the lower left. And smack int he middle is the Arduino Uno that is the heart of this beast. The two jumpers shown on A4 and A5 are for centering the servos, J1 installed will center Servo1 and J2 will center Servo2. Again internal pullups will be enabled on those pins.
 So - good start, total crap, nearly there, or don't give up your day job? Also this is only the second thing I've drawn in KiCad, the other was an earlier, simpler version of this which I only showed to my best friend who IS a practicing EE (though my puny 20MHz clock speed amused him - he does high frequency RF and microwave sorts of things).

[Ian.M]

Its not a great idea to have off-board signals going direct to MCU input pins.  Some RC filtering for EMI protection and to attenuate ESD events would be a good idea.  Also, where are your button pullups and the series resistors for the LEDs?

Driving servos while powering the Nano directly from the same 5V rail can be dodgy.  The high current spikes can brown-out the MCU.  Consider adding a Schottky diode in the feed to the Nano, with the relays and servos powered upstream of it and a 470uF bulk decoupling cap downstream of it to maintain the Nano's 5V rail while a current spike is glitching the main 5V rail.

[homebrew]

So, I'm still not sure what the application of the system is - my guess would be model railway. Right?

So here are my 2 cents ...
1) General remark: Why using an arduino nano, when you could use a microcontroller directly? You are planning to do a pcb anyway ... so why bother?
2) Power input: Nice touch with the PMos - I really like that configuration. However, I would additionally spent a well dimensioned fuse. Especially in a model railway environment with long thin cables. Depending on your PSU you would have a fire hazard otherwise.
3) I/O protection. I would add R/C combinations on all inputs, just as a absolutely basic protection. Maybe also on the output lines to the servos - just enough to take the sharp edged off. Hard square waves and long cables don't generally mix well. You gonna radiate RF everywhere...

[sanwal209]

As @Ion.M suggested its not a good idea to power motors and uC with same power line without back EMF protection. Try looking for snubbers. or just add isolated dc to dc block for MCU(bit overkill). Try isolating the noisy side of power supply from clean side for uC. It is also not a good idea to drive LED from uC. Always use reverse logic (uC Pin=0 LED ON: uC Pin=1 LED OFF) Let the current sink:)

Add RC filters close to uC for buttons. 

[rrinker]

 In no specific order:

 Yes, model railroad application. The servos move the switch points. There are local pushbuttons and LEDs for manual access, the inputs from the other board (not yet designed) feed central dispatcher commands through too operate the turnouts and to lock/unlock the local buttons. The relays are to switch the polarity of the switch frog to match the direction of the switch points - which reminds me I actually need a pair of inputs and outputs for that so the RailA and RailB can be switched to match the physical installation of the servo motor - no guarantee they would be the same for both sets of points.

 It's actually working very well on breadboard, no glitches with the Nano. Could be because I am using a nice HP bench power supply too feed it that way and it handles the surges. I was originally going too feed it from individual power supplies, however each of those would source off the same higher voltage bus. I was planning somewhere around a 14V DC bus on the layout and where lower voltage is needed, some of those LM2596 based buck converters. A fuse is probably not a bad idea, but perhaps on the input to the buck.

 Pullups for the pushbuttons are also the internal micro ones. My test setup is using the Bouncer2 library for button debounce and thus far I have been unable to generate any incorrect operation even with the cheap tact switches I have and deliberately trying.

 Active low for the LEDs is no big deal, as long as there are no issues with signal and +5 sharing a pair in the cable. I was going to put the limiter resistors on the panel board, as I have not yet decided on what buttons to use. Some have limiting resistors on the LEDs and others do not.

 The Nano - well, originally I was going to need ALL the I/O lines, including ones you only get in the SMD version of the ATMegas328. Add me and surface mount soldering do not get along. However, since I have resolved the pin count issue, you're right, I could just use the ATMega328. Considering I have a)built a programmer shield already and b) have a box full of 20Mhz resonators and 22 pF caps.... 

 Version 2.0, coming up.

Thanks everybody.

[Ian.M]

Don't go active low for off-board LEDs. That's an anachronism from the days of bipolar TTL when outputs at logic '1' had piss-poor current sourcing capability and certainly couldn't maintain their oiutput level while driving a LED.  Modern CMOS logic and MCUs have much more symmetrical drive capabilities, and although there still is some advantage going active low for on-board loads, due to the typically lower Rds_on of NMOSFETs, the risks and problems of having to provide 5V to the remote board makes active high the better choice.

I'd strongly recommend 10K or even lower external pullups for the button inputs.  EMI immunity is inversely proportional to the pullup resistance as induced currents develop voltage across the pullup resistor, and must not be allowed to take the input below the logic '1' threshold.

[rrinker]

 I am going to replace using the internal pullups with external, resistors are cheap and a code mistake won't break it then. For input protection - 470 ohm series resistor and .01uF cap to ground? Or smaller R, like 220 or even 100 ohm? The switching frequency of even those remote inputs is going to be VERY slow, human pushing a button slow. It would never toggle back and forth even at 1Hz let along some kHz or higher frequency.

[Ian.M]

A T network, 10nF leg to ground and 3.3K for each arm of the T, one to the button and the other to the input should survive an 8KV human body model ESD discharge - charge sharing with the capacitor (which must be low inductance, with short leads or SMD, direct to a wide ground track or plane) keeps the peak voltage down to under 80V, and the second resistor (assume the first flashes over during ESD events) keeps the MCU's internal clamping diode current under 25mA.  Adding a PCB spark gap where the signal comes onto the board can further improve the protection at minimal cost.

Hint: to get good logic levels, place the pullups at the button end of the RC input protection circuits.  However you then have to consider what happens if they flash over in an ESD event - if the Vdd rail is well decoupled, the answer is 'not much happens' (especially if its decoupled to a ground plane or is an adequately decoupled power plane) but if its poorly decoupled or long and skinny then any voltage sensitive devices between the pullups and the first decoupling cap effective at HF are likely to be damaged.

[poorchava]

I routinely use 100R on signal lines. Gives good results. Add 100p...1n to GND if signal is prone to be very noisy or it is critical in some way.

It is always a good idea to use a resistor (eg. 1...10k) across BE or GS of every mosfet, in order to make sure that it doesn't turn on accidentally when uC pins are not configured yet or it is not programmed yet.

[T3sl4co1l]

So - good start, total crap, nearly there, or don't give up your day job?

Depends, what's in it for me?

Tim

[rrinker]

 The problem with putting the pullup at the button end is, I don't have +V available there. And I think I am missing something here, with 2x 3.3K in series and a 10K pullup, an absolute perfect to ground connection with the button will not yield a good logic low. At least not without absolutely requiring the pullup to be at the button end - that I can see working, but as it stands I can't put anything needing connection to +5 at the button side.

 Tim - that depends. There's definitely no money in it, this is for my own use and I'm willing to make the schematic and board layout freely available, along with my source code. Now if you enjoy the occasional adult beverage perhaps we can work something out 

[Ian.M]

At the button end of the input protection network DOES NOT mean at the button end of the cable.  Just put the pullup at the MCU board input, and  with the button open, after the RC network has settled, the input pin sees a 16.6K pullup.  When the button is pressed the input sees a 6.6K pulldown.   However there is one possible refinement you may wish to introduce - soft hysterisis.   If you change the resistor in the arm of the T before the cap to 1K to get a more favourable pulldown of  4.3K,  you can then conditionally enable the weak pullup only when the button is detected high to add hysterisis.  The logic '0' threshold is 0.3*Vcc, and the minimum equivalent weak pullup resistance is 20K.  A 20K-4.3K potential divider comfortably gives you fractionally under 0.18*Vcc at the actual input when the button is pressed, which is more than 0.6V below the logic '0' threshold.   Decreasing the first resistor doesn't significantly decrease the ESD resistance, although the reduced time constant may slightly decrease EMI immunity.

[rrinker]

 OK, gotcha. Makes sense now. Fell into the trap of the physical location along a wire making a difference electrically (not counting transmission line loss and all that). And that right after reading another post here where I wanted to reply that the resistor confusing the OP was wired exactly the same as the others, just drawn horizontally on the schematic.
 I'm more concerned about spurious actuation due to induced currents on the cable than ESD issues, but the software debounce library I am using has hysteresis incorporated in the detection logic. Bottom line is, I don;t want to over complicate things, but I also don;t want to spend all of my time repairing units after they are deployed. It is after all just a hobby.

[Ian.M]

I doubt you'll see any problems with induced currents due to EMI with the sort of input filter and twisted pair to individual buttons I proposed. The loop area is minimal, and your proposed 10nF cap will shunt RFI before it can be rectified in any diode junction inside the MCU.   However it may be worth building one up on protoboard with a logic gate in place of the MCU and torture testing it to gain confidence in the design before ordering PCBs

[rstofer]

I am going to suggest that you take a bigger view of the entire railroad and decide whether it makes sense to network all of these controllers along with bridge controllers (gotta have a bridge), signal lights, building lighting, etc.

Would it make sense to have everything capable of talking to everything over a 2 wire RS-485 bus?  Just tossing it out there...

http://www.bdmicro.com/code/robin/

You would very likely have the simple situation of a single master and many slaves but the 2 wire bus is capable of multi-master configuration.

It's true that standalone controllers are simpler to make.  It's also true that folks have been using the track voltage to signal for many years.  Either of these may be better than the networked setup but I kind of like the idea of a single communication network for the entire setup.  Among other things, you could automate the entire operation by using a PC as a bus master (not necessarily the only master).

[rrinker]

 Well that is sort of the big picture. This is just the servo driver part. Those inputs - they come from a much more complex board with another ATMega328 and a bunch of shift registers to extend the output count. Those modules will be linked by RS485, using C/MRI protocol. Lots of inputs and outputs, driving signals, sending commands to these turnout controllers, an reading block detectors.

 I don;t really want to make multiple servo controllers, but I can leave off parts - in some places like yards, there will be no connection to one of the RS485 controllers, so I will leave off the one RJ45 jack.

 This servo controller is just one part of the whole. I may also make some signal decoder boards so that instead of 6 output lines to display 9 possible aspects, I can use 3 lines. I liek simple though and one bit per LED is simple instead of having a code.

           

[tecman]

General comment, your transistors should have a resistor from the base to emitter, something like 10K.  this will swamp any leakage current from the micro or possible leakage in the transistor.  I see it a lot on this forum that the base drain resistor is missing.  Nine out of ten times it will work fine without it, but occasionally you will have the transistor starting to pass a little collector current.  This can possibly lead to a relay not dropping out or an LED glowing ever so slightly.

paul

[Ian.M]

Again, we aren't dealing with bipolar TTL any more.  For low to moderate sinking currents Vol is right down at the 0V rail, not one Vce_sat drop above it.

Base pulldowns are only an issue when the MCU is starting up before the pins have been configured as outputs.  After that, the pin's low-side MOSFET will effectively pull the base low via the series base resistor.

Unlike gate pulldowns, where a floating gate can fry the MOSFET if the MCU is stuck in reset for an extended period, a base pulldown seldom makes much difference.   Lets suppose a worst case leakage current of 2uA, double that of a typical AVR or PIC and a H_FE of 400, double that of a typical small switching transistor.  Ignoring Icbo leakage which isn't significant well below Vceo_max, the worst case collector current will be 0.8mA, and, except for high voltage drivers, the dissipation will be negligable.  As time in reset is usually brief and damage is unlikely to occur, base pulldowns on switching transistors driven by CMOS logic are usually pointless.  Exception:  High voltage drivers and Darlingtons.

[rrinker]

 I have replaced the original with TurnoutController2.pdf which is updated to reflect the suggestions made here. Some notes on the update:

 ATMega328P instead of Uno. 20MHz clock and reset circuit per Atmel data sheet added.

 Power supply pulls out power for the servos then feeds the logic through a Schottky diode with additional capacitors added. Main decoupling capacitors attached to the 328P instead of floating off in the power line.

 All input lines have dedicated 10M pullup resistors, no longer relying on internal pullups in the micro.

 Input lines have 100R series resistor and 680pF cap to ground

 Drives to panel LEDs have 1K resistors. I am using some fairly high efficiency LEDs in my breadboard testing and they are plenty bright at the resulting ~3ma. This may change - I am looking at some pushbuttons with LEDs built in and the LED characteristics may change, requiring a different resistor.

 Track power and frog connection lines made into 2 sets

 Who knew, tagging things with +5 and GND does not actually make them a power net in KiCad. Thus the two PWR_Flags  sitting there, it now passes the ERC. Told you I was new to KiCad.

(if it's better to attach the update here instead of back at the first message, I'll edit and make those changed. But for now, the version on the first post of the thread is the current one)

[Ian.M]

All input lines have dedicated 10M pullup resistors, no longer relying on internal pullups in the micro.

10Meg pullups?  Really?  I'd like to know what was responsible for that brain-fart!  10K would be more appropriate.

I don't see any ISP header.  It would be as well to put one on the board - standard AVR-ISP 6 pin header.   

Otherwise its looking fairly sane to a brief inspection.

[rrinker]

Oops, yes. Just a few orders of magnitude off. 

 I was just going to socket the micro, I don't have any ICSP device, I program them using the Arduino as ICSP. For my $20 LCR tester I just did it on a breadboard but I made a programming shield for ATTiny's and I was just going to make another using a ZIF socket for the ATMegas.

 My copy in KiCad has been updated, but I am not going back to edit my previous message or swap the file so no one sees my goof. Just change the M to K in your head