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 support@ccsinfo.com

How to software - filter mobil signals from a ADC

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







How to software - filter mobil signals from a ADC
PostPosted: Mon Jun 01, 2009 7:10 am     Reply with quote

Hello,

I have a pressure sensor on the ADC of a 18F6723 giving me a 0 - 5V signal. Everything works fine with the data collection until a mobile phone being around (eg. 15cm) starts to ring. From this point on the ADC goes crazy as the mobil signal is modulized over the pressure signal. I did not find a good electronic solution as the board is already fixed.
Does anyone know what the best software filtering would be to get rid of the mobil modulation?
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Mon Jun 01, 2009 10:07 am     Reply with quote

From an EMC regulation point of view, it's not required for electronic devices to work unaffected with a mobile phone in a 15 cm distance, because the field strength is above required EMC susceptibility limits by several orders of magnitude.

Most likely, the device would fail burst tests, however. So there's probably room for serious improvements and a necessity of a redesign.

Software filtering can be workaround, if the distorted signal is still in it's linear range and the average maintained. Otherwise, something like a interference blanking may work, holding the previous measurement until the interference ends. Depending on the applications signal dynamic, this mode of operation may bring up the danger of supplying wrong measurements for an unknown time interval. It's at least illegal with any safety related measurement.
SherpaDoug



Joined: 07 Sep 2003
Posts: 1640
Location: Cape Cod Mass USA

View user's profile Send private message

PostPosted: Mon Jun 01, 2009 5:40 pm     Reply with quote

If at all possible you need to stop this signal BEFORE it gets to the A/D. Better than filtering it on the PCB is to stop it before it gets to the PCB with a shielded enclosure. If you have a metal box make sure it is grounded to the same ground as the analog circuitry leading to the A/D. If it is a plastic box look hard at a metallic spray paint or an adhesive metal foil to add shielding to the enclosure. If there are wires, or metallic pipes leading into the enclosure they should be grounded or filtered as they pass through the enclosure with maybe a ferrite bead or ballast resistor between where they pass through the shield and where they connect to the PCB.

With strong RF interference it is not likely software can do any good to recover a corrupted signal. Once the A/D saturates all meaningful information is lost. FvM's suggestion to hold the last valid signal is good if the application permits.

If you must do software filtering search for "Olympic scoring" or "Olympic sorting" on this BBS for a simple way to remove sporadic bad readings.
_________________
The search for better is endless. Instead simply find very good and get the job done.
Ttelmah
Guest







PostPosted: Tue Jun 02, 2009 3:09 am     Reply with quote

Yes.
_If_ the signal generated what (at your sampling frequency), was effectively 'random' noise, then software filtering, could remove it. However the problem is that the hardware in the chip (particularly the diodes in the input), will tend to first rectify, and then clamp the signal, typically resulting in the noise sending the signal 'off scale', possibly just in one direction, but also possibly to both extremes.
One approach that might work, if your 'normal' signal has a known range, less than the full scale of the ADC, is a combination of a simple average, and an 'olympic' limiting algorithm. So (for example), if you generate a simple average of a number of samples, and at the same time, have a 'flag' cleared at the start of the averaging process. If the incoming value goes outside the 'known acceptable' range, you set the flag, and reject the average, going back to the 'last good' value. The averaging will tend to help for lower level interference, and you effectively use a value coming outside the range, as a indicator that something is wrong.
If the pulses are really short (less than one sample time), you might consider trying a basic 'olympic' average, with something like:
Code:

static int32 sum;
int16 max,min;
int16 adcval;
int8 loop;
int16 result;

max=0;
min=1023; //Set max and min to the limits of the range
for (loop=0;loop<10;loop++) {
    adcval=read_adc();
    if (adcval>max) max=adcval;
    if (adcval<min) min=adcval;
    sum+=adcval; //Generate sum of ten samples
}
sum-=max;
sum-=min; //remove the maximum, and minimum values

result=sum/8; //Average the remaining total.


This simply works by summing ten samples, then removing the highest and lowest value from the sum, and dividing by eight to give the average of the remaining eight values. In some cases it will work well (this will reject the 'spike' caused by a cosmic ray hit, on a photo detector for example). However, if the incoming signal actually 'swamps' the input, it will typically take significant time for the input to recover, resulting in more than one sample being damaged, and making this approach useless...

At then end of the day, the really does need to be rejected earlier. One thing to look at with care, is the possibility that the track length, may be close to a resonant length for the frequencies involved, making the entire input function as an aerial, and simple diode receiver stage.....

Best Wishes
Guest








PostPosted: Fri Jun 12, 2009 11:31 am     Reply with quote

Why is 'Sum' dimensioned as an Int32? The largest value that it can be is 10230 (1023 X10), so the result will fit in an Int16 nicely!

Doug
Ttelmah
Guest







PostPosted: Fri Jun 12, 2009 2:48 pm     Reply with quote

Because the code was actually based on some being used on a chip with a 14bit ADC...
Yes, you can save time, and space, by switching to int16 for the application involved here.

Best Wishes
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

other things to consider
PostPosted: Fri Jun 12, 2009 3:51 pm     Reply with quote

Sherpa Doug is setting you in a good direction: - iI'd like to add - that u did not say what you were using for the ADC reference source.

If it is an external 2 or 3 terminal device - - thing like the LM385 TL431 etetctetc - they can be shockingly GOOD at rectifying the packet pulses emitted by mobile phones and turning it into GLITCHES in the ref output.

When using such things - i use a small series R and capacitor to minimize the issue.

being sure that your DC POWER is well decoupled for RF may be of help also. for any product I design - I assume the end user may be in a 2V/M or stronger , modulated radio field.
( for the NON - RF person - thats about the field strength of a 5KW MW transmitter at a distance of 500 M from the main array - or a cell phone output when dialed up to max TPO at about .25M - kinda your case i think )

I always insist on a ground flood for the PCB and use a simple , "octave above Fmax" PI filter for any inputs and then use a 10uhy multi winding ferrite choke on any power entering.

Serial data flows through 100 ohm ferrite choke bead inductors leaving with a "1/2" pi or ( LC - Lnet ) with the 'c' on the inboard side of the connection.

Be aware that your interference is almost surely happening because your
circuit is conducting radiated energy and rectifying it in an incidental fashion courtesy of all the fine supply breakdown virtual diodes
in the PIC and nearly any CMOS chip ever made.

At cellphone freqs - unintended 1/4 wave resonant structures exist all over the wiring design too - you just don't realize it till it hits the fan.

BTW: my background before semi retirement was in high power RF design
and I've seen good bad and ugly - often enuf to know that there is usually no single answer to RF problems - just more ways to further supress the undesired aspects of ubiquitous RF emitters in our lives.
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