Notices

Cool, I guess those in that industry get flagged by intelligence a lot with that acronym they may even flag themselves.

I always think of "Light" as the visible spectrum of EM radiation but I guess I've heard "IR light" enough to not be bothered by it, a bit like "AC current". Sorry, IED was me being a bit pedantic and I was just wondering if that was the formal term for them.

Hm, theoretically, sounds like very good idea, that could even fit inside N900 body itself, if small components used (no need for mugen cover). No idea, if there wouldn't be lost in transmitted IR "data" (checksums, or whatsnot), that would ruin compliance with receiver's protocol implementations - Copernicus, any ideas here?

As for LED synaptic problem, well, there is ultraviolet light, so why infrared shouldn't be light too, still? Of course, I understand what you mean - generally, "light" is referred only to visible spectrum (or our Wifi antennas, radars, etc, would be also called light-emitting devices - after all, it's only difference of wavelength).

/Estel

Er, well, I'm not much of a hardware guy. But there's nothing special involved in consumer IR signals, beyond just turning the LED on and off. I suppose the hardest part of the IR signal to accurately replicate would have to be the carrier frequency; while each individual on/off command will last for something like 500 to 1000 microseconds, during the time it is set to be "on", the carrier frequency will further subdivide it into smaller on/off pulses at a rate of something like 20 to 30 microseconds. (There's even a "duty cycle" value that specifies how long the LED should be left on during each carrier pulse.)

So, I guess it's a question of how well the hardware can keep up with these pulses. Most IR receivers are tolerant of some sloppiness in the timing, but yeah, get too far off and it just won't understand what you're trying to send...

ir transmitter connected via usb in host mode?

Yeah, that should be doable; it's a very popular way to get LIRC working on desktop and laptop PCs. I don't know that I'd want to put any more stress on the USB port, though.

I've once again learned a basic fact of nature -- when you start adding more agressive changes to a large project, yet reduce the total available coding time, things get bogged down. In my attempt to take full control of the keyboard, I started creating my own custom tabbed window class, and started getting bogged down in the details of overriding the Qt virtual methods...

Anyway, the solution to this basic fact of nature is to add more coding time and make less agressive changes. So, I'm doing that now. While I'm taking another look at my keyboard implementation, I've gone ahead and created a new update with a few minor changes. The biggest addition would be the new "Advanced Settings" panel (found in the new "Advanced Settings" tab collection), which allows you to modify the carrier frequency and duty cycle of the protocol currently in use. I've set up the carrier frequency to go between 30000 and 60000 Hz; this is pretty much the range of most consumer IR devices. The duty cycle can vary from 5% to 95% (the device driver doesn't let you choose 0 or 100%, which makes sense).

Let me note that these values are not yet stored persistently; closing Pierogi or switching between keysets will cause them to be reset to the default values. But, at least, you can test out different values to see what their effect will be. (With luck, an appropriately tweaked carrier frequency may fix some of the range problems we've been seeing with certain devices.)

I've only played with the settings a little bit, so far. My Sanyo TV does start to fail to recognize commands when you move a few thousand Hz up or down. (It also doesn't like when you push the duty cycle too high.) On the other hand, my Mac Mini is amazing -- it doesn't seem to give a care what the duty cycle is (from 5% to 95%), and I have to push the carrier frequency all the way up near 60000 Hz before it starts to drop commands. So, some devices are very tolerant of off-spec timing!

I've also added a few more buttons to the Input panel (including the HDD input key), and added the Input panel back to the TV panel collection. (I made room for it by dropping the Adjust panel down to the Video Media collection, even though it really doesn't fit there...) Anyway, I really do need to do some more work cleaning up the panel collections.

And as always, new keysets: I've made a first pass at keysets for Medi@link, Multichoice, and NEC, and added new keysets to ADB, LG, Mitsubishi, and Pioneer. (This includes a collection of projectors, some home theater systems, and a car stereo keyset.)

The update should be in the extras-devel repository soon. Please post or pm me if you find bugs!

This is ideal IMO.
I know it's annoying to some
I feel the best method is to test and let you know so it can be updated and mass tested in devel.
Thanks for the update.

Hi,

I just came across Pierogi and tried it out on my Samsung TV and it works straight away! Thanks! Next, I'd like to try my Singapore DVR. It's called the Hubstation by the cable TV provider Starhub (SCV). Not sure how to start to get it to work. I found some links to data files that might help (though I'm not 100% sure they relate to the exact same device I have...).

http://lirc.sourceforge.net/remotes/...b/ABQ-1H57-SCV

http://www.hifi-remote.com/forums/dl...e&file_id=5706

I do have an IR receiver for my desktop, but I have no clue how to collect and share the information from the device's remote control.

/Magnus

...waaait. I've never thought about _this_. Thanks!
(Alpine support in there, btw?)

Thanks! I will add all the Starhub/SCV config files I can find into the next update. However, you might also try using the "ADB TV Receiver Keyset 4", it looks like it might be at least partially compatible with the SCV keysets.