Originally Posted by pichlo (Post 1340417)

The input might be a challenge though. How I wish there was an external mic or line in on my phone!

Originally Posted by sixwheeledbeast (Post 1340475)

This covers my thoughts on IR power I guess you haven't read it?
http://talk.maemo.org/showthread.php?t=25998

Originally Posted by Copernicus (Post 1340471)

Er, the earphones that come with the N900 have a microphone (for use in talking on the phone) -- wouldn't that mechanism work just as well for general audio input?

Originally Posted by Estel (Post 1349989)

Hey, it's great idea! If you manage to come up with writing/porting some software to control it, I'll gladly patch-up a receiver and transmitter and send it to you, of course as a donation.

Originally Posted by pichlo (Post 1350011)

I wonder what the frequency response of that mic input is. I would not expect it to go far beyond 15kHz, and even that is very optimistic. It is probably limited to something like 4kHz, just enough for speech. The carrier frequency on many remotes go to tens of kHz.

Originally Posted by Copernicus (Post 1350021)

Actually, I'm kind of late to the game with this. The LIRC server has apparently had support for this particular gadget for some years. (Of course, this also means that Irreco & co. have as well, as they are all using the LIRC server.)

So, in short, your N900 can already control it. :)

Originally Posted by Copernicus (Post 1350021)

Let me see if I can't get the same support into Pierogi. I can probably get the software to you faster than you can get the hardware to me... :) :)

Originally Posted by Swordfish II (Post 1471693)

Hey Copernicus did you ever end up converting pierogi files to audio to support this?

Originally Posted by Copernicus (Post 1471694)

The trick is just to create an audio waveform that matches the carrier signal being used by the remote (most often, this is something like a 38 kHZ frequency).

Originally Posted by Swordfish II (Post 1471744)

One question that maybe you could answer for me, Going through the LIRC database I see two different formats if you will. In one (usually in LIRC 0.6 or earlier) codes are very long, like this:
KEY_1 0x0000000000000144 # Was: 1

But in the newer LIRC format (usually 0.8 or higher) codes are expressed like this:

KEY_1 0x8877 # Was: ONE

Audio encoded as is, I know the top format works (tested it on my tv), but I am not sure the bottom format works...is the bottom format a shorthand to get rid of all those zeros?

Originally Posted by Copernicus (Post 1471751)

Hmm. I don't knand how it convertsow much about earlier versions of LIRC; but, for most config files, the value provided for the key is the "code" that gets sent in the command. I don't really see how you can translate "0x0000000000000144" directly into an audio file that does something to your TV; you need to have the additional info at the top of the LIRC file in order to decipher how the command is encoded as IR pulses. For example, an LG tv config file will have something like this:

You can read this as follows:

Bits: this remote sends 16 bits of "command" data for each key pressed. Flags: the bits are "space encoded", meaning that the value of each bit (zero or one) is determined by the length of time the IR led is on or off; "constant length" means that, regardless of how long a single sequence of bits takes to finish, the next sequence will start at a fixed time after the start of the current one. (The "eps" and "aeps" values are only of interest when receiving commands, so I generally ignore them.)

The "header" specifies that, before any bits are sent, the LED should be left on for 9069 uSec, and off for 4455 uSec. (These are values determined by LIRC's "irrecord" utility off of a physical remote control; they may vary from the official timings for this protocol, but probably not enough to matter.) The "one" specifies that the binary bit "1" is sent by turning the IR on for 597 uSec and off for 1651 uSec, and the "zero" specifies that a "0" bit is on for 597 uSec and off for 531 uSec. (Again, these are a bit off from the official values, but close enough not to matter.) Finally, after the entire sequence has been sent, a last "on" pulse of 591 uSec is sent, and then the IR is kept off until the next sequence starts.

(The "repeat" value describes a special feature of the NEC protocol, which I'll skip here.)

The "gap", in this case, describes the amount of time, in uSec, between the start of one full sequence of pulses and the start of the next. (If the "CONST_LENGTH" flag hadn't been set, the gap would be the time from the end of one sequence to the beginning of the next.)

Now, we get to the interesting part. Before we start sending the "command" bits, we need to send the "device" bits. In this case, these are the 16 bits of "pre_data". In hexadecimal, they are shown as 0x20DF; so, in binary, that should be 0010000011011111. For each of these bits, you would now turn the LED on and off corresponding to the on/off times defined above.

Then, you can now send the command for the key. In this case, KEY_1 is 0x8877; which, in binary, should be 1000100001110111. Again, these get converted to IR timings using the values for 1 and 0 defined above.

So, in total, the IR should be flipped on and off once for the header, thirty-two more times for all the "device" and "command" bits, then flipped on once more for the trailing bit and then turned off until the next command starts.



Thanks! But, I don't think there is really a question of maintaining individual audio files here; both the LIRC and Pierogi construct their timing strings dynamically as needed. It'd be awfully unwieldy otherwise! All I really need to do is set up Pierogi to switch that particular sound on and off (in a precise enough manner to match the LED timings); everything else should fall into place after that...

Originally Posted by jellyroll (Post 1471778)

I know that the infrared security is messed up but still don't understand why infrared is disappeared on de modern days cell phones. I got a Palm OS device that can read and write infrared signals. Now I'm happy to use Pierogi on the N900.

Originally Posted by Swordfish II (Post 1471779)

it just seems weird to me how some LIRC keys are incredibly long (goldstar for instance) and some are short (like the LG example you gave).

Originally Posted by Swordfish II (Post 1471788)

So correct me if I am mistaken but the 0x8877 (example you gave) could also be expressed as 0x0000000000008877 with the 16bit header

Originally Posted by Swordfish II (Post 1471780)

They disappeared for a while since IRDa functionality was replaced by Bluetooth. They are making a comeback these days in the high end tablets and phones (Galaxy S 4/5) but are only transmitters and the sole purpose is as a tv remote.