Searching \ for 'RF Noise' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/serials.htm?key=rf
Search entire site for: 'RF Noise'.

Truncated match.
PICList Thread
'RF Noise'
1998\02\01@125404 by Andy Shaw

flavicon
face
Hi Folks,
I've just observed rather strange behavior that maybe one of you can help
explain. I'm currently working on a Radio control project that is driven by
a standard 40MHz FM RC receiver (I decode the standard 1.5ms pulses). So I
have a PIC that is attached to one of the receivers output pins and has
common ground and +5V lines. Now at startup I have a loop that basically
waits for valid RC pulses and also waits for the stick on the transmitter to
be in neutral.

All so far so good. Well the odd thing is that I noticed that if I powered
up the receiver and PIC before turning on the transmitter I got all sorts of
glitches on other chans on the receiver. Not really surprising. Also these
glitches are much worse with the PIC running than with just the receiver
turned on. Again not that surprising (but a pain because I guess this means
that the PIC is generating interference for the RC receiver - sigh). Now for
the odd part I found that by simply adding a few nops to the loop in my code
I get get rid of the glitching. What I don't understand is why. The code I
have does not change the state of any external pins it simply runs waiting
for an interrupt on change from portb and maintains a few time related
internal state variables. I'm surprised that changing the length of the main
loop with this sort of code would change the nature of any RF noise being
generated by the PIC! So can anyone explain?

Oh and can anyone offer any advice on the best way to isolate PIC based
projects that are used with RC equipment (given that they probably need to
share a power supply and take input(s) from the RC gear)?

Thanks

Andy

1998\02\01@130654 by Charlie McCook

flavicon
face
> on a Radio control project that is driven by
>a standard 40MHz FM RC receiver

>because I guess this means
>that the PIC is generating interference for the RC receiver - sigh). Now for
>the odd part I found that by simply adding a few nops to the loop in my code
>I get get rid of the glitching. What I don't understand is why. The code I
>have does not change the state of any external pins it simply runs waiting
>for an interrupt on change from portb and maintains a few time related
>internal state variables. I'm surprised that changing the length of the main
>loop with this sort of code would change the nature of any RF noise being
>generated by the PIC! So can anyone explain?

My guess is that by inserting the NOP's you increased the cycle time of the
loop thus making the freq. of the interference lower.  It's probably still
present just moved lower and out of range of the receiver.  Something we
all need to consider -- RF interference from our projects!

chas  K4YC

http://www.qsl.net/k4yc/

1998\02\01@141625 by Mike Keitz

picon face
On Sun, 1 Feb 1998 17:52:05 -0000 Andy Shaw <spam_OUTandy.shawTakeThisOuTspamVIRGIN.NET>
writes:
>Hi Folks,
>I've just observed rather strange behavior that maybe one of you can
>help
> Well the odd thing is that I noticed that if I
>powered
>up the receiver and PIC before turning on the transmitter I got all
>sorts of
>glitches on other chans on the receiver. Not really surprising. Also
>these
>glitches are much worse with the PIC running than with just the
>receiver
>turned on. Again not that surprising (but a pain because I guess this
>means
>that the PIC is generating interference for the RC receiver - sigh).

The output of a FM reciever is undefined when no radio carrier is
received.  Most receivers output white noise.  The pulse demultiplexing
logic in the receiver may try to reject it, but usually not.  Your PIC
circuit is working like a very weak transmitter, and giving the output
some regular pattern which is interpreted as a legitimate transmitted
signal.  Signals and noise from other places could do the same thing.
The key is that the signal from the transmitter will be stronger than any
of them, so the receiver will "capture" the transmitter signal and ignore
the rest.

To tell if this is a major problem, test the maximum distance that the
transmitter can be moved away before control is lost (Put the transmitter
antenna down, making the transmitter much weaker than normal, so it isn't
too far to see).  If it is significantly less with the PIC circuit
connected, then there could be a problem.  Operate the PIC circuit
through all its modes, not just idle.


>Oh and can anyone offer any advice on the best way to isolate PIC
>based
>projects that are used with RC equipment (given that they probably
>need to
>share a power supply and take input(s) from the RC gear)?

As a common-sense measure, keep the antenna and the reciever as far from
the PIC as posible.  If noise is still limiting the range, put the PIC
circuit in a closed metal box, and use ferrite beads and feed-thru
capacitors to filter the power and signal lines going in and out.  I
doubt this would be needed often.  The typical RC model has significant
noise from the DC motors in the servos and drivetrain that would I think
overwhelm noise from a PIC.  Also the model is usually operated much,
much, closer to the transmitter than the maximum range.


_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\02\01@145036 by paulh

flavicon
face
On Sun, 1 Feb 1998, Andy Shaw wrote:

>  Now for
> the odd part I found that by simply adding a few nops to the loop in my code
> I get get rid of the glitching. What I don't understand is why. The code I
> have does not change the state of any external pins it simply runs waiting
> for an interrupt on change from portb and maintains a few time related
> internal state variables. I'm surprised that changing the length of the main
> loop with this sort of code would change the nature of any RF noise being
> generated by the PIC! So can anyone explain?

It sounds like you don't have a good enough capacitor across the power
pins of the PIC or the capacitor is too far away.

I recently made the mistake of having the capacitor too far away from the
PIC's Vdd and Vss.  Without the capacitor in the right place, I saw lots
of high frequency noise on the power lines.  I only have a 20 Mhz
oscilliscope.  There was certainly noise at 20 Mhz.  I assume that there
was probably a fair amount of noise at 40 Mhz, but my scope can't show
that.

I didn't experiment to see how the noise correlated with the running
program.

> Oh and can anyone offer any advice on the best way to isolate PIC based
> projects that are used with RC equipment (given that they probably need to
> share a power supply and take input(s) from the RC gear)?

If possible give each part of the circuit its own voltage regulator.  So,
isolate the power supplies as much as is practical.

