weird lircd behaviour since 3.10.18


26 posts   Page 1 of 2   1, 2
by mrgrey » Fri Nov 29, 2013 10:55 am
Hi all!

here's the deal:
I have 2 raspberries, both running the raspbian-image (from Sept 25th). Both are equipped with IR-Diodes, an IR-Receiver and an RF-Transmitter on a little shield I made sitting on the GPIO ports.

--
Raspberry Nr1 is running an up-to-date raspbian and kernel 3.6.11 #557 (commit #8234d5148aded657760e9ecd622f324d140ae891 from https://github.com/Hexxeh/rpi-firmware/commits/master)

More info here: http://pastebin.com/c2GKLsVi

Everything is working well on this one; I can read IR-Codes from remotes, can remote control the TV, an optical audio switch and the audio system.
--
Raspberry Nr2 is up-to-date regarding raspbian and the default branch rpi-update pulls, means it's running 3.10.19+ #600
Now on this one, sending IR-Commands really drives me nuts - the TV is working (with the lircd.conf generated on 3.6.11+) but no other device. So I decided to re-(ir)record the remote of the optical (spdif) switch again (just power and 4 input-src buttons) with the current kernel + firmware. I ended up with a slighty modified version of the lircd.conf, but for reasons yet to be identified, remote (ir-)controlling anything besides the TV still fails.

More info here: http://pastebin.com/U8T958Gi
--
Since the underlying root cause seems to be related to the kernel upgrade to 3.10.18 / 3.10.19 I'd appreciate any pointers as to where to look next. (Not very exited about making the kernel-changelog my good-night lecture for the next few weeks ;) )

Has anyone got an idea? Have the GPIO default settings/timings changed in any way maybe? I've searched the forum and googled a bit but didn't come up with any good leads. I'd be happy to provide more info and do more tests. The issue has been reproduced in a similar environment by a colleague of mine. His raspberry won't send working IR-Codes with >3.10.18+ either..

thanks & regards,

mrgrey
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by navic » Fri Dec 06, 2013 6:51 pm
I am experiencing the same issue as you describe. Both of my Pi's are:
Code: Select all
Linux ModelA 3.10.22+ #606 PREEMPT Thu Dec 5 18:16:13 GMT 2013 armv6l GNU/Linux


Both have LIRC 0.9.0-pre1 and while the receiver sees the transmitted IR with mode2 and LIRC off, irw sees nothing from the transmitter while LIRC is running.

I've verified that the Pi transmitter works fine with the TV, as well as the Pi receiver irw working fine with the TV remote but the Pi's will not work together.

After a bunch of Googling I came up with nothing as well.
User avatar
Posts: 9
Joined: Mon May 28, 2012 11:52 am
Location: NY, USA
by GeofP » Fri Jan 31, 2014 10:24 am
I have a Raspberry-Pi installed with wheezy-raspbian and lirc with a TSAL6200 IR diode connected to the GPIO interface via a driver transistor. It is being used to remotely switch on my Humax Foxsat-HDR satellite receiver via a ssh session over the local network and the internet. I also have a TOSP4828 IR receiver on the GPIO interface to capture the Foxsat remote control codes and generate the lircd.conf file.

Up until I did a sudo apt-get update and sudo apt-get upgrade on 24th January, the IR control worked OK.

At about this time I also did some changes to the IR LED interface. Either this interface change or the software upgrade caused the IR control to stop working. During the past week I have carried out numerous experiments and present a summary of my findings here in case it helps someone else with a similar problem.

I conclude that my Foxsat stopped responding to the IR signals because the timing of the pulses has changed. I can't see why this would have been caused by work on the IR interface, unless I have damaged the GPIO chip on the Pi. (In error, I had tried to source about 24mA from the GPIO22 pin). At some stage I will try another Pi board but until then I assume the timing change is as a result of the software upgrade.

The timing parameters for the lircd.conf produced by "irrecord -d" were as follows (I have only listed those significant to this discussion):

