rtl_433

rtl_433 copied to clipboard

I have a 915MHz ThermoPro TX2-B. As far as I can tell, it's almost identical to the TX2C, except instead of each repeat ending with 12 bits of 0's it ends with 0xFF8.

Can the current spec be adjusted to accommodate this?

I've attached a zip of the cu8. BitBucket link: http://triq.net/bitbench#c=FE%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%202F%20F8%20&c=68%20AB%20F1%20DD%2020&f=TYPE%3A%204b%20ID%3A%208d%20BATTERY%3A%20b%20BUTTON%3A%20b%20CHANNEL%3A%20~2d%20TEMP%3A%20~12s%20HUM%3A%20~8d%20ZERO%3A%2012h&cw=4 g001_915M_250k.zip

See src/devices/thermopro_tx2c.c. Near the the check for zero, also allow 0xff8. It's not clear if every single data field matches, and if we should somehow put this "c mode" bit into the id. You could then head towards a PR.

Sorry, I may have blurred things. There are multiple thermapro drivers and it would be good to study all of them. Sometimes the way things are is an accident of history rather than a grand plan.

FWIW, it seems like the 0xFF8 ending is due to something unusual in this signal.

This is what the signal looks like:

If we decode using PCM instead of PPM and split on the longer gaps,

rtl_433 -R 0 -X "m=OOK_PCM,n=TPTX2B,s=480,l=480,r=6000,t=10" -r g001_915M_250k.cu8

we get data rows that look like:

{304}8042100840201008402100840210842108040201084201084201080402100821084210841000

For the most part, each logical bit is a pulse symbol followed by either 4 or 8 gap symbols.

But near the end, there's a pulse followed by 5 gap symbols, then 7 pulses each followed by 4 gap symbols, then another pulse followed by 5 gap symbols, and the final pulse followed by a longer gap to signify the end of the row.

The PPM decoder considers these pulses followed by gaps of either 4 or 5 gap symbols in length to be the same, so it's decoding all of those as logical "1" bits and thus the 0xFF8.

We can create a flex decoder that decodes into logical bits and stops after the first occurrence of one of those "100000" symbol patterns using something like this:

rtl_433 -R 0 -X "m=OOK_PCM,n=TPTX2B,s=480,l=480,r=6000,t=10,symbol_zero={9}800,symbol_one={5}800" -r g001_915M_250k.cu8

Data rows now look like: {37}68abf1dd28 with a final {37}68abf1dd20

BitBench

I'm having a difficult time with this device. If I make a capture, rtl_433 -f 915M -S unknown then analyze it rtl_433 -A dev_914.95M_1000k.cu8 and finally use the suggested flex decoder to read the capture, rtl_433 -X 'n=name,m=OOK_PPM,s=1963,l=3830,g=8579,r=10000' -r dev_914.95M_1000k.cu8 , I get data, but if I try to live read the signal with the same flex decoder, I never get anything.

Using -f 915M switches to the minmax discriminator, otherwise classic is used. Perhaps try -Y classic for the live capture.

Using -f 915M switches to the minmax discriminator, otherwise classic is used. Perhaps try -Y classic for the live capture.

That did it!! Thanks!!

I am able to read a tx-2b just fine with rtl_433 -f 914.995M -R 245 -Y classic

calling it fixed. yell if that's wrong.