Add support for TFA Dostmann 14.1504 Radio-controlled grill and meat thermometer (#2288)

[joel-bourquard]

No description provided.

[zuckschwerdt]

That checksum looks accidental. A wide enough CRC can always be produced for just a few bits.
Are you sure it's a CRC? Maybe it's a digest (LFSR)? Can you share the list of captured codes you derived this from?

[joel-bourquard]

That checksum looks accidental. A wide enough CRC can always be produced for just a few bits. Are you sure it's a CRC? Maybe it's a digest (LFSR)? Can you share the list of captured codes you derived this from?

I know, I can tell you that I tried a few exhaustive searches with the 16-bit LFSR functions from util.c (rtl_433), more precisely the lfsr_digest16() function with all possible combinations for "gen" and "key", and applied that to all possible substrings... with no success there. I was very surprised/frustrated too, but maybe I missed something obvious.

Sure, here are all samples along with the tool to compare the computed CRCs against them. You can simply clone this and run "./build.sh":
https://github.com/joel-bourquard/tfa_tpx305_reveng

[zuckschwerdt]

Did you try our revdgst16? It finds gen 8810 key 93ad final xor d17c when you omit the preamble.
0x8810 is the gen used everywhere, which sounds reassuring, the final xor could mean that we picket up some sync that shouldn't be used -- not sure.

[joel-bourquard]

Did you try our revdgst16? It finds gen 8810 key 93ad final xor d17c when you omit the preamble. 0x8810 is the gen used everywhere, which sounds reassuring, the final xor could mean that we picket up some sync that shouldn't be used -- not sure.

Aah awesome, thanks a lot! No I didn't know that tool, works great indeed. The reason my prior brute force attempts didn't work out, was that final XOR.

I've tried a few things but no zero final XOR so far - - so I've updated my PR with the LSFR and the values that you mentioned - which I think are the most suitable so far.

[zuckschwerdt]

If possible I wouldn't use the full preamble but just a tail portion. This will improve reception if the signal isn't immediatly demodulated perfectly, how typical receivers work to "tune-in". That scheme needs a "sync" at the end to known when data starts, could be a single bit, but is usually aligned. So if 5c is hard coded to be matched anyway then you can use a robust preamble of e.g. aaaa5c.

[joel-bourquard]

If possible I wouldn't use the full preamble but just a tail portion. This will improve reception if the signal isn't immediatly demodulated perfectly, how typical receivers work to "tune-in". That scheme needs a "sync" at the end to known when data starts, could be a single bit, but is usually aligned. So if 5c is hard coded to be matched anyway then you can use a robust preamble of e.g. aaaa5c.

Good point thanks, I will do that!

Question about the Probe status: currently I set it to "Connected" / "Disconnected", is this good? Or should I use a different upper/lowercase convention, or an int (0/1) for that?

[zuckschwerdt]

Question about the Probe status: currently I set it to "Connected" / "Disconnected", is this good? Or should I use a different upper/lowercase convention, or an int (0/1) for that?

I would use a 0/1 int for easier transfer into databases (int supports aggregation), like the common battery_ok, so probe_ok. Or perhaps even invert the output and name it probe_fail? We don't have a common scheme for these "event like" data keys.

[joel-bourquard]

Question about the Probe status: currently I set it to "Connected" / "Disconnected", is this good? Or should I use a different upper/lowercase convention, or an int (0/1) for that?

I would use a 0/1 int for easier transfer into databases (int supports aggregation), like the common battery_ok, so probe_ok. Or perhaps even invert the output and name it probe_fail? We don't have a common scheme for these "event like" data keys.

Good point! I think probe_fail is the best option, and pushed the change now!
(user-friendly text is "Probe failed").

[joel-bourquard]

Battery flag implemented yesterday evening and works well. No more changes planned, so if you can consider it for inclusion, it would be great 😉
If any other changes are advised or if I should squash, please let me know...

Edit: Renamed to TFA-14.1504.V2 to perfectly match the manufacturer's model number, and because the older 14.1504 had a completely different protocol.

[joel-bourquard]

Hi @zuckschwerdt,
I've been run-testing the decoder for a few days now, under challenging SNR conditions, and it's working great so far. No other changes planned for me at this point.

What do you think about merging my PR?

I'm also looking forward to getting feedback from other owners of this device, to validate whether all LSFR params are identical or not. If they are not, then I have some ideas on how to address it.

[zuckschwerdt]

Yes, looks good. The "mic" should be "CRC" as it's the same strength.
And "model" should be simpler, e.g. "TFA-141504v2" (only one dash in the middle, no other special chars).

[joel-bourquard]

Yes, looks good. The "mic" should be "CRC" as it's the same strength. And "model" should be simpler, e.g. "TFA-141504v2" (only one dash in the middle, no other special chars).
Hi @zuckschwerdt,
Great, thanks! I've implemented the exact changes that you suggested and squashed my commits. Ready to merge for me 😉

[joel-bourquard]

Hi @zuckschwerdt ,
Great, thanks! I've implemented the exact changes that you suggested and squashed my commits. Ready to merge for me 😉

[joel-bourquard]

Hi @zuckschwerdt,
Do you know when my PR can be merged? Or should I ping someone?
Thanks 😉

[merbanan]

LGTM, but I think we we need docs and config changes also. And then some sample signals.

[merbanan]

@joel-bourquard
Did you upload any signal samples to the test repo ? I can not see any pull request.

https://github.com/merbanan/rtl_433_tests/pulls

[merbanan]

In this commit you can see the needed config and documentation changes.

cd90897

[zuckschwerdt]

Indeed. Run ./maintainer_update.py to refresh docs and the add that commit.

[joel-bourquard]

In this commit you can see the needed config and documentation changes.

cd90897

Should be all done, thanks! => d145440

[joel-bourquard]

@joel-bourquard Did you upload any signal samples to the test repo ? I can not see any pull request.

https://github.com/merbanan/rtl_433_tests/pulls

@merbanan not yet, but I will definitely do it! I'll fork that repo and do a PR.

[joel-bourquard]

Hi @zuckschwerdt , @merbanan ,
All ready on the rtl_433 side, I think :-)

So I have created a PR with documentation+samples on the rtl_433_tests side:
merbanan/rtl_433_tests#445

[joel-bourquard]

Rebased on latest master.

[joel-bourquard]

Hi @zuckschwerdt ,
Rebased on latest master. Would it be possible for you to merge it please? :)

[zuckschwerdt]

Just a few other (~3) merges first.