Infrared Serial COMM, cannot write?
Last night my friend bought an IR-Serial module, so I got it receiving data from household Remotes, etc... at a Baud of 115200, however when using WriteFile to write to the open COM the computer locks up. So then I used SetCommState to set only afew settings for the COM port such as Baud, ByteSize, Parity, and StopBits. However, if I change the Baud to 115200 I cannot receive data from the remotes, but if I set it to any lower setting I can receive data. I am wondering if I must somehow synchronize the BaudRate to devices that I want to work with. I have not resolved the problem with the application locking up when I am using WriteFile, I decided to look at what other people have done with Serial reading/writing they all seemed to use OverLapped I/O, and in one sample one person used SetEvent, to set the COMM event into a Write-State, but I dont think either of those should have an effect on the serial its self; When I send data it might range from a buffer size of 500-3100 bytes(since I am just trying to synthesize the same pattern as a Remote Control for a test). If there are any limits to what kind of data a Serial can send, and the lengths that it can send at a time, or any other information if anyone has used an InferRed before, please dont hesitate to respond :) Thanks
Warning... this is not an answer, but...
This really isn't a C++ question, but I don't know where else you could ask it.
First the easy answer (Serial communication is very tricky): Of course the baud rates of both devices have to match. So do the other settings. If you don't know the settings for "both ends" you could be "hacking" forever 'till you find a match. IMHO This is a major weakness of the RS-232 standard… Nothing is standardized. It’s been a common experience for me to know the settings for one device but not the other. Some devices have the hardware / software to auto-detect baud rates and such. (Modems do this).
These remote control communications protocols may be proprietary. There may be some psudo-standards ‘cause, as you know, you can buy a universal remote and program it to work with your stuff. The protocol might not even use parity, data size, or stop bits. With the com ports, these settings refer to the RS-232 standard, and who knows if these remotes use RS-232??? The computer hardware and operating system are all designed for RS-232. Because IR is very “vulnerable” I’ll bet that there is usually error checking that’s better than simple parity.
I have an old (1995) data book from a company called Holtek. They make chips for remote control transmitters and receivers. The book only covers hardware (which kind-of left me with insufficient information back when I was looking into this.) Maybe they have a web site with some protocol info.
Here’s what I would recommend… if you don’t’ get a straight answer from someone: Try to write a program that captures and displays raw bits without regard to the format. Push some buttons on the remote and try to see what the bit-stream looks like. Or, you could write a program that continuously samples the port state at a high rate and displays a graph of the status over time (without regard to baud rate). If you’re a hardware-guy (or gal)… I’m talking about an oscilloscope-like program. When I was thinking about doing a remote control project, my plan was to going to use a ‘scope (and a home-built IR receiver circuit) to try and figure out the code.
I haven’t looked, but if there are programs that let you use your IR port to control your TV out there… at least you’ll know its possible. And the only reason it would be impossible would be if the hardware is fundamentally incompatible. For example, because of hardware differences, you can’t write a program to make the (electrical) com port interface with a USB device.
:D Maybe I should change my handle to: WordyDougDoesn’tGiveStraightAnswers :D