 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
 Posted: Mon Apr 01, 2024 3:56 pm Post subject: |
 |
|
Happy to hear that!
| davecs wrote: | | If I wanted to do this with one of my regular RMDU files, i.e., not learned signals, could I? How would I go about it if so? |
Step #2: In RMDU, select File -> Export as Girr or IrScope file.(There is also File -> Export remote as Girr file in RMIR, but it is more logical in the device upgrade tool.)
Step #3: You should probably press Import all/param instead of Import all/raw, although the latter will probably work too. The rest is the same. |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Mon Apr 01, 2024 6:35 pm Post subject: Re: Ansio electric fan |
|
|
| davecs wrote: | | Works perfectly!! |
Thanks for testing it Dave
_________________
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 |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Tue Apr 02, 2024 7:21 am Post subject: |
|
|
| Barf wrote: | | There is a user settable parameter, min-leadout, in IrpTransmogrifier; setting this makes the decoding succeed: ... Graham: this parameter can be set with DecoderParameters.setMinimumLeadout(Double). What do you think? Changing globally or making user settable (like frequencyTolerance)? |
Like frequency tolerance. I will include this in the next RMIR release. I have said elsewhere that I need to turn development build v3.0.14 into a general release, so I will include this and make it v3.0.15.
_________________
Graham |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Wed Apr 03, 2024 7:40 am Post subject: |
|
|
| Barf wrote: | Turn out that the signals have very short leadout (that is the last duration, a gap) of 1708 micro seconds, as opposed to the nominal 48-nec leadout of around 50 milliseconds (^ 108m to be exact). Extending this -- and it decodes nicely. There is a user settable parameter, min-leadout, in IrpTransmogrifier; setting this makes the decoding succeed:
| Code: | irptransmogrifier --min-leadout 1700 decode --girrinput ansio-fan-raw.girr
1: 48-NEC: {D=1,F=7,E=7}, beg=0, end=99
2: 48-NEC: {D=1,F=3,E=3}, beg=0, end=99
3: 48-NEC: {D=1,F=11,E=11}, beg=0, end=99
4: 48-NEC: {D=1,F=15,E=15}, beg=0, end=99 |
|
I have implemented the minimum leadout parameter (but not posted it to the SVN), as I said above, and am now totally confused. With the minimum set to 1700us I get multiple decodes. Here is one signal:
48-NEC Dev=1, SubDev=254, OBC=7, E=7
NEC Dev=1, SubDev=254, OBC=7
When I investigated why I get both decodes, I saw that the leadout is the same as a 1-bit OFF value, 1708. Both decodes are therefore valid as the E-value of 48-NEC, lsb format, starts with a 1 and so can also be interpreted as a leadout, so terminating an incomplete NEC protocol.
I do not know what to make of this. Is the learned signal itself incomplete, with a true leadout missing? That seems the most likely interpretation, with the complete signal being neither 48-NEC1 (or 2) nor NEC1 (or 2)? Is it worth retaining the new minimum leadout parameter, since to me it makes no sense to have a leadout that is the same as a 1-bit OFF? Your views, please, Bengt.
_________________
Graham |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21238
Location: Chicago, IL
|
| Posted: Wed Apr 03, 2024 12:37 pm Post subject: |
|
|
Here are the 4 signals converted to binary (see full Pronto hex here), using "0016 0040" = 1 and "0016 0016" = 0:
1 0000 006E 0032 0000 0156 00AB 10000000 01111111 11100000 00011111 11100000 00011111 0016 0040
2 0000 006E 0032 0000 0156 00AB 10000000 01111111 11000000 00111111 11000000 00111111 0016 0040
3 0000 006E 0032 0000 0156 00AB 10000000 01111111 11010000 00101111 11010000 00101111 0016 0040
4 0000 006E 0032 0000 0156 00AB 10000000 01111111 11110000 00001111 11110000 00001111 0016 0040
The format does appear to be a 48-bit version of NEC where the obc and its comp are repeated, like this: dev, ~dev, obc, ~obc, obc, ~obc. As the posted signals do not repeat it's not possible to say if this would repeat like NEC1 or NEC2.
As the sub-device is equal to 255-device I consider it to not have a sub-device. Reporting such sub-device codes only leads to confusion because people consider dev 1, sub 254 as different to just dev 1, which it isn't.
And if we're going to give this new variant a name, could I request that it be called NEC-48 rather than 48-NEC so that it sorts together with the other NEC variants?
_________________
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 |
|
|
Barf
Expert
Joined: 24 Oct 2008
Posts: 1415
Location: Munich, Germany
|
| Posted: Thu Apr 04, 2024 11:01 am Post subject: |
|
|
Graham, I absolutely agree with you that 1700 as min-leadout is nonsensical, for the reason you are given. The most likely explanation is that the signals are truncated, i.e. incompletely captured. The fact that the signals are exactly 100 durations long is another indication. Does anyone know if there is such a hard limit on learning in the UEIs?
davecs, can you possibly capture with another method, like with IrScrutinizer?
The complete decodes include NEC:
| Code: |
$ irptransmogrifier --min-leadout 1700 decode --all --girrinput ansio-fan-raw.girr
1: 48-NEC: {D=1,F=7,E=7}, beg=0, end=99
JVC: {D=1,F=254}, beg=0, end=35 {UNDECODED. length=64}
JVC_squashed: {D=1,F=254}, beg=0, end=35, reps=1 {UNDECODED. length=64}
NEC: {D=1,F=7}, beg=0, end=67 {UNDECODED. length=32}
NEC-Shirriff-32: {data=2155864095}, beg=0, end=67 {UNDECODED. length=32}
NEC-f16: {D=1,F=7}, beg=0, end=67 {UNDECODED. length=32}
....
|
but the prefer-overs eliminate JVC_squashed, NEC-Shirriff-32 and NEC-f16. Of the three remaining (48-NEC, JVC, NEC), only 48-NEC matches the whole signal ("end=99"), so therefore JVC and NEC are rejected. Why you get two decodes I cannot tell from the top of my head, but have to investigete more thoroughly, if needed. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
