Menu

Main Menu
Talk Get Daily Search

Member's Online

    User Name
    Password

    [Announce] Pierogi - a universal infrared remote control app

    Reply
    Page 79 of 140 | Prev | 69   77     78   79   80     81   89 | Next | Last
    Cue | # 781 | 2012-10-20, 21:48 | Report

    Originally Posted by sixwheeledbeast View Post
    IR LED, IED is normally used for Intelligent Electronic Device.

    There still emitting light no reason to drop the L.
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Estel | # 782 | 2012-10-21, 03:25 | Report

    Originally Posted by Cue View Post
    The new IR diode could run off 3.7 volts directly from the battery instead of being limited to 1.8V or the component limited current on the other side of the opto. It's also just three components (or two if you buy an LED with a built in resistor); an optocoupler, an LED and a resistor. I'm not brave enough to give it a shot (I only have one n900). It is just an idea for anybody wanting a more powerful IR diode built into their N900. The optocoupler/LED/Resistor combo is in a sense a repeater and can be made very small ( easy to fit into mugen type cover).
    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

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Copernicus | # 783 | 2012-10-21, 06:37 | Report

    Originally Posted by Estel View Post
    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?
    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...

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to Copernicus For This Useful Post:
    Cue, Estel

     
    Android_808 | # 784 | 2012-10-21, 08:13 | Report

    ir transmitter connected via usb in host mode?

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Copernicus | # 785 | 2012-10-21, 12:04 | Report

    Originally Posted by Android_808 View Post
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Copernicus | # 786 | 2012-10-25, 01:00 | Report

    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!

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by Copernicus; 2012-10-25 at 05:06. Reason: Gotta get my Hz units straight!
    The Following 11 Users Say Thank You to Copernicus For This Useful Post:
    ade, bioman, Cue, don_falcone, Estel, freemangordon, kent_autistic, malfunctioning, petur, sixwheeledbeast, TomJ

     
    sixwheeledbeast | # 787 | 2012-10-25, 07:06 | Report

    Originally Posted by Copernicus View Post
    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.)
    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.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to sixwheeledbeast For This Useful Post:
    Copernicus, Estel

     
    magnuslu | # 788 | 2012-10-26, 08:06 | Report

    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

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following 2 Users Say Thank You to magnuslu For This Useful Post:
    Copernicus, Estel

     
    don_falcone | # 789 | 2012-10-26, 08:19 | Report

    Originally Posted by Copernicus View Post
    and a car stereo keyset.)
    ...waaait. I've never thought about _this_. Thanks!
    (Alpine support in there, btw?)

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Copernicus | # 790 | 2012-10-26, 11:27 | Report

    Originally Posted by magnuslu View Post
    I'd like to try my Singapore DVR. It's called the Hubstation by the cable TV provider Starhub (SCV).
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by Copernicus; 2012-10-26 at 11:30.
    The Following User Says Thank You to Copernicus For This Useful Post:
    Estel

     
    Page 79 of 140 | Prev | 69   77     78   79   80     81   89 | Next | Last
vBulletin® Version 3.8.8
Normal Logout