Notices

Thank you for continuous support, Copernicus.

Just got an older Sony CDP-990 from flee market and happy to find a compatible remote control in Pierogi.

Now I am looking for a somewhat exotic Tivoli Model CD (MKI with Chinese CD transport) player remote. This remote is needed because by default the output signal is rather weak and it can be increased only be remote control (how genious is that)

Have a good weekend!

Very pretty device! But man, I'm not finding anything close to a config file so far... Complicating things is that "Tivoli" seems to be a very popular name for products. IBM even has a Tivoli Remote Control.

Microsof(R) t? Haven't seen that one before

OK, so I've just acquired my first N900... after having found Pierogi.

I like it and would like to use it to control all sorts of devices, one of which is my Beovision MX 7000 TV which Pierogi does not currently support.

Now, I've skimmed the source code and there is definitely something written to support Bang & Olufsen equipment, so what's the holdup?

OK, so I've just acquired my first N900... after having found Pierogi.

I like it and would like to use it to control all sorts of devices, one of which is my Beovision MX 7000 TV which Pierogi does not currently support.

Now, I've skimmed the source code and there is definitely something written to support Bang & Olufsen equipment, so what's the holdup?

Man, B&O strives to make the life of a universal IR control coder hard. There are a handful of popular ways to encode data in IR out there; protocols by NEC and by Philips tend to be the most popular, and most folks who don't use their protocols verbatim tend to mimic many of the techniques used by those two.

B&O, though, they've come up with their own protocol, from the ground up. Most folks go with a standard binary value system -- one value for "0", another for "1". B&O adds a third "same as last bit sent" value, which is kind of a pain to code for (and, honestly, what's the point?). IR remotes use a "carrier frequency" (quickly pulsing the IR LED) to distinguish the signal from other sources of infrared light in the local area; almost all protocols use a frequency somewhere between 30 and 50 kHZ. B&O decided they want to use a frequency of 455 kHZ.

Anyway, B&O doesn't just do a few things differently, they're practically unique. So it's been kind of a pain to come up with code that works for them. (Even to find adequate data about how their protocol works; most of the time, I can fill in the blanks for a given protocol by comparing it to similar protocols from other manufacturers...)

But let me give it another try. I'll see if I can knit all the pieces together into a working piece of code this time...

B&O products are so annoying. Just try to use one. It is not only in the implementation details that they differ from everything else. Their engineers must all suffer from a serious case of NIH. My TV does have the redeeming quality that it looks and sounds great. Which is important, too.

That would be most excellent. Thanks.

That sounds familiar

Yup, I've been picking away at B&O for a while now. I did manage to find a much better description for their protocol since I wrote that post, so I _should_ have a better shot at getting a working keyset together, but we'll see...

If I were to hazard a guess at their motivations, I'd suppose that they chose 3 symbols -- and those particular three -- instead of two to ensure that you'd never send the same symbol twice in a row. This might make timing recovery on the receiving end much easier. You get away without a clock on that end. And fewer parts in the IR receiver means more budget for rosewood veneer, and leave the hard work to the optional (and added cost) remote control.

Glad to hear you found some useful info on the B&O stuff. Sure hope it pans out.