Current loop NoiSe*&% woes and the PROPer solution

Peter Jakacki · 2010-11-09 06:24

I have been asked to improve a situation for a customer where they transmit serial data at 4800 baud on a opto-isolated current loop interface. Normally they never have a problem except this time where the current loop signals are in the same 5-core power cable as the 240V mains for the pumps, 3 for the mains and 2 for the loop, makes sense

This is not the customer's doing but a problem with the site he had to work with.

Sounds bad except it's worse. The cable runs back and forth across a road to a distribution box so that they can bypass loop nodes. The total length of this cable is estimated to be around 600 metres, that's about 2,000 feet :smhair:. Can you imagine the noise on the loop when the pumps are running? This is in the "bush" out west.

Fix up the cable you say? Well although it is non-compliant and considered a safety hazard by any standard you care to name it is a fait accompli and eventually the proverbial **** will hit the turbofan big time but in the meantime my customer would somehow like to just get his system to work and the problem off his back.

After tackling the whole loop side itself I was still left with some noise on the receivers which I thought some oversampling/majority vote would remove but there is always the problem with start bit synchronization in certain situations etc. So I simulated a purely simple analog solution for this which when blasted with various exaggerated noise sources was able to produce a clean glitchless digital signal.

Now this circuit just uses RC filtering and called for some comparators. The threshold for the comparators was around 0.5Vdd so I thought I'll skip the comparators and feed it straight into a Prop pin which has a very similar threshold. Well, it took two stages of in and out and simple PASM code with one cog but look at the image which has been verified with hardware and real signals. Because we still sample in the middle of a normal bit then even if there is a slight timing distortion of the start bit there is still a clean bit to sample. BTW, the output pin is sampled by a normal software UART as if it's an input.

The top trace is the original signal whereas the V(rxd) is the noisy (injected) rx signal which when passed through two RC filter stages buffered by Prop I/O as simple threshold comparators we end up with the bottom trace. Although it is possible to do this to some extent purely in software the RC circuit is always "sampling" and when tuned to reject noise is an easy way to clean up a signal.

I don't think it's perfect but it works, needed just 2 resistors and capacitors and just demonstrates another way the Prop just works and is so flexible. I believe P2 will be even more flexible. It's like an SOC (system on a chip) isn't it?

KaosKidd · 2010-11-09 06:43

Nice write up. I was actually able to understand the problem and how you got around it. Awesome answer too!

kwinn · 2010-11-09 07:40

Excellent solution to a tough problem that shows the versatility of the prop. As you point out this could also be done in software with a relatively simple pasm program.

Cluso99 · 2010-11-09 09:23

Nice job Peter !

Phil Pilgrim (PhiPi) · 2010-11-09 09:55

Peter, that's a nice application of the Prop's "analog" capabilities! Just out of curiosity, was the output to the second stage done programmatically or via counter feedback. (Since you exhibit non-inverted waveforms throughout, I suspect the former.)

I've often thought that the Prop's feedback counters could be configured with external passives to perform similarly to op amps. The success you had with your app inspires me to investigate this further.

Thanks for sharing it!

-Phil

Peter Jakacki · 2010-11-10 04:57

Phil Pilgrim (PhiPi) wrote: »

Peter, that's a nice application of the Prop's "analog" capabilities! Just out of curiosity, was the output to the second stage done programmatically or via counter feedback. (Since you exhibit non-inverted waveforms throughout, I suspect the former.)

I've often thought that the Prop's feedback counters could be configured with external passives to perform similarly to op amps. The success you had with your app inspires me to investigate this further.

Thanks for sharing it!

-Phil

Thanks Phil, the work that's shared on this forum always inspires me too so if I can get around to sharing something then I at least try. Sure this is a simple app but with real world application and it was only possible to keep the hardware simple because of the I/O thresholds and being able to dedicate a cog for this too. I'm sure a fast ARM CPU could do it somehow but not as easy and simple as the Prop does.

Now, I was thinking about using the counters but I wanted to get it functioning first and get the problem licked. However when I have time available I will look into using the counters as well. Do you have some ideas yet?

Peter Jakacki · 2010-11-11 05:23

I tried using the counters instead of code to handle the RC pins. Even though the POSDET inverts the signal I do have 2 stages so the output is non-inverted. Even so there would not be a problem to have the signal inverted anyway.

So setting up the counters is all I have to do. The attachment shows an actual signal being filtered so you see there is no problem whatsoever for the uart object to get a clean sample.

  dira[lprxd_out1]~~   ' output feeding into second RC
  dira[lprxd_out2]~~   ' output of the two RC stages
  ctra := (%01001 << 26) + (lprxd_out1 << 9) + lprxd_rc1
  ctrb := (%01001 << 26) + (lprxd_out2 << 9) + lprxd_rc2

Current loop NoiSe*&% woes and the PROPer solution

Comments