JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

IrpTransmogrifier: new program/library for IRP protocols
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Software
View previous topic :: View next topic  
Author Message
Barf
Expert


Joined: 24 Oct 2008
Posts: 973

PostPosted: Thu Sep 12, 2019 1:50 am    Post subject: Reply with quote

No problem; you made me find a nasty bug in the development version, that I would not have found (so quickly) otherwise. Cool

Quote:

Is there a way that the command line can also be made to use this file?

It is the --configfile option. I will check in new versions of irptransmogrifier.bat and irptransmogrifier.sh, hope that is OK.

In the longer time span I plan to merge you changes. In the short time span, using separate versions is likely better. I would suggest that you update the version "number" of if (it is the version attribute of the top level element) to anything unique, for example with a suffix -rm or such. That version number is (at least presently) only used by humans.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3250
Location: Cambridge, UK

PostPosted: Fri Sep 13, 2019 7:35 am    Post subject: Reply with quote

Barf, I have found that there are problems caused by changing the default frequency tolerance to 1000 to handle the Pioneer issue. Although it is OK for my test file 1, most of the signals in test file 2 give no decode.

I have found an alternative fix and want to run it past you. I looked at DecodeIR and see that it distinguishes Pioneer by a frequency in the range 39700 to 41000. I have mimicked this (fairly closely) in IrpDatabase by changing the Pioneer frequency from 40k to 40.3k, setting its frequency tolerance to 700 and as prefer over NEC2. I've done the same to Pioneer-Mix and have also commented out all the "prefer over Pioneer" elements in the various NEC protocols.

This works. My test Pioneer signal decodes as Pioneer and the test file 2 signals decode as expected. Is this a reasonable fix?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 973

PostPosted: Fri Sep 13, 2019 8:47 am    Post subject: Reply with quote

I do not think that 1000 is a good default. Users measured signals tend to be pretty imprecise. Many live in a 38k world (Lirc mostly, IRremote,...).

Please consider also to reduce the frequency tolerance in the NEC protocols.

I do not like the idea of changing a known, correct value to a value that is known to be incorrect to achieve something else. (This is also used for rendering.) Too much like changing the value of pi... As a last resort, we can introduce a lower (and a higher) frequency tolerance, but only if it is really important.

Having the Pioneer protocols prefer-over-ed the NECs is sensible, since it is (sort-of) more specialized.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19070
Location: Chicago, IL

PostPosted: Fri Sep 13, 2019 9:44 am    Post subject: Reply with quote

When trying to differentiate between Pioneer and NEC2, you could consider that Pioneer only uses the following device codes: 162, 163, 164, 165, 168, 170 and 175 (and the sub-device is always the complement of the device).

Checking the JP1 upgrades, I found one file that uses NEC1 with device code 165, and I found a few UEI setup codes that uses some of those setup codes, but again with NEC1, not NEC2.

VCR/0758 = 163
VCR/1226 = 165
TV/0090 = 170
VCR/0225 = 170

I'm not suggesting that you add any hard rules here, but when a tie-breaker is needed, this might help.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3250
Location: Cambridge, UK

PostPosted: Fri Sep 13, 2019 9:55 am    Post subject: Reply with quote

Barf wrote:
I do not like the idea of changing a known, correct value to a value that is known to be incorrect to achieve something else. (This is also used for rendering.) Too much like changing the value of pi... As a last resort, we can introduce a lower (and a higher) frequency tolerance, but only if it is really important.

I agree with you that I do not like changing the correct value, but I would like to set the same frequency limits as DecodeIR. DecodeIR has been used for a long time so its decodes have had a pretty good testing. IrpTransmogrifier has probably never been used yet to decode a genuinely learned Pioneer signal, as opposed to one created by IrpTransmogrifier itself. So I would feel more confident about the ability of IrpTransmogrifier to decode real learned Pioneer signals if it mimicked the frequency discrimination of DecodeIR.

So what I am saying is that I really would like to have separate tolerances for the lower and upper limits of the frequency range and yes, to me it is really important.
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 973

