Dave, do you know what's the size of this RAW data in bytes for each package?
I suppose each byte of such raw data contains the time in micro or mili seconds that the input pin was high or low (1 or 0). This way, the protocol is irrelevant because once you alternate the output IR led again on the same sequence and timing, it is just acting exactly as the original Remote Controller.
If I'm right above, I'm wondering if it's possible to convert the data back to bytes on a shorter message, creating a intermediary data format that would be used only to send data back and forth between the computer and the arduino. The arduino would then translate the data back to original format before emitting such data through the IR led.
For example, if I send 64 bytes of data in an IR packet (lets say, the On button of the remote controller). Then, depending of the protocol I may have a maximum of 64 bytes * 8 bits = 512 bytes, each containing the timing of each bit. In reality, if I'm captuing raw data, there are also the control bits, like the start bit, the stop bit and the parity bit, which could turn the space necessary to store the data for a single IR packet to a total of 704 bytes!. But then, not all bits will be different, for example, one byte being recorded could be FF, meaning the raw data for this byte would be a long 1, stored in one single byte instead of 8 like I was saying. Anyway, I see how this can be a nightmare, but maybe there are alternatives?
Just a thought...
Otherwise, I can imagine many reasons for the data being lost when you divide it in many packets of 25 bytes. Where is the data being lost?
I'm just trying to help. I'll probably face the same problems once I try it myself, so I'm deeply interested.