--
.....paulhKILLspamspam@spam@hamjudo.com  http://www.hamjudo.com
The April 97 WebSight magazine describes me as "(presumably) normal".

1998\02\01@145036 by paulh

flavicon
face
On Sun, 1 Feb 1998, Andy Shaw wrote:

>  Now for
> the odd part I found that by simply adding a few nops to the loop in my code
> I get get rid of the glitching. What I don't understand is why. The code I
> have does not change the state of any external pins it simply runs waiting
> for an interrupt on change from portb and maintains a few time related
> internal state variables. I'm surprised that changing the length of the main
> loop with this sort of code would change the nature of any RF noise being
> generated by the PIC! So can anyone explain?

It sounds like you don't have a good enough capacitor across the power
pins of the PIC or the capacitor is too far away.

I recently made the mistake of having the capacitor too far away from the
PIC's Vdd and Vss.  Without the capacitor in the right place, I saw lots
of high frequency noise on the power lines.  I only have a 20 Mhz
oscilliscope.  There was certainly noise at 20 Mhz.  I assume that there
was probably a fair amount of noise at 40 Mhz, but my scope can't show
that.

I didn't experiment to see how the noise correlated with the running
program.

> Oh and can anyone offer any advice on the best way to isolate PIC based
> projects that are used with RC equipment (given that they probably need to
> share a power supply and take input(s) from the RC gear)?

If possible give each part of the circuit its own voltage regulator.  So,
isolate the power supplies as much as is practical.

--
paulhspamKILLspamhamjudo.com  http://www.hamjudo.com
The April 97 WebSight magazine describes me as "(presumably) normal".

1998\02\01@161418 by Andy Shaw
flavicon
face
Hi Folks,
Thanks for the feedback. I understand the general issues with RF noise. I
think the thing that surprised me was that I had assumed that it would be
the rate of execution (i.e. processor speed) that defined the type and
frequency rather than the actual mix of instructions being executed. I
suppose I shouldn't be that surprised since presumably different
instructions cause different groups of gates to operate etc. and so cause
different amounts of current to flow. So I guess an interesting follow-up
would be to find out if anyone knows anymore about which instructions
generate the most noise. My guess would be that a mix of low current use and
high current use instructions would generate the most - but that would only
be a guess. Oh well intertesting but not that important (to me at least :-))

Andy

>My guess is that by inserting the NOP's you increased the cycle time of the
>loop thus making the freq. of the interference lower.  It's probably still
>present just moved lower and out of range of the receiver.  Something we
>all need to consider -- RF interference from our projects!
>

1998\02\01@164642 by Bryan Hord

flavicon
face
OK,

Here are some things that are fairly standard to get rid of interference.

1.  Make sure that you have a good ground plane under anything that uses RF
frequencies especially the micro controller and I/O lines.  This should be
part of the PCB design.  If you are prototyping, try using protoboard with a
ground plane.  It won't be as good as a PCB made with a large ground plane
but it should help.  Some people use a split ground plane but I have had
disastrous results using a split ground plane.

2.  Try to choose a crystal frequency that is not a multiple (harmonic) of
the frequencies found in you radio equipment.  I don't know what the IF
(Intermediate Frequency) of the receiver is but you should stay away from
harmonics of it as well as the 40MHz frequency that you are trying to
receive.  If I were to guess I would say your IF is 10.7MHz.  So a 20MHz
crystal in a project that is trying to receive a 40MHz signal can cause
interference because 40MHz is the second harmonic of 20MHz.

3.  Bypass your supplies well.  Are you using a linear regulator or a
switching regulator?  Some switching regulator designs are rich in harmonics
and need more filtering that linear supplies.  Use good quality caps for
bypassing.  If you are using electrolytic or tantalum caps, put a good
quality ceramic in parallel with it.  For low current applications at high
frequencies, I use 0.01uF X7R (X7R is the describes the dielectric of the
ceramic) parts.  If you are running servos, check your supply voltage with a
scope and see if the voltage dips when the servo starts to move.  I had that
problem on a project and it caused a lot of strange behavior.

4.  Ferrite beads can help.  Many people swear by them.  I noticed that a
lot computer equipment cables now have the big "snap on" type of ferrite RFI
suppressors.  Put small beads on power supply leads, I/O lines and anything
else that has a wire to or from the micro controller board.  I personally
have not had good luck with ferrite beads.

5.  Shielding is a good way to protect against radiated noise.
Experimentation is the only guideline I can think of for shielding.


How do the "gliches" manifest themselves?

-------------------------------------------------------------------------
At 05:52 PM 2/1/98 -0000, you wrote:
{Quote hidden}

------------------------------------------------------
Wireless Link Corp.
wllink.com          web site
.....bryanKILLspamspam.....wllink.com    email
(408)739-5465 x103  ph
(408)739-5483       fax

1998\02\01@165615 by John Payson

picon face
> Thanks for the feedback. I understand the general issues with RF noise. I
> think the thing that surprised me was that I had assumed that it would be
> the rate of execution (i.e. processor speed) that defined the type and
> frequency rather than the actual mix of instructions being executed. I
> suppose I shouldn't be that surprised since presumably different
> instructions cause different groups of gates to operate etc. and so cause
> different amounts of current to flow.

Generally, the most important thing is the clock rate; on the PIC, most of
the noise will be at harmonics of the instruction clock (xtal/4).  For very
tight loops there will be additional noise at harmonics of the loop rate,
but for loops longer than a few cycles the frequency will be low enough that
you don't need to worry about /that/ aspect of RF interference.  On the
other hand, there were some games for the Timex-Sinclair 1000 which used an
AM radio for their sound output; bursts of instructions at regular intervals
could cause identifiable sounds on the radio (supposedly).

In your particular situation, what's probably happening is that the RF noise
at the particular frequency of interest is being affected greatly by the
instruction mix, even though the total amount of RF noise is not.  Unless
you have equipment to measure the spectrum of RF noise emitted, anything you
try to do with the instruction mix will be primarily hocus-pocus and will
have little practical effect on RF emissions.