PostPosted: Fri Sep 13, 2019 10:37 am    Post subject: Reply with quote

@Graham:
Ok, I accept your argument. See issue. Planned for 1.2.0, not 1.1.1 (which will be out next few days).

@Rob:
Quote:

... the sub-device is always the complement of the device


This can be taken into account by changing the IRP from {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)*[D:0..255,S:0..255=255-D,F:0..255] to
{40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)*{S=255-D}[D:0..255,F:0..255].

Quote:
you could consider that Pioneer only uses the following device codes: 162, 163, 164, 165, 168, 170 and 175

Cannot do exactly that (recall, in IrpTransmogrifier everything decision is governed by the configuration file, no decisions in Java code permitted), but what can be done is (combining with previous) {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,^108m)*{S=255-D}[D:162..175,F:0..255]. Would this be desirable?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19070
Location: Chicago, IL

PostPosted: Fri Sep 13, 2019 3:43 pm    Post subject: Reply with quote

Why use D:8,S:8{S=255-D}, isn't this normally notated as D:8,~D:8 ?

I only pointed out the sub-device part (or lack of a sub-device) to show that Pioneer needn't clash with NEC signals which have a sub-device (ie, one that isn't ~D).

Pioneer doesn't use all the device codes in the range 162..175, some of the other codes are used for NEC signals. But none the less, if this would help steer the program in the right direction, maybe it would help, not sure.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 973

PostPosted: Sat Sep 14, 2019 3:59 am    Post subject: Reply with quote

Thinking about it, I really dislike restricting the domain of D like [D:162..175,F:0..255]. How about instead having a predicate in prefer-over, that specifies that the prefer-over should only take effect if the predicate is true, like
Code:

<irp:parameter name="prefer-over">D==162 || D==163 || D==164 || D== 165 || D==168 || D==170 || D==175 ; NEC2</irp:parameter>

