Notices

Thank you, I really appreciate that. Say, is there any way I could help? What would I specifically be looking for? My googling skills are pretty good.

Google's pretty much the only source left for me as well; I get most of my data from either the LIRC project (www.lirc.org) or the hifi-remotes website (www.hifi-remote.com), but when they run out, I can sometimes find config data hidden in other websites all over the place.

Almost all the devices using consumer infrared today send their data in a very similar manner -- usually, each time you press a button, the remote control sends out two numbers, a "device" value and a "command" value. (Most devices only use one "device" number; the only common devices I've seen with multiple device numbers are stereo component systems, where each component frequently gets its own number.)

Most consumer IR systems encode information by varying the duration of time that the LED is on or off. So, when someone reads the pulses off of their remote to construct a config file, they might either just list the length of each pulse received when a button was pressed, or (if they know the encoding method) they might actually figure out the original numeric values and write those down instead.

So, in short, what I'm looking for is a list that associates each button with either timing values or device/command numbers.

Search strings like "IR Protocol" or "Remote Codes" seem to work fairly well. Sometimes I can get a hit with "LIRC", as it seems many people generate their own personal LIRC config files.

(And, of course, if you've got a PC with an IR receiver, you can just run LIRC yourself and read off the pulses for each button on your remote. )

...not to mention, that for PC's with legacy serial ports, constructing IR receiver (compatible with LIRC on Linux) is very cheap and easy

USB-only comuter pose much bigger problem, last time I've checked (but still possible, so we could even do receiver for N900, and give it "learning remote" function).

/Estel

hi...
can control the security system of cars with this program?
if no:
can do this with any remote program?
tnks

Security system? You mean like the "keyless entry" mechanism?

I'm pretty sure that's done with RF signals, not IR. (And, as for myself, I'm really not interested in messing around with security systems in the first place...)

I'm always interested in messing with security systems, but none car that I know uses IR for this purposes. Would be horribly unpractical.

BTW, encrypted (aka hard to spoof) IR transmission is fun idea. Just fun.

/Estel

I am a security systems engineer and no product would use IR controls for there systems.
Maybe IR for a remote control on CCTV but many better methods are used for security and practical reasons.

I may be mistaken but I think some product keys (Including cars and garage doors) use IR for security, especially cars pre 1990. I think the SmartKey was the successor to IR keys for cars post 1990 though.
.
I have a Mercedes Smartkey which uses RF for practicality but on the end has an IR transmitter for the engine immobilizer when the key is inserted.

IR is just like any other transmitted signal, it can be victim to replay attacks (recording the signal, then repeating the signal). This is the case for RF too isn't it? The only difference is that RF equipment is less common. These systems however do not rely on obscurity for security.

Publicly transmitted signals (IR or RF) employ a rolling code. That means the expected/transmitted signal changes with every keypress based on an algorithm known only to the intended transmitter and receiver which means a signal cannot be recorded and repeated (unless the car missed a valid transmitted signal that somebody recorded, so if you're super paranoid don't press your unlock buttons when out of range ).

Sorry for always taking this thread off topic, please do let me know if it annoys anybody so that I will refrain from doing it again.

P.S. since I went off topic already I might as well report my past findings, for anybody still curious about the past discussion regarding the correct term for IR LEDs. The IEC do not like the term IR LED. The agreed standardised term for IR LED is IRED according to IEC60050-845. So beware! The IEC will frown on you.

IEC use IRED for infra-red and not UVED for ultraviolet, double standards or what?

As for security...
Yes, hopping and rolling code is possible for both but it's the combination of "practical and security" that ticks the RF box in the industry.

Yes, either (IR and RF) signals can be intercepted or jammed and susceptible to replay attacks if not encrypted somehow.

I can't say I have seen a car with IR transmission technology but I wouldn't expect pierogi to be compatible as I would expect rolling or hopping codes to be involved.

The huge downfall in infra-red transmissions is they can be effected by sunlight, take the IR proxy sensor on the N900 as an example.
Also to send data (voice, audio etc) any distance encrypted, the kit gets very expensive compared the same security in RF.

Pro's of IR is about 5 times more data can be sent along the same channel. Although RF will generally use multiple channels. Also now mesh RF technology is being introduced mainstream, systems can become self healing; if working over a network type scenario. Which makes signals as guaranteed as wired methods.

Due to this infra-red systems would only be used if indoor and the P2P is fixed or P2P is always in view, or RF cannot be used due to radio noise.

Thus being left mainly for consumer remote controls (edging back on-topic)
Consumer short range IR controls ("CIR" to make IEC happy) can be bashed together cheaply are fairly simple and energy efficient.

@Copernicus
Is there a correlation to a particular protocol(s) that have range issues?

Most of the protocols I have seen recommend about a 25-33% duty cycle, is pierogi on 50% ATM?

I believe it is possible that a poorly defined protocol could manage to be understood by the receiver better when at a shorter range. Maybe. But yeah, all my protocol info is third- or fourth-hand at this point, so I'm certain I don't have the all my timings set exactly the way they were defined. So if I can find a correlation between a specific protocol and range issues, hopefully I can come up with a fix.

Yes, I've now got all my protocols defaulting to a 50% duty cycle. A while back, I had the default set at 33%. I'm not sure that either default setting has made a huge impact; and, while I also see recommendations for anything from 25% to 50% in various places, I haven't yet found a protocol that requires a specific duty cycle.

I'm planning on setting the default back to 33%, as that is the LIRC's default as well...