Undetecable encoding from alarm system

[themrupwork]

Hi, im trying to detect signal from fishing alarm.

I owned 4 of them + remote, but dog eat remote((( So now im trying to implement it

I have tried to use your lib, to decode raw signal, but no luck, its just keep stuck on do_events while i see trough logic analizator that packets is coming

Here i have attached sniffs made with https://github.com/sebmillet/rf433snif, maybe you can help what is wrong here, i also have tried all other libs, none is working.

Im not pro in rf encoding, i can't identify which one is used here, but i dont think its 3bit

sniff_green.txt sniff_yellow.txt

[themrupwork]

Small update: I have tried RF433Recv with this config:

    rf.register_Receiver(
        RFMOD_MANCHESTER, // mod
        2200,            // initseq
        0,                // lo_prefix
        0,                // hi_prefix
        0,                // first_lo_ign
        160,             // lo_short
        240,             // lo_long
        0,                // hi_short (0 => take lo_short)
        0,                // hi_long  (0 => take lo_long)
        0,             // lo_last
        2200,            // sep
        32,               // nb_bits
        callback_anycode, // callback (optional ; just to show received code)
        0                 // delay between two calls to callback
    );

The encoding seems to be manchester, but i do not understand why its still not working

By the way, in sniff files H and L are swaped by some reason

[themrupwork]

@sebmillet thank you, that you taked over this. If you want i can record signal right from MCU, instead of RF, to get more accurate and less noisy records, just let me know

[sebmillet]

Hello

after looking at the signal timings and code you posted (this is precise feedback that helps a lot, thanks by the way):

• I confirm it is Manchester, no doubt.

• Because it is Manchester, you only have to specify the lo_short duration. All the rest is derived = with Manchester, by definition, hi_short = lo_short, lo_long = 2 x lo_short and hi_long = 2 x hi_short = lo_long) Best is to leave the lo_long value to zero (see my code below). Note that I don't think it is the issue, I mention it FYI.

• I believe the issue in your code is, the number of bits. Doing some simulated snifs (with your timings), RF433any tells me it is Manchester + it says, the code is 33 bits, not 32. This is key, as RF433recv will consider the decoding is successful if and only if the separator duration (in your case: at least 2000 ms) is encountered exactly after the last bit. There is no flexibility, a code must be terminated.

Ultimately, using real signal (= I used a signal emitting device with RF433send, close to a physical receiver ; no simulation), I could successfully decode the signal with the below:

rf.register_Receiver(
    RFMOD_MANCHESTER, // mod
    2000,         // initseq
    0,            // lo_prefix
    0,            // hi_prefix
    0,            // first_lo_ign
    200,          // lo_short
    0,            // lo_long
    0,            // hi_short (0 => take lo_short)
    0,            // hi_long  (0 => take lo_long)
    0,            // lo_last
    2000,         // sep
    33,           // nb_bits
    callback,
    0
);

I double-checked and the signal EMITTER produces a signal close to yours (of course with different timings due to measure errors, but shorts are shorts, longs are longs etc.)

If ever interested, the sender code FYI:

tx_whatever = rfsend_builder(
    RfSendEncoding::MANCHESTER,
    PIN_RFOUT,
    RFSEND_DEFAULT_CONVENTION,
    4,
    nullptr,
    2000,           // initseq
    0,              // lo_prefix
    0,              // hi_prefix
    0,              // first_lo_ign
    200,            // lo_short
    0,              // lo_long
    0,              // hi_short
    0,              // hi_long
    0,              // lo_last
    2000,           // sep
    33              // nb_bits
);

Hope this helps,

Regards, Sébastien Millet

[themrupwork]

@sebmillet all 4 alarms works well.

But when i at the begining tried to sniff it with rf433any, i got 0 results, is that cause of 33 bit length?

By the way, how i can buy you a coffee?

Thank you very very much

[sebmillet]

Hello,

Don't know how to organize a coffee but thanks for the idea ;-)

About RF433any having 0 result: I re-checked, tuning rf433send, and it works when putting the lo_short duration at 300 ms or higher. Below this value, the duration is too short and RF433any cannot catch up.

You might wonder how I could identify signal with RF433any (as written in my first response): I used RF433any in a simulated manner (re-using your timings as input ; NOT using real RF signal), and in that case, RF433any code rapidity doesn't matter, it can decode any signal including those with very small timing values.

By the way it means, I shall bring an improvement to RF433any, where it'd be easy to reuse rf433snif output as RF433any input (Today: it requires dev tools + knowledge). I keep it in mind.

Regards, Sébastien Millet

[themrupwork]

Got it, thank you very much, i will wait for a moment to buy a coffee