(meaning that a decode as Pioneer should be preferred over NEC2 if the D is as described. Comments?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3250
Location: Cambridge, UK

PostPosted: Sat Sep 14, 2019 9:08 am    Post subject: Reply with quote

This might help for learns where the frequency is not well learned. I presume this is new syntax and it would give flexibility that may be useful again in future. So on the whole I would support it. I too don't like restricting the domain of D.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19070
Location: Chicago, IL

PostPosted: Sat Sep 14, 2019 9:51 am    Post subject: Reply with quote

I agree, I don't like restricting D, but as a "preferred" tie-breaker I think it's good.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3250
Location: Cambridge, UK

PostPosted: Sat Sep 14, 2019 12:43 pm    Post subject: Reply with quote

Barf wrote:
mathdon wrote:
This is just a comment made as I am working through IrpProtocols.xml. You have a protocol called Ortek whose IRP shows it to be NEC-like. Protocols.ini has an executor called Ortek (Official) that sends signals that are nothing like NEC. They are instead similar to OrtekMCE, both having an IRP that begins roughly
Code:
{39.0k,490}<-1,1|1,-1>(4,-1,

with the values in braces differing only slightly between Ortek (Official) and OrtekMCE. Where did your Ortek IRP come from? Could it possibly be Onkyo, which protocols.ini says is NEC-like but for which I have no further details?

As written in the documentation string, that protocol comes from this thread. The IRP form is the one given in 3FG's post from Dec 06, 2013. I have no personal experience with it, nor preferences. I will be happy to accept any sensible changes.

I've only just got round to looking up 3FG's post and I think you have misread it. It says that we used to use PID=01ED for OrtekMCE but that PID is now used by UEI for a completely different protocol, and the IRP you have given as Ortek is the one 3FG gives for that different protocol. It appears we have not identified what that protocol is, so I suggest you delete your Ortek entry as whatever it is, it isn't Ortek.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 19070
Location: Chicago, IL

PostPosted: Sat Sep 14, 2019 1:00 pm    Post subject: Reply with quote

The official Ortek PID is PID=021B
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 3250
Location: Cambridge, UK

PostPosted: Sat Sep 14, 2019 1:08 pm    Post subject: Reply with quote

Barf, in the context of DirecTV, you wrote
Quote:
Parameterizing the leadout is "in principle" easy, but in practice a hairy thing: The capturing device only detects how long no activity has been registered, not how long the leadout is supposed to be. Users always tend to complain like "why does this signal not decode as xxx". For these reasons, IrpTransmogrifier considers all trailing durations > minLeadout (which is a user settable parameter) to be acceptable as leadout.

If I am reading your source code correctly, the default minimum leadout is 20ms. I see from protocols.ini that the two values used by DirecTV are 9ms and 30ms, so with your default, the longer one would be decoded and the shorter one would not. Is the default minimum leadout something like the default frequency tolerance that can be set globally but overridden by an XML parameter in the protocol entry? If so, that could be used to distinguish the two cases, with the protocol with the shorter leadout being set as prefer-over the longer one. Is this possible?
_________________
Graham
Back to top
View user's profile Send private message
Barf
Expert


Joined: 24 Oct 2008
Posts: 973

PostPosted: Sun Sep 15, 2019 1:33 pm    Post subject: Reply with quote

IrpTransmogrifier Version 1.1.1 has been released!
Code:

Release Notes for IrpTransmogrifier 1.1.1.

The notation #n refers to issues number n at
https://github.com/bengtmartensson/IrpTransmogrifier/issues

===============================================================================
2019-09-15: Version 1.1.1

Open issue: Protocol G.I.4DTV partially broken, see #126.

* --ignoreLeadingGarbage now forces IrSequence decoding.
* Improved logging of prefer-over removal of decodes (loglevel FINE).
* Bugfix: User parameters sometimes did not take effect (after #121). #131.
* IrpProtocols.xml: Prefer NEC2 over NEC, and prefer NEC1 over NEC1-rnc.
* For decoding of IrSignals, remove prefer-overs transitively. #130.
* Fixed definition of F12. Resolves #129.
* New render option --decode.
* Handle XHTML in element irp:documentation sensibly. Resolves #125.
* Allow XML in irp:parameter element. Resolves #124.
* Refusal to render decode-only protocols implemented. Resolves #123.
* New decode option --ignoreLeadingGarbage. #122.
* New decode option --override. #121.
* New common option --blacklist. #120.
* Refactoring some decoding stuff. Dramatic speedup on --recursive.


(Graham & Rob: I will answer your issues shortly.)
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 973

PostPosted: Sun Sep 15, 2019 2:35 pm    Post subject: Reply with quote

Predicates in prefer-overs, hopefully implemented in 1.2.0.

Quote:
I've only just got round to looking up 3FG's post and I think you have misread it. It says that we used to use PID=01ED for OrtekMCE but that PID is now used by UEI for a completely different protocol, and the IRP you have given as Ortek is the one 3FG gives for that different protocol. It appears we have not identified what that protocol is, so I suggest you delete your Ortek entry as whatever it is, it isn't Ortek.

OK, so I am open to any suggestion what to call it. "NotOrtek"?

mathdon wrote:
Barf, in the context of DirecTV, you wrote
Quote:
Parameterizing the leadout is "in principle" easy, but in practice a hairy thing: The capturing device only detects how long no activity has been registered, not how long the leadout is supposed to be. Users always tend to complain like "why does this signal not decode as xxx". For these reasons, IrpTransmogrifier considers all trailing durations > minLeadout (which is a user settable parameter) to be acceptable as leadout.

If I am reading your source code correctly, the default minimum leadout is 20ms. I see from protocols.ini that the two values used by DirecTV are 9ms and 30ms, so with your default, the longer one would be decoded and the shorter one would not. Is the default minimum leadout something like the default frequency tolerance that can be set globally but overridden by an XML parameter in the protocol entry?

yes.

Quote:
If so, that could be used to distinguish the two cases, with the protocol with the shorter leadout being set as prefer-over the longer one. Is this possible?

(You probably mean the other way around, since matching the longer implies matching the shorter.) In principle do-able, but I doubt that it will work "in practice"; the only way to really determine the intended lead-out it to send the signal immediately followed by something else.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Software All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 3 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central