EMI suggestions please

[Jester]

I'm in the early design stages of a push button interface PCB that will control a LinuxCNC based mill.

I cobbled together an Arduino (just for proof of concept) using this -->  software to communicate with LinuxCNC:  https://github.com/AlexmagToast/LinuxCNC_ArduinoConnector

At the moment I have 28 buttons connected as a KB matrix (no signal conditioning) to the Arduino, that then uses the ArduinoConnector code to update LinuxCNC, via the USB port. The messages sent by the Arduino are captured by a python script on the Linux machine and converted to either: inputs, Keystrokes, or text based on how you configure the script. This is all working, however it's temperamental while the ac servo's are running.

The ac servo's I'm using work great but they broadcast enough EMI to rival a small radio station. I fully appreciate that my cobbled together proof of concept shown below with wires hanging in the breeze is a disaster from a EMI rejection perspective. Strangely for short spells everything works as expected, however often and only when the servo's are on it can be really erratic receiving all sorts of bad messages and the existing code has no error checking.

Hopefully just getting the circuit onto a PCB with a back plane and short traces will help. 

1) The yet to be ordered PCB is presently 2 layers, thoughts on using a 4 layer board to help with EMI?
2) Any and all suggestions are welcome for EMI mitigation, I much prefer to add a few filter components now than have to spin the board later.

Pictures attached, everybody like pictures

Questions are welcome.

[moffy]

Switch inputs are very susceptible to noise and need some noise conditioning e.g. caps, resistors and schmitt triggers.

[Benta]

Something's wrong with the 12-key part.
The keys are partially unconnected, and you cannot decode 12 keys using four lines.

[Jester]

Something's wrong with the 12-key part.
The keys are partially unconnected, and you cannot decode 12 keys using four lines.

The matrix is presently 4 rows x 7 columns = 28 buttons all working perfectly, the details of the button matrix associated with the alpha-numeric keypad at the top are not shown (just the pins are shown).

The buttons on the RHS use row1-4, and column 5-7, C5, C6, C7

[Benta]

That's not what your schematic shows. It shows four (row) wires. Period. No column connections are visible.
Perhaps you should post a correct schematic? Or review this one.

[Phoenix]

That's not what your schematic shows. It shows four (row) wires. Period. No column connections are visible.
Perhaps you should post a correct schematic? Or review this one.

There are subtle netlabels - C5, C6, C7.

[PGPG]

No column connections are visible.

Columns are connected using not wires but labels C5, C6, C7.
For me to be easier readable Z3, Z4, Z10, Z11 should be in the same place at schematic (Z3 were others are or others where Z3 is).
The same with Z1, Z7, Z9.

2) Any and all suggestions are welcome for EMI mitigation,

I think that to speak about EMI the destination construction should be known and not 'At the moment I have...'.
In my opinion 4 layers do not automagicaly improve EMI. Important is what is at these layers - if each signal line have next to it return path.

As you need not to read keys million times a second you can limit emissions by making your signal slopes being slow.
Interference immunity can be improved/achieved by software.

[Benta]

There are subtle netlabels - C5, C6, C7.

Subtle indeed. What's wrong with a wire? I'm not going to buy a 70" screen to be able to read this.

[Jester]

There are subtle netlabels - C5, C6, C7.

Subtle indeed. What's wrong with a wire? I'm not going to buy a 70" screen to be able to read this.

hmmm....I guess the image you see is quite different from the one I see when I expand the image, the net labels are very clear when I look and net labels are standard practice?

I sketched in the C5, C6, C7 column wires for clarity. BTW there is still a tranzorb on C6, I just edited it out of the attached image to make room for the C6 wire.

Note all 28 keys work perfectly, except occasionally when entering a key sequence with the servo's running. As shown in my original post the noise (2-7MHz) from the servo's increases by >20dB while operating.

[jmelson]

Most servo drives, especially cheap ones, just put out high-voltage square waves of varying duty cycle.  These are huge noise sources.  First thing is to isolate all cables from drive to motor from all other wiring.  I make servo drives, and put an LC low-pass filter on the motor output wires.  I use 47 uH toroid inductors and 10nF capacitors.  This greatly reduces the EMI output from the drives.
Jon

[twospoons]

You could improve the immunity of your key pad by adding 100nF across each of those 4k7 pullup resistors.

