This is sort of a combination of this thread and this thread.
I'm running LIRC on a Linux box and have successfully converted many remotes to working lircd.conf files using irrecord. Well, I recently switched from Dish Network to the ADB 3800W IPTV box and have had a difficult time learning all the butttons on the remote using irrecord. Buttons 1-9 and a few others are reliable, but several of them, including the arrow keys, '0' and a few other important ones are, at best, unreliable.
In the second thread I referred to, it appears that there is a .rmdu file for the 3800 and in the first thread, Rob provides a handmade lircd.conf file for the Pansat 3500A. I looked at the file he started with and looked at his lircd.conf file and I can't for the life of me figure out how he did the conversion.
Can anyone enlighten me on how this is done? How is the "header" information obtained/derived (values for items like: bits, flags, eps, aeps, header, one, zero, ptrail, repeat, pre_data_bits, pre_data, gap, min_repeat, and toggle_bit)? Additionally, how are the codes for each key determined?
Any help would be greatly appreciated! This remote is driving me crazy!
lircd.conf file for ADB 3800W IPTV box
Moderator: Moderators
I think we are all still not experts in LIRC, plus there may be issues specific to your LIRC hardware.
For both reasons it would be much harder to invent an lirc.conf file from scratch than to examine the one you made from imperfect learns and figure out what to fix.
So post that lirc.conf file (the one in which 1-9 etc. are reliable and 0, etc. are not).
For both reasons it would be much harder to invent an lirc.conf file from scratch than to examine the one you made from imperfect learns and figure out what to fix.
So post that lirc.conf file (the one in which 1-9 etc. are reliable and 0, etc. are not).
That is all much harder to explain generically than in the context of a specific file. If you want a generic explanation, you need to get it from the internals documentation in the LIRC project. If you want an explanation for a specific lirc.conf file, post that file.lra wrote:How is the "header" information obtained/derived (values for items like: bits, flags, eps, aeps, header, one, zero, ptrail, repeat, pre_data_bits, pre_data, gap, min_repeat, and toggle_bit)? Additionally, how are the codes for each key determined?
Thanks for your rapid response! Below is the requested lircd.conf file. Note that I could not get irrecord to do anything but generate the "raw codes" for the keys I pressed. According to the documentation, the raw codes consist of:johnsfine wrote:I think we are all still not experts in LIRC, plus there may be issues specific to your LIRC hardware.
For both reasons it would be much harder to invent an lirc.conf file from scratch than to examine the one you made from imperfect learns and figure out what to fix.
So post that lirc.conf file (the one in which 1-9 etc. are reliable and 0, etc. are not).
That is all much harder to explain generically than in the context of a specific file. If you want a generic explanation, you need to get it from the internals documentation in the LIRC project. If you want an explanation for a specific lirc.conf file, post that file.lra wrote:How is the "header" information obtained/derived (values for items like: bits, flags, eps, aeps, header, one, zero, ptrail, repeat, pre_data_bits, pre_data, gap, min_repeat, and toggle_bit)? Additionally, how are the codes for each key determined?
Anyway, here's my lircd.conf file in all its glory:A button description begins with the parameter name and followed by the name of the button. The button description ends with the next button description or the end of the raw_codes block. The lines in between consist of a list of decimal numbers describing the signal sent by that button. The first number indicates the duration of the first pulse in microseconds. The second number indicates the duration of the space which follows it. Pulse and space durations alternate for as long as is necessary. The last duration should represent a pulse.
Code: Select all
begin remote
name adb_3800w
flags RAW_CODES|CONST_LENGTH
eps 30
aeps 100
ptrail 0
repeat 0 0
gap 99104
begin raw_codes
name 1
1066 789 682 1173 362 533
341 874 341 874 341 874
341 874 341 874 341 1194
341 874 341 1194 341 554
341 576 341 874 341 1834
341 874 341
name 2
1088 789 682 1152 448 448
426 789 490 746 448 768
448 768 469 746 448 1088
469 1045 426 789 469 426
341 554 341 874 341 874
341 874 341
name 3
1109 768 661 1194 341 554
341 874 341 874 341 874
341 874 341 874 341 1194
341 1514 341 554 341 554
341 554 341 874 341 874
341 1194 341
name 4
1002 896 661 1194 341 554
341 874 341 874 341 874
341 874 341 874 341 874
341 1194 341 1514 661 874
341 874 341 1813 341 554
341
name 5
1109 768 768 1088 490 426
341 874 341 874 341 874
341 874 341 874 341 874
341 1514 341 1194 661 874
341 874 341 1813 341 874
341
name 6
1024 853 682 1173 362 533
362 853 362 853 362 853
362 853 362 853 362 853
362 1792 384 853 682 853
362 853 362 853 362 853
362
name 7
981 874 661 1194 384 533
362 853 362 853 362 853
362 853 362 874 362 1173
362 533 362 1792 661 874
362 853 362 853 362 1173
362
name 8
981 896 618 1216 341 576
341 874 341 874 341 874
341 874 341 874 341 1194
341 874 341 1514 618 917
341 874 341 874 341 1514
341
name 9
981 896 640 1216 362 533
362 853 362 853 362 853
362 853 362 853 362 1173
362 1173 362 1173 640 874
362 853 362 853 362 1792
362
name enter
1066 789 682 1173 426 490
341 874 341 874 341 874
341 874 341 874 341 874
341 874 341 1813 341 874
640 853 341 874 341 874
341
name menu
981 874 661 1194 341 554
341 874 341 874 341 874
341 874 341 874 341 874
341 1514 341 1194 341 874
661 874 341 874 341 1514
341
name last
1152 725 682 1173 426 490
426 789 448 768 512 704
426 789 384 832 448 768
512 704 426 1429 448 448
448 448 512 725 426 1429
448 768 426
name info
1130 746 725 1109 512 405
341 874 341 896 341 874
341 874 341 874 341 1194
341 1514 341 874 661 874
341 874 341 1194 341 554
341
name cc
1088 768 682 1152 362 533
362 853 362 853 426 789
448 768 341 874 341 874
341 874 341 1834 341 256
341 554 341 874 341 1834
341 576 341
################ solid to here ################################
name exit
1130 746 682 1173 362 533
362 853 362 853 426 789
426 789 426 789 426 789
426 1109 426 1109 426 1109
682 853 426 1749 426 234
362
# best 0 so far (if repeated)
name 0
1002 853 682 1173 426 490
341 874 341 874 341 896
341 874 341 874 341 874
341 1194 341 1514 341 256
341 554 341 874 341 1813
341 874 341
# 2nd best 0 so far
name 02
1109 746 682 1152 341 554
341 874 341 874 341 874
341 874 341 874 341 874
341 1173 341 1514 341 256
341 576 341 874 341 1834
341 874 341
# 3rd best 0 so far
name 03
1002 853 618 1216 362 533
362 853 362 853 362 853
362 853 362 853 362 853
341 1194 362 1472 362 234
341 576 341 874 341 1834
341 874 341
name guide
1066 810 746 1109 426 490
512 725 426 789 512 725
448 789 405 789 448 1088
469 746 384 1450 426 234
362 490 512 725 512 704
512 1664 512
name up
1109 768 768 1088 512 405
426 789 426 789 426 789
512 704 341 874 341 874
341 1813 341 554 341 234
341 874 341 874 341 1813
661
# down - broken
# name down
# 1002 853 682 1152 426 490
# 362 853 426 810 426 789
# 362 853 448 768 362 1152
# 469 426 426 1429 362 213
# 320
# another down - broken
# name down
# 1045 789 682 1152 362 533
# 426 789 426 810 384 832
# 426 810 426 810 426 1109
# 362 533 426 1408 362 213
# 320
# name right
# 1088 768 746 1109 512 405
# 448 768 448 768 426 789
# 426 789 426 789 426 1109
# 426 1109 448 768 1002 853
# 341 874 341 1813 341 874
# 341
# name left
# 1066 810 682 1152 384 533
# 362 853 362 853 426 789
# 384 853 426 789 362 1173
# 448 768 384 1173 362 213
# 341 874 341 874 341 1834
# 341 576 341
end raw_codes
end remote
That is a disappointing lirc.conf. I'll try to find time to investigate tomorrow. You aren't going to get much improvement by tweaking that file. You will need a non raw file.
My next step (unless someone else gets there first) will be to find a similar protocol non raw file posted by brand on the lirc site. Failing that, I probably can start from scratch, but that is a last resort.
My next step (unless someone else gets there first) will be to find a similar protocol non raw file posted by brand on the lirc site. Failing that, I probably can start from scratch, but that is a last resort.
Yeah, I know it's embarassingjohnsfine wrote:That is a disappointing lirc.conf. I'll try to find time to investigate tomorrow. You aren't going to get much improvement by tweaking that file. You will need a non raw file.
My next step (unless someone else gets there first) will be to find a similar protocol non raw file posted by brand on the lirc site. Failing that, I probably can start from scratch, but that is a last resort.
! But what can I do? irrecord doesn't seem to recognize the "pattern" of this remote's codes in order to generate a useful header and command codes. If this helps any, the remote used is the UEI Potenza, as described in this thread.I half remember that given a decent header you can more easily learn the rest of the signals correctly. Is that correct? That would at least save the effort of hand translating all the signals.lra wrote:irrecord doesn't seem to recognize the "pattern" of this remote's codes in order to generate a useful header and command codes.
I think I know what the correct header should look like. Test whether you can recognize signals with this header and whether it helps with learning the rest.
There are a lot of details on which I might have been careless, so even if I have the concepts right, I'm not sure this will work. Hopefully it is close enough to debug.
Code: Select all
begin remote
name adb_3800w
bits 40
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100
one 305 0
zero 0 305
pre_data_bits 32
pre_data 0xE3091111
begin codes
1 0x0000001088491022
2 0x0000001084491110
end codes
end remote
Yes, you are right about irrecord. When you start with a new remote, it prompts you to press all the keys till it recognizes some sort of pattern. After it has gone through that initial phase, it prompts you to provide a key "name" and then press the corresponding button on the remote.johnsfine wrote:I half remember that given a decent header you can more easily learn the rest of the signals correctly. Is that correct? That would at least save the effort of hand translating all the signals.
Ultimately it writes out this ".conf" file. If you reuse that same conf file in another run of irrecord, it skips that "learning" phase and just prompts for key names and remote button presses. So, yes, once you get a decent header, learning additional keys should be easy.
My first comment on your proposed header is: where on earth did those values come from? Are they from some .rmdu file or something?I think I know what the correct header should look like. Test whether you can recognize signals with this header and whether it helps with learning the rest.
I tried the code you provided and got the follwing:
Code: Select all
% irsend send_once adb_3800w 1
irsend: command failed: send_once adb_3800w 1
irsend: transmission failedCode: Select all
Nov 22 18:19:51 hog lircd: too short gap: 0Do you have any other suggestions on what to try next?
Thanks again for your help!
Somehow I completely misunderstood the goal of this activity.
LIRC can be used to learn a set of signals so that it can recognize them later, so extra layers of code can do things on the Linux system in response to whatever you are doing with your remote. For that use, the raw format was never going to work well, the gap doesn't matter much, and other things I did should make sense (though your testing implies I didn't get everything right even for that use).
In hindsight it seems silly to have focused on that use.
For transmitting the signals from lirc, the raw format can be cleaned up enough to send signals that are just as good as anything that could be sent with a correct non raw file.
A non raw file would be easier, if we can figure out how to debug it. So one of my suggestions still applies: Try learning more keys with the header I gave you and see whether it can and what they look like.
In case I got sloppy hand decoding the pre data bits, try with 72 bits and no pre data:
If that doesn't get us somewhere quickly, I'll figure out how to clean up the raw ones so they can be transmitted reliably.
LIRC can be used to learn a set of signals so that it can recognize them later, so extra layers of code can do things on the Linux system in response to whatever you are doing with your remote. For that use, the raw format was never going to work well, the gap doesn't matter much, and other things I did should make sense (though your testing implies I didn't get everything right even for that use).
In hindsight it seems silly to have focused on that use.
For transmitting the signals from lirc, the raw format can be cleaned up enough to send signals that are just as good as anything that could be sent with a correct non raw file.
A non raw file would be easier, if we can figure out how to debug it. So one of my suggestions still applies: Try learning more keys with the header I gave you and see whether it can and what they look like.
In case I got sloppy hand decoding the pre data bits, try with 72 bits and no pre data:
Code: Select all
begin remote
name adb_3800w
bits 72
flags SPACE_ENC|CONST_LENGTH
eps 30
aeps 100
one 305 0
zero 0 305
begin codes
end codes
end remote I don't believe you completely misunderstood what I'm trying to do. LIRC does in fact allow you to learn remote codes and then use them to initiate some activity on the Linux machine when it sees those codes again on its IR receiver from a remote. That is not, however, what I'm trying to do.johnsfine wrote:Somehow I completely misunderstood the goal of this activity.
LIRC can be used to learn a set of signals so that it can recognize them later, so extra layers of code can do things on the Linux system in response to whatever you are doing with your remote. For that use, the raw format was never going to work well, the gap doesn't matter much, and other things I did should make sense (though your testing implies I didn't get everything right even for that use).
In hindsight it seems silly to have focused on that use.
I'm using LIRC the "other" way -- where it learns the codes from the remote using its IR receiver and then regenerates the proper pulses on its IR transmitter, using the irsend command (FYI, I'm using the Iguanaworks USB IR Transceiver.) Using LIRC in this way, I can (and do) control a lot of my IR devices (except that @#$^% ADB IPTV box) in my house, right from desktop, which is very handy!
I tried using the new lircd.conf file you mention above. When irrecord prompts me to name keys and then press the remote buttons, I get the message:
Code: Select all
Something went wrong.I am suspicious of the values you provide for "one" and "zero" in the header you gave me. According to the documentation, "one is the pulse and space lengths representing a one", likewise for "zero". In all my conf files for other remotes I've never seen a 0 for the pulse or space value. To me that doesn't make sense.
Not the one to give up too easily, I decided to try to create a new conf file "from scratch" using irrecord. It prompts you to keep pressing keys until it figures out the pattern and generates a header. I did this at least for different times. Here's a typical excerpt from the "learning session":
Code: Select all
Press RETURN now to start recording.
................................................................................
Found const length: 99120
Please keep on pressing buttons like described above.
................................................................................
RC-5 remote control found.
Found possible header: 1067 793
Found lead pulse: 721
No repeat code found.
Unknown encoding found.
Creating config file in raw mode.
Now enter the names for the buttons.
So, I'm still back at "square 0". I thought that maybe with all the info available for this remote on JP1, there would be some way to convert it to a non-raw lircd.conf file. Am I just way off base here?
I'm still open to any other suggestions...
The delay before I posted that was because I thought I needed to look for an example of that.lra wrote:I am suspicious of the values you provide for "one" and "zero" in the header you gave me. According to the documentation, "one is the pulse and space lengths representing a one", likewise for "zero". In all my conf files for other remotes I've never seen a 0 for the pulse or space value. To me that doesn't make sense.
In this protocol, a one is just a pulse and a zero is just a space. I wasn't sure how lirc represented that uncommon structure. The example I found was:
http://lirc.sourceforge.net/remotes/pcm ... conf.pcmak
In your device the length of each bit is about 305uS vs. 833uS in that example. The polarity (which bit is "one" vs. "zero") ought to be arbitrary, so I chose to set it the more understandable way vs. the backwards way it is in that example. Your device also has more pre data bits and more regular bits than that example. Other than all those big differences, I tried to follow that example.
I'm pretty sure there is a way to do it. I probably was pretty close. But even missing by a minor detail can be pretty hopeless when the diagnostics give no information beyond "failed".there would be some way to convert it to a non-raw lircd.conf file. Am I just way off base here?
Our best understanding of the protocol is a series of bits, all the same length (about 305uS). When two bits of the same polarity occur together, the durations are added together.
Then that signal is distorted in various ways by the learning process. If we're right about the true signal, the major distortion is that on every transition from pulse to space the learning system extends the pulse reducing the following space. It appears that the first pulse is extended more than typical pulses.
So we are guessing the initial 1066 789 you have for '1' is really 915 915, so the learning system extended the pulse by 151 while reducing the space by 126 (the fact that the 151 is so different from the 126 is some other undiagnosed distortion). Then the following 682 1173 is really 610 1220, so increased by 72 followed by decreased by 47 is more typical of the scale of the usual primary distortion (but we still have some other distortion because the 72 is so different from 47).
We don't know what, if any significant, distortion is generated by the transmitter, probably much less than by the learning system.
The final receiver tolerates a large amount of distortion, It isn't obvious to me what about the distortion of the failing signals makes them worse than the working signals.
If I understood everything correctly, we can clean up any signal by rounding each pulse downward to the next lower multiple of 305 and each space upward to the next higher multiple of 305. That is worth trying. If it isn't quite right, hopefully it will give us more feedback than just "fails" to get a better idea what we ought to try.
For example, your "best 0" would clean up to:
Code: Select all
name 0
915 915 630 1220 305 610
305 915 305 915 305 915
305 915 305 915 305 915
305 1220 305 1525 305 305
305 610 305 915 305 1830
305 915 305 Thanks John, for that great explanation! I tried your "cleaned up" version of "0" above (I changed the "630" in line 1 to 610), but still got unreliable results for it. Sometimes, if I sent a single 0, the IPTV box would display a 0 and other times not. If I sent two zeros in a row, a few milliseconds apart (I thought I'd try it), sometimes I'd see two zeros on the TV, other times only one.johnsfine wrote: If I understood everything correctly, we can clean up any signal by rounding each pulse downward to the next lower multiple of 305 and each space upward to the next higher multiple of 305. That is worth trying. If it isn't quite right, hopefully it will give us more feedback than just "fails" to get a better idea what we ought to try.
For example, your "best 0" would clean up to:Code: Select all
name 0 915 915 630 1220 305 610 305 915 305 915 305 915 305 915 305 915 305 915 305 1220 305 1525 305 305 305 610 305 915 305 1830 305 915 305
This thing is really getting to me! I'm so close to being able to have my box change channels at a predetermined time (my Panasonic DVR already does so), but I can't count on the darned thing if the channel contains a 0 and unfortunately, all my movie channels are in the range from 300 to 310!!
What really puzzles me is why many of the keys (1 through 9, enter, info, exit, etc.) are "rock solid" with the "sloppy" raw codes, while a whole other group of keys (0, up, down, left, guide, etc.) are so erratic.
Do you have any other suggestions on things to try? Thanks again for all your help!
Creating NON-RAW lircd.conf file
I was having the same problem with LIRC creating RAW files also and just discovered if you run irrecord with "-a" it will create the nicer / non-raw version of the file. Of course you'll probably need to add whatever other options you need to the command line also. Using the "-f" will force it to create the painful to work with raw version.
-
packerswin@hrtc.net
- Posts: 1
- Joined: Mon Dec 28, 2009 6:18 pm
- Location: Greenfield, IN
adb 3800w
lra
Hello Ira. I was searching for help on the adb 3800w Set Top Box. I also have that STB with my fiber optic provided by my rural telecom provider. I have a Tivo series 2 dual tuner recorder and the ADB 3800W simply will not change channels properly when run through the Tivo. Oddly enough I have the same STB run through another series 2 Tivo, a single tuner, on another TV and the IR Code 10073 A or 10073 B works great to be able to change channels.
I don't know if it is the dual tuner that is problematic operating with the ADB STB or if I am using the wrong IR code for this STP/Tivo recorder pairing.
Could this ADB box have a different IR code? Tivo itself does not have the codes for ADB 3800W STB's but others report some success with the 10073 B code.
I saw that you had the ADB 3800W STB and wondered if you knew the IR code for your box, or if you have a pronto-capture file that I could give someone to generate the format codes.
I don't have a pronto remote and cannot generate the file myself. I have read that OmniRemote software used on a Palm Pilot can be used to capture the IR codes and save them in a pronto file format and I may have to go that route. There is a Tivo support guy in the UK who will take that file and create the IR codes from it.... if I can get it for my STB.
I thought I would contact you and see what your progress has been with your ADB 3800W to date and see if perhaps you could help.
By the way I went to grade school a bit in Eau Claire when I was a boy. My mother's family all came from the Eau Claire/Menomonee area....
Thanks. I hope you are able to help.
Paul
Hello Ira. I was searching for help on the adb 3800w Set Top Box. I also have that STB with my fiber optic provided by my rural telecom provider. I have a Tivo series 2 dual tuner recorder and the ADB 3800W simply will not change channels properly when run through the Tivo. Oddly enough I have the same STB run through another series 2 Tivo, a single tuner, on another TV and the IR Code 10073 A or 10073 B works great to be able to change channels.
I don't know if it is the dual tuner that is problematic operating with the ADB STB or if I am using the wrong IR code for this STP/Tivo recorder pairing.
Could this ADB box have a different IR code? Tivo itself does not have the codes for ADB 3800W STB's but others report some success with the 10073 B code.
I saw that you had the ADB 3800W STB and wondered if you knew the IR code for your box, or if you have a pronto-capture file that I could give someone to generate the format codes.
I don't have a pronto remote and cannot generate the file myself. I have read that OmniRemote software used on a Palm Pilot can be used to capture the IR codes and save them in a pronto file format and I may have to go that route. There is a Tivo support guy in the UK who will take that file and create the IR codes from it.... if I can get it for my STB.
I thought I would contact you and see what your progress has been with your ADB 3800W to date and see if perhaps you could help.
By the way I went to grade school a bit in Eau Claire when I was a boy. My mother's family all came from the Eau Claire/Menomonee area....
Thanks. I hope you are able to help.
Paul
Re: Creating NON-RAW lircd.conf file
Thanks for the suggestion (I'm willing to try anything). I trimmed down my lircd.conf file listed above to only the keys that work reliably and then ran irrecord -a on the file and got the following:jp1-lircr wrote:I was having the same problem with LIRC creating RAW files also and just discovered if you run irrecord with "-a" it will create the nicer / non-raw version of the file. Of course you'll probably need to add whatever other options you need to the command line also. Using the "-f" will force it to create the painful to work with raw version.
Code: Select all
Found lead pulse: 676
Unknown encoding found.
irrecord: decoding of 1 failed
irrecord: decoding of 2 failed
irrecord: decoding of 3 failed
irrecord: decoding of 4 failed
irrecord: decoding of 5 failed
irrecord: decoding of 6 failed
irrecord: decoding of 7 failed
irrecord: decoding of 8 failed
irrecord: decoding of 9 failed
irrecord: decoding of enter failedAm I doing something wrong here? I did try it from scratch, with the "-a" option and got the message "irrecord: gap not found, can't continue creating config file in raw mode". So that didn't work either.
I don't really care if all I get are raw codes if they'd work reliably, but that seems nearly impossible. My hope was that there was some way to convert a .rmdu file (or some such) to create a conf file with non-raw codes, but it's looking more and more like that isn't going to happen...
-
vickyg2003
- Site Admin
- Posts: 7109
- Joined: Sat Mar 20, 2004 12:19 pm
- Location: Florida
- Contact:
I shouldn't be commenting on this thread, because I really don't understand all the LIRC and this whole thread is over my head.
ADB often uses XMP protocol on their boxes. XMP is notroiuosly difficult to learn because it has up to 16 timing pairs. Could this whole problem be an XMP issue? The "found lead pulse of 676" would seem to indicate no, since the first timing pair of an xmp is ~200,-740.
Just a thought
ADB often uses XMP protocol on their boxes. XMP is notroiuosly difficult to learn because it has up to 16 timing pairs. Could this whole problem be an XMP issue? The "found lead pulse of 676" would seem to indicate no, since the first timing pair of an xmp is ~200,-740.
Just a thought
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.