Undetectable ceiling fan remote from Warmiplanet

[spiriapbergeron]

Bonjour Sebastien, I speak French but for everyone's benefit I will write in English.

I have two ceiling fan remotes here. One Yukihalu (an aftermarket ceiling fan controller from Amazon) and one WarmiPlanet (a remote that comes with the fan).

Using RF433Any, I can see, and control, and do anything I want with the Yukihalu, but RF433Any cannot decode the signals from Warmiplanet.

So I plugged in my Salae Logic 16, to see what is going on, and the only thing that really stands out is the beginning of the sequence.

Both seem to be Tribit, but it's possible the Warmiplanet is following a tribit convention that is similar to what is found here (see the 4th tribit) I am not sure but maybe I suspect it. https://tinkerman.cat/post/decoding-433mhz-rf-data-from-wireless-switches/

In any case, I have attached the captures from both remotes, maybe you can have a look?

I uses Salae Logic 2.4.12 to do the signal captures.

remote_captures.zip

[sebmillet]

Bonjour

could you send the result of rf433snif? It'd be easier to see what the coding looks like. rf433snif is here: https://github.com/sebmillet/rf433snif

Don't know what a 4th bit could mean, never seen it. From all I've seen, a given "OOK"-flavored encoding is either tri-bit (and variations: tri-bit inverted and/or with fixed duration on low or high signal), or, Manchester. Never seen something else, that obviously does not mean it does not exist ;-)

Looking forward to seeing rf433snif record result.

Regards

[spiriapbergeron]

I have attached here the result rfsnif

rfsnif_result.txt

[sebmillet]

Bonjour

your system is using regular TRIBIT encoding. Running your modified (see later in this reponse) sniffed timings as a simulation, I get this result:

-----CODE START----- // [WRITE THE DEVICE NAME HERE] rf.register_Receiver( RFMOD_TRIBIT, // mod 2048, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 304, // lo_short 696, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 272, // lo_last 2048, // sep 49 // nb_bits ); -----CODE END-----

So all this is fine. Good.

BUT...

If sending the original snif timings to the simulator (those you provided), there was no decoding at all - output was simply empty, RF433any was simply not finding any sequence it could identify.

What did NOT work The encoding starting like this (it is the original one): 0,183488 7600, 2508 7272, 1084 684, 320 300, 724 ...

What did NOT work, still 7600, 2508 7272, 1084 684, 320 300, 724 ... (= the first line has been removed)

What did NOT work, still... 7272, 1084 684, 320 300, 724 ... (= the two first lines have been removed)

AND WHAT DID WORK 7272, 2084 684, 320 300, 724 ... (= the two first lines have been removed + first timing "1084" replaced with "2084" + you don't see above, but the timing line 51, "1112" replaced with "2112")

So what does the above mean in the end?

Well, what prevents RF433any from doing its job are two things:

1- The coding start is atypical and one that RF433any does not identify. RF433any can deal with one prefix, that is, after initialization sequence or separator, a first line with "not coding" timings. But your timings show there is a prefix followed by a separator.

2- Even when removing this weird additional prefix, still RF433any did not decode anything, because the separator duration (in your file: line 6 "001 7272, 1084" and line 56 "051 7232, 1112") is made of a high signal of about 1000 us. This is too close to the "long" duration that's between 700 and 750. RF433any 'thinks' the 1084 duration is part of coding, instead of identifying it as a separator.

What's next

• RF433any will never be able to decode such timings.
• I suggest to try RF433recv library and playing around with durations, in particular, the duration of the separator.
• Example to try out: rf.register_Receiver( RFMOD_TRIBIT, // mod 1200, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 300, // lo_short 700, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 272, // lo_last 1200, // sep 49 // nb_bits );

I put above a separator of 1200 versus a long signal duration of 700, so that hopefully the two are not too close and can be successfully handled by rf433recv. You may try lower separator values (like 1000), ...

All in all, beside the fact that the "double prefix + short separator in regards to long duration" makes it a weird timing, I can guarantee you the coding is "Usual TRIBIT", that is, short-then-long opposed to long-then-short. This is 100% certain because of RF433any output when cleaning prefixes.

Hope this helps,

Cdlt

[sebmillet]

Sry I did not mention: actually I also changed the low signal duration in the separator.

You should try the below:

rf.register_Receiver( RFMOD_TRIBIT, // mod 1200, // initseq 0, // lo_prefix 0, // hi_prefix 0, // first_lo_ign 300, // lo_short 700, // lo_long 0, // hi_short (0 => take lo_short) 0, // hi_long (0 => take lo_long) 7000, // lo_last 1200, // sep 49 // nb_bits );

The difference is the lo_last value, that matches your snif.

Reg