Ansio electric fan, not decoded by RMIR

[Barf]

Happy to hear that!

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.

[The Robman]

Works perfectly!!

Thanks for testing it Dave

[mathdon]

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.

[mathdon]

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: Select all

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.

[The Robman]

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?

[Barf]

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: Select all

$ 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.

[MrMoody]

Hi guys,

I've run unto another A/C device that decodes in IRScope as 48-NEC2.

The executor above looks close, but when loaded into the Nevo, decodes as 48-NEC. It shows the right device/subdevice but doesn't activate the A/C.

Is there a slight change that could be made to the executor? I'd be happy to upload the captures or whatever else.

Thanks!

[The Robman]

Hi guys,

I've run unto another A/C device that decodes in IRScope as 48-NEC2.

The executor above looks close, but when loaded into the Nevo, decodes as 48-NEC. It shows the right device/subdevice but doesn't activate the A/C.

Is there a slight change that could be made to the executor? I'd be happy to upload the captures or whatever else.

Thanks!

If you have captured learns that work, then we'd absolutely need to see your RMIR file in order to do anything.

[MrMoody]

http://www.hifi-remote.com/forums/dload ... e_id=26918

The 1 key has the only toggle, I'm hoping to find others.
The 2 key is power off, but likely includes multiple settings as is common on AC units.

[The Robman]

Does this AC only have 2 buttons? And no brand or model number?

[MrMoody]

The remote keeps track of status of temperature, fan, mode etc. except energy save which is learned on the 1 key and seems consistent.

There is another key that sends a consistent code, display. I have learned on 3 and updated the upload. Power off (2) also looks consistent.

Pressing any of the other buttons adjusts one setting and sends them all. This is not unusual with some AC models with temp display on the remote.

The other buttons' code sent is different every time depending on what's shown on the remote. In fact, it's possible to send an identical code by pressing a different button if it ends in the same state. But I can learn some if you like. Without major design changes, this can't work in our remotes except as single-state learns, i.e. 74F-High-Cool. OK for a few favorites but not what I want.

My faint hope is that because there are 3 single-function codes, that I can find others. I have had success with using an alternate protocol to control one other unit (Soleus) that was like this. I suppose I could randomly try NEC or other common protocols with multiple device codes and hope I get lucky.

I don't want to clutter up this site with search hits for the model if it can't work. There are no upgrades here for the brand now.

[The Robman]

I am very familiar with the general format of AC signals, having previously decoded lots of them. The reason I want the brand and model is because I might well have done this very AC before, so no point in doing it again.

The reason I want a sample of more than just 2 signals is because when I decode a batch of signals, it's as much work to do 200 as it is to do 2, but if the samples are only supplied 2 at a time, then the amount of work for me increases exponentially and I'm not prepared to do that.

Bottom line, if I don't have the complete information at the start, I'm not going to bother looking into this any deeper.

[MrMoody]

OK, the unit is a Midea MAW08.

I have replaced the rmir file with one with learns of all keys.

[The Robman]

Here are those learned signals in binary format:

101100100100110100011111111000000100010010111011 Down
101100100100110100011111111000001100010000111011 Up
101110010100011011110101000010100000100111110110 3
101100100100110101111011100001001110000000011111 2
101110010100011011110101000010100110100110010110 1
101100100100110100011111111000000100010010111011 MODE
101110010100011011110101000010100000010011111011 SWING
101100100100110100011111111000000100010010111011 C /F
101100100100110110011111011000000100000010111111 FAN
101100100100110110111111010000000100000010111111 SLEEP

This is similar to the NEC2 format, except that there's 48 bits of data. The whole signal repeats with +4400 -4400 as the lead-in and +550 -4950 as the lead-out.

What are your goals here? You already know that each signal carries all the settings, which makes it not very useful for a JP1 upgrade. There's quite a bit of work involved in developing this to a JP1 level, for you as well as me. For starters, you would need to do a series of learns where only 1 thing changes, and capture each possible level of the thing that's changing, like all of the temps, all of the timer settings, all of the swing settings, etc, etc. Then I'd have to examine each of the learns to see what changed. Then I'd have to develop an executor to replicate the signal, then I'd have to create a protocols.ini entry so you can program each setting, like I did for the Keeprite A/C. So, that's a lot of work.