# pulse space
header 8978 4428
one 590 1642
zero 590 526

These values tie up with those displayed whilst pressing a key on the remote with command "mode2 -d /dev/lirc0".

I used a "Velleman PC Scope" oscilloscope connected to the TOSP4828 IR receiver and captured the IR pulses coming from the Foxsat remote control and from the Pi IR LED. I noticed that the length of the pulse sequence coming from the Pi output was shorter than the Foxsat remote output. I increased the parameters in the lircd.conf as follows:

# pulse space
header 9590 4730
one 630 1755
zero 630 560

The oscilloscope confirmed the Foxsat remote and Pi output now had similar timings. The Pi was now able to control the Foxsat satellite receiver, but not fully. The power command would not turn the Foxsat on. I eventually found that the timing of the header pulse was very critical. The pulse had to be in the range of 10400 and 10500 for the Foxsat satellite receiver to respond to the power on command. The lengths of the one and zero did not seem so critical. I also changed the header space value to match the 4.4ms measured from the Foxsat remote

The header pulse measured by oscilloscope is 9ms (9000us) (same now for both Foxsat remote and Pi IR LED, within measurement uncertainty). I guess that the values in the lircd.conf file are in units of 1us, so the theoretical header pulse value should be 9000, which is almost what the original lircd.conf contained.

I am of course taking measurements from the output of the TOSP4828 IR receiver and thought this may distort the timings of the pulse. I programmed both header pulse and space to 10000. This produced a pulse = 8.6ms and space = 9.9ms. They should have been 10ms for each. I measured the signal going to the transistor driver for the IR LED, this showed a burst of what I assumed was 38KHz starting 0.2ms before the header pulse, length of burst 8.7ms. This confirmed the output of the TOSP4828 gave a good representation of the output from the IR LED.

However, checking the frequency, it was not 38KHz but more like 45KHz. (lircd.conf defaults to 38KHz).Setting the lircd.conf parameter frequency to 33000 gives 38KHz

The values I now use for a working lircd.conf are as follows:

# pulse space
header 10450 4500
one 630 1755
zero 630 560
frequency 33000

The timing for the transmit part of the LIRC module has been corrupted and the signals are about 87% of the programmed value. The pulse and space parameters need to be increased by about 1.15 and the frequency parameter decreased to about 0.87 required value.

I note also that it is the length of header pulse that critical for the Humax Foxsat-HDR satellite receiver.

My current software is:
Linux Geof-Pi-1 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux, lirc version: 0.9.0~pre1-1

I don't know what is was before the 24th January. I wish I had made a back-up of the SD card and will do so in future before doing an upgrade....
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by mrgrey » Fri Jan 31, 2014 10:37 am
@GeofP:
Thanks for your feedback! This sounds promising, I'll run some tests on my Pi's ...

BTW
In case you want to try/test older Kernel/Firmware versions:

