EMI issues - but not as you know it!

[puffernutter]

This is quite a long explanation, so please bear with me!

I volunteer for a Heritage Railway and last year we installed and commissioned a new signalling system. As we now have signals a lot more remote from the signal box, I suggested we could employ Signal Post Telephones (SPT) for communication driver/signaller if there was a problem. Yes, we can use mobiles phones (in fact they were) but the signalling system now allows two trains to run and it was important to know which signal the driver was talking from. Now, many years ago, from here I think, I got a BT Revelation Exchange. With a lot of bastardisation including locking away the System Phone (in case the signaller tried to reprogram things) and modifying the SPTs to only have the "0" button, we had it working. Now, one of the key requirements is a display that shows the signaller where the call is coming from. So initially I just put the System Phone in a box and extended the wires to the display and we used a dial phone with the remote display above - the dial phone also doesn't have the # or R keys (what you need to programme the system!)

So far, so good. However, whilst the signaller has a phone in the signal Box, the control of the signals and acceptance of the token is at a Ground Frame (a small lever frame to controls signals) next to the signal Box, so we needed a phone and a display there. The phone extension was simple, the display is what this is all about!

It is a simple 2 line x 16 character display with the characters stored on the display unit. Apart from power, there is an enable, interrupt, write (not used) and 4 data lines (that select the character). I initially just tried to extend the cables, that resulted in too much interference and garbage on the displays. I tried different cables including Cat 5 and multi-par telephone, but nothing worked.

In discussions with my son, he suggested we use RS485. We had a look at that, but there was no clock that we could synchronise the messages to, so that idea was shelved.

Eventually, we settled on an Arduino where there would be a Master, that was attached to the System Phone that would read the messages sent to the display and then transmit down a single pair (through a TTL buffer/driver) to another Arduino (slave) which would put them on the display. It took a while to figure out the protocol, but when we did, it worked. My son initially powered it from a power block using a USB connection to the Master and then that through a 5vDC and Ground that linked all three would power the others. That was not practical for the actual installation, so I bought a small mains powered to 5v DC switch mode power supply and that is where the fun started.

I should also add, that from the System Telephone we sent the following signals to the Master Arduino - Ground, Enable, Write, Interrupt and the four data lines that were used. We did not need the 5v as the Arduinos were powered separately and we used the ground to reference the data signals. Also, the telephone ground is connected to the Arduino ground.

This is what we found:

- USB power pack - system works with no issues and over the distances we need
- USB power pack on charge - random garbage appears on the screen
- mains to 5vDc switch mode power supply (Chinese pcb type) - random garbage appears on the screen
- laptop 5v DC supply "power brick" (hoped for better filtering) - random garbage appears on the screen
- laptop power from a laptop USB port - system works with no issues and over the distances we need (assume the PC has good internal filtering)
- Weir Bench Power Supply (old school!) - system works with no issues and over the distances we need

So, wherever a switch mode is involved, it is corrupting something, either the data bits, or the interrupt, what I can't work out is where it is getting in and what I could do to stop it. We tried disconnecting the telephone ground from the Arduino, but then it just didn't work at all. I know the System Phone power supply will not be straightforward as it is powered from the exchange and will be creating a 5v supply for its electronics from the incoming cables (it is a 4 wire phone). All other extensions are 2 wires.

I have found in my workshop a 240 to 12v transformer and using a rectifier, some smoothing components and a 7805, I have made a regulated 5v DC supply (without I hope an switch mode frequencies) in case that is not enough, I have bought through Amazon a low pass filter, which I hope is belt and braces.

So, what are the thoughts from the hive mind as to where this interference is affecting the display and apart from not using switch mode power supplies, what would they suggest I try! I should add, I need to commission this by the end of February in time for our first running days of the season!

Thank you if you have got this far. An interesting puzzle, that has me stumped.

Cheers

Peter

 

[Farside]

Humph, ask anyone who's plagued by RF noise from cheap-ass SMPSs.
I go into a ferrite frenzy every so often and apart from silencing new additions, have to routinely check LEDs, PSUs that have been in place, silently, for ages, as even the known good ones go rogue.

 

[Erie Fred]

Did you put a scope on it ?
Could it be that you have a ground loop ?

Is the problem all the time ? or just when a something rolls by ?

Steam or electric ?

 

[sako243]

In discussions with my son, he suggested we use RS485. We had a look at that, but there was no clock that we could synchronise the messages to, so that idea was shelved.

I think you've missed the idea behind RS485 - it's a signalling layer, nothing more. It's purpose is to get bits of data from a to b in a noisy environment. You don't need a clock to synchronise messages to - you built that synchronisation into your protocol that sits on top of RS485.

RS485 is a differential signalling mode so any noise will affect both signals and that's the beauty of it - you simply subtract one from the other and any common mode noise is just gone (caveats but generally speaking it just works). There's a reason why industrial control equipment etc., used it for so many years.

RS485 is basically just a UART operating at up into the Mbps speeds. It may be asynchronous but there's still timing constraints on it. The time it takes a bit to travel down the wire is governed by the speed of light. If you pick a data rate of 1Mbps you will be able to transmit 1 million bits per second and they will arrive very shortly after you send them. Given you're dealing with humans and signalling a couple of lines I don't think you need to be able to time things down to the nanosecond.

Eventually, we settled on an Arduino where there would be a Master, that was attached to the System Phone that would read the messages sent to the display and then transmit down a single pair (through a TTL buffer/driver) to another Arduino (slave) which would put them on the display.

So let me get this straight you ditched the idea of a differential signalling protocol and implemented your own single ended one?

First stage - eliminate the signing protocol (as given the information above I'm skeptical to it's robustness). Put each arduino into a test mode and drive the displays with local data. Do you still get garbage in any of the scenarios listed above? If so then you've got an issue driving the display, nothing to do with your signalling.

If the above all checks out then it's time to introduce the signalling protocol. Have you implemented any error checking or error correction on the protocol? If you haven't then you have no idea whether what you are receiving is garbage or not, if you're just sending that straight to the screen then I'm not surprised you're getting garbage.

If you can draw a system diagram of what's going on so I can better understand it but you need to find our where the garbage is being introduced first. If it's local to the display controller / arduino at that end then it's time to start characterising where the noise comes from..