[Nominal Animal]

I'm only a hobbyist, but I've done some gamepads and arcade button matrices.  Here's what I'd do, and why:

(Click to embiggen)

In both the original and my schematic, the selected row is pulled LOW with all others HIGH, so that pressing a button on the selected row pulls the corresponding column LOW.  (I personally prefer the opposite logic, all lines idling LOW, but I don't think it matters much at 3.3V CMOS logic.)

I like to use Schottky diodes to avoid glitches when more than one button is pressed at the same time.  The ones in the above schematic are common anode dual cathode ones, like BAT54A, BAS40-06, BAS70-06.  Here, it does mean that the column inputs are pulled to about +0.3V compared to the currently active (low) row pin.

I would add pull-up resistors on each column input as well, and use stronger pull-ups, maybe 2.2k.  This means that the active row pin must sink 3mA (1.5mA when no button is pressed, plus an additional 1.5mA for each concurrently pressed button on the same row, instead of the current 0.7mA), so check the datasheet of the microcontroller you're using.  (With 7 buttons per row, that'd be 12mA max, when all seven buttons on that row are pressed simultaneously, which would not be a problem for the microcontrollers I use.)

The reason is to increase the power needed to change the logical state of the column input pins.  As it is now, when no buttons are pressed, the column input pins are effectively floating (or if using internal pull-ups, pulled up with a transistor circuit that roughly corresponds to a pull-up resistor in the 20k-80k range), so very little electric power is needed to couple to the column input pins to affect their logical state.

With my schematic, when no buttons are pressed, you need a milliwatt of power coupled to the column inputs to drop the voltage below 1V.

I would also use software debouncing, scanning the matrix at a fixed rate (timer interrupt causing one row of inputs to be read at a time), ignoring spurious state changes (say, by requiring N consecutive same states before a transition).

[Geoff-AU]

the net labels are very clear when I look and net labels are standard practice?

you're seeing them because you know they're there

There is an art to making readable schematics (ie, readable by someone new to the circuit) and a lot of it is underpinned by conventions but often also how the brain works.

For example, the R1, R2, R3, R4 net labels near the buttons are clear because they are located outside the matrix, in a column by themselves, and separated from other information.  The C5, C6, C7 nets on the microcontroller are clear because the wire line finishes, so the visual cue is to look at the adjacent label to see what it should connect to.  But the C5, C6, C7 labels near the switches are crowded by S15, S3, S10 annotations so the brain just skims over that whole area because it's too "busy", and when scanning for wiring connections you're deliberately ignoring anything that might be a component number or value annotation.

You could make it clearer and more explicit by bringing those net wires out above or below the columns and labelling the net on the outside of the matrix, as you did with R1-R4.  But if you bring them out below you might as well just connect the wire lines to the microcontroller like you subsequently did.  Then you also save the reader time because their eyes are not hunting all over the page for the matching annotations.

When a wire is inelegant to drag all over the page, that's the best time to use a net label.  But on both ends of the net, bring the wire out to an unconnected end, and then label it, that makes it much clearer that the wire connects elsewhere. 

For me to be easier readable Z3, Z4, Z10, Z11 should be in the same place at schematic (Z3 were others are or others where Z3 is).
The same with Z1, Z7, Z9.

It's a subtle point, but I would prefer to see them all where Z3 is.  The reason is that the zeners are protecting the microcontroller from button ESD.  Therefore, on the PCB, the zeners must be located between the buttons and the micro in order to give adequate protection.  If, on the PCB, you put them on a long wire by themselves like Z4,Z7,Z10,Z11 then they will not do a good job.  By placing them near the microcontroller on the schematic you're giving a visual cue about their purpose as well, and that purpose is to protect the microcontroller.  Therefore, on the PCB, they should also end up in a similar physical location.

[twospoons]

hmmm....I guess the image you see is quite different from the one I see when I expand the image, the net labels are very clear when I look and net labels are standard practice?

Yes, but not the way you are using them. Standard practice would be to extend the wire and put the net label at the end to make it obvious that it connects somewhere else.
But  the priority should be to use wires over netlabels, unless that would create a tangled mess.  Consider using busses as well - you still need a net label at each connection but the drawn  buss line makes it clear where the nets go to/from.

Excessive use of netlabels can make a schematic unintelligible - I'm sure we've all seen those horrible schematics where every part is in its own little box and all the connections are via netlabels .

