I haven't used that particular device, so I have no way of testing with your setup, but I have used devices (from another manufacturer) with similar characteristics. See Footnote.
Here's what I observed.
1. The device is designed to work with sequences of bursts with carrier-on and carrier-off times on the order of a millisecond or so during communications, not tens (or hundreds or thousands) of milliseconds.
2. After carrier-off times of more than a few milliseconds, the response to the very first carrier pulse is erratic. So I needed to "prime the pump" with some carrier-on time for a couple of milliseconds before starting data transfer. (The internal circuitry needs a little time to lock to the carrier. The amount of time depends on how long the carrier has been off.)
3. The internal filtering circuitry keeps the device from working with long-duration carrier-on times. (In other words the output goes high again if you keep the carrier on for longer times.) The data sheet says:,
"Some examples of disturbance signals which are suppressed are...Continuous signals at any frequency"
Bottom line: The data sheet does not say what the maximum carrier-on signal time is, but that could be a show-stopper for using this device with any method that doesn't have fine enough granularity in the carrier-on time characteristics.
If you want the convenience of using tone() to create the carrier but need carrier durations of less than a millisecond, maybe you can try something like the following.
I haven't tested this, and I don't have a lot of confidence that it will work without some timing adjustments, but it's something to try):
- Call tone*(pin,freq)* to start the carrier.
- Call delayMicroseconds(whatever) to wait until it's time to stop.
- Call noTone(pin) to turn off the carrier.
Maybe you can look for other infrared remote projects that people use to transmit TV remote signals and try whatever methods that seem to be successful..
Maybe you already have done this, and are just trying the long times for testing. An appropriate test signal would be something like a burst of a dozen or so 600 usec on-time, 600 usec off-time sequences followed by a rest time of a few tens of milliseconds and then repeat the bursts again.
Here may be the reason that the timing of the tone duration can be off: The tone() stuff has been tested pretty thoroughly at audio frequencies (a few hundred Hz). I don't have perfect pitch and I haven't put a melody on the scope, but it sounds "about right." Long duration notes don't seem to be a problem.
The tone() function is capable of generating 40 kHz square waves alright, but that requires a timer2 interrupt every 12.5 microseconds. The context switch and the time to execute the instructions is (probably) on the order of a two or three microseconds. This may be too much overhead to keep timing accuracy, even with delayMicroseconds()
The real bottom line: Maybe using the tone() function is not appropriate for 40 kHz carrier generation for sub-millisecond carrier on-times (without some heuristically obtained data to tweak the actual duration).
My project did not involve TV remote signals, but used a proprietary data format sequence with timing characteristics compatible with the various standards for which these modules were designed.
A bit time is 1800 us.
"Zero" is 1200 usec carrier-on and 600 usec carrier-off.
"One" is 600 usec carrier-on and 1200 usec carrier-off.
The module output is low when it detects the presence of a carrier and high when there is no carrier, so I sample the module output 900 usec after I see the output go low. Then I wait for 400-500 more usec before starting to look for the output going low again (for the start of the next carrier-on time).
The data bytes are sent the same way a UART does the deed: One start bit (zero), eight data bits, one stop bit (one)