Menu
▾
▴
lirc-list
|
From: Brian J. M. <br...@in...> - 2012-04-23 06:02:17
Attachments:
signature.asc
Huawei DC730.rmdu
|
I have a device (Huawei DC730) which has a remote which LIRC can't seem to learn from (see the "irsend with raw codes?" thread for more information). Using raw codes doesn't seem to be at all effective. I have managed to find a configuration file for this device/remote in "RMDU" format? Is there any way to convert that to an LIRC remote control configuration file? The RMDU file can be found attached to this message if you are interested in seeing it. Cheers and much thanks, b. |
|
From: Bengt M. <bu...@be...> - 2012-04-23 23:03:37
Attachments:
xmpff-1_62_16_2012-04-23_22-59-04.lirc
|
On 04/23/12 08:01, Brian J. Murrell wrote: > I have a device (Huawei DC730) which has a remote which LIRC can't seem > to learn from (see the "irsend with raw codes?" thread for more > information). Using raw codes doesn't seem to be at all effective. > > I have managed to find a configuration file for this device/remote in > "RMDU" format? Is there any way to convert that to an LIRC remote > control configuration file? The RMDU file can be found attached to this > message if you are interested in seeing it. Hi Brian, a rmdu-file is for the use of the program RemoteMaster, see http://www.hifi-remote.com/forums/. It contains the name of an IR protocol used, here "XMP-1 with final frame", together with the parameters "device" (62) and "subdevice" (16). These are shared by all the command in the rmdzuu-file. In addition, every command has its own command number, that is the "hex" parameter in the rmdu-file. I am almost finished (just documentation and web site setup remains) of a tool that will do this semi-automatically (and much more). Try the included "fragment": The first 10 commands should correspond to 0 to 9, Command d062f013s016 and d062f014s016 should be channel up and down respectively, while d062f015s016 should be power, Does it work? Greetz, Bengt |
|
From: Brian J. M. <br...@in...> - 2012-04-24 12:56:59
Attachments:
signature.asc
|
On 12-04-23 05:16 PM, Bengt Martensson wrote: > > Hi Brian, Hi Bengt, > a rmdu-file is for the use of the program RemoteMaster, Indeed. > It contains the name of an IR > protocol used, here "XMP-1 with final frame", Which I'm guessing is a protocol that LIRC doesn't know about, yes? > I am almost finished (just documentation and web site setup remains) of > a tool that will do this semi-automatically (and much more). Try the > included "fragment": The first 10 commands should correspond to 0 to 9, > Command d062f013s016 and d062f014s016 should be channel up and down > respectively, while d062f015s016 should be power, Does it work? Woot! It works great! The only thing I found was the gap between duplicate key sends was not quite long enough to defeat the STBs de-bouncing when doing something like: # irsend SEND_ONCE xmpff-1 3 3 However # irsend SEND_ONCE xmpff-1 3 2 works as expected. For the duplicate key press situation I can do: # irsend SEND_ONCE xmpff-1 3; sleep .5; irsend SEND_ONCE xmpff-1 3 and it works as expected. Much, much thanks for this. I truly appreciate it. Cheers, b. |
|
From: Bengt M. <bu...@be...> - 2012-04-25 20:39:38
Attachments:
xmpff-1_62_16_2012-04-25_22-16-41.lirc
|
On 04/24/12 14:56, Brian J. Murrell wrote: > >> I am almost finished (just documentation and web site setup remains) of >> a tool that will do this semi-automatically (and much more). Try the >> included "fragment": The first 10 commands should correspond to 0 to 9, >> Command d062f013s016 and d062f014s016 should be channel up and down >> respectively, while d062f015s016 should be power, Does it work? > > Woot! It works great! Nice to hear that. I enclose a file containing the commands 0-100, which should be more than you need, according to the rmdu. Use the "hex" attribute in the rmdu-file to associate them to command names. > The only thing I found was the gap between > duplicate key sends was not quite long enough to defeat the STBs > de-bouncing when doing something like: > > # irsend SEND_ONCE xmpff-1 3 3 > > However > > # irsend SEND_ONCE xmpff-1 3 2 > > works as expected. For the duplicate key press situation I can do: > > # irsend SEND_ONCE xmpff-1 3; sleep .5; irsend SEND_ONCE xmpff-1 3 > > and it works as expected. The used protocol XMP-1 with final frame is unfortunately quite complicated, containing both a long intro sequence, and long repeat sequence, AND a long ending sequence. LIRC cannot (as I recall) do anything near this. Be happy that it "almost" works! > > Much, much thanks for this. I truly appreciate it. Glad to be of help. The program will be available next week, estimated. Greetz, Bengt |
|
From: Tom M. <tme...@gm...> - 2012-04-27 19:51:55
|
Bengt Martensson wrote: >Brian J. Murrell wrote: >> The only thing I found was the gap between duplicate key sends was >> not quite long enough to defeat the STBs de-bouncing when doing >> something like: >> # irsend SEND_ONCE xmpff-1 3 3 >> >> For the duplicate key press situation I can do: >> # irsend SEND_ONCE xmpff-1 3; sleep .5; irsend SEND_ONCE xmpff-1 3 >> >> and it works as expected. I wrote about the same problem with a Thompson DTA in these threads: http://sourceforge.net/mailarchive/forum.php?thread_name=4F94A895.6090500%40gmail.com&forum_name=lirc-list http://sourceforge.net/mailarchive/forum.php?thread_name=4F809A16.9050904%40gmail.com&forum_name=lirc-list No one had any suggestions. > The used protocol XMP-1... Is that the same as XMP (flags XMP) as used by: http://lirc.sourceforge.net/remotes/motorola/DTA100 ? > ...with final frame is unfortunately quite > complicated, containing both a long intro sequence, and long repeat > sequence, AND a long ending sequence. LIRC cannot (as I recall) do > anything near this. Be happy that it "almost" works! Interesting. Any pointers you can provide for more information on this? I'd like to understand the problem better, confirm if it applies to my situation, and see what can be done to fix it. If LIRC doesn't fully implement XMP, or the variation in use, then would using raw codes be a workaround? Thanks, -Tom |
|
From: Bengt M. <bu...@be...> - 2012-05-03 19:59:09
|
On 04/27/12 21:51, Tom Metro wrote: > Bengt Martensson wrote: >> Brian J. Murrell wrote: >>> The only thing I found was the gap between duplicate key sends was >>> not quite long enough to defeat the STBs de-bouncing when doing >>> something like: >>> # irsend SEND_ONCE xmpff-1 3 3 >>> >>> For the duplicate key press situation I can do: >>> # irsend SEND_ONCE xmpff-1 3; sleep .5; irsend SEND_ONCE xmpff-1 3 >>> >>> and it works as expected. > > I wrote about the same problem with a Thompson DTA in these threads: > http://sourceforge.net/mailarchive/forum.php?thread_name=4F94A895.6090500%40gmail.com&forum_name=lirc-list > http://sourceforge.net/mailarchive/forum.php?thread_name=4F809A16.9050904%40gmail.com&forum_name=lirc-list > > No one had any suggestions. > > >> The used protocol XMP-1... > > Is that the same as XMP (flags XMP) as used by: > http://lirc.sourceforge.net/remotes/motorola/DTA100 Yes it is. I run it through lirc2xml (Free GPL-software by myself: http://www.harctoolbox.org/lirc2xml.html), and got exactly the same result back XMP-1 (but without "final frame"), device number 62, subdevice 16, command numbers different (in order 1..9,0, 14, 13,12,11,10,130,38,37,81),. Somehow XMP was directly implemented in Lirc around version 0.8.6; the other examples, including the stuff I generated, use raw signals. >> ...with final frame is unfortunately quite >> complicated, containing both a long intro sequence, and long repeat >> sequence, AND a long ending sequence. LIRC cannot (as I recall) do >> anything near this. Be happy that it "almost" works! > > Interesting. Any pointers you can provide for more information on this? > I'd like to understand the problem better, confirm if it applies to my > situation, and see what can be done to fix it. My primary source is http://www.hifi-remote.com/wiki/index.php?title=DecodeIR#XMP As can be seen, the protocol has a long intro sequence, a long and different repeat sequence ("button held down"), and a long, again different, ending sequence. Lirc is, to my knowledge, not capable of even sending independent intro and repeat sequences, even less a complicated ending sequence (at least for raw signals). Possibly the is coded in the XMP protocol implementation though. Need to study the code for this. The real XMP experts are found in the JP1-forum (http://www.hifi-remote.com/forums/), search it for XMP; you will be busy for some time... > > If LIRC doesn't fully implement XMP, or the variation in use, then would > using raw codes be a workaround? No, see above. Possibly the other way around, if the protocol is sufficiently elaborately coded. BTW, the program I used to generate the raw signals is IrMaster 0.1.2, free software by myself, available since yesterday here: http://www.harctoolbox.org/irmaster.html Greetz Bengt |
