merbanan / rtl_433

Program to decode radio transmissions from devices on the ISM bands (and other frequencies)
GNU General Public License v2.0
6.16k stars 1.33k forks source link

Request to add EN2053 two-channel BBQ thermometer #1478

Open lychaxo opened 4 years ago

lychaxo commented 4 years ago

This is a generic-brand device (manual gives "bbq@support20h.com") which is probably distributed by a number of vendors. The one I got had this on a sticker on the box:

X0028WROHL Feelle Digital Thermometer US 02 / New / 2020 / Orange

I saw on FCC ID on the transmitter, but based on some googling and poking around the FCC database, I think it's 2APN2-EN2053. If that's correct, then: manufacturer is Fuzhou Esun Electronic Co., registration date 09/28/2018, frequency range 433.92-433.92.

I wasn't able to use -A to decode anything (all the bit rows are zeroes), but it did give me the timings by looking at the width buckets, using master from the 8/20 branch (97a3abd). -a 4 seems to not produce anything useful in master, but in version 20.02 it produced the bit stream, so I used that version (plus a 6kHz wide capture with AM decode from CubicSDR tuned to 433.92MHz, studied in audacity [433.927_2020-08-22_17-33-18_feelle_us_02_x0028wrohl.wav.gz]https://github.com/merbanan/rtl_433/files/5113367/433.927_2020-08-22_17-33-18_feelle_us_02_x0028wrohl.wav.gz) to look at the protocol. It's a PPM, and a typical output is 9 bursts of Y LLSS SSSS SSSS SLSL SLSS LLLL LLSL SLLS SSLL SSLS Y. The S is a short gap, the L is a long gap, and the Y is a longer bit-row-transition gap. Each Y/S/L in the above represents a pulse followed by a delay (the spaces are just to break it up into nibbles and the row-marker pulses). So that's nine repetitions of 40 bits. After each set of nine, it's common for there to be a delay and the whole thing to repeat; this can happen a few times. The transmitter seems to transmit regularly, plus when it detects a change in temperature for either attached probe. If a probe is disconnected, the channel reads as "LLL" on the probe, and it transmits the temperature 4,054 degrees Fahrenheit. Temperatures are transmitted in Fahrenheit (at least for my model, regardless of whether F or C is being displayed; there could be non-US models which transmit in Celsius perhaps?) as 12-bit numbers (so, if you treat it as a signed value, -42 degrees is the probe-disconnected value).

The first two nibbles appear to be a signature (never seen them change, but perhaps there could be a low-battery bit in there somewhere). The next three nibbles are channel 1, MSB first; the next three nibbles are channel 2, MSB first; the last two nibbles are probably some kind of checksum, but I can't decode the pattern at all.... so maybe they're something different.

To use a flex decoder for this: -X 'name=bbq2,modulation=OOK_PPM,short=960,long=1936,reset=7500,gap=3892,tolerance=50,repeats>=5,preamble={8}0xc0,unique'

You can use awk to parse the output if you output using -F json with something like

 /"model" *: *"bbq2"/{
  nf=patsplit($0,a,/"[^"]+" *: *("[^"]*"|[0-9]+)/,s);
  if(!length(a[0])){
    $0=s[0]
  }else{
    $0=""
  };
  for(i=0;i<=nf;++i){
    if(a[i] ~ /^"time"|^"model"|^"count"/){
      $0=$0 a[i] s[i]
    }else if(a[i] ~ /^"data"/){
      hex=gensub(/^"data" *: *"|"$/,"","g",a[i]);
      ch1=strtonum("0x" substr(hex,1,3));
      ch2=strtonum("0x" substr(hex,4,3));
      end="0x" substr(hex,7);
      ch1="\"ch1\" : " ch1;
      ch2="\"ch2\" : " ch2;
      end="\"endbytes\" : \"" end "\"";
      $0 = $0 ch1 ", " ch2 ", " end s[i]
    }else if(i == nf){
      $0=$0 s[i]
    }
  }
}
{
  print
}

Here's a quick table of some data recorded, in case you want to try to figure out the last byte:

ch1 F ch2 F nibbles LLL 84 c0fd605451 LLL 83 c0fd6053d0 LLL 86 c0fd6056d3 LLL 88 c0fd605855 LLL 87 c0fd605754 LLL 86 c0fd6055d2 LLL 89 c0fd605ad7 LLL 90 c0fd6059d6 LLL 72 c0fd6048d5 LLL 70 c0fd604653 LLL 69 c0fd604552 LLL 68 c0fd6044d1 LLL 67 c0fd604350 LLL 57 c0fd603ad7 LLL 56 c0fd603855 LLL 55 c0fd603754 LLL 54 c0fd6036d3 LLL 35 c0fd602350 LLL 37 c0fd602552 LLL 36 c0fd6024d1 LLL LLL c0fd6fd652 38 LLL c0026fd657 37 LLL c0025fd657 36 LLL c0024fd617 35 LLL c0023fd657 84 LLL c0054fd632 83 LLL c0053fd672 91 LLL c005bfd632 89 LLL c0059fd672

(I was only experimenting with one probe, just to keep things simple. Next time I am grilling/barbecueing with this, I'll try to monitor data to ensure it functions the same when both probes are operating. When the battery starts running low, I will try to grab data again as well.)

lychaxo commented 4 years ago

Here's the -S unknown output with the -X flex removed, for testing. This, by the way, is ch2=LLL/disconnected and ch1 reading around 72 to 73 degrees Fahrenheit. (And, yes, I did check -G 4 -- nothing) ch1_around_72-to-73F.tar.gz

zuckschwerdt commented 4 years ago

Great analysis and writeup! Indeed the "checksum" looks strange, esp. in the last rows posted it doesn't "move" enough.

gdt commented 1 year ago

@lychaxo What's the status of this issue and next steps?

lychaxo commented 1 year ago

@gdt I'm not sure on next steps -- I moved to a new house and don't have an SDR setup here (yet). It's probably possible to implement some decoding as per my notes above but I'm not sure how battery/"checksum" stuff factors in, and I don't know when I can investigate further there.

gdt commented 1 year ago

Thanks; marked inactive.