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.