1998\02\02@014229 by Leon Heller

flavicon
picon face
In message <01bd2f3a$1b874360$LocalHost@eeyore>, Andy Shaw
<EraseMEandy.shawspam_OUTspamTakeThisOuTVIRGIN.NET> writes
{Quote hidden}

A long time ago, it was found that by putting an AM radio near a
computer, with appropriate programs using delay loops, tunes could be
generated and heard on the radio.

You really need to read up on EMC! It's a big topic, I'm afraid. For
starters, you need to screen the PIC and it's circuitry from the Rx, by
enclosing it in a grounded metal case. You'll then need to decouple the
leads entering the box, with capacitors, ferrite beads, etc.

Leon
--
Leon Heller: leonspamspam_OUTlfheller.demon.co.uk http://www.lfheller.demon.co.uk
Amateur Radio Callsign G1HSM    Tel: +44 (0) 118 947 1424
See http://www.lfheller.demon.co.uk/dds.htm for details of my AD9850
DDS system. See " "/diy_dsp.htm for a simple DIY DSP ADSP-2104 system.

1998\02\02@145055 by ken

flavicon
picon face
I have design lots of PIC based units for use with RC systems and 100's
of them have been made all around the world. I have never seen any
indication of RF noise from the PIC and have never had one builder of my
projects mention it.

I would suggest that this problem is being caused by some other inter-
action.

Ken.

+-----------------------------+--------------------------------------------+
|      Ken Hewitt  G8PWC      |        Email @spam@kenKILLspamspamwelwyn.demon.co.uk        |
|      /\/\/\/\/\/\/\/\/      |  Homepage   http://www.welwyn.demon.co.uk  |
+-----------------------------+--------------------------------------------+

1998\02\02@175632 by Andy Shaw

flavicon
face
Hi Ken,
Ken said....

>I have design lots of PIC based units for use with RC systems and 100's
>of them have been made all around the world. I have never seen any
>indication of RF noise from the PIC and have never had one builder of my
>projects mention it.
>
>I would suggest that this problem is being caused by some other inter-
>action.
>

Well I sort of agree. I only see this problem when testing the breadboard
version of my project (which has lots and lots of wires and no real
decoupling etc.) and only when the RC transmitter is turned off. However it
is real and certainly changing the instructions in the loop generates the
effect I mentioned. It is also much more noticeable when I'm using an ICE to
run the code, but is still there with a PIC in the board. However in the PCB
version of the project (which is obviously much cleaner and has caps etc.) I
do not see the problem. It was really the effect of changing the loop that
intrigued me rather than having an actual problem. Also I thought I would
take the chance to take advantage of the lists experts on EMC issues. Which
as usual has resulted in lots of interesting and good advice. Thanks to
everyone that replied.

Andy

BTW Ken do you take any special steps in your own designs ?

1998\02\02@195438 by Mauro, Chuck

flavicon
face
Andy,

I'd like to throw my 2 cents in, if you'll allow me, before you close
the chapter on this topic (at least for your personal needs).

First off, let me say that I'd never imagine that in all the work I did
in designing mice at Microsoft, so many problems exist in making the
little critters work, and NOT THE LEAST of which is passing agency
testing...  The bar for agency compliance in the various markets of the
world is constantly being raised, as knowledge of just how noisy, and
how susceptible to noise (electronic, that is) our products REALLY are.
RFI is a serious problem for much of the world.  Example:  The pilot of
a domestic airline flight recieved a communication from his ATC, and was
asked if he realized he was more than 20 degrees off course!  The pilot
checked his instruments, and did not concur.  ATC assured him he was
hundreds of miles off course.  This veteran pilot, wise to the ways of
his typical plane full of business travelers, then got on the P.A. to
the main cabin, and asked if all passengers could turn off their PC's,
or any other electronic equipment is use.  As the passengers complied,
sure enough - the navigation gear indicated that he was on a heading
more than 20 degree deviated from the course he thought he was on...  I
don't know about you - but I want to GET to my destination when I take a
flight - in one piece - without an emergency landing!

This of course is an extreme example - but very real - and laptop PC's
are already supposed to be FCC compliant before they can be marketed!

Here are some general issues that all who read this should be aware of -
whether you are designing a commercial product or are just working on
hobby projects.

1) In talking about RFI, You are concerning yourself with a subset of
the field known as EMC - Electro-Magnetic Compatability.  EMC is often
broken down into:

a) EMI/RFI (both radiated and conducted) Emmisions,
b) Electro-Magnetic Susceptibility to:

 i) RFI (both conducted and raditated),
 ii) ESD (both contact and air discharge), and
 iii) EFT/B (Electical Fast Transient / Burst)

2) ALL microcontrollers generate and use Radio Frequency energy.
3) RFI comes from several sources in a given chip:

a) The oscillator,
b) Core logic switching noise (induced onto the power supply and
radiated from the die),
c) Peripheral logic (pin drivers).
d) Overall board layout radiaters (improper traces lengths, poor power
gridding, decoupling, etc.)

4) Most RFI, in general, will be 3rd order harmonic related, because
most signals internal to the chip are fundamentally a square, or
rectangular wave.  There will be, of course, derived, lower operating
clocks and signals that will contribute what LOOKS like even harmonic
noise to the fundamental, but aren't really, although they are real
harmonics none-the-less...

5) I've designed mice with PIC's, and although they can be  one of the
better low-emission chip types, they still all radiate, some to a
greater degree than others.

6) Instruction mix is a major factor affecting noise because it's the
dynamic mix of 1's and 0's propagating around the CPU that changes the
current flow through core.  It's mostly this dynamc current flow that is
responsible for core noise, do to di/dt issues with CMOS gate
structures, and the very fast edge rates present from today's fast
switching CMOS gates.

7) Your PIC is also sensitive to RF noise.  Place your chip close enough
to a high power, high frequency source, and you may start to notice
strange behaviour from the little guy.