[Jester]

Well so far I have about 10x schematic critique, and 2 responses to my actual question.

1) put a cap in parallel with the pull-up resistors.
2) add a LPF to the servo outputs.

[Nominal Animal]

Well so far I have about 10x schematic critique, and 2 responses to my actual question.

1) put a cap in parallel with the pull-up resistors.
2) add a LPF to the servo outputs.

My schematic suggestion shows how to increase the immunity of the circuit against coupled EM noise (both capacitively and inductively coupled), and I even mentioned that the lack of external pull-up resistors on the column inputs means very little power needs to couple to the column inputs to change the voltage when no buttons are pressed.

Well, that's the last time I tried to help you, that's for sure.

[Jester]

Well so far I have about 10x schematic critique, and 2 responses to my actual question.

1) put a cap in parallel with the pull-up resistors.
2) add a LPF to the servo outputs.

My schematic suggestion shows how to increase the immunity of the circuit against coupled EM noise (both capacitively and inductively coupled), and I even mentioned that the lack of external pull-up resistors on the column inputs means very little power needs to couple to the column inputs to change the voltage when no buttons are pressed.

Well, that's the last time I tried to help you, that's for sure.

Well if you look carefully at the schematic, the row pins are inputs and column pins are outputs as shown by the pin direction symbols, and the column pins are driven, either high or low at all times. So as much as I appreciate your input, I don't see how adding pull-up resistors to driven output signals will help.

It seems that some of the responders, glanced at the schematic at best, assumed that I didn't know how to connect up a keyboard matrix (was doing that and writing the assembler code for it 45 years ago), and then proceeded to jump on the bandwagon of the 2nd responder.

One would think that the fact that I included a spectrum analyzer image of the EMI from the servo drives (so anyone reading would have some perspective on the EMI) would have an inkling that I just might know how to connect up a few push buttons.

[xvr]

One would think that the fact that I included a spectrum analyzer image of the EMI from the servo drives

This is good, but not enough. Oscillograms from R1-R4 with the servo on would be much more useful.

[Jay_Diddy_B]

Hi,

You may want to take a look at the 'transmitter'. I would hazard a guess that a lot of the noise comes from the capacitance of the windings in the motors to the frame of the motors (ground).

Try a common mode choke on the wiring to each motor. You may need a three winding choke.

The cables to the motors benefit from shielding with the shield connected to the chassis.


Then use a search coil, a couple of turns of wire an inch in diameter, to check for noise.

Regards,

Jay_Diddy_B

[Nominal Animal]

All I know is OP is having issues that I've somehow managed to solve before, even though I'm only a hobbyist and they the expert.

One trick I'd consider here is using NX138AKR N-channel MOSFETs on both columns and rows to boost the actual button voltage to 12V-16V (whatever is easily available on the system).  I prefer NX138AKR over BSS138's, because although they have very similar specs, NX138AKR are faster (smaller total gate capacitance); and they have sufficiently low V_GS(th) that they fully conduct at 2.5V or so, plenty of diode headroom for 3.3V logic.  With sufficiently strong pull-up resistors on inputs and diode for each button (or half a diode pair, or quarter of a dual common anode pair in SOT23-6), you can increase the power needed to toggle the input state to above the EMI noise floor, regardless of what the microcontroller can source or sink.  The exact (high) voltage doesn't matter, either, so you can heavily filter it (using say a capacitive multiplier or a Pi filter on the PCB, just before the MOSFETs); the NX138AKR gate can withstand ±20V with respect to source (which here would be ground in all 7+4 cases).

Another trick is twisting each button wire pair (signal and return) to minimize loop area.  Arcade buttons are often microswitch-based, so needing foot long wires between each button and the PCB is common.  Although cabinets tend to be slightly EM noisy (several SMPS, display backlight PWM flicker nearby, long leads), twisting usually suffices.  In even noiser systems I'd definitely use shielded cable between PCB and each button, say Belden 9451, Tasker C114, Tasker C121 –– these "microphone cables" have served me well in such use, as long as I ground the shield properly.  I suspect, but have not tested in practice, that a resistor-capacitor parallel single point connection between the PCB ground and each button cable shield would also help (as it would act as a low-pass filter for any EMI coupled to the cable shield, before it reaches the PCB ground).

