I've found a bug in Winlirc 0.6.5 that deals with tranismitting codes on the Tx line. In summary, the data buffer used to send the carrier signal is incorrect, so the carrier signal that gets sent is not consistent. The problem stems from an integer buffer (32 bit) that gets filled with an 8 bit value (0x12 or 0x55). For my particular case, I was using a frequency greater than 48000 hz so the buffer value was 0x55. Because the buffer is integer size but the COM port functions transmit bytes, the output on the serial port would be 0x55, 0x00, 0x00, 0x00 instead of a constant 0x55, 0x55, 0x55, 0x55. Needless to say, the output carrier signal was wrong and my target device didn't recognize the signal.
Fixing the bug is fairly simple, either change the buffer size to a character size or change the routine that fills the buffer from 0x55 to 0x55555555. For my testing, I chose the second option. With the change, my Scientific Atlanta Explorer 2000 box (actually 2100) now recognizes the signal without problem.
I have seen messages about others having problems with the Scientific Atlanta boxes, though this bug likely affect any box with a high frequency (>48000 hz) carrier (it will likely affect slower speed remotes too, though the impact is less of a problem). After this change, these boxes can easily be controlled with a simple transmitter (LED, resistor) connected to the TX line. This should be a great help to those with MythTv or GBPVR.
BTW, I initially tried using the DTR approach, though the highest frequency I could generate was about 10K below what I needed (~45k vs. ~56k). It's quite possible this problem is limited to XP and the task sharing time-slice resolution.
Once these changes are made, the Explorer_2000.cfg file can be used to control a Scienific Atlanta Explorer 2000 or 2100 box, though you'll need to modify the .cfg file and add the following line:
I suspect the other Scientific Atlanta configuration files will need the same change.