Reverse the process and generate an rf tx.

[adminy]

I have a bunch of relays I have switches for, but I'd also like to emulate what the switches do. if I get a json from rtl_433, is it possible to get the rf tx code in reverse so I can play it on my hack rf one or flipper zero.

[zuckschwerdt]

Likely you need to analyze the cu8 and copy or reproduce that.
https://triq.org/rtl_433/ANALYZE.html

[adminy]

but say I have a rtl_433 result from a known rtl_433 device, how to reverse that into a cu8 file.

[zuckschwerdt]

You can reassemble data you got from a known device along with the description of the protocol into a cu8 file using https://github.com/triq-org/tx_tools/

You need to write a spec like this https://github.com/triq-org/tx_tools/blob/master/examples/pmv107j.txt
(created from https://github.com/merbanan/rtl_433/blob/master/src/devices/tpms_pmv107j.c using the header comments and the timings at the end)

[adminy]

Hey @zuckschwerdt, just wondering how do I get the code:
{HEX FC} {DMC 79e15a06209f5034b}

I can record a cu8 file but not sure how to convert it to this code.

[zuckschwerdt]

That's the content of the bitbuffer, the raw data you get from rtl_433. E.g.

$ rtl_433 -R 110:v rtl_433_tests/tests/Toyota_TPMS/03/a.cu8

model     : PMV-107J     type      : TPMS          id        : 079e15a0
status    : 24           battery_ok: 1             counter   : 3             failed    : OK            pressure_kPa: 223.200     temperature_C: 24.000
Integrity : CRC

[pulse_slicer_pcm] PMV-107J (Toyota) TPMS
codes     : {144}fcb32b32ab4b2d554d52aad4ccb4aaacb52c

The fc is the raw hex code FC the rest b32b32ab4b2d554d52aad4ccb4aaacb52c is the DMC coding of 79e15a06209f5034b
You can just use the raw code if already have the data DMC encoded, but when generating data that's usually a convenient step.

[adminy]

so I'm getting:

time      : 2024-04-19 17:49:28
model     : Smoke-GS558  id        : 32028
unit      : 29           learn     : 0             Raw Code  : 1fa39d
[pulse_slicer_pwm] Wireless Smoke and Heat Detector GS 558
codes     : {25}9da31f0, {25}b9c5f80, {25}b9c5f80, {15}b9c4

time      : 2024-04-19 17:50:11
model     : Smoke-GS558  id        : 32028
unit      : 29           learn     : 0             Raw Code  : 7fa39d
[pulse_slicer_pwm] Wireless Smoke and Heat Detector GS 558
codes     : {25}9da37f0, {25}b9c5fe0, {25}b9c5fe0, {25}b9c5fe0, {25}b9c5fe0, {6}b8

Given that does it mean my file would look something like this:

[_ (1949us) ]                   # define a long gap
[0 (-40kHz 436us) ]             # define a space symbol as lower frequency
[1 (40kHz 1202us) ]              # define a mark symbol as upper frequency
                                # define the payload
_ _
{HEX b9c5fe0}
_ _ _ _

?

Thanks @zuckschwerdt

[zuckschwerdt]

That's a EV1527 code, common with buttons, doorbells, PIRs and such. A very simple 25 bit OOK code.
Depending on your TX hardware you'll just need to send the OOK file data. Look at the OOK from your cu8 files to see what pulses and gaps you need to send rtl_433 -w OOK:- thefile.cu8 -- rebuilding a whole .cu8 file is only needed if you have a flexible sender like HackRF, Pluto, LimeSDR, …

[adminy]

I have the hackRF
but I'm guessing is what you're saying is I could just send the cu8 OOK data through something like a cc1101 dongle, so OOK is raw signal? No need for processing?

I currently use 2 antenas, 1 for receiving and one for sending. Just wondering would it be possible to share hackrf lets say rtl_433 for receive and rx_tools for send?

[zuckschwerdt]

Look at the .ook files, it's just on and off times. It can be cleaned up to nominal times if needed.

Note that the code you wrote above is for FSK, a OOK code would be like this (adjust the timings as needed):

[~ (10kHz) ]            # define a base frequency
[_ (10ms) ]             # define a long gap (15 clks)
[0 (~330us) (990us) ]   # define a short pulse and long gap (1:3)
[1 (~990us) (330us) ]   # define a long pulse and short gap (3:1)