I would also use a microcontroller with native USB so I can do a direct USB HID interface, and not need any Serial-to-uinput daemon running on the host.  Much simpler, much more robust; no drivers or applications needed on Linux that way.  Teensy LC used to be perfect for this, but they're no longer made –– I've even done a few carrier boards for gamepads and such –– but Teensy 4.0 is just as easy to use, only costs a bit more (currently approx. 24 USD).  I've also used ATmega32u4 (Arduino Pro Micro clones, based on the SparkFun Pro Micro but using Leonardo bootloader) and AT90USB1286 (Teensy 2.0++) 8-bit AVRs, and have a couple of projects I'm not finished yet using WCH CH552G's.  For the CH552G's, I recommend either using wagiminator's CH55xG DevBoard, or basing your own board design on it.  I trust wagiminator's design more than my own: more experience in that sort of stuff.  CH55x do not even need a crystal for USB Full Speed stuff, so are very, very easy to implement.  JLCPCB has CH552G's in stock for assembly, so you can have such boards made for your exact requirements for very little money. 

Teensiest are easiest to develop for, because the Teensyduino add-on gives you a menu in Arduino IDE to select what kind of USB device you want your microcontroller to be: the Keyboard ones allowing a very easy interface via the automagically-exposed Keyboard object to send the exact keypresses (as if from an actual keyboard, without any Linux/host-side driver assistance).  All you need is a loop to check the keyboard matrix, debounce buttons, and send key press and release events when necessary.  With AVRs and CH55xG's there is a bit more set up to do, and CH55x's are limited to C (compared to the C++ that Arduino sketches are normally based on) as it uses the Small Device C Compiler instead of GCC.

Using a cheap cast aluminium enclosure (like Hammond 1550A, 1550B, 1550P, 1590A – might need a bigger one to fit 28 2-pin connectors on the PCB; I recommend 2.0mm pitch JST PH2.0 ones), with the board connected to the lid using M2.5 nylon stand-offs, only wires poking out with all connectors inside the enclosure, cable shields connected to the enclosure, and the entire enclosure grounded at a single point (perhaps via a resistor-capacitor filter), would seriously limit any EM noise from coupling to the buttons and HID logic.  If it works correctly when someone is stick welding within a meter or so, I think it should withstand a noisy servo or a couple of motors nearby too.  Also, with a bit of silicone (I like using the automotive safe-for-electronics stuff in a tube) to insulate the cable and wire passthroughs and the lid, you can make it spray-proof against typical coolants.  And you won't break anything if you happen to hit the box with a chuck key.

Never underestimate the solutions even hobbyists have discovered.  Experience is experience, even if it is only at the hobbyist level, and not at proper electrical engineering or PCB design level.

[Jester]

Update - resolved.

The messaging scheme only sends messages when something changes. The uC has numerous UARTs so I connected a FTDI cable to a spare UART as a dedicated debug port. With that running I could see the messages were idle until I turned on the servos, and at that point enough EMI was making its way into the analog inputs to cause them to send a lot of messages. I tweaked the 10 bit A/D code to only send a message if the analog value changed by > 2 counts, that and 3 ceramic caps in that section and it's steady as a rock.

My truly ugly (wires everywhere) test bed has served its purpose it has allowed me to test the firmware for all the functions I want to incorporate on the final PCB before ordering the PCB and having it operating flawlessly two feet from "Radio Free Servo Drives" gives some confidence that the board will work well when it gets here.

Note to Jay_Diddy.
Thanks for your advice, I'm going to follow up on your suggestion to get a better feel for the EMI hot spots. I actually have a little EMI kit with ferrite beads, probes etc for when I was making trips to Ultra Tech in Mississauga Oakville In that kit I have a couple of 3M quick and dirty near field probes for tracking down noise, I'm
going to do a bit of probing for educational purposes.


Note to Nominal Animal,
Thanks as well. I considered the HID approach until I discovered the ArduinoConnector project. The selling point for me was the ability to easily customize and direct messages to either: HAL, or as keyboard emulation, I need to do both for the functionality that I want. Final board will use just the shielded USB cable interface.  I try to minimize or eliminate: daughter boards, wiring, cables connectors wherever possible. The SAMD21 (emulating the MKRZero) is on the back of the board.



Thanks to everyone that contributed.