from: https://github.com/Hexxeh/rpi-update , Section "Options":
To upgrade/downgrade to a specific firmware revision, specify its Git hash (from the https://github.com/Hexxeh/rpi-firmware repository) as follows:
sudo rpi-update fab7796df0cf29f9563b507a59ce5b17d93e0390

The latest, working version for me is: 8234d5148aded657760e9ecd622f324d140ae891

regards,

mrgrey
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by GeofP » Sun Feb 02, 2014 7:50 pm
Using another SD card, I have installed a copy of the git hash version supplied by mrgrey, as follows; I can confirm that lirc produces the correct timing with this version!

sudo rpi-update 8234d5148aded657760e9ecd622f324d140ae891
(note that this errors if 'fab' is included in the command).

My /etc/lirc/lircd.conf includes the following parameters:
#........ pulse space
header 9590 4730
one 630 1755
zero 630 560
frequency was not defined but the default is 38KHz

The software version of the re-installed software is as follows:
Linux Geof-Pi-1 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 armv6l GNU/Linux

Measurements on the storage oscilloscope were as follows:
Header pulse = 9.7ms
frequency = 38KHz
These measurements show the timing for lirc is now correct.

Before the install of the mrgrey software version, my version was:
Linux Geof-Pi-1 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux

Measurements on the storage oscilloscope were as follows:
Header pulse = 8.2ms
frequency = 45KHz
These measurements show the timing for lirc is wrong.

Having proved this error, how do we get the software corrected?
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by GeofP » Mon Feb 03, 2014 8:09 am
I have attached the oscilloscope waveforms for the above post. There are 4 screen shots:
The top two, 1 and 2, are for my later software, 3.10.25+ #622. This timing is wrong.
The bottom two, 3 and 4, are for mrgrey earlier software, 3.6.11+ #557. This is the timing that should be produced by the lircd.conf.
lircd timing compare.jpg
Edited 5/2/2013: Compares output of lircd from 3.6.11 and 3.10.25
lircd timing compare.jpg (59.87 KiB) Viewed 2879 times

The upper trace of each screen shows the header pulse. This is the output of the TOSP4828 IR receiver.
The lower trace shows the carrier frequency . This is the input to the IR LED driver transistor. (Note that these lower traces on screen 1 and 3 are distorted by aliasing with the sampling frequency of the oscilloscope, so do not show the true signal shape, but do indicate the signal length.)

Screens 1 and 3 have markers showing header pulse widths of 8.16ms and 9.68ms respectivilly. The timebase is 1ms/div.
Screens 2 and 4 have markers showing carrier frequencies of 45.45KHz and 38.46KHz respectivilly. The timebase is 50us/div.
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by GeofP » Wed Feb 05, 2014 3:48 pm
I have now checked the lirc timing problem on a number of versions of software.
These produce the correct timing: versions 3.6.11+ #363 through to 3.6.11+ #557 (the last in the 3.6.xx series I could find)
These produce the wrong timing: versions 3.10.13+ #555 through to 3.10.28+ #634 (latest release at time of writing).

By correct timing, I mean as described in my earlier posts, a header pulse of approx. 9.6ms and carrier frequency of 38KHz
The wrong timing produced is 8.2ms and 46KHz.

I have listed below the commit number, software version and firmware date of all the versions tested (sorry about the formatting!)

The following give correct timing:

bf92ca9ac1604b4bcfb3ff24c7e8dc885938a432 | 3.6.11+ #362 PREEMPT Tue Jan 22 14:52:21 GMT 2013 | Jan 26 2013 19:25:49
b68696fa24c2512e91903b8e202502e7c21f325b | 3.6.11+ #401 PREEMPT Fri Mar 29 22:59:09 GMT 2013 | Mar 29 2013 23:13:56
dc2196389c242cff158a709572a0207320a41830 | 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 | Sep 1 2013 23:31:02
9530adbe31fe6b8e05b3bd5cfadfc90f067f5362 | 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 | Oct 2 2013 19:05:23
8234d5148aded657760e9ecd622f324d140ae891 | 3.6.11+ #557 PREEMPT Wed Oct 2 18:49:09 BST 2013 | Oct 18 2013 16:07:43


The following give wrong timing

91e44f072a8378c485b3ced8675b2c751074582e | 3.8.10+ #429 PREEMPT Sun Apr 28 20:55:17 BST 2013 | Apr 28 2013 21:11:45
33a80d74454c52c5ad1a3f6f97f3219c45dc1705 | 3.9.11+ #516 PREEMPT Thu Aug 1 12:59:07 BST 2013 | Aug 1 2013 13:19:52
7d605b7bf162fd4a9151804b2dcbd4d6e4b671d4 | 3.10.13+ #555 Mon Sep 30 22:25:24 BST 2013 | Sep 30 2013 18:19:36
2eebc5d1f955dc4e5afcccb11ba6e06d37b58a5f | 3.10.15+ #563 Mon Oct 7 19:48:26 BST 2013 | Oct 7 2013 18:08:50
42d3a7c3f0db73749d42e28af39c1732f325b65d | 3.10.15+ #567 Wed Oct 9 22:29:26 BST 2013 | Oct 9 2013 22:48:47
a7a5b4b600ad803b0cf2880da1dcbfb4d3996b80 | 3.10.16+ #569 Fri Oct 18 17:08:00 BST 2013 | Oct 18 2013 17:29:58
6f5c2e55741701eecc85678ad9a0d14e6a6be4ac | 3.10.17+ #571 Tue Oct 22 19:42:58 BST 2013 | Oct 22 2013 20:02:20
f382e9a226e7cb3df2fba58dbe2956773c5d14a8 | 3.10.17+ #573 Wed Oct 30 22:06:03 GMT 2013 | Oct 30 2013 22:22:16
dc709fae6f7fca6d1062dd49ef3527b27439ca73 | 3.10.18+ #577 Tue Nov 5 12:33:36 GMT 2013 | Oct 18 2013 16:07:43
4dd2c5de608ec1756dc6db5a423eaa076b32f618 | 3.10.18+ #579 Wed Nov 6 13:49:03 GMT 2013 | Oct 18 2013 16:07:43
3626277a5915a7cfeb90d536355227570c6f8c17 | 3.10.19+ #600 PREEMPT Sat Nov 16 20:34:43 GMT 2013 | Nov 15 2013 14:17:01
Latest vesion of software, number not known | 3.10.28+ #634 PREEMPT Sun Feb 2 15:16:25 GMT 2014 | Feb 2 2014 15:33:06
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by mrgrey » Wed Feb 05, 2014 4:06 pm
I've emailed Artur Lipowski (Author of the GPIO Part of lircd). Maybe he can either take a look at the issue directly or tell us where to open a ticket for this 'cause I'm not sure wether it's a LIRC or a kernel(-module) bug..

will post an update as soon as I hear back from him and/or when I get my Pi sending again.
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by GeofP » Wed Feb 05, 2014 4:15 pm
Thank you. I think I have done all I can now so will wait to see what Artur Lipowski advises. If you need the information above in a better format, please let me know.
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by mrgrey » Thu Feb 06, 2014 8:52 am
Update:
Artur isn't the go-to guy anymore so I've emailed Aron of (http://aron.ws/projects/lirc_rpi/).
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by mrgrey » Thu Feb 06, 2014 10:16 am
Update:

Aron answered. He suggested to open a ticket here https://github.com/raspberrypi/linux/issues/new. If no one beats me to it, I'll open one tonight.

He suggests to:

...try to go back to the direct register manipulation version (this version: https://github.com/ar0n/linux/commit/69 ... 742de48dcb ) where the output levels are directly modified using the registers of the bcm chip, just to rule out a few problems.

I'll try to verify this on the weekend.

regards
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by GeofP » Thu Feb 06, 2014 11:37 am
I don't know how to try this old version.
I ran the following:
sudo rpi-update 69af0bf569f66fa3262f2b46e5e636742de48dcb
but received a ERROR 404: Not Found, so obviously not the correct approach.
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by mrgrey » Thu Feb 06, 2014 11:53 am
The link sent by Aron points to the changelog of the kernel-module itself, not the 'whole raspi package' provided by hexxeh. In order to test Aron's suggestion, one would have to (at least) rebuild that kernel-module. Best way for that IMHO is to setup a cross-compile environment in a VM.
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by GeofP » Thu Feb 06, 2014 12:04 pm
Thanks. Unfortunately I don't have enough Linux knowledge to do that.
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by netlin » Thu Feb 06, 2014 1:39 pm
Hello,
I confirm troubleshooting with lirc since an update of my pi in december.
With my Universal remote ( from Alexba project), I notice that:
- My Panasonic TV, my Sherwood AV doesn't receive commands anymore,
- my RGB lamp, my Hauppauge TV card receiver works like a charm.
my config : 3.10.27+ #630 PREEMPT Fri Jan 17 19:44:36 GMT 2014 armv6l GNU/Linux

I can reproduce the problem with another brandnew config. (another pi and another electronic components)

So thanks to GeofP, I have modified my lircd.conf, (only for the problematic's device)
- header, one, zero increasing with a 1.15 factor;
-set the frequency to 33000

and it's works !
So, until the developers solve the problem, the tip of GeofP is a good workaround. :D

Regards.
Posts: 1
Joined: Thu Feb 06, 2014 1:08 pm
by mrgrey » Thu Feb 06, 2014 9:16 pm
User avatar
Posts: 11
Joined: Tue Jul 17, 2012 12:32 pm
by GeofP » Fri Feb 07, 2014 7:05 am
Thank you netlin. It is a relief to hear that someone else has a similar problem and it can be fixed in the same way!
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by GeofP » Wed Apr 30, 2014 8:58 pm
This problem has now been diagnosed and fixed as of a couple of days ago.
Perform a sudo rpi-update to load the corrected version of lircd.
A software version equal or later then the following will produce the correct timing for lircd commands.
3.12.18+ #677 PREEMPT Mon Apr 28 22:45:00 BST 2014.
Posts: 24
Joined: Fri Jan 31, 2014 9:59 am
Location: NE Hampshire UK
by timg11 » Sun Jun 01, 2014 12:42 am
Hi,

I'm having the same problem. I performed the rpi-update, and after rebooting, the uname -a command reports:
Linux raspberrypi 3.12.20+ #687 PREEMPT Fri May 30 16:39:11 BST 2014 armv6l GNU/Linux

lircd -v reports: lircd 0.9.0-pre1

Unfortunately, I'm still having the same problems. Timing is running about 85% of what it should be. The initial pulse has a value of 8600 (uS), but measures on the scope at about 7000 uS. Frequency is supposed to be 38 KHz but measures at 43 KHz.

What did I miss in the updating process?
Posts: 9
Joined: Sat May 31, 2014 11:14 pm
by timg11 » Sun Jun 01, 2014 2:24 am
I have continued to study the results after the update.
It appears that there is still a frequency shift, but the timing of the header has been corrected by the update.
I found setting the frequency to 34000 brought it close to 38KHz as measured on a scope.
The header timing seems correct, and the 38KHz clock timing is within a few percent, but it still doesn't work.

I have tried two ways of creating the lircd.conf file. First by converting from Pronto codes that I captured with a USB-UIRT. That one uses raw-codes. It starts off like this:

Code: Select all
begin remote
   name   LG_Pronto_LIRC
   flags   RAW_CODES
   eps   30
   aeps   100
   gap   104504
      begin raw_codes

         name KEY_STOP
            8598 4065 495 1537 495 521
            495 521 495 521 495 1537
            495 521 495 521 495 521
            469 1563 495 1537 469 547
            495 521 495 521 495 521
            469 547 495 521 495 521
            495 547 469 547 495 521
            495 521 495 1537 495 521
            495 1537 469 547 495 521
            495 521 495 1537 495



The second version of lircd.conf was created by capturing directly using IRRECORD. It starts off like this:

Code: Select all
begin remote

  name  LG_EN61000
  bits           20
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100

  header       8651  4063
  one           485  1538
  zero          485   526
  ptrail        486
  pre_data_bits   8
  pre_data       0x88
  gap          226818
  toggle_bit_mask 0x0
  frequency    34000

      begin codes
          KEY_STOP                 0xC0051


If I break down the raw-codes into pairs and convert the bits back to codes, they match the codes used in the IRRECORD file.

Still, although physical remote works fine, there is no response from irsend commands from the Raspberry Pi.
Posts: 9
Joined: Sat May 31, 2014 11:14 pm
by jdb » Sun Jun 01, 2014 9:14 am
For those experiencing issues with 3.12 kernels, can you try adding dwc_otg.fiq_fsm_enable=0 to /boot/cmdline.txt?

The new FIQ uses more CPU time and can fire anywhere, including in Lirc driver timing loops - though this should have the effect of reducing the output frequency, not increasing it.
✂ – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 825
Joined: Thu Jul 11, 2013 2:37 pm
by timg11 » Sun Jun 01, 2014 1:14 pm
jdb, I am unfamiliar with editing cmdline.txt. My current cmdline.txt looks like this:
Code: Select all
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

I didn't find any details on the expected format of cmdline.txt with a quick search. I assume it is normal to separate items with space rather newline?

So after adding your suggestion, my cmdline.txt would look like this?
Code: Select all
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait dwc_otg.fiq_fsm_enable=0

(that is one long line with space delimiters - the code window may make wrap it)

Also, could you point me to an explanation of what "fiq_fsm_enable=0" actually does? I searched on it, and Google wants to change it to "fiq_fix_enable", which seems to be related to USB support.
Posts: 9
Joined: Sat May 31, 2014 11:14 pm
by Richard-TX » Sun Jun 01, 2014 3:02 pm
I recommend that you go back to the 9-25-2013 image of Raspbian. Link is in my .sig
Richard
Richard
Doing Unix since 1985.
The 9-25-2013 image of Wheezy can be found at:
http://downloads.raspberrypi.org/raspbian/images/raspbian-2013-09-27/2013-09-25-wheezy-raspbian.zip
User avatar
Posts: 1349
Joined: Tue May 28, 2013 3:24 pm
Location: North Texas
by timg11 » Sun Jun 01, 2014 4:01 pm
Richard
re: going back to 9-25-2013: I know how to apply a fresh image to an SD-card, and I know how to update with rpi-update.

However, I don't know how to "downgrade" without losing all the installations and configurations I have done - e.g. LIRC.
Is there a recommended process for that?
Posts: 9
Joined: Sat May 31, 2014 11:14 pm
by timg11 » Sun Jun 01, 2014 4:29 pm
I've got it working with this configuration:
Linux raspberrypi 3.12.20+ #687 PREEMPT Fri May 30 16:39:11 BST 2014 armv6l GNU/Linux
lircd -v reports: lircd 0.9.0-pre1


I have not tried the dwc_otg.fiq_fsm_enable=0 setting or the downgrade process. I'll do some more experimenting when I have some extra time.

For any that need a config for an LG EN61000 air conditioner, here is the working lircd.conf file:

Code: Select all
# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was generated
# by converting raw data captured in Pronto format from a USB-UIRT
# and converting pronto to LIRC with pronto2lirc.py
#
# using lirc-0.9.0-pre1(default) on Sat May 31 01:36:27 2014
#
# contributed by Tim Godfrey
#
# brand:      LG
# model no. of remote control:
# devices being controlled by this remote: EN61000 Air Conditioner
#
# Note: Actual frequency of remote is 38KHz.
# The setting for frequency 34000 below is to compensate for an issue seen with Raspbian
# versions in the range of 3.10.19 through (at least) 3.12.20+
# See http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=62063&p=558583
# LIRC Default frequency is 38KHz, so remove that line if using non-Raspberry Pi platform
# or after bug is fixed in Raspberry Pi.
#
# Namespace Mapping  (LIRC namespace does not directly support air conditioners)
#--LIRC Key---------Function --------------------
# KEY_POWER        Power On
# KEY_STOP          Power Off
# KEY_F18           Temp 18C
# KEY_F19           Temp 19C
# KEY_F20           Temp 20C
# KEY_F21           Temp 21C
# KEY_F22           Temp 22C
# KEY_F23           Temp 23C
# KEY_F24           Temp 24C
# KEY_KP5           Temp 25C
# KEY_KP6           Temp 26C
# KEY_KP7           Temp 27C
# KEY_KP8           Temp 28C
# KEY_KP9           Temp 29C
# KEY_KP0           Temp 30C
# KEY_ZOOMIN        Jet Mode On
# KEY_ZOOMOUT       JetMode Off
# KEY_FN_S          FAN Louver Oscillate Toggle
# KEY_FN_F1         FAN Random Speed (CHAOS)
# KEY_FN_F2         FAN Low Speed
# KEY_FN_F3         FAN Medium Speed
# KEY_FN_F4         FAN High Speed
#


begin remote
   name   LG_EN61000
   flags   RAW_CODES
   eps   30
   aeps   100
   gap   104635
    frequency    34000
      begin raw_codes

         name KEY_POWER
            8676 4091 495 1563 469 547
            495 547 469 547 495 1537
            495 521 469 547 495 521
            495 521 495 547 469 547
            495 547 495 521 495 521
            469 547 495 521 495 547
            495 1537 495 1537 495 1537
            495 547 495 521 495 547
            469 547 495 521 495 1563
            469 1563 495 1563 469

         name KEY_STOP
            8598 4065 495 1537 495 521
            495 521 495 521 495 1537
            495 521 495 521 495 521
            469 1563 495 1537 469 547
            495 521 495 521 495 521
            469 547 495 521 495 521
            495 547 469 547 495 521
            495 521 495 1537 495 521
            495 1537 469 547 495 521
            495 521 495 1537 495

         name KEY_F18
            8598 4091 495 1537 495 521
            495 521 495 521 469 1563
            495 521 495 521 495 521
            495 521 495 521 495 521
            469 547 495 1537 495 521
            469 547 495 521 495 521
            495 521 495 1537 495 1537
            495 521 495 1537 495 521
            469 547 495 1537 495 1537
            495 1537 495 1537 495

         name KEY_F19
            8598 4065 495 1537 495 521
            495 521 495 521 495 1537
            495 521 495 521 469 547
            495 521 495 521 495 521
            469 547 495 1537 495 521
            469 547 495 521 495 521
            495 1537 495 521 495 521
            495 521 495 1537 495 521
            495 521 469 547 495 521
            495 521 495 521 469

         name KEY_F20
            8650 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 469 547 495 521
            495 521 495 547 469 547
            495 521 495 1537 469 547
            495 521 495 521 495 521
            495 1537 495 521 495 1537
            495 521 495 1537 469 547
            495 521 495 521 495 521
            469 547 495 1537 469

         name KEY_F21
            8624 4091 495 1563 495 521
            495 521 495 547 469 1563
            495 521 495 521 469 547
            495 521 495 521 495 521
            469 547 495 1537 469 547
            469 547 495 521 495 521
            469 1563 495 1537 495 521
            495 521 495 1537 495 521
            469 547 495 521 495 521
            495 1537 495 521 495

         name KEY_F22
            8650 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 495 521 495 521
            495 521 495 521 469 547
            495 521 495 1537 469 547
            495 521 495 521 495 521
            495 1537 495 1537 495 1537
            495 521 495 1537 495 521
            495 521 495 521 469 547
            495 1537 495 1537 469

         name KEY_F23
            8650 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 495 521 495 521
            495 521 495 521 469 547
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 521 495 521 495 521
            495 521 495 1537 495 521
            469 547 495 521 495 1537
            495 521 495 521 495

         name KEY_F24
            8624 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 495 521 495 521
            495 521 495 521 469 547
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 521 495 521 495 1537
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 521 495 1537 495

         name KEY_KP5
            8624 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 495 521 495 521
            495 521 495 521 495 521
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 521 495 1537 469 547
            495 521 495 1537 495 521
            495 521 495 521 495 1537
            495 1537 495 521 469

         name KEY_KP6
            8624 4065 495 1537 495 521
            495 521 495 521 495 1537
            495 521 495 521 469 547
            495 521 495 521 495 521
            469 547 495 1537 495 521
            495 521 495 521 495 1537
            469 547 495 1537 495 1537
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 1537 495 1537 495

         name KEY_KP7
            8598 4038 495 1537 495 521
            495 521 469 547 495 1537
            495 521 495 521 495 521
            495 521 495 521 469 547
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 1537 495 521 495 521
            495 521 495 1537 469 547
            495 521 495 1537 469 547
            495 521 495 521 495

         name KEY_KP8
            8650 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 469 547 495 521
            495 521 495 547 469 547
            495 521 495 1537 469 547
            495 521 495 521 495 1537
            495 1537 495 521 469 1563
            495 521 495 1537 495 521
            495 521 495 1537 495 521
            495 521 495 1537 469

         name KEY_KP9
            8598 4038 495 1537 495 521
            495 521 495 521 495 1537
            495 521 495 521 469 547
            495 521 495 521 495 521
            469 547 495 1537 495 521
            495 521 495 521 495 1537
            469 1563 495 1537 495 521
            495 521 495 1537 469 547
            495 521 495 1537 469 547
            495 1537 495 521 469

         name KEY_KP0
            8624 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 469 547 495 521
            495 521 495 521 469 547
            495 521 495 1537 495 521
            495 521 495 521 495 1537
            495 1537 495 1537 495 1537
            495 521 469 1563 495 521
            495 521 469 1563 495 521
            495 1537 495 1537 495

         name KEY_ZOOMIN
            8650 4065 495 1563 469 547
            495 521 495 521 495 1537
            495 521 495 521 495 547
            469 547 495 521 495 521
            495 1537 495 521 495 521
            495 547 495 521 495 521
            495 521 495 521 469 547
            495 1537 495 521 469 547
            495 521 495 1537 469 547
            495 521 495 1537 469

         name KEY_ZOOMOUT
            8598 4065 495 1537 495 521
            495 521 469 547 495 1537
            495 521 469 547 495 521
            495 521 495 521 469 547
            495 521 495 1537 469 547
            495 521 469 547 495 521
            495 521 495 1537 495 1537
            495 521 495 1537 469 547
            495 521 495 1537 469 1563
            495 1537 469 1563 495

         name KEY_FN_S
            8624 4065 495 1563 495 521
            469 547 495 521 469 1563
            469 547 495 521 495 521
            495 521 469 547 495 521
            495 1537 469 547 495 521
            495 521 495 521 469 547
            495 521 495 521 469 547
            469 547 495 521 495 521
            495 521 469 547 495 521
            495 521 495 1537 495

         name KEY_FN_F1
            8650 4065 495 1563 495 521
            495 547 469 547 495 1537
            495 547 469 547 495 521
            495 521 495 547 469 547
            495 521 469 1563 469 547
            495 521 495 521 495 521
            469 547 495 1537 495 1537
            495 521 495 1537 469 547
            495 1537 495 521 469 547
            495 547 495 521 495

         name KEY_FN_F2
            8650 4065 495 1563 469 547
            495 521 495 521 469 1563
            495 521 495 521 495 521
            495 521 495 521 495 521
            469 547 495 1537 495 521
            469 547 495 521 495 521
            495 521 469 1563 495 1537
            469 547 495 521 495 521
            495 547 469 1563 495 521
            495 1537 495 1537 495

         name KEY_FN_F3
            8624 4091 495 1537 495 521
            495 521 495 521 469 1563
            469 547 495 521 469 547
            495 521 495 521 495 521
            469 547 495 1537 495 521
            469 547 469 547 495 521
            495 521 469 1563 495 1537
            469 547 495 521 495 1537
            469 547 495 1537 495 1537
            495 521 469 1563 495

         name KEY_FN_F4
            8650 4065 495 1563 495 521
            495 521 469 547 495 1537
            495 521 495 547 469 547
            495 521 495 521 495 547
            469 547 495 1537 495 547
            495 521 495 521 495 521
            495 547 469 1563 495 1537
            469 547 495 1537 495 547
            469 547 495 1537 495 1537
            495 1537 495 1537 495
      end raw_codes
end remote
Posts: 9
Joined: Sat May 31, 2014 11:14 pm