ArchiveOrangemail archive

LIRC mailing list


lirc-list.lists.sourceforge.net
(List home) (Recent threads) (67 other SourceForge lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • Low traffic list: less than 3 messages per day
  • This list contains about 4,090 messages, beginning Aug 2009
  • 15 messages added yesterday
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

convert RMDU file to lirc remote config file?

Ad
Brian J. Murrell 1335160980Mon, 23 Apr 2012 06:03:00 +0000 (UTC)
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.
Bengt Martensson 1335222288Mon, 23 Apr 2012 23:04:48 +0000 (UTC)
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
Brian J. Murrell 1335272305Tue, 24 Apr 2012 12:58:25 +0000 (UTC)
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.
Bengt Martensson 1335516936Fri, 27 Apr 2012 08:55:36 +0000 (UTC)
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
Tom Metro 1335556352Fri, 27 Apr 2012 19:52:32 +0000 (UTC)
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?...
http://sourceforge.net/mailarchive/forum.php?...

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/...
?> ...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
Bengt Martensson 1336075206Thu, 03 May 2012 20:00:06 +0000 (UTC)
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?...
> http://sourceforge.net/mailarchive/forum.php?...
> 
> 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/...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?tit... 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
Home | About | Privacy