well, as for 50us. It doesn't have to be exactly 50us. The faster the better really, but it's a law of diminishing returns . I only suggested 50us because that's a good speed to use and that's what a few other receivers use. WinLIRC only needs raw timing information, how you get there doesn't really matter. With my audio plugin, it uses the lowest sampling rate which is around 90us I believe (11khz) (assuming i did the math right).
Depending on the sampling frequency depends on how you pack the data though. The streamzap and iMon hardware can get away with using 1 byte of data for transmissions as they use a resolution of 250us.
The simple LIRC serial receiver actually generates an interupt when it changes from PULSE/SPACE so it doesn't use a sampling resolution as such, but the timing is done on the CPU side, and basically breaks if you max out your CPU
good job Ian Maybe we can get WinLIRC support soon. If you are trying to come up with a protocol, I think the longest PULSE that remote sends is something like 10,000 us. You can check http://lirc.sourceforge.net/remotes/ to see the sort of values.
Theres often a long space between the main data, and the repeat values, can be up to 100,000 us I think. There's 2 potential ways you can handle this.
The iguana receiver I supported, it just sends data constantly, so if the data is just SPACE, it keeps sending those every 1 second or so. The streamzap API, it sends an 0xFF value to indicate an end of stream. Then when it gets the next pulse it carries on sending data. I have to time when the last data was received to when the next data was received to get the GAP or SPACE value. That works as long as the timing is okay.
If the remote sends at 40khz, and the receiver is set for 36khz, it'll still work, just the range will be less I believe. A few remotes use 56khz and that wont work with a 36khz receiver. Band and olufsen use 455kHz for their equipment You'd need a special receiver to make those work. But 90+ % are probably 36-40 khz
I think the raw mode in the UIRT protocol is basically just for learning. On the USB-UIRT hardware I believe they use a special infra-red sensor that requires the remote to be placed like 1inch from the receiver, so maybe it's not that suitable for you guys.
Then each byte sent will reprisent the time of the length pulse/space data. Always multiplied by 50 to get the actual value. This is the format the windows media remotes use, or something similar. Zero can reprisent the end of the data, or no data Something like that would work.
If the hardware is based on IRMan, the 6 byte code should map directly to LIRC_MODE_LIRCCODE. However, according to the LIRC webpage,
Quote
any, but config file receiver specific,
It says on the LIRC website that IRMan ones basically need their own config files, which kinda sucks. If possible I'd go with raw timing information. Something like this
Quote
space 1917573 pulse 3529 space 1727 pulse 477 space 412 pulse 458 space 1277
The timing is in µs. Normally receivers are accurate to 50-250µs. 250µs is probably the upper limit though. You might get problems with some remotes with that sampling. You'll have problems generating reliable config files with a resolution of 250. LIRC normally just takes an array of timing values.
Pulse times are marked with PULSE_BIT
So 400 & PULSE_BIT <- pulse 600 <- space value
The pulse bit is defined as #define PULSE_BIT 0x01000000
Well, the plugin decoding is based off LIRC 0.8.6, instead of the really old version. I know there's been a few changes made to the config file format over the years, but I assume they are mostly backward compatable. If you post the file I can see if it loads correctly in the latest version. But you can always try generating a new config file with IRRecord. If you have problems you should file a bug report or something.
have you checked the winlirc webpage recently ? I rewrote basically the entire project, redesigning it so it now has a dll/plugin architecture. I've already supported 2 usb receivers ! You need to have a little understanding of the signal, more than just converting timing codes to a button name, otherwise you will get in trouble with toggle bits and button repeats. I only suggested feeding raw timing info because the code to decode that is already written. The code supports other types of IR info also. The whole point is to get winlirc, to do this decoding for you, instead of rewriting the wheel ? Hell, I would have probably even written a plugin for you guys, if you loaned me some hardware.
Hi, If you can feed raw IR timing information to WinLIRC it would be a peice of cake to write a plugin to support this receiver. The plugin design is flexible though, I recently wrote one for the streamzap remote, and I just wrote my own simple decoding algorithm for their remote based off nothing but guess work :p The only requirement for the plugins for WinLIRC is, they spit out the name of the button pushed on the remote, what you do, internally decoding wise is entirely up to you.
You'd need a special receiver to make those work. But 90+ % are probably 36-40 khz