InferRed 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

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

Thanks for your input. After talking with my uncle, and looking at other material I have discovered that the IrDa protocol isn't necessarily one that a household device will use, all they have is simply an Infrared receiver. Since Infrared receivers can get alot of interference, it uses a more complex method of receiving data; The data is sampled by analysing the bursts of data, and the time between breaks is recorded and is critical when transmitting. In order for me to determine these bursts, and the timing between them I would likely have to use an amount of Assembly. I've seen it done with an iPaq, but unfortunately I dont have the source code for it. So, realistically the data interpretted by the IrDa/RS232 could be identical for different commands just because of the timing between the bursts of data(But writing to an IrDa just pushes out data without regards to breaks, therefore the waves aren't really formed.). I'll try using Overlapped I/O and an EventObject to record breaks and the times between the transmissions, then I'll try to synthesize it somehow. If worst comes to worst I could always build an IR-LED transmitter through my com or parallel port, I have a few schematics for it, then I could try to transmit at the Bit-Level. Its probably too complex for me at this time, but I guess it's worth the try. I'll also try what you reccommend, I'll tell the COM to receive in 8-Bit data, and I'll store everything into a short or integer array, then I could convert each array index into its binary representation.

Quote:

---

a more complex method of receiving data

---

If the above is true, then you can't "simply" do this:

Quote:

---

tell the COM to receive in 8-Bit data

---

This is because to operating system & hardware are too smart! They are looking for (or transmitting) 8-bit "bytes" embedded in the data-stream along with the start bits, parity, and all that stuff. A quick-look at one of Salem's links and I see "50-bit continuous stream..."

So, I what I was suggesting... and I don't know if this can even be done... because the serial to parallel converter is probably done in hardware... is to read the instantaneous status (1 or 0) of the serial port (in a loop).

If you are going to build your own hardware, I'd suggest the parallel port. You can read/ write individual bits... For example you could use bit 0 to transmit and bit 1 to receive. You'd be free from the built-in protocols... You'd have to write your own. And you'd have to provide the timing too. (Maybe the timing will be built-into your hardware?)

Of course, you'd have to write software to convert "parallel" variables to a "serial" stream of ones and zeros to/from the parallel port too.

A couple of "gotchas"... With a multitasking OS, you have to make sure that some other process/program doesn't start doing stuff in the middle of transmitting/receiving a data stream. At work, we have a FLASH/EPROM programmer that plugs-into the parallel port and runs from a DOS program. When I asked the manufacturer "Why no Windows software"? He said "Because it relies on the computer for timing."

And... this is a big one... any of the windows newer than WinME actually PREVENT a "user level" program from reading or writing directly to hardware. (WinNT has this protection too, as does Linux.) This requires a driver. I don't know how to write drivers yet.