Menu

#360 Same remote, different codes (irrecord)

Future
open
nobody
None
na
2020-08-11
2020-08-07
Peter B.
No

Hi everyone :)

I ran into a strange issue:
I've got lircd running on RPi1/Raspbian for >1 year without problems, but suddenly my remote stopped working. Nothing was changed (that I'm aware of).

My debugging tests:
irw* just stayed silent, while "mode2" for that remote clearly shows buttons are received. Other remotes work fine with irw.

So I irrecord-ed the non-working remote again and was surprised to see that the same keys now have different "pre_data" bytes:

  • before: 0x4EB3
  • now: 0xCE33

This stays consistent, and after search/replacing the pre_data bytes in the remote's lircd.conf file, the remote works again.

The remote in question is a Cyberhome DVD remote (no model number on the remote, and the deck is long gone). I've compared it to existing Cyberhome DVD remotes in the "lirc-remotes" collection: For example, CH-DVD_402 has the identical button codes (2 bytes without pre_data) as my remote, yet it also contains the old "pre_data" of 0x4EB3.

Before this oddity, the remote used to work flawlessly with this hardware even at a distance of >5m for over a year, used daily.

Of course I can replace the Cyberhome remote with a less problematic one, but if can anyone here can shed light on why the same remote suddenly registers different, but consistent pre_data, I'd be very grateful! :D

Thanks in advance!

Hardware:
Raspberry Pi 1B
TSOP 4838: connected to GPIO pin BCM 18 and 3.3V/GND

Discussion

  • Peter B.

    Peter B. - 2020-08-07

    Oh, I forgot to mention, the behavior is identical on:

    • Raspbian 9.1 Stretch:
      • lirc v0.9.4c-9
      • driver module: lirc-rpi
    • Raspios 10 Buster:
      • lirc v0.10.1-6.2~deb10u1
      • driver module: gpio-ir
     
  • Bengt Martensson

    That remote (normally!) sends NEC1 signals with device address 114 and subdevice address 205. (If you transform these to hexadecimal, reverse the bit order, and concatenate the two numbers, you get your "pre_data" 0x4EB3.) For some reason, two bits flipped, and now the addresses are different. If this is "bit rot" or if accidentally some hidden functionallity was triggered, we will probably never know. Smeagol turned Gollum; Anakin Skywalker turned into Darth Vadar, ...

    Why don't you just change your configuration files? The remote as such is a good remote (I have one such...), and NEC1 a good, not very error prone protocol. If it keeps changing that is another story though...

    It is not a Lirc problem. I suggest that you close the ticket. The mailing list is more appropriate for these kind of problems.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.