Reply
Thread Tools
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#11
Originally Posted by pichlo View Post
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.
Yeah, the most common carrier frequencies I've seen are around 33 kHz, 38 kHz, and 55 kHz. On the other hand, since we're just receiving IR here, it isn't 100% necessary to be able to recognize the carrier spikes; their only purpose, really, is to help separate the signal from the noise. If we can at least pick out the "on" and "off" periods in the signal, that is sufficient to learn commands, and that generally doesn't require nearly as much accuracy...
 

The Following 3 Users Say Thank You to Copernicus For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#12
Originally Posted by Copernicus View Post
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.
Well, for sure Irreco and co doesn't have it in their source code - probably require talking with LIRC server directly?

Originally Posted by Copernicus View Post
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...
Haha, that's for sure, considering how fast you're with implementing ideas into nicely working and polished programs

In this case, it's even better - I would like to test any "monstrosity" I've created before sending it to you, as I've never build something like that before. By briefly looking at example schematics found in NET, it's so simple, that could be used to teach kids as "my first project with soldering iron", but you never know until you actually start to patch it up

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following 4 Users Say Thank You to Estel For This Useful Post:
Posts: 68 | Thanked: 113 times | Joined on Sep 2014
#13
Hey Copernicus did you ever end up converting pierogi files to audio to support this?

I recently made one of these audio ir transmitters with a 3.5mm jack and 2 ir leds taken from a remote. A few tv-b-gone wav files and it is working nicely for on/off of select tv's. Range is pretty good, about that of a normal remote.

But I would love to have more functionality which pierogi has. Most of the LIRC is based around an input to create an output file...haven't been able to figure out how to convert the LIRC output conf to a wav.
 

The Following 4 Users Say Thank You to Swordfish II For This Useful Post:
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#14
Originally Posted by Swordfish II View Post
Hey Copernicus did you ever end up converting pierogi files to audio to support this?
Nope, I never did. As I may have mentioned, I'm kinda clueless about hardware. On the other hand, I did finally pick up a USB IR dongle that works beautifully with Linux on my PC, so I've finally started encoding the pile of remote controls I've been stacking up here for years... It looks like I might be able to connect PIerogi to USB IR for free, if it follows the same protocol LIRC uses.

But yeah, setting up the audio-IR interface shouldn't be that hard, either. 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). Then, you just send that audio waveform when you want the LED on, and go silent when you want it off. So it isn't really a matter of encoding the entire command as a .wav file, just the carrier signal.

Anyway, I'm pretty sure that LIRC does support this already, although I'm sketchy on the details; so there should be some way to get LIRC running on it right now...
 

The Following 2 Users Say Thank You to Copernicus For This Useful Post:
pichlo's Avatar
Posts: 6,445 | Thanked: 20,981 times | Joined on Sep 2012 @ UK
#15
Originally Posted by Copernicus View Post
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).
38kHz sounds tricky but it is actually easier than you think, provided the line output is high enough.

LEDs need some minimum voltage to light up. Imagine an audio line playing a sine waveform and an LED connected between the live end and the ground (remember a protective resistor, but the audio output's internal impedance should suffice in this simple scenario). At the points where the waveform level is below the threshold, the LED will be dark. Where the level exceeds the threshold, it will be lit up, like this:

Name:  waveform1.gif
Views: 476
Size:  3.6 KB

Now connect a second LED anti-parallel to the first one. It will act exactly the same as the first one, only on the negative part of the waveform:

Name:  waveform2.gif
Views: 504
Size:  4.5 KB

However the receiver does not know that the light comes from two LEDs and not one. It knows nothing about the original sine waveform either. All it can see is light pulses.

Note that the light pulses come at a frequency that is double the frequency of the original waveform:

Name:  waveform3.gif
Views: 523
Size:  4.0 KB

You can double the frequency again (to 4x the original waveform) by using the above arrangement in e.g. the left channel, the same on the right channel (i.e. 4 LEDs altogether) and playing the waveform through the two channels phase shifted by 90°.
 

The Following 3 Users Say Thank You to pichlo For This Useful Post:
Posts: 68 | Thanked: 113 times | Joined on Sep 2014
#16
I have figured out my issue converting IR to audio . Irscrutinizer is pretty nifty, and 44100 Sample freq 2 channels 8 bits works well and keeps files small.

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?

As a side note, if you would like to add this to pierogi, I am willing to share my audio files (and would like to convert your files for my own personal use, not for distro)
 

The Following 2 Users Say Thank You to Swordfish II For This Useful Post:
Copernicus's Avatar
Posts: 1,986 | Thanked: 7,698 times | Joined on Dec 2010 @ Dayton, Ohio
#17
Originally Posted by Swordfish II View Post
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?
Hmm. I don't know 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:

Code:
begin remote

  name  LG_MKJ61842704_TV
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9069  4455
  one           597  1651
  zero          597   531
  ptrail        591
  repeat       9055  2222
  pre_data_bits   16
  pre_data       0x20DF
  gap          108123
  toggle_bit_mask 0x0

      begin codes
...
          KEY_1                    0x8877
...
      end codes
end remote
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.

As a side note, if you would like to add this to pierogi, I am willing to share my audio files (and would like to convert your files for my own personal use, not for distro)
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...

Last edited by Copernicus; 2015-05-28 at 18:08.
 

The Following 2 Users Say Thank You to Copernicus For This Useful Post:
jellyroll's Avatar
Posts: 435 | Thanked: 684 times | Joined on Apr 2012 @ Netherlands 020
#18
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.

Last edited by jellyroll; 2015-05-28 at 21:20. Reason: infrared security.
 

The Following 3 Users Say Thank You to jellyroll For This Useful Post:
Posts: 68 | Thanked: 113 times | Joined on Sep 2014
#19
Originally Posted by Copernicus View Post
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:

Code:
begin remote

  name  LG_MKJ61842704_TV
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       9069  4455
  one           597  1651
  zero          597   531
  ptrail        591
  repeat       9055  2222
  pre_data_bits   16
  pre_data       0x20DF
  gap          108123
  toggle_bit_mask 0x0

      begin codes
...
          KEY_1                    0x8877
...
      end codes
end remote
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...
Yeah I understand how the LIRC files work (just shortened things to show the part relevant) 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). Guess I'll just have to test more.

Last edited by Swordfish II; 2015-05-28 at 21:54.
 

The Following User Says Thank You to Swordfish II For This Useful Post:
Posts: 68 | Thanked: 113 times | Joined on Sep 2014
#20
Originally Posted by jellyroll View Post
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.
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.
 

The Following User Says Thank You to Swordfish II For This Useful Post:
Reply

Tags
ir transceiver, nokia n900

Thread Tools

 
Forum Jump


All times are GMT. The time now is 17:12.