remote code learning

[dhouston]

Bruce,

I wrote a PC application 6-7 years ago that scanned IR & RF codes (recorded using a soundcard), identified them by manufacturer's type, and allowed converting them to Pronto and other formats.

A couple of tips: Accuracy is not critical as most remotes, being battery powered, allow a fairly wide range on pulse/space durations. 20% will work with most.

And, as you noted, most codes have a lengthy space between copies and/or have an initial pulse that is significantly wider than subsequent pulses. You can look for these to determine the end(s) of a code rather than having to predefine the number of bits.

[Bruce]

Hey Dave,

I'm not sure I follow you on this! Could you elaborate?

I have found individual bit timing to not be that critical, but if you're off by a certain margin on each data bit & the space between each data bit, you're potentially off by a mile by the end of the complete data packet, and this really did make a huge difference.

For example - if you're off by say 20% on each data bit, and the space between each bit, you're way off by the end of the packet.

And this may/may not be impacted by your measurement technique. I.E. measureing bits directly from the encoder output or the output of an RF receiver or IR module with a relatively slow rise/fall time, so it's best to be as close as possible in my experience.

[dhouston]

Bruce,

Many of the IR protocols go back 40 years or more when both remotes and receivers were less refined. The overall length of the code is not as important as the bit times. For both PPM (e.g. NEC) and PWM (e.g. Sony) the difference between a 1-bit and 0-bit depends solely on the time between rising edges and the duration of a 1-bit is usually twice the duration of a 0-bit so differentiating them is very easy. The NEC protocol is detailed in the datasheet for their µPD6121.

I haven't tested every protocol but have tested several using either a Pronto or a device I designed a few years back (when early PDAs had a CF slot) that sent IR codes. I found the receivers were very tolerant. I've done similar tests with various RF devices (X10, ceiling fans, garage door openers, etc.) with similar results. And, while not much of a factor for this discussion, most consumer IR receivers also have a fairly wide bandwidth (±5kHz) and this does come into play as many protocols are defined using cycles of carrier rather than time.

Even biphase protocols like Philips RC5, etc. are forgiving as their timing is contained within the code..

That said, when designing transmitters, I tried to keep them within ±10%.

[Ioannis]

How about re-calibrating on every header to the possible slip?

If header is x% off then probably all the bits will be too.

Ioannis

[dhouston]

How about re-calibrating on every header to the possible slip?

Again, it really isn't necessary as the codes need not be precise. For example, NEC defines a 1-bit as ~2.2mSec between rising edges and a 0-bit as ~1.1mSec between rising edges. It's child's play to differentiate even if overall timing varies widely.

The only codes that require you to capture both pulses and spaces are the biphase protocols like Philips RC5, RC6, etc. where you need to recover the timing before you can decide between 1 and 0.

Ooops - I forgot about one protocol. I don't recall who uses it (it's a high-end RF home automation system used mostly in Europe). It uses 5 different pulse widths and 5 different space widths which allows for an enormous code base. If you assign ADCDE to pulses and abcde to spaces, you can see there are lots of possible 10 letter words (10^5 or 100,000)

[Bruce]

Thanks Dave. I agree. I have one version that simply spits out up to 100 pulse periods to a serial port. Then it's easy to see everything at a glance. The period between packets is easy to locate, etc,,.

Even fiddled with one version that actually printed out working PBP code to reproduce the data packets, adjust for various carrier frequency, etc. Was fun. Just cut & paste and viola...;o)

That sounds like a pretty nifty PC app you wrote a while back.

[cesar35]

Hello about mister Bruce code
Can i use another photo as pic16f876a
I appreciate it

[Ioannis]

Photo? What Photo?

Ioannis

[cesar35]

Excuse me
Hello about mister Bruce code
Can i use another o pic16f876
I appreciate it