8) Proper layout can help in a PC board - but if the chip is a huge
radiator (some are), all the board layout tricks in the world may not
give you FCC, CE, C-Mark, or other agency approval.  One of the hardest
problems I ever had to solve as an EE, was to quite down a mouse using
brand X microntrollers...  It was an on-going 2+ yr. struggle, and it
finally was only solved by understanding the fundamental current flow
model of the brand X microcontroller, and by applying various "tricks"
to the core, Osc. and peripheral logic design of the chip!  No amount of
external caps, ferrites, critical length trace minimization, proper
supply distribution or other PCB issues would EVER fix the basic
problem.  The chip was a horrenduous EMI radiator.  Period.


The list of issues involved in this arena is a very large one - and I've
barely begun to scratch the surface on the subject.  The bottom line is,
you may not percieve a problem in the final product, but unless you
design in EMC from the get-go, your deign, just like everyone else's,
generates RFI and is susceptable to RFI - to some degree or another.

Hope this sheds some light.

Peace,

Chuck Mauro

> {Original Message removed}

1998\02\02@234656 by John Payson

picon face
> >  Example:  The pilot
> >of
> >a domestic airline flight recieved a communication from his ATC, and
> >was
> >asked if he realized he was more than 20 degrees off course!
>
> [due to a passenger's portable computer in the cabin]
>
> >This of course is an extreme example - but very real
>
> If this incident really did happen, I'd like to know more details.  As
> far as I've heard the restriction on the use of electronic devices inside
> airplanes is based on a legitimate concern that there is a potential for
> trouble, not an actual documented incident.  These restrictions have been
> reduced since it doesn't seem to cause much of a problem after all.
> Still much better safe than sorry though.

The only incident I read about involved passengers listening to a sports
broadcast on portable radios.  I'm not an RF expert, but my understanding
is that the game was on a weak station at 104MHz or so while there was a
much closer station broadcasting at 96Mhz.  Apparently many FM radios use
tuning circuits that can "reflect" other frequencies about the tuning
frequency; consequently the radios were radiating energy at 104+(104-96)
or 112Mhz, right in the middle of a navigation band.

As it happens, by the way, computers happen to pretty well avoid the bad
frequencies, since the harmonics of 33Mhz (66, 99, 132, 165) all miss the
navigation band as do the harmonics of 25Mhz (50, 75, 100, 125).  While
computers do also generate lower frequencies, the likelihood of computers
spending much time in identical loops is pretty remote.

1998\02\03@032920 by Morgan Olsson

picon face
>Apparently many FM radios use
>tuning circuits that can "reflect" other frequencies about the tuning
>frequency

FM radios use a frequenzy synthesised signal that mixes with the antenna
signal. The result is then fed trough a 10,7 MHz very narrow bandpass filter.
To listen at a station at 96 MHz the frequenzy synthesizer is set to 96MHz
plus OR minus 10,7MHz.

So, an FM radio always emits a 10,7MHz signal when tuned. Also a signal of
the station to listen to, plus or minus 10,7 MHz. And also the frequency
synthezizer's crystal frequenzy (whatever it is) and maybe some
microcontroller. But om modewrn radios all theese signals are very weak.

>As it happens, by the way, computers happen to pretty well avoid the bad
>frequencies, since the harmonics of 33Mhz (66, 99, 132, 165) all miss the
>navigation band as do the harmonics of 25Mhz (50, 75, 100, 125).  While
>computers do also generate lower frequencies, the likelihood of computers
>spending much time in identical loops is pretty remote.

I«m no not an RF expert either, but is not the deangerous frequencies the
overtones odd of 3,5,7 etc, like as with crystal resonance?

Anyway, in my office most FM radio signals are weak, and my computer hits
most of the stations (100 MHz Pentium) And I can also listen to my how my
hard disk and modem work in the FM-band!
/Morgan
Morgan Olsson, MORGANS REGLERTEKNIK, Sweden
KILLspammrtKILLspamspaminame.com, ph: +46 (0)414 70741; fax 70331
-

1998\02\03@050322 by Steve Baldwin

flavicon
face
> As it happens, by the way, computers happen to pretty well avoid the bad
> frequencies, since the harmonics of 33Mhz (66, 99, 132, 165) all miss the
> navigation band as do the harmonics of 25Mhz (50, 75, 100, 125).  While
> computers do also generate lower frequencies, the likelihood of computers
> spending much time in identical loops is pretty remote.

The actual clock frequency plays a fairly small role in RF emissions. The
killer is the switching edges (di/dt), which is where the energy transfer
takes place, and loop aeas.

If you want a graphic demonstration of this, find a board with an external
data bus and something relatively slow (say an 8051 @ 10MHz). Now replace
the HC logic with the equivalent AC family parts and watch the emissions
hit the roof.

Rule of thumb - Use the slowest speed parts you can.

A good example is the difference between an inbuilt crystal oscillator and
using an external can type. With something like a PIC, you have a nice sine
wave on the outside with no harmonic content and low energy. It doesn't
become digital until it's inside the chip where the loop areas are small.
On the other hand. If you buy an oscillator unit, it will be one of a range
that may go as high as say, 50MHz. The output is therefore designed to give
suitable switching edges for a 50MHz clock, even though yours is say, 4MHz.
Now you have all the harmonics of a high frequency impulse superimposed on
the harmonics of the 4MHz square wave. Given all those harmonics floating
around the PCB (and Mr. Fourier says there are quite a few), what are the
chances of one of them finding a track that's just the right length to
resonate ?

I'm quite impressed that so many PC's are able to pass FCC limits. When you
have things like PCI that rely on reflections over a few inches in order to
work and VRAM being clocked at God knows what. Add to that cables all over
the place and big holes in the front, it's suprising the cordless phone
ever had a chance.

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: RemoveMEstevebTakeThisOuTspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1998\02\03@111425 by Mauro, Chuck

flavicon
face
Mike,

Please allow me to address your concerns about the validity of the
airline story.  This was not an "urban legend" as you so eloquently put
it.  I did not feel it relevant to include all of the details - it was a
several page document replete with a discussion about all of the actual
nav gear affected and so forth. This comes from a report filed with the
FAA and FCC, and was part of an article in an agency testing journal I
read while on the job at Microsoft - it was highly recommended reading
as far as I know for all of the 30 or so EE's at MSH (it was distributed
to us by the company performing agency compliance testing for us at the
time).  I read the material 16 or so months ago, and naturally, not all
of the minutia are completely fresh in my mind.  I omitted various
details that I do remember for 3 reasons:

