Noise from nerby contactor / relay causes glitch in programme
LA6WNA
Posts: 138
Hi. I`m working on a Propeller project thats going to control my micro hydro-power station. (2kW) It`s now up running for a test period to see if all work as expected. Been doing some programme changes and "bug fixes", and now it seem to work almost perfect. But I got a strange behavior that I have not worked out yet: When a nerby (2feet away) contactor is turned off, my relay outputs randomly changes states for a short while. Sort of glitch.. The contactor is 230V ac, but there`s no wires between that one and the propeller boards. Contactor just pushing a mechanichal time delay relay, and does not switch any load.
My system has a "main board" with the propeller and 4 other daugtherboards with analog inputs, digital inputs and relay outputs. Relay output board has 16 channels with transistor controlled (BC548) relays. Transistors is controlled from 2 x 74HC595 shift registers, wich is controlled from 4 outputs from the propeller.
Power supply is 12v battery with constant voltage controlled charging.
It does not cause the propeller to fully reset, but I also se a "glitch" on the TV output display at the same time. This tells me that the noise affects not only the relay output board, but also the processeor itself.
If this is HF noise at the reset line, could this make such behavior without fully reseting the processor???
Reset pin is only connected to reset button (NO) and to programming port. No pull-up or caps. Just wired as the example in the propeller book.
Any suggestion anyone..?
My system has a "main board" with the propeller and 4 other daugtherboards with analog inputs, digital inputs and relay outputs. Relay output board has 16 channels with transistor controlled (BC548) relays. Transistors is controlled from 2 x 74HC595 shift registers, wich is controlled from 4 outputs from the propeller.
Power supply is 12v battery with constant voltage controlled charging.
It does not cause the propeller to fully reset, but I also se a "glitch" on the TV output display at the same time. This tells me that the noise affects not only the relay output board, but also the processeor itself.
If this is HF noise at the reset line, could this make such behavior without fully reseting the processor???
Reset pin is only connected to reset button (NO) and to programming port. No pull-up or caps. Just wired as the example in the propeller book.
Any suggestion anyone..?
Comments
I'd guess the 74HC595's are being corrupted until refreshed. How are these mounted/connected to the Prop and power supply? There is likely a grounding issue between the two modules.
Shielding helps too. I had one specialised controller die repeatedly, of EPROM/Flash erasure, from a near by contactor switching.
The main board is connected to the daughterboards by 10-wire flat cables, each abt 20cm long.
EDIT: evanh: Yeah, I think the Prop is impressive itself. At the start of the project, I had the MR (master reset) of the 74HC595`s hooked up with the reset pin of the Prop.That caused the Prop to fully reset when contactors nearby switched, Then I removed that connection and now I do not get any reset, but as I described first, more sort of a glitch in the programme loops. I also sometimes see that some cogs are stopping and starts again when this happens. I have a 12-pole switch connected to one of the analog inputs that make me able to switch between 12 different TV-output pictures. In that way, I can monitor all the parameters all the time by one knob.
During a fully reset, TV-screen is getting all blue. That don`t happens when this contactor-made glitch appears. It just make a "jump".... Strange things..!
All 8 cogs is running when system is turned on.
Ah okay, the Prop is getting upset then. Lots of potential problems. Ground loops - major layout rearrangement and/or redesign to resolve, and power decoupling - throw lots of ceramic caps at it, are likely big problems. I'd also look at filtering the digital inputs also - just simple RC lowpass works wonders.
Shielding I've seen done just by adding a ground wire literally arching over the chip in question but a full metal case is often the method used.
Shiedling is a black art. It may work; but if you have a long straight wires feeding power into the device, that may be your antenna that is causing triggering even with sheiding.
Do the relays trigger when you hit a Reset? The reason I ask is you may be experiencing complete Reset conditions mixed in with other things, and not an isolated relay behavior.
The analog inputs can easily pick up noise that might trigger the relays as well. But this is dependent on your code. With analog, it might take much less of a spike than with digital logic.
Are you distributing to the daughter boards with ribbon cables? There are twisted pair ribbon cables that might help.
If you are sure that's the source of the interference then it's most likely just coil flyback generating arcing on the contacts. It's a good idea to add suppressors across all coils, preferably right at the coil terminals: Varistors are a simple cheap option, or specialist mains rated RC suppressors are also alternately used. On DC coils a reversed diode works too.
Loopy: Yes I know well about this antenna effect from long (or short) straight wires. All input to system from sensors / switches etc, is feeded through twisted pair. Connections between boards is ribbon cable, yes. That may be a drawback, I see that. Relays do not trigger by a fully controlled reset, so it can not be a fully reset going on here. Then I leastly would have expired a blue tv screen while this occours. I don`t. Analog inputs are ADC0838. I see that this setup could be very sensitive for spikes, but I mean that they should not make the Prop act like this.
evanh: I agree that this must be some kind of flyback that make RF-noise that is distributed through the air, and gets picked up on a input wire etc. I have just tested this with the actual mentioned contactor, but I beleeve it could occour from any othe source too. Therefore I would like to make the system as resistent as possible for spikes etc. I know I could use varistors at the actual contactor, but that would not protect the system from other sources. I just trying to figure out what`s really going on into the Prop when I am pretty shure that this is not a fully reset.
I will do some more research, maybe tonight.
BTW: sorry for my bad english writing, but I hope you`ll understand...
I've had similar problems. Tried many solutions. The one that worked was to remove all wires connecting to the reset pin. Any wire more than a few cm seems to act as an antenna.
Do you have another video source to verify its not the tv, or its input cable, picking up the glitch? The video input is only 1 volt remember, so a small induced voltage could cause that glitch.
Can you detach the 12v battery from the charging circuit, and do you get the same result? I'm guessing there may be long wires (=antenna) associated with the charging circuit.
How is the TV powered?
You can put X2 mains rated capacitors across the contactor contacts, and coil too. But I understand you wanting to make the system robust, rather than supress the source.
Dr:Acula: I`ve red your earlier threads about this things and I shure know you`re familiar with the problems. I will also first pay attention to the reset line, so I`ll do my research there first. Do you use any pull-up and/or cap at the reset line? Mine have none, just going through the print trace from reset pin to reset switch and the programme port. Maybe 3 cm long trace all together.
http://www.onsemi.com/pub_link/Collateral/AND8230-D.PDF
But when you look at actual boards, you see TVS diodes and several other options. Trying to find publicatios leads to a lack of public white papers, but publishers such as Wiley have expensive texts. I find it all frustrating. You can draw your own conclusions to why it is this way.
This is one of the best reasons to acquire a good oscilloscope to run down specific sources.
I made a "filtering code" at the read input routine tonight. That code read input registers twice and then compare the results.If results from first reading equals result from second reading, then the variables Di[x] are uptated. If the two readings differes, Di[x] remain its old value. And the big thing is; IT WORKS... Now I get clean readings from the inputs and the Prop act like he should.
So now the question is how to get rid of the output data corruption. Do`nt think this could be done by code, so I`ll look for a way to shield/decoupple the wires between Prop and relay board.
Or any othe suggestions out there????
evanh; your suggestion was right already in post #3
I've had a similare problem trying to control a spark gap ignitor from a propeller board. I tried every isolation technique given from the many talented people on this forum: opto isolation, tvs diodes, permanently hold RSET, RF shielding, all sorts of filters and I could never get it stable. I ended up using a resistive ignitor, everything works perfectly now. That contactor is acting as a spark gap, change it our for a SSR if possible.
It gets more tedious from now. We know it's a broad glitch on the home brew add-on board. At this stage it's not confirmed if the cause of corruption is from RF injection or ground bounce or supply glitch. Best to do it all really.
Shielding from RF noise can be done in a number of ways and it's effectiveness is dependant on the sources of the RF noise. Snubbing the source is the best answer if it's possible. This outright prevents the RF from existing.
A quick first thing to do is add ceramic capacitors all over the add-on board. These can be easily spread around the power rails just by soldering them on the tracks. This addresses supply glitching.
I'd also ensure the ground rail and/or power rail is overrated or split between functions. Running more/heavier wiring from the power supply to the add-on board or route separate ground/power wiring for the drivers/pickups. This addresses ground bounce. Using electrical isolators is another option here but will require a redesign of the add-on board.
- connect your battery (-) terminals to earth ground.
- place the circuitry in a metallic enclosure with an isolated ground to an earth ground, i.e. cold water pipe or ground rod.
- use ferrite bead / choke on the power supply cables to the circuit board.
- use STP type twisted pair cable, i.e. CAT5e STP, for all analog / digital paths out of the enclosure, and ground the shield conductor(s) to the enclosure.
The more RF there is the better the shielding has to be. Most of what I listed above was not covering RF at all. Opto-couplers for example do very little useful to protect from RF noise. Especially if they aren't on the same board as the controller then all they're doing is removing ground loops and thereby stopping any high currents from causing ground bounce within the control circuits.
RF shielding is difficult and I'm no expert on it. Any exposed wiring is a potential interference point, it's not just the chippery. Although, shielding the individual ICs is a good starting point.
However, as they say, prevention is better than cure - Your solution of changing to SSRs is a good way to eliminate the source of the noise, not to mention potentially making the equipment last longer due to no wear of contacts.
If you really must have arcing, eg: testing insulation breakdown, then you are in for a long learning curve with lots of expensive failures.
The U stands for unshielded. This means the cable is exposed to whatever RF is passing by. This would have been chosen for cost reasons, unshielded obviously is cheaper. But then how to design the electronics at each end so that it doesn't care that lots of RF is indeed hitting the wires of the cable?
Bare in mind that this isn't dealing with RF injection into the logic side of things, only how the cable is handled.
Isolation is being put to good used in this case. And it is explicitly combined with good grounding on the logic side and also, being transformer isolation, can very simply be constructed to: a) supply it's own power and, b) produce a balanced signal that will merrily travel on a pair of wires. This wire pair is twisted and insulated with specific physical parameters that does wonders for performance but is still cheap to produce. The details of this is not something I'm up to speed on though.
At any rate the basic premise is the twisted pair creates a situation where any RF hitting the pair will affect the individual wires equally. Meaning, differentially, there is no noise. That leaves just the common mode noise to deal with and that's where the isolation kicks in.
Beyond that, error correction is employed. Luckily, short term glitches can be processed out of the signal just like OP has done with his inputs.
Next best practise is to fill all gaps on both top and bottom layers with ground pours. In doing so you'll prolly want to make some openings in the component positions for strong conduction paths across the whole board.
If you start down the path of putting stuff in metal boxes then the linking cables between boards also should be shielded with excellent bonding to the ground planes at both ends.
If these cables are supplying power to power switching devices then make sure they have their own power and ground running all the way from the power supply in parallel with the logic/signal supplies. And some even add internal shielding for analogue supplies and signals.
Resolving these issues are is an art more then science. Start at the contactor and work your way back to the prop to deal with the voltage spikes coming from the contactor. While there are aspects of this that are considered "best practice" type things but in the end there's a lot of trial and error involved.
Contactors (arcing contacts) are always sources of grief, best avoided if at all possible.
You may be able to do some checks on OP corruption, in SW, or move to a IO device that allows read-back for verify.
Even with a HC595, you can read-in the Qs, and check it is in-phase, if not, skip the load until it is.
You can also do extra shifts, with no loads, to act as CLK noise detectors.
eg do a normal shift.check.load and then shift in 11111110, and watch the Qs, If a H appears, you have had a bogus clock edge.
Add some noise filters right at the HC devices, and buy ones with schmitt trigger pins.
Or, you could use something like NPIC6C4894, and read-back 2 QO, if you make those 10 or 01, and also watch Qs, you can verify the shift and load had no bogus clocks.
You also should be able to predict when spikes occur, so using that, just refresh the OPs with a new write, after the noise is done.
There are some LED i2c drivers with ReadBack abilities, but it is surprising how this ability ois missing from Serial Driver devices in general.
I was suspecting groundloops, cause last night I measured 4,1v DC between battery minus and ground. Not a good thing at all, so now the 12v system`s minus is properly connected to earth. (my powerstation has its own ground electrode outside the house) That itself did`nt get the problem any better, but I guess it does`nt get it any worse either.
jmg: I really liked the idea with read-back from registers. That would be a good way to verify data. Only problem here is that I`m out of pins at the prop. All is in use. I might could do it if I combined a pin for that moment of read-back.
There is so much knowledge out there, I can see, and I`m really thankfull for taking your time to write it down. Thanks again.
My plan is to get the system as resistant as possible against this kind of noise. Afther doing so, I will shurely remove the source of the noise by decoupple the coil of any nerby contactor.
In that way, I know by myself that I can trust the system when it is running "stand-alone". It was really a luck that this problem showed up now in the test period and I`m there when the system is running. I`m pretty shure to come to a solution now, with all the inputs from you out there.
Hope to get time to work futher on the project tomorow night. Today is the big "Spring-Meet" at the model airfield, so I`m gonna take my planes out there and just have fun all day.
CUAGN SN (thats morse code; see you again soon
Another device to check would be a HEF4094, which is a slow 4000 CMOS variant of 595, the low speed acts as its own noise filter.
As you say, you can connect Qs to DI, with a resistor, and PushPull drive for send the float to read Qs to check, for no pin cost.
It is not just the coil, but the contacts (and the coil, is of course, close to the contacts).
Simple Distance and cable dress can help, as that pushes down the stray coupling C
I've found Spice to be quite educational on these types of problems.
Dial up a pulse generator of a few hundred volts per ns, choose some tens of femto Farads as cStray, and tens of nano-Henrys common mode inductance, and look at the resulting impulse.
Things moving forward. See if I can get linked the data from the powerstation to my Spinneret soon, so those of you who are interested can follow the conditions of the machinery.
Data is allready brought back home via RS-485 and I have them present on my TV set, so it should just take some programming time to get them "online"
BTW ; all planes safely landed at the "spring-meet" last day. Great day, no crashes. (club is called Crash & Burn RC)
This is my bigest Propeller project so far, so it`s really fun to see it run as I wanted. I`ve learned alot this and from all of you out there that shared your experience. Thank you all.
Hope to get the data from my hydro power station into my Spinneret soon.
Got any pictures? Really interested in the placement of the ferrite cores.
D.P : Hi. Have no pictures for the moment. I plan to document this project at my homepage aftherwards, but have no time for doing so yet. http://la6wna.com
There you also can find a link to my Spinneret where I plan to put some data from the power-station. I got some troubble with my Internet connection the last days, so I`m not shure the link will always work.