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: >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 > > ------------------------------------------------------ Wireless Link Corp. wllink.com web site bryan@wllink.com email (408)739-5465 x103 ph (408)739-5483 fax