Noisy data line clears up on wiring up multiple output pins of uC to Logic Analyzer

Question

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.

Answer 1

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.

Answer 2

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?