Some people reading my question might be familiar with a string of questions (latest being this one) where I have been asking about how to decode data from an ISM-band ASK/OOK type RF receiver module. One of the excellent techniques I learnt from one of the answers was to use the pin-toggling to debug my program, using a logic-analyzer. The uC platform of my choice is Arduino (at 20MHz).

Now from my previous post it would be clear that I was dealing with the situation where the valid received data (encoded) was to be found from a data stream which seemed very noisy with high frequency signals, and I thought that I'd found a satisfactory rationale to ignore the high frequency signals by discarding them in software if the duration in that state was lesser than that of valid signals expected. This seemed to be going well for a while, and I started making some progress.

In debugging some of the problems I was facing, I landed up adding 5 additional lines to the logic-analyzer (in addition to the RF Rx data going from the RF module to uC). These additional lines would toggle in software based on various runtime conditions in the program, s.a. ISR invocation, every 100th main loop() invocation, meeting some conditions etc. To my surprise, I noticed that with this, my "noisy" RF-RX data line had cleared up, or rather instead of the high frequency noise, I was seeing low frequency noise, and the lengths of marks/spaces have become much longer than that of the valid RF data signal. So to validate my observation, I plugged out my debugging pin lines. Lo-and-behold, the noisy chatter was back. I computed the smallest pulse duration, and also the typical pulse-duration in both of these cases, and there is an order of magnitude difference. The observation is highly repeatable.

My circuit is on breadboard, and I am using home-made connectors (between 6cm - 15cm), i.e. the stiff single-strand copper wire, you find in Ethernet (CAT-5) cables. My logic-analyzer's unused inputs are all grounded. It is the Openbench Logic Sniffer.

My question is, how do I explain this ?

Edit: Thanks to many of the tips, clues I received here, I believe that I've managed to isolate the behaviour to usage of Pin# 13 on Arduino, although I can't quite (yet!) nail it, i.e. what exactly is the reason for the behaviour.

I have confirmed by several rounds of tests that, if I have my ISR() logic mapped to Pin#13, s.t. whenever a particular external interrupt (#0) is triggered on either rising or falling edge, I use pin#13 to make the waveform accordingly, i.e. to follow the state of pin with external interrupt#0.

If instead of Pin#13, I use any other digital I/O pin, I notice that the noise goes back to being high-frequency noise, but if I use pin#13 for the above-stated purpose, then the noise switches back to low-frequency noise.

Reading Arduino reference manual, I see this text, but I believe that it is not relevant as in my case the pin is configured for OUTPUT, not INPUT.

NOTE: Digital pin 13 is harder to use as a digital input than the other digital pins because it has an LED and resistor attached to it that's soldered to the board on most boards. If you enable its internal 20k pull-up resistor, it will hang at around 1.7 V instead of the expected 5V because the onboard LED and series resistor pull the voltage level down, meaning it always returns LOW. If you must use pin 13 as a digital input, use an external pull down resistor.

  • \$\begingroup\$ I'm not sure, but I think I smell a grounding problem. \$\endgroup\$ Dec 23 '11 at 17:25
  • \$\begingroup\$ Thanks @John. Had several rounds of visual inspection, and rewiring, but see nothing obvious that could mean "grounding problem". GND on breadboard is provided by Arduino. The RF module uses this GND, as do the unused logic-analyzer channels. Every other probe, connected to the Arduino digital output pins, are staggered and separated by 1 row each on the breadboard to reduce any chances of crosstalk. Is there something else I could check ? \$\endgroup\$
    – bdutta74
    Dec 24 '11 at 12:12

You need to step back and deal with this noise properly. Trying to cover it up in the firmware is the last resort. Something is making a mess somewhere.

Start by turning off everything except the receiver module and look at its output with a scope. Make sure the scope probe is properly grounded right at the receiver module ground. Make sure the logic analyser, the arduino, etc, are all off. Power the receiver from batteries if you have to. Is the noise now present on the receiver output? If so, then all the stuff that's off isn't at fault. Shut off as much other equipment in the vicinity as you can manage. Put a antenna tuned to your frequency (you only said ISM band, which doesn't tell us the frequency) on the receiver. Make a 1/2 wavelength dipole from wire if you need to. Keep poking around to find the source of the noise, which in this case is either bad module hookup or actual RF interference in your band. If the latter, there is little you can do about it.

If the signal is clean with just the module, then slowly add back other parts of the circuit one by one. Each time watch the output of the receiver on the scope. At some point you'll get the noise back, but now you'll know the source.

The best way to deal with any noise is to eliminate it at the source. Once noise gets added to your signal, there are likely parts of the noise that can't be distinguished from valid signal anymore. No amount of post processing can get rid of such noise.

  • \$\begingroup\$ I would also recommend that you pay careful attention to how you connect your probe to avoid circuit loading. Check to see if you get different results using the 1x and 10x settings. \$\endgroup\$
    – JonnyBoats
    Dec 24 '11 at 0:57
  • \$\begingroup\$ Thank you @Olin. Shall definitely try the stepwise isolation approach, in fact in some ways I did try it, but probably not too methodically so far. BTW, I've read that in the 433.92MHz ISM band, there is significant ambient noise, and also in my case, I do not have (or don't want to take) control of the transmitting end. The transmitting end is a mass-produced cheap temp + humidity sensor, and I'd rather not touch that end. So wondering if by "source" (of noise) you meant absolute source, or source within circuit i.e. my RF receiver module ? \$\endgroup\$
    – bdutta74
    Dec 24 '11 at 5:46
  • \$\begingroup\$ Thanks @JonnyBoats. I do not have scope. It is a rather inexpensive (but quite handy) logic-analyzer based on Sump (Openbench Logic Analyzer). So there are no 1x, 10x settings that I have control over. \$\endgroup\$
    – bdutta74
    Dec 24 '11 at 5:48
  • \$\begingroup\$ @icarus: In my experience the 434 MHz band is reasonably clean since most signals are low power, just isolating yourself by using distance usually works well enough. Also the duty cycle must be low, so you may get a occasional burts, but in between the RF receiver output should be fairly quiet. You really need a scope for this sort of thing. \$\endgroup\$ Dec 24 '11 at 15:35
  • \$\begingroup\$ Thanks @Olin. Have updated my question with latest findings. \$\endgroup\$
    – bdutta74
    Dec 24 '11 at 21:13

Clearly the inductance and capacitance of the lines changes when you plug/unplug your debugging lines.

I would bet that if you moved your design from the breadboard to a printed circuit board where the inductance and capacitance (which would imply engineering the length and width of the traces) were engineered, you would see much better results.

With your breadboard have you looked for crosstalk and ringing on the lines?

  • \$\begingroup\$ That does seem to be one clear possibility. I remember someone advising me against doing 2.4GHz RF on a breadboard, but I'd imagined 433MHz to be a rather low freq and thus safe for breadboards. I'm still tinkering so maybe I could move to a veroboard / GP cktboard, and keep the wirelengths minimum. Certainly one of the several things I'd try exploring. \$\endgroup\$
    – bdutta74
    Dec 24 '11 at 5:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.