Decoding Maverick XR-50

[Luca7993]

Hi,

I'm working on decoding signals from the Maverick XR-50 BBQ Thermometer, and I'd appreciate some help.

I capture the signal using these parameters:
-f 868000000 -g 40 -S

Here is the configuration I'm using in my decoder:
r_device const maverick_xr50 = { .name = "Maverick XR-50 BBQ Sensor", // Nome del nuovo modello .modulation = FSK_PULSE_PCM, .short_width = 107, .long_width = 107, .reset_limit = 109568, .decode_fn = &maverick_xr50_callback, // Collegamento alla nuova funzione di decodifica .fields = output_fields, };

I’ve written a decoder function, and it usually works (though I still need to fine-tune the low/high temperature conversion — that's not the issue right now).

I’d like to ask:

• Am I on the right track? I have a solid background in programming, but I’m still learning about RF and modulation.
• What is the purpose of the digest function in this context?
• Is there a checksum in each message that I should validate?

I’ve attached:
Some .cu8 sample files
My decoder code

All files decode correctly, except for old18.cu8. I’m not sure why that one fails. When I load it in triq.org/pdv, it auto-detects:

Guessing modulation: Pulse Code Modulation (Not Return to Zero)
modulation: PCM short: 107300000.0 long: 107300000.0 sync: - gap: - reset: 109875200000.0

Which clearly isn't correct — so I suspect there’s something wrong in how I’m parsing or preprocessing the data.

Any suggestions would be greatly appreciated!

Thanks in advance!

maverick.zip

[zuckschwerdt]

The old18.cu8 doesn't work because you removed the meta-data from the filename. Rename to e.g. old18_868M_1000k.cu8 and it will work.
You usually start with a flex decoder for the timings found (107 µs FSK PCM):
-R 0 -X 'n=Maverick-XR50,m=FSK_PCM,s=107,l=107,r=2200'
Then look at the structure in BitBench. There is a preamble and then d2aa 2dd4as sync word.

Now you can table codes and see what the fields represent. Digest is a checksum.

[ProfBoc75]

Hello @Luca7993

What is the purpose of the digest function in this context?

RF transmit is sensitive to any interference, so you need to validate the overall message by a mechanism to be sure that the data are accurate. And for that, before sending the message, the sensor calculated a checksum or better a CRC, and the value is added to the message and then transmit. The receiver is able to decode the message and to control the data integrity by doing again the checksum or CRC. If the calculated AND the transmitted values are the same, then the message is valid, can be used, if not valid, it needs to wait the next transmit. This is also why sensors could send several times the same message to increase the success of transmit and decoding.

[Luca7993]

Thanks, I'll let you know when I have time to work on it.

[Luca7993]

I'm currently able to read all the data in the message and successfully extract temperature and alarm values (high and low). However, I still haven't figured out how data integrity is ensured — is there a checksum or some kind of CRC?

Here’s what I’ve understood so far, using a message from BitBench (which works when testing with my Maverick and different values):

0806f00041a1f4f00091a410f0005aa1f4f000a506726a00aaaa000000

Hypothesis 1: 1-3-3-3 group format

• 0806: Possibly a session ID?
• f00041a1f4f00091a410f0005aa1f4f000a5067: 40 characters, interpreted as 4 groups of 10 (e.g. filler + 3 temperature values each).
• 26: Possibly a checksum or CRC? It changes with each message.
• a00aaaa000000: Constant across messages.

Hypothesis 2: 3-3-3-1 group format

• 0806f: Possibly the session ID?
• 00041a1f4f00091a410f0005aa1f4f000a50672: Again, 40 characters for temperature values, but the grouping shifts.
• 6: In this case, only 1 hex character remains before the constant tail — maybe still a checksum?
• a00aaaa000000: Again, this part is always the same.

I’m not yet sure which grouping is correct (1-3-3-3 or 3-3-3-1), and how exactly the checksum is computed (if that’s what the changing byte(s) represent).

thank you

[zuckschwerdt]

Usually groups would be 2 or 3 hex characters, i.e. 8 or 12 bit (12 bits is common for a .1 degree resolution temperature value).
Try to table 20-40 distinct codes, preferably with only very slight changes in values, e.g. slowly warming up or cooling down.

[Luca7993]

All temperature values are 3 hex characters (After i convert them in decimali, subtract 500 and divide 10 and i get all correct temperature values)
My problem now Is to understand how to get the checksum to understand if the signal Is completely ok.
Anyway, as soon as i have time i Will give you distinct codes, hoping you help me go understand how is build the checksum

Thank you

[ProfBoc75]

Hi @Luca7993

I can confirm the last byte you identified as a checksum is a nice CRC 8, poly 0x31, init 0x00 and final XOR 0x00

reveng -w 8 -s 0806c33041a1f4d27491a410c2ee5aa1f4d2f0a5067286 0806c32c41a1f4d27991a410c2ee5aa1f4d2f0a5067202 0806c2ef41a1f4d2e091a410c2f25aa1f4d2f6a50672a8 0806f00041a1f4f00091a410f0005aa1f4f000a506726a
width=8  poly=0x31  init=0x00  refin=false  refout=false  xorout=0x00  check=0xa2  residue=0x00  name=(none)

[ProfBoc75]

The end of the message after the CRC8 , ie 0x00aaaa000000, it's trailing bit, could be used by the receiver at rf decoding level to synchronize, but useless with rtl_433, and not part of the decoding.

[ProfBoc75]

@Luca7993

Is it the correct data layout ?

ID? 16h ONE_F 4b ONE_T 12d ONE_H 12d ONE_L 12d TWO_F 4b TOW_T 12d TWO_H 12d TWO_L 12d THREE_F 4b THREE_T 12d THREE_H 12d THREE_L 12d FOUR_F 4b FOUR_T 12d FOUR_H 12d FOUR_L 12d CRC 8h 48x

where:

• Probe number_F = Flags : alarms, up, down, inside range, outside range, Meat mode, BBQ mode ... 16 possible use cases to be confirmed and cross check with your device ? But from your samples :
  0xF = b1111 = No probe, Temp_raw = 0x000
  0xD = b1101 = Temp above Low Temp, inside range
  0xC = b1100 = Temp below Low Temp, outside range --> May be LL.L is displayed on the LCD Receiver ?

• Probe number_T = Actual Temp

• Probe number_H = High Temp value

• Probe number_L = Low Temp value

About the ID, the file with the bad name, the value is 0x3408, other message the value is always 0x0806, you probably change the battery ? The CRC is valid, so the message too.

[Luca7993]

have an Excel file that shows the decoded values, but I need some time to organize and share it (I have a child and now I have to go out 🙂).
I also managed to calculate the CRC correctly.

So far, this is what we have understood:

• 4-digit prefix

• Then 4 groups of 10 characters (one for each probe):

• Each group has:     
  

•   1 character (still unknown purpose)     
  

•   3 characters for the temperature      
  

•   3 characters for the high threshold     
  

•   3 characters for the low threshold
  

After these 40 characters, there are 2 characters for the CRC-8 checksum (as you suggested)

Then the remaining part: a00aaaa000000, which seems to be constant and likely not part of the decoding

I attach the working decoder file, even I have to refine it

maverick_xr50.zip

[ProfBoc75]

@Luca7993 I will check your decoder and create a PR if you want?

[Luca7993]

I think i Need some more time to refine It (for example i still have tò compare the checksum and to write comments and make more testa). After yes, i Will create the pr, thanks Inviato da Outlook per Android<https://aka.ms/AAb9ysg>

…

________________________________ Da: Bruno OCTAU ***@***.***> Inviato: domenica, giugno 8, 2025 1:03:26 PM A: merbanan/rtl_433 ***@***.***> Cc: Luca7993 ***@***.***>; Mention ***@***.***> Oggetto: Re: [merbanan/rtl_433] Decoding Maverick XR-50 (Issue #3287) [https://avatars.githubusercontent.com/u/62882637?s=20&v=4]ProfBoc75 left a comment (merbanan/rtl_433#3287)<#3287 (comment)> @Luca7993<https://github.com/Luca7993> I will check your decoder and create a PR if you want? — Reply to this email directly, view it on GitHub<#3287 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAIDGP4Y2NPNACQ7DB7AYGL3CQJ7ZAVCNFSM6AAAAAB6MN3NH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJTHE2DANZUGE>. You are receiving this because you were mentioned.

[ProfBoc75]

@Luca7993

I reviewed your decoder and updated it to meet our standard, and simplified a lot the code, as we already have built-in features to show message or to get the crc. (look at bit_util into src folder), decoder.h already include all you need for that.

decoder_log or decoder_logf let you show information when using verbose option.
The number 1 after decoder_log(decoder, is one v, you can put 2 for verbose vv, 3 for vvv at the device protocol number.

decoder_log(decoder, 1, ....
rtl_433 -R 278:v   or rtl_433 -vv -R 278, will give you message from decoder_log if = 1

decoder_log(decoder, 2, ....
rtl_433 -R 278:vv   or rtl_433 -vvv -R 278, will give you the message from decoder_log if = 2

Notice that you need one more v into the verbose option rtl_433 -R xxx:v = rtl_433 -vv -R xxx

My version, I let you copy it, and use it to PR. I tested it successfully with your cu8 files.

maverick_xr50.c

/** @file
    Maverick XR-50 BBQ Sensor.

    Copyright (C) 2025 Luca Pinasco

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.
*/

#include "decoder.h"

/**
Maverick XR-50 BBQ Sensor.

Examples:

    555555555555555a5545ba8100de0008343e9e001234821e000b543e9e0014a0ce4d401555400000
    555555555555555a5545ba8100de0008347d1e0008347d1e0008347d1e0008347d02c01555400000
    555555555555555a5545ba86811a5c2d5cc13a5e2d5cc1d85c89743e985b89883e80801555400

align preamble sync word:

    PP PP PP PP PP SS SS SS SS
    .. aa aa aa aa d2 aa 2d d4

Data layout after sync word:

    Byte Position  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 TT TT TT TT TT TT
    Sample        34 08 d2 e1 6a e6 09 d2 f1 6a e6 0e c2 e4 4b a1 f4 c2 dc 4c 41 f4 04 00 aa aa 00 0
    Sample        08 06 f0 00 41 a1 f4 f0 00 91 a4 10 f0 00 5a a1 f4 f0 00 a5 06 72 6a 00 aa aa 00 00 00
    Sample        08 06 f0 00 41 a3 e8 f0 00 41 a3 e8 f0 00 41 a3 e8 f0 00 41 a3 e8 16 00 aa aa 00 00 00
    Sample        08 06 f0 00 41 a1 f4 f0 00 91 a4 10 f0 00 5a a1 f4 f0 00 a5 06 72 6a 00 aa aa 00 00 00 [no probe]
    Layout        II II FT TT HH HL LL FT TT HH HL LL FT TT HH HL LL FT TT HH HL LL CC TT TT TT TT TT TT
                       [Probe 1      ][Probe 2      ][Probe 3      ][Probe 4      ]

- II:{16} Probably ID, 0x0806 or 0x3408 from above samples
- F:{4} Some flags, depends on the presence of probe, if temp below, within or above range
    0xF = No probe, in that case, the TTT = 0x000
    0xD = Temp below low temp value
    0xC = Temp within the range, between low and high temp values set.
    0x? all flags not yet guessed

- TTT:{12} Actual probe Temperature in Celsius, offset 500, scale 10
- HHH:{12} High Temperature set, Celsius, offset 500, scale 10
- LLL:{12} Low Temperature set, Celsius, offset 500, scale 10
- CC :{8}  CRC 8, poly 0x31, init 0x00, final XOR 0x00, from all previous 22 bytes.
*/
static int maverick_xr50_decode(r_device *decoder, bitbuffer_t *bitbuffer)
{
    uint8_t const preamble[] = { 0xd2, 0xaa, 0x2d, 0xd4 };

    uint8_t b[23];

    if (bitbuffer->num_rows > 1) {
        decoder_logf(decoder, 1, __func__, "Too many rows: %d", bitbuffer->num_rows);
        return DECODE_FAIL_SANITY;
    }

    int msg_len = bitbuffer->bits_per_row[0];
    int start_pos = bitbuffer_search(bitbuffer,0, 0, preamble, sizeof(preamble) * 8);

    if (start_pos  >= msg_len ) {
        decoder_log(decoder, 1, __func__, "Sync word not found");
        return DECODE_ABORT_LENGTH;
    }

    if ((msg_len - start_pos ) < 184 ) {
        decoder_logf(decoder, 1, __func__, "Packet too short: %d bits", msg_len);
        return DECODE_ABORT_LENGTH;
    }

    start_pos += sizeof(preamble) * 8;

    // Need 23 bytes, last bit are useless trailing bits
    bitbuffer_extract_bytes(bitbuffer, 0, start_pos, b, 23 * 8);

    if (crc8(b, 23, 0x31, 0x00)) {
        decoder_logf(decoder, 1, __func__, "CRC Error, found: %02x, expected: %02x", b[22], crc8(b, 22, 0x31, 0x00));
        return DECODE_FAIL_MIC;
    }

    decoder_log_bitrow(decoder, 1, __func__, b, 23 * 8, "MSG");

    int id               = b[0] << 8 | b[1];

    int p_1_flags    = (b[2] & 0xf0) >> 4;
    int p_1_temp_raw = ((b[2] & 0x0f) << 8) | b[3];
    int p_1_high_raw = (b[4] << 4) | ((b[5] & 0xf0) >> 4);
    int p_1_low_raw  = ((b[5] & 0x0f) << 8) | b[6];

    int p_2_flags    = (b[7] & 0xf0) >> 4;
    int p_2_temp_raw = ((b[7] & 0x0f) << 8) | b[8];
    int p_2_high_raw = (b[9] << 4) | ((b[10] & 0xf0) >> 4);
    int p_2_low_raw  = ((b[10] & 0x0f) << 8) | b[11];

    int p_3_flags    = (b[12] & 0xf0) >> 4;
    int p_3_temp_raw = ((b[12] & 0x0f) << 8) | b[13];
    int p_3_high_raw = (b[14] << 4) | ((b[15] & 0xf0) >> 4);
    int p_3_low_raw  = ((b[15] & 0x0f) << 8) | b[16];

    int p_4_flags    = (b[17] & 0xf0) >> 4;
    int p_4_temp_raw = ((b[17] & 0x0f) << 8) | b[18];
    int p_4_high_raw = (b[19] << 4) | ((b[20] & 0xf0) >> 4);
    int p_4_low_raw  = ((b[20] & 0x0f) << 8) | b[21];

    float p1_temp     = (p_1_temp_raw - 500) * 0.1f;
    float p1_set_high = (p_1_high_raw - 500) * 0.1f;
    float p1_set_low  = (p_1_low_raw - 500) * 0.1f;

    float p2_temp     = (p_2_temp_raw - 500) * 0.1f;
    float p2_set_high = (p_2_high_raw - 500) * 0.1f;
    float p2_set_low  = (p_2_low_raw - 500) * 0.1f;

    float p3_temp     = (p_3_temp_raw - 500) * 0.1f;
    float p3_set_high = (p_3_high_raw - 500) * 0.1f;
    float p3_set_low  = (p_3_low_raw - 500) * 0.1f;

    float p4_temp     = (p_4_temp_raw - 500) * 0.1f;
    float p4_set_high = (p_4_high_raw - 500) * 0.1f;
    float p4_set_low  = (p_4_low_raw - 500) * 0.1f;

    /* clang-format off */
   data_t *data = data_make(
        "model",                "",                         DATA_STRING, "Maverick-XR50",
        "id",                   "",                         DATA_FORMAT, "%04x",   DATA_INT,  id,
        "probe_1_flags",        "Flags Probe 1",            DATA_FORMAT, "%1x",    DATA_INT,  p_1_flags,
        "temperature_1_C",      "Temperature 1",            DATA_COND, p_1_temp_raw != 0, DATA_FORMAT, "%.1f C", DATA_DOUBLE, p1_temp,
        "temperature_high_1_C", "Temperature 1 alarm high", DATA_FORMAT, "%.1f C", DATA_DOUBLE, p1_set_high,
        "temperature_low_1_C",  "Temperature 1 alarm low",  DATA_FORMAT, "%.1f C", DATA_DOUBLE, p1_set_low,
        "probe_2_flags",        "Flags Probe 2",            DATA_FORMAT, "%1x",    DATA_INT,  p_2_flags,
        "temperature_2_C",      "Temperature 2",            DATA_COND, p_2_temp_raw != 0, DATA_FORMAT, "%.1f C", DATA_DOUBLE, p2_temp,
        "temperature_high_2_C", "Temperature 2 alarm high", DATA_FORMAT, "%.1f C", DATA_DOUBLE, p2_set_high,
        "temperature_low_2_C",  "Temperature 2 alarm low",  DATA_FORMAT, "%.1f C", DATA_DOUBLE, p2_set_low,
        "probe_3_flags",        "Flags Probe 3",            DATA_FORMAT, "%1x",    DATA_INT,  p_3_flags,
        "temperature_3_C",      "Temperature 3",            DATA_COND, p_3_temp_raw != 0, DATA_FORMAT, "%.1f C", DATA_DOUBLE, p3_temp,
        "temperature_high_3_C", "Temperature 3 alarm high", DATA_FORMAT, "%.1f C", DATA_DOUBLE, p3_set_high,
        "temperature_low_3_C",  "Temperature 3 alarm low",  DATA_FORMAT, "%.1f C", DATA_DOUBLE, p3_set_low,
        "probe_4_flags",        "Flags Probe 4",            DATA_FORMAT, "%1x",    DATA_INT,  p_4_flags,
        "temperature_4_C",      "Temperature 4",            DATA_COND, p_4_temp_raw != 0, DATA_FORMAT, "%.1f C", DATA_DOUBLE, p4_temp,
        "temperature_high_4_C", "Temperature 4 alarm high", DATA_FORMAT, "%.1f C", DATA_DOUBLE, p4_set_high,
        "temperature_low_4_C",  "Temperature 4 alarm low",  DATA_FORMAT, "%.1f C", DATA_DOUBLE, p4_set_low,
        "mic",                  "Integrity",                DATA_STRING,  "CRC",
        NULL
    );

    /* clang-format on */

    decoder_output_data(decoder, data);
    return 1;
}

static char const *const output_fields[] = {
    "model",
    "id",
    "probe_1_flags",
    "temperature_1_C",
    "temperature_high_1_C",
    "temperature_low_1_C",
    "probe_2_flags",
    "temperature_2_C",
    "temperature_high_2_C",
    "temperature_low_2_C",
    "probe_3_flags",
    "temperature_3_C",
    "temperature_high_3_C",
    "temperature_low_3_C",
    "probe_4_flags",
    "temperature_4_C",
    "temperature_high_4_C",
    "temperature_low_4_C",
    "mic",
    NULL,
};

r_device const maverick_xr50 = {
    .name        = "Maverick XR-50 BBQ Sensor",  // Nome del nuovo modello
    .modulation  = FSK_PULSE_PCM,
    .short_width = 107,
    .long_width  = 107,
    .reset_limit = 2200,
    .decode_fn   = &maverick_xr50_decode,  // Collegamento alla nuova funzione di decodifica
    .fields      = output_fields,
};

Results:

With verbose message:

rtl_433 -vv -R 278 -y aad2aa2dd40806f00041a1f4f00091a410f0005aa1f4f000a506726a

Replay cu8 file:

rtl_433 g001_868M_1000k.cu8

[Luca7993]

thank you for your help :)

I have only changed high and low values to int (even if are float in the message, on devices are only seen as int)

I create the pull request

[ProfBoc75]

@Luca7993 I understand for your needs, up to you, but for overall usage, keep any temperature value as float even if the source is int, this is a standard to be respected. rtl_433 is used by other programs like HA or Domoticz, where Temperature is expected to be float value.