1) they are lengthy, and detract from the general knowledge and point I
was trying to clearly make,
2) I don't have a copy of the report any more - It's Microsoft property,
and I no longer work there. I'm not in the habit of taking things that
aren't mine.
3) I was trying to focus on the topic of EMC issues, not the art of
story telling.

BTW: it turned out that this particular flight had well beyond the
average number of users banging away on PC keyboards...  I take many
business flights, and the frequency of PC usage onboard a typical
business flight is way up.  EMC issues do matter, and will continue to
be a problem for equipment manufactures as operating frequencies rise.
Much higher levels of RF energy radiate from the average laptop or
desktop and can easily interfere with sensitive receiver gear now more
than ever, due to the fundamental clock rates of CPU's today.  The point
of the original article was that the onus falls upon the aircraft
manufacture(s), and the avionics experts to design extremely well
shielded nav and comm gear (it turns out that the fuselage does a pretty
good job of acting like a Faraday cage, although the windows can still
cause problems), but that's not an excuse or license to manufacture
poorly design products that radiate all over the spectrum...

I'm not in the habit of spreading unfounded rumors, and do not wish it
to occur on the PICLIST.  My reason for joining was to help shed light
on various topics based on my 25 years of microprocessor/microcontroller
experience, and to perhaps pick up a pearl or two of wisdom from other
members.  The point of my earlier response was to hopefully contribute
useful information on the issues one needs to address when solving EMC
problems.  Given the wide range of user experiences clearly present on
this list (from beginners to industry veterans), I did not feel
justified in going into more detail than I did.

I hope that helps to at least partially answer your questions.  I really
would like to kill this potential thread now before it turns into
another OT discussion, wasting everyone's bandwidth, time and money...

Sincerely,

Chuck Mauro




> {Original Message removed}

1998\02\03@114630 by Mauro, Chuck

flavicon
face
       " I'm quite impressed that so many PC's are able to pass FCC
limits. When you
> have things like PCI that rely on reflections over a few inches in
> order to
> work and VRAM being clocked at God knows what. Add to that cables all
> over
> the place and big holes in the front, it's suprising the cordless
> phone
> ever had a chance.  "
>
Steve,

Actually, don't be all that impressed with PC... yet.  One of the most
frustrating things about agency testing I found was that the typical PC
we would buy to test our peripheral products on would often over be over
FCC limits when we took baseline measurements.  Believe me - the "art"
of designing EMC compliant equipment for a high volume, low margin
business like the PC industry, is not quite ready for prime time.  Most
companies add the absolute minimum of shielding and suppression
components to impact COGs as little as possible.  I even found that my
mouse designs would pass one day with -3db to spare, and be +2db over
the limit the next day...  Same mouse, same computer, same test
procedure, same test engineer, etc...  The stuff that gets shipped to
the market often barely passes testing, and with the usual tolerances in
components in very high manufacturing volumes, your going to see
computers that aren't in compliance...


Chuck Mauro

1998\02\03@121743 by John Halleck

flavicon
face
On Tue, 3 Feb 1998, Mauro, Chuck wrote:

> [...]

> Please allow me to address your concerns about the validity of the
> airline story.  This was not an "urban legend" as you so eloquently put
> it.  I did not feel it relevant to include all of the details - it was a
> several page document replete with a discussion about all of the actual
> nav gear affected and so forth. This comes from a report filed with the
> FAA and FCC, and was part of an article in an agency testing journal I

 Could you point us at a specific flight, date, airline, or other information
 that would allow everyone to check the facts?
 Everytime I've tried to track this down it disappears into
 Urban Legend...

> [...]

1998\02\03@154046 by ken

flavicon
picon face
In article <01bd302d$a81d5c80$5c46a8c2@eeyore>, Andy Shaw
<spamBeGoneandy.shawspamBeGonespamVIRGIN.NET> writes
>Hi Ken,
>Ken said....
>
>>I have design lots of PIC based units for use with RC systems and 100's
>>of them have been made all around the world. I have never seen any
>>indication of RF noise from the PIC and have never had one builder of my
>>projects mention it.
>>
>>I would suggest that this problem is being caused by some other inter-
>>action.
>
>BTW Ken do you take any special steps in your own designs ?

No all I do is use a 220nF - 470nF cap as close to the supply pins of
the PIC as possible.

Ken.

+-----------------------------+--------------------------------------------+
|      Ken Hewitt  G8PWC      |        Email TakeThisOuTkenEraseMEspamspam_OUTwelwyn.demon.co.uk        |
|      /\/\/\/\/\/\/\/\/      |  Homepage   http://www.welwyn.demon.co.uk  |
+-----------------------------+--------------------------------------------+

1998\02\04@101736 by Tom Handley

picon face
  Chuck, you (and others here) raise some very good points. Another
problem is how well the case of a PC (or other equipment) is fastened
to the chassis. I've seen loose or stripped screws and paint on the
case where it meets the chassis...

  - Tom

At 08:37 AM 2/3/98 -0800, you wrote:
>>        " I'm quite impressed that so many PC's are able to pass FCC
[snip]
{Quote hidden}

1998\02\04@123258 by Martin McCormick

flavicon
face
       I agree with those who say that the problem is getting worse even
though the standards are getting more strict.  With the fundamental
frequency of the clocks in high-performance computers and telecommunications
systems now in the 100 to 200 MHZ range, that puts them in the prime
realest ate area that most of the world uses to carry out its business.
The carriers and sideband splatter from modulation of those carriers by
switching activity makes for what has been called electronic smog.  It is
very bad on a college campus or a business building with lots of computers
and a fast network.

       The steady carriers from clock generators are a show stopper if they
land right on the frequency used by an organization to communicate, but the
worst problems are those caused by the noise bursts that happen in a
continuous torrent while hundreds of processors crunch data and chatter back
and forth over the 156-MB network backbone.

       That noise is a very wide-band crackle that sounds like a lightning
storm in fast-forward if one uses an AM receiver and hears it.  The noise
disrupts the sort of narrow-band FM receivers that are the main stay of
two-way radio systems and pagers all over.  Narrow-band FM or NBFM receivers
commonly mute the speaker between transmissions by rectifying the noise
picked off from the discriminator in the absence of signal.  A high-pass
filter gets rid of the audio so the only signal at this point is noise when
nothing is being received.  This noise is rectified and used to bias the
muting switch.  When there is extra noise from computers or other sources,
that noise fools the mute in to thinking that the signal is not there or is
weak and it kills the speaker.  The person using the system may not hear a
thing while somebody in the field is needing help.  They may also hear bits
and pieces of the transmission and waste time calling for repeats.  They
will probably not think of computers, but will call the service technicians
who will possibly miss the problem but won't miss sending a bill to the
customer.  Even if the technician suspects noise interference, he or she
may have trouble finding or curing the problem because it is coming from
several locations at once.

       This last Fall, when hundreds of students and their computers moved
in to student housing for the new school year, one of our campus public
safety radio systems got hard of hearing on the day the students moved in.
There does not appear to be any malicious behavior involved and the racket
appears to be from many sources.  The only thing that has changed is the
availability of 100 and 200 MHZ systems for the masses.

       The stories about lap-top computers on airplanes and other tails
of the strange probably do get mangled in the retelling, but the problems
are real and not to be taken lightly.

Martin McCormick WB5AGZ  Stillwater, OK 36.7N97.4W
OSU Center for Computing and Information Services Data Communications Group

1998\02\04@132425 by David W. Duley

picon face
In a message dated 98-02-02 23:15:57 EST, you write:

<<
Umm, yeah.  Names and other verifiable details conveniently omitted (even
to the type of "navigation gear" that was affected).  Pilots have several
radically different, completely independent methods of determining their
position and course, not even including reports from the ground.  Sounds
like an urban legend, or a pilot who made a mistake (fortuantely one that
didn't hurt anyone) trying to blame technology to cover his rear.

If this incident really did happen, I'd like to know more details.  As
far as I've heard the restriction on the use of electronic devices inside
airplanes is based on a legitimate concern that there is a potential for
trouble, not an actual documented incident.  These restrictions have been
reduced since it doesn't seem to cause much of a problem after all.
Still much better safe than sorry though.
 >>

I was recently on a very long flight from LAX to Seol.   They would let us use
lap top computers but not CD players.
Why would you get more RF from a CD player but not a laptop?

Dave

1998\02\04@133608 by Rob

flavicon
face
On Wed, 4 Feb 1998, David W. Duley wrote:
>
> I was recently on a very long flight from LAX to Seol.   They would let us use
> lap top computers but not CD players.
> Why would you get more RF from a CD player but not a laptop?
>

Possibly because the CD player only has to comply to FCC class B but the
laptop has to comply to Class A??

Or maybe becuase the frequencies are more problematic with CD players than
PCs?

Rob


> Dave
>

1998\02\04@160428 by Steve Baldwin

flavicon
face
>  Umm, yeah.  Names and other verifiable details conveniently omitted
(even
>  to the type of "navigation gear" that was affected).  Pilots have
several
>  radically different, completely independent methods of determining their
>  position and course, not even including reports from the ground.  Sounds
>  like an urban legend, or a pilot who made a mistake (fortuantely one
that
>  didn't hurt anyone) trying to blame technology to cover his rear.
>
>  If this incident really did happen, I'd like to know more details.  As
>  far as I've heard the restriction on the use of electronic devices
inside
>  airplanes is based on a legitimate concern that there is a potential for
>  trouble, not an actual documented incident.  These restrictions have
been
>  reduced since it doesn't seem to cause much of a problem after all.
>  Still much better safe than sorry though.

I can remember seeing some details on that incident and it included that
sort of information (flight number, etc). It was a few years ago and oddly
enough, I can't remember any details.

If you must find something, you may wish to follow up this quote from a
book on the subject.

>> The IFALPA International Quarterly Review has reported 97 EMI-related
events due to passenger "carry-on" electronic devices since 1983. <<

If you can find that (probably published around 1993), there will probably
be references to the original reports on each case.

You may also want to consider why Korean Airlines flight KE007 wandered
into Russian airspace.
AFAIK, there hasn't been a conclusive reason found (apart from the spy
theory which is the one  favoured by people who have seen Elvis).

Steve.

1998\02\04@161922 by Rick Kozak

flavicon
face
part 0 430 bytes
head>

:
:
: Possibly because the CD player only has to comply to FCC class B but the
: laptop has to comply to Class A??
:

NOTE: Class B is MORE stringent than class A. As class B is for consumer products, and Class A is industrial. (If only my stuff could just get away with Class A....)

rick

1998\02\04@162128 by Morgan Olsson

picon face
At 13:12 1998-02-04 EST, you wrote:
>I was recently on a very long flight from LAX to Seol.   They would let us
use
>lap top computers but not CD players.
>Why would you get more RF from a CD player but not a laptop?
>
>Dave

I think this is more a question of audio noise...

Maybe the pilot want the passengers to be able to hear eventual emergency
information, or "fasten your seatbelts" etc.

/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  RemoveMEmrtspamTakeThisOuTiname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

1998\02\04@162328 by Mauro, Chuck

flavicon
face
Thanks for your contributions to my original point, Steve.

- C. Mauro

{Quote hidden}

1998\02\04@193315 by Wayne Foletta

flavicon
face
Steve:
Yes, di/dt - important point for RFI.
Just to expand on your point of di/dt - reducing di/dt or dv/dt reduces
the energy of each frequency component.

V                      Amplitude|   |
^   ___     ___               ^ |   |   |               |
| _|   |___|   |___ = >       | |___|___|___|___.___|___|___|___.___
 -> time                        -> frequency

^ V ___     ___        Amplitude|   |
| _/   \___/   \___ = >       ^ |___|___|___.___ ___.___|___.___ ___
 -> time                      | -> frequency

Second point - loop area.
Larger loop area or conductor traces =  larger antenna size in
wavelength.
Larger antenna size = larger radiation energy.
So higher frequency operation requires shorter, lower inductance signal
conductors to reduce RFI.

- Wayne Foletta
BMI - Saratoga, CA

{Quote hidden}

1998\02\04@215322 by Tom Gretton

flavicon
face
Some time ago,  a major carrier (Delta, TWA, ?) announced a similar
prohibition.  I recall the rationale was that there was a critical frequency
in the laser diode driver circuit.

Several months/years ago,  IEEE Spectrum ran an article on Personal
Electronic Devices in the airborne environment and gave insight into the
deliberations of the Radio Technical Commission for Aeronautics Special
Committee which was looking into the subject and its associated hazards.


Tom

{Original Message removed}

1998\02\05@004400 by Pedro Drummond

flavicon
face
>
>I was recently on a very long flight from LAX to Seol.   They would let us use
>lap top computers but not CD players.
>Why would you get more RF from a CD player but not a laptop?
>
>Dave
>
>


What kind of music do you usually listen ? :)

1998\02\05@090246 by Brian Schousek

picon face
-----Original Message-----
From: Steve Baldwin <EraseMEstevebspamspamspamBeGoneKCBBS.GEN.NZ>
To: RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU <PICLISTSTOPspamspamspam_OUTMITVMA.MIT.EDU>
Date: Wednesday, February 04, 1998 4:05 PM
Subject: Re: RF Noise


>>  Umm, yeah.  Names and other verifiable details conveniently omitted
>(even
>>  to the type of "navigation gear" that was affected).  Pilots have
>several


This description sounds somewhat similar to the situation described earlier.
This came from the ASRS Database Report Sets Index (at
http://www-afo.arc.nasa.gov/ASRS/repsets.htm ) The PED subcategory contains
49 more reports. This should be enough anecdotal evidence... and someone
also mentioned the IEEE Spectrum article. Before you go flaming me, note
that the report is originally in all caps :-) and I'm not going to waste my
time prettifying this one. Also, the specific airline, flight # etc. are
apparently removed as a matter of course to encourage reporting of these
minor incidents without fear of reprisal.

Brian



ACCESSION NUMBER             : 236131
DATE OF OCCURRENCE           : 9301
REPORTED BY                  : FLC; ; ; ; ;
PERSONS  FUNCTIONS           : FLC,PIC.CAPT; FLC,FO; FLC,SO; MISC,CAB;
ARTCC,RDR;
FLIGHT CONDITIONS            : VMC
REFERENCE FACILITY ID        : ZZZ
FACILITY STATE               : US
FACILITY TYPE                : ARPT; TRACON;
FACILITY IDENTIFIER          : IAH; IAH;
AIRCRAFT TYPE                : WDB;
ANOMALY DESCRIPTIONS         : ACFT EQUIPMENT PROBLEM/CRITICAL; NON
ADHERENCE LEGAL RQMT/FAR;
ANOMALY DETECTOR             : COCKPIT/FLC; COCKPIT/EQUIPMENT;
ANOMALY RESOLUTION           : FLC OVERCAME EQUIP PROBLEM;
ANOMALY CONSEQUENCES         : NONE;
SITUATION REPORT SUBJECTS    : AN ACFT TYPE; ACFT EQUIPMENT; PROC OR
POLICY/FAA;
NARRATIVE                    : FIRST TIME: GOING FROM DEN-CLE LOST ALL
DIRECTIONAL GYROS EXCEPT WHISKEY COMPASS. ADVISED ZAU. 10 MINS LATER, LOST
VOR'S AND RMI'S. NOTIFIED ZAU AND DECLARED EMER. WX GOOD AT DEST (CLE).
CONTINUED ON AND LANDED WITHOUT INCIDENT. DID NOT THINK TO HAVE FLT
ATTENDANTS CHK CABIN FOR ELECTRONIC DEVICES. SECOND TIME: GOING FROM
SAN-IAH, LOST REMAINING DIRECTIONAL GYRO (#2). #1 COMPASS COUPLER PLACARDED
IN SAN NIGHT BEFORE, DID NOT LOSE VOR'S OR RMI'S AS DID FIRST TIME. DIRECTED
FLT ATTENDANT TO SEARCH CABIN FOR 'RADIOS AND TELEPHONES,' FORGOT TO ASK HER
FOR LAPTOP COMPUTERS, SHE RETURNED AND SAID SHE FOUND NOTHING. ADVISED ZAB
LOST ALL DG'S BUT STILL HAD NAVS. WX AT IAH, LOW CEILING 800-1000 MSL WITH 2
MI VISIBILITY AND FOG. DID NOT DECLARE EMER. APCH GAVE ME TIMED TURNS.
INTERCEPTED LOC FOR ILS. LANDED WITHOUT INCIDENT. THIRD TIME: GOING FROM DEN
TO EWR. LOST ALL DG'S AT CRUISE ALT. TALKING TO ZAU, ODDS OF COINCIDENCES
TOO GREAT. INSTRUCTED FLT ATTENDANT TO GO THROUGH CABIN AND INSTRUCT ALL PAX
WITH RADIOS, LAPTOPS, ETC., TO TURN THEM OFF. SHE RETURNED AND RPTED APPROX
25 PAX WITH RADIOS LISTENING TO FOOTBALL GAME AND ONE PAX USING LAPTOP. DID
NOT RECOVER DG'S. AFTER 5 MINS, ASKED FLT ATTENDANT IF PAX STILL USING
RADIOS. SHE CAME BACK AND RPTED 'YES.' I IMMEDIATELY MADE A PA FOR ALL PAX
USING SUCH DEVICES TURN OFF ALL RADIOS DUE TO AFFECTING NAV EQUIP. LESS THAN
90 SECONDS PASSED, GYROS CORRECTED THEMSELVES TO PROPER HDG. 20 MINUTES MORE
PASSED AND DIRECTIONAL GYROS BEGAN MOVING OFF CORRECT HDG BY AS MUCH AS
20-30 DEGS. PICKED UP MIKE AND MADE ANOTHER PA. TOLD PAX IF THEY DIDN'T TURN
RADIOS OFF, I WOULD HAVE FLT ATTENDANT GO THROUGH CABIN AND CONFISCATE ALL
RADIOS AND HOLD THEM UNTIL REACHING EWR, OUR DEST. LESS THAN 2 MINS PASSED
AND GYROS SWING BACK TOWARD CORRECT HDG. NO FURTHER INCIDENT ENSUED. I
THOUGHT I WAS THE ONLY CAPT EXPERIENCING THESE PROBS UNTIL I READ ARTICLE IN
AVIATION PERIODICAL, ALSO IN LCL NEWSPAPER. I AM SUBMITTING THIS INFO IN
HOPES THAT REMEDY CAN BE FOUND AS SOON AS POSSIBLE. CALLBACK CONVERSATION
WITH RPTR REVEALED THE FOLLOWING INFO: RPTR STATED THAT THE 3 INCIDENTS
HAPPENED IN 3 DIFFERENT ACFT. HE WAS UNABLE TO EXPERIMENT TO PIN DOWN JUST
WHICH ELECTRONIC DEVICES WERE CAUSING THE PROB.
SYNOPSIS                     : PAX ELECTRONIC DEVICES AFFECT DIRECTIONAL
GYROS AND VOR NAV INDICATIONS.
REFERENCE FACILITY ID        : ZZZ
FACILITY STATE               : US
MSL ALTITUDE                 : 33000,33000

1998\02\05@104455 by Tom Rogers

flavicon
face
Boy, is this ever a good example of how these legends get started. Note that
the offending devices were reported second hand to be radios; in no case was
the computer or a cd player indicted. The pilot only had his 'black box'
experiment ("I say it in the intercom HERE and the gyros correct THERE") in
one case to support the supposed cause and effect. The report contains third
hand anecdotal evidence of other incidents (from the controller), and to top
it all off, I don't even know the source of this relatively poorly
identified source. I don't know with any real assurance that there ever was
a pilot, or a real report, or even any such organization as the one refered
to in the posting. This is not a good foundation for forming an engineering
opinion.

I could go looking for the original source of the quoted material, I
suppose, but the real point is that I would be overstepping the bounds of
truthfulness if I were to talk about this material (say, at a party or over
dinner) as if it concerned the issue of interference with the nav systems on
airplanes. What this stuff actually addresses is the reporting of alledged
incidents, but I'll bet by Friday there are at least 2 dozen conversations
by list members about it, leading to dozens more, and in two months we'll
catch the wave coming back at us all over.

Yikes.

--Tom Rogers

----------------------------------------------------------------------------
------------------------------------------
>ACCESSION NUMBER             : 236131
>DATE OF OCCURRENCE           : 9301
>REPORTED BY                  : FLC; ; ; ; ;
>PERSONS  FUNCTIONS           : FLC,PIC.CAPT; FLC,FO; FLC,SO; MISC,CAB;
> &etc.................

1998\02\05@125635 by Lee Jones

flavicon
face
> Boy, is this ever a good example of how these legends get started. Note that
> the offending devices were reported second hand to be radios; in no case was
> the computer or a cd player indicted. The pilot only had his 'black box'
> experiment ("I say it in the intercom HERE and the gyros correct THERE") in
> one case to support the supposed cause and effect.

It certainly lacks experimental rigor.

> and to top it all off, I don't even know the source of this relatively
> poorly identified source.

If the design works, you never will.  ASRS depends on annonymity.
(A previous voluntary safety reporting system run by the FAA had
a little problem.  The FAA used the reports as the basis of action
against the pilot.  Participation kind of dropped off rapidly.)

> I don't know with any real assurance that there ever was a pilot, or
> a real report, or even any such organization as the one refered to in
> the posting. This is not a good foundation for forming an engineering
> opinion.

ASRS is the Aviation Safety Reporting System.  It's a joint
FAA-NASA program.  As I recall, it's funded by the FAA and
totally run by NASA.  It's an attempt to gather & disseminate
information about incidents before they cause accidents.  It's
been in existance for years (decades?).

You (pilots, controllers, etc) file reports with the ASRS office
at Moffet Field (San Francisco bay area).  Top strip contains all
the identifying information.  ASRS assigns an incident number and
date/time stamps the strip then returns it to the submitter.  ASRS
is also supposed to censor any identifying information from the
body of the report before entering it in their computer files.

As part of the carrot to get people to file reports, there's a
provision where if the FAA starts action on the incident, if the
person charged filed an ASRS report within 10 days of the event,
the FAA waives the penalty.  There are certain restrictions but
overall it's a powerfull incentive.

From everything I've heard, the ASRS office happily cooperates
with anyone doing serious research.

> DATE OF OCCURRENCE           : 9301

Notice that the event(s) described occured 5 years ago.  I
expect the emissions from current generation handheld (or
laptop) devices have significantly different characteristics.
Assuming the old devices interfered (a position I'm not willing
to defend), do the current ones do so too?  In the same ways?

                                               Lee Jones

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...