CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

EMI/Noise testing...

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
ELCouz



Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec

View user's profile Send private message

EMI/Noise testing...
PostPosted: Sun Jun 21, 2015 5:24 pm     Reply with quote

Hi,

I just found out that some PIC are more sensitive to other to EMI / noisy places.

I did some test programming with a 30F6014A board running at full speed (120mhz) was susceptible to EMI at full speed than another board with the same layout running another PIC at lower frequency.

Both were working fine with the same program compiled for different PIC (DSPIC30F6014A and PIC24FJ128GA010) in an office environment then when I take it to an industrial electrical cabinet the dsPIC30F6014A would freeze randomly / clock fail while the PIC24 board clocked a 32 mHz continued to run happily without any glitch whatsoever.

The electrical cabinet contained few AC Servo drives.


What do you guys do to test them "in-field" without being "in-field" ?

Regards,
Laurent
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!
Ttelmah



Joined: 11 Mar 2010
Posts: 19515

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 1:14 am     Reply with quote

Any kit I normally design, has to pass a 250,000v spark test to the cabinet, and recover successfully before it even moves to beta testing....
Inside the case with your kit though is always another thing.

This is also where tweaks to the software design are important. A 'watchdog' is a commonly 'misused' way of recovering from EMI. However I'd want the board to actually survive most tests _without_ the watchdog enabled (most...), and only once I'm confident that it can survive 99.99% of problems, then enable the watchdog (and make sure the software is genuinely giving this a chance to work). A lot of people have 'restart_wdt' calls all round their code, when using a watchdog, but this really makes it pointless. The restart should be setup so it is only reached when the code is running correctly, and cannot accidentally be reached by something 'walking' through the code. Then the code has to be written to give a safe recovery, without needing to fully wake up.

Generally the faster a chip is working, the lower the noise margins, and the better the suppression round the chip will have to be. If you study a PC motherboard for example, you will find there are the big capacitors where the supply couples to the board, but also little SMD capacitors adjacent to just about every chip on the board. This despite using thick power and ground planes across the board. These manufacturers 'know what they are doing', and this immediately gives some idea of the care needed for high frequency working. Then look at how every signal actually get 'onto' the board. Typical problem lines are things like ICSP connections in particular. In general, are the wires shielded/twisted?. Where is the ground?. Could the signal be opto-coupled?. Every wire to a board, and on a board, is potentially an RF receiver. The diodes inherent in the gate structure of the PIC, will rectify such signals.
The chip itself will be drawing more current at higher frequencies, and injecting more noise itself on the rails. These both increase the need for good suppression.
How were the supply lines to the servos run, relative to the lines to the PIC?. Is there suppression close to the servo units?.

As a 'silly' suggestion, get yourself one of the electric piezo gas barbecue lighters. Get rid of the gas in it, and trigger it 25mm above your board. Does the board keep working?. If not, then you have a way of simulating the sort of RF you should be able to deal with. Then try raising it away, till the board works. Does the effect differ over different parts of the board?. (Remember the 'spark' inside the nozzle is the actual radio source, so is very local.). If the board works with the spark only 25mm away on the right, but needs to be 50mm away on the left, then you have an idea of what part of the board is actually picking up.....

There is a lot to this, and good design here is a field that can take an entire lifetime. I find it really annoying, when a board is designed, and produces very low RF out itself, and is able to survive RF injection, and direct voltage injection on it's pins, and then other equipment used with it causes problems. You may well find that the drives are actually producing very high levels of signals, and are inside the cabinet, as the 'only way' to keep this from being objectionable outside. Could you put a metal box round your unit?. Might be a simple solution.
ELCouz



Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 2:57 pm     Reply with quote

The board was used as a signal generator (variable frequency) for emergency repair while we order another unit. It was use to drive a stepper motor drive. The drive input signal was optically isolated and checked the 24V power supply comes out clean almost no ripples... so it has to be EMI.

I know industrial environment can be pretty nasty compared to a home or office.

We have beside regular 120/240V ... 480 V / 347V (mostly lightning) / 600 V.




Thank you Ttelmah!

In fact, after few test I've lowered the uC speed and it worked!

Thanks for the piezo trick.

I will try it tomorrow Smile
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!
gpsmikey



Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 6:38 pm     Reply with quote

One of the big ones that many people miss is the ground. They are busy looking at the supply lines but miss the fact the ground for the board may be jumping for some reason (which may take inputs below ground on various things). The signal conditioning can be pretty tough for a rugged environment (we had to do LOTS of design and testing for our cards that were part of the 777 flight controls (you should be glad Very Happy ). The ground one is one that a lot of folks miss in the testing though - you have a ground line that runs to the board and a big transistor that sinks lots of current for some device - power looks good, but the ground may come up a volt or two (or more) when that triggers.

mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3
Ttelmah



Joined: 11 Mar 2010
Posts: 19515

View user's profile Send private message

PostPosted: Mon Jun 22, 2015 11:42 pm     Reply with quote

Very true. Classic problem is things like 'daisy chaining' of grounds.....
Or (of course), the two devices, both with a separate good ground back to the supply, that then have a data connection between them, also with a ground. One board draws more power then the other, and current then starts to flow on the data cable ground wire (earth loop).
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Jun 23, 2015 5:31 am     Reply with quote

My PICs mostly control RF power amplifiers. RF leakage is not just a potential problem, they have to work continuously in fairly high fields. They are also sometimes involved with controlling and measuring modestly high currents, into the few tens of amps range. Spikes and surges are not really our issue, its continuous medium, and locally high, level RF fields up 12GHz.

Our products are those used by EMC/EMI test houses to generate the RF fields needed for product testing: anything from wearable tech, through mobile devices up to automotive sub-systems and even whole cars and trucks. If we weren't careful it could get hairy for our PICs.

With RF systems, there's never really any such thing as a homogeneous ground. There can be high RF currents generated in even thick metal. There's no real distinction between ground, 0V and chassis, everything is liable to be "hot". The chassis is very often the return for DC power to RF components, as such you won't necessarily find much black wire in our products. It tends to be much like older automotive wiring: "negative earth".

In this environment, I've found that trying to be clever with grounds, especially splitting analogue and digital grounds and the like, is counter productive. Instead of having a nice 0V return via wiring and isolating PCB mounting points, my practice is now to go with the flow and provide a solid overall ground plane that connects to every possible mounting point. Most of my boards are four layer with one of the internal layers being the ground. On the rare occasions I've done a double sided layout, we've flooded the bottom. The principle is to have as much copper as possible covering as much as possible, and to connect it so that it becomes, in effect, a continuation of the chassis, but on the PCB.

Power switching has proved troublesome, as the transients, and related ground currents, generated by the switched tracks if they are any length at all, and can cause PIC restarts/"crashes". The trick here is to switch as physically and electrically close to the load as possible. Especially with very fast switching, which is desirable both for fast blanking of our amps, and for ensuring reliability and power dissipation of our switching FETs by ensuring they spend as little time as possible out of their SOA.

Thankfully I've encountered relatively few problems with these simple precautions, but when there has been trouble, no amount of tinkering with screens, cans and foils, etc., has been able to really make much difference. My experience is that robustness needs to be designed in, it generally cannot be added later.
Ttelmah



Joined: 11 Mar 2010
Posts: 19515

View user's profile Send private message

PostPosted: Tue Jun 23, 2015 7:01 am     Reply with quote

and (of course), having switching devices close to what they are switching inherently tends to avoid the risk of the grounds for these 'crossing' grounds for other signals.
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Jun 23, 2015 7:14 am     Reply with quote

Another thought: older, slower, 5V PICs with larger geometry on the die, are arguably less susceptible as they have larger noise margins that newer, faster, 3.3V and lower voltage, devices built with smaller feature sizes. On the otherhand, in general, the smaller the die, the better. So there is some flip side to the argument.

Up till now I've used 5V parts, and deliberately not gone to 3.3V. I have gone to newer parts with lower voltage cores, most notably the PIC18F66K80 series which are my current go tos for most things (CAN is my bus of choice due to its robustness and EMC tolerance). I'm also running these at higher speeds: 16MHz crystals are my standard, with PLLs on in most cases. We used to run older PICs, such as the PIC18F8585 (nasty errata issues on that one) and PIC18F6680 family, from 10MHz crystal oscillators.

However, the availability of newer support ICs is much easier in 3.3V, and I may yet have to bite the bullet and go 3.3V through out my controllers. I'm putting this off for as long as I reasonably can as I know there are likely to be some tricky EMC issues.

I have lots of done stuff at 3.3V, mainly with ARMs, but not in this RF rich environment. So for now, I'll stick with what I know works: 5V supplies.
ELCouz



Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec

View user's profile Send private message

PostPosted: Tue Jun 23, 2015 2:09 pm     Reply with quote

Thanks guys for all your inputs... Smile


RF_Developer wrote:

I have lots of done stuff at 3.3V, mainly with ARMs, but not in this RF rich environment. So for now, I'll stick with what I know works: 5V supplies.


I wonder why there isn't a lot of 3.3V-5.5V range 16-bit PIC.

All the new stuff looks capped at 3.3V max... i've seen few PIC24 capable of a wide voltage range.

If they could come out with a universal pic which support 1.8,3.3 and 5v that could be the winner lottery ticket...

Never need to worry again if the PIC is capable of running at which voltage!
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!
Ttelmah



Joined: 11 Mar 2010
Posts: 19515

View user's profile Send private message

PostPosted: Wed Jun 24, 2015 12:36 am     Reply with quote

It is the problem of cost & heat.

Bigger PIC's imply more real estate. More real estate, implies bigger chips, & more heat. unless you shrink the circuit elements. Shrink the circuit elements, and you have to use lower voltages.

There are a few of the larger PIC's that use larger elements for the I/O components, and then a regulator, and run the processor 'core' at a lower voltage.
ELCouz



Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec

View user's profile Send private message

PostPosted: Wed Jun 24, 2015 3:10 am     Reply with quote

Ttelmah wrote:
It is the problem of cost & heat.

Bigger PIC's imply more real estate. More real estate, implies bigger chips, & more heat. unless you shrink the circuit elements. Shrink the circuit elements, and you have to use lower voltages.

There are a few of the larger PIC's that use larger elements for the I/O components, and then a regulator, and run the processor 'core' at a lower voltage.



I thought it was the opposite since higher the voltage smaller the line can be (lower current draw)

Thanks Ttelmah for the explication! Smile
_________________
Regards,
Laurent

-----------
Here's my first visual theme for the CCS C Compiler. Enjoy!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group