Arduino 433MHz transmission fails if falling edge is less than 122ms

I am trying to control a LED using a high-power 433MHz transmitter receiver pair, with transmitter connected to my Arduino Nano.

Here is the transmitter (XLPCF20): http://www.colorapples.com/rf-wireless-transmitter-module-315-or-43392mhz-xlpcf20-p-38493.html

I can send HIGH to a data channel at the transmitter (it has 4 channels) and receive the HIGH input at the same channel at the receiver, successfully lighting up a LED. This is my current test sketch:

void setup(){
pinMode(8, OUTPUT);
}

void loop(){
digitalWrite(8, HIGH);
delay(122); //this is the important line
digitalWrite(8, LOW);
delay(100);
}


This works well, however, if I change the 122ms delay at the falling edge to 121ms (or anything below that) I have no output at the receiver. The LED doesn't light at all. It's the same for all channels, there's a sharp change at that very border between 121ms and 122ms (found the exact value by trial and error). At the transmitter/Arduino, the output signal is clear so it's an error with the transmitter or receiver. I've used other, much simpler/cheaper 433MHz transmitter/receiver pairs in the past with no such issue. At the rising edge (second delay call, the one with 100ms), there's another issue when I drop below 13ms. At exactly 12ms, the LED is unstable, it sometimes blinks as expected, but sometimes just lights up. Anything below 12ms, the LED is constantly high, not a single blink.

UPDATE: If I use _delay_ms instead of regular delay, I get about 1ms more room for both edges, but below that, it's still the same.

UPDATE 2: I've tried changing to different output pins on my Nano, both PWM and non-PWM ones. Nothing changes.

What would be the problem?

• Does it exhibit this if you use _delay_ms() instead? – Ignacio Vazquez-Abrams Aug 21 '14 at 20:58
• @IgnacioVazquez-Abrams I get about 1ms more room. Like it's almost stable at 121ms falling and stable at 11ms falling. Go just below that (120ms rising or 10ms falling), the same problem persists again. – Can Poyrazoğlu Aug 21 '14 at 21:02
• It's a bit hard to know for sure without proper datasheets but if the encoder is set for a fairly low rate it might take that long for the tx/rx to lock and for it to the complete sequence of bits so it can be decoded. There's a bit more going on that a simple tx/rx module and many are designed for use as remote controls where that sort of delay is acceptable. – PeterJ Aug 22 '14 at 3:35