Creating .ook file

[ifuchs]

I don't think is is really a problem with rtl_433 and it may be a bit out of scope so but I thought that perhaps I could tap your vast knowledge on this subject to suggest what the problem is that I am having. I am trying to capture and replay some sensors that operate at 319.5Mhz and 345Mhz. I am simply running rtl_433 with the appropriate frequency setting and -w filename.ook. I am then running a utility (https://github.com/evilpete/flipper_toolbox/blob/main/subghz_ook_to_sub.py) which converts the .ook file to .sub format so that I can "play' it on a Flipper Zero. Rtl_433 is able to decode the sensors that runs at 319.5Mhz and after converting the file to .sub, they work as expected. Rtl_433 is also able to decode the sensors running at 345Mhz but after converting the .ook file to .sub it does not do anything when replayed. The output looks like this: rtl_433 -f 345000000 -w door1.ook rtl_433 version 22.11 branch at 202211191645 inputs file rtl_tcp RTL-SDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "rtl_433.conf"... Trying conf file at "/Users/ihf/.config/rtl_433/rtl_433.conf"... Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"... Trying conf file at "/etc/rtl_433/rtl_433.conf"... Registered 191 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ] Found Rafael Micro R820T tuner Exact sample rate is: 250000.000414 Hz [R82XX] PLL not locked! Sample rate set to 250000 S/s. Tuner gain set to Auto. Tuned to 345.000MHz. baseband_demod_FM: low pass filter for 250000 Hz at cutoff 25000 Hz, 40.0 us

---

time : 2023-05-17 18:54:51 model : Honeywell-Security id : 2af7d channel : 10 event : a8 state : open contact_open: 1 reed_open : 1 alarm : 0 tamper : 0 Battery : 0 heartbeat : 0 Integrity : CRC

---

(repeated 12 times) The question is why the 2 sensors running at 319.5 replay and the 2 sensors running at 345Mhx don't. Do you have any suggestions or thoughts on what the problem might be or any further tests I could perform to diagnose this?

[ProfBoc75]

Hi @ifuchs

Did you try to record with another extension like cu8 ? Then you will need the good converter to sub. Because your 2 other sensors at 345 MHz may be not using ook signal but fsk ? We can see the modulation coding into the device file , what are the 2 sensors ? Notice also that if they are fsk you may need to refine the exact frequency.

[ifuchs]

@ProfBoc75 thanks. I recorded in .ook because I saw the converter to .sub. Is there a similar utility to convert from .CU8 files? All I know about the sensor is posted above. It may very well use FSK. The flipper and GQRX suggest that the frequency is almost precisely 345 MHz.

[zuckschwerdt]

The path cu8->(rtl_433)->ook->sub is correct. What he meant is: we can not be sure that the ook you have represents the cu8 perfectly. It will be good enough to read data but perhaps not good enough to send data. You need to inspect the cu8 ( https://triq.org/pdv/ ) and also view the header of the ook (just open the file as text).

[ProfBoc75]

I may found the reason, may be related to Flipper Zero itself. Even if you can receive at this frequency, you are not allow to send at 345 MHz.

From Flipper Zero web site at Tech Specs section : Sub-1 GHz module Chip: TI CC1101 TX Power: 0 dBm max Frequency bands (depends on your region): ● 315 MHz ● 433 MHz ● 868 MHz ● 915 MHz

You have the rf range table here where the 345 Mhz is not listed, not part of any range. And yes, 319.5 Mhz is allowed, and could explain why it works at this frequency.

[ifuchs]

I run the Roguemaster firmware which I thought was able to xmit at that freq.. Furthermore, it works at 319.5Mhz and there is no error message indicating that it has any problem transmitting at 345 Mhz.

[ifuchs]

Sorry, I reread your post and looked the table and it appears that 345Mhz may be outside its hw capability, regardless of firmware. I do find it odd that it doesn't complain and appears to be sending. I will check with RTL.

[ifuchs]

I just tested by transmitting at 345Mhz from the F0 and receiving on the RTL. It worked though the signals "sound" rather different. So the problem would not appear to be hardware related. Back to the drawing board...

[ifuchs]

The main page for the F0, says "Flipper Zero can receive and transmit radio frequencies in the range of 300-928 MHz with its built-in module, which can read, save, and emulate remote controls." I believe it is using the CC1101 chip.

[ProfBoc75]

Ok, so back to what is the kind of signal, ook or fsk and the coding ?

If it's regarding the "Honeywell-Security" , its modulation and coding is OOK_PULSE_MANCHESTER_ZEROBIT

2 things to be considered : the modulation OOK and the coding PULSE MANCHESTER ZEROBIT : OOK is supported, Manchester is supported , but I can't find if the PMZ coding is supported by CC1101 chip in the datasheet. or by the F0 firmware.

Something went wrong during your conversion (the python program) or do not supported PMZ ? Because Flipper Zero is not a software-defined radio, you need to configure the right modulation, this means that the information must be correctly encoded into the sub file generated by the script. Are you able to edit the sub file and see if any readable / text information with the modulation and pulse coding information ?

[ifuchs]

The header on the .sub file is: Filetype: Flipper SubGhz RAW File Version: 1

generated with ook_to_sub.py

Frequency: 345000000 Preset: FuriHalSubGhzPresetOok650Async Protocol: RAW If there is any other file or info that would help solve this, just let me know. I can get .cu8 or .ook

[ifuchs]

I don't think it helps, but the head of the .ook file looks like this. (I can resample with the RTL with different settings if that seems like it might help. ;pulse data ;version 1 ;timescale 1us ;created 2023-05-17 13:40:56-0400 ;received 2023-05-17 13:40:57-0400 ;ook 10 pulses ;freq1 344988064 ;centerfreq 345000000 Hz ;samplerate 250000 Hz ;sampledepth 8 bits ;range 42.1 dB ;rssi -12.1 dB ;snr 21.0 dB ;noise -33.1 dB 792 136 472 52 76 60 340 68 732 48 64 60 196 56 264 48 220 44 0 32 ;end ;received 2023-05-17 13:40:57-0400 ;ook 5 pulses ;freq1 344995424 ;centerfreq 345000000 Hz ;samplerate 250000 Hz ;sampledepth 8 bits ;range 42.1 dB ;rssi -12.1 dB ;snr 15.2 dB ;noise -27.4 dB

[ProfBoc75]

Hi @ifuchs ,

FuriHalSubGhzPresetOok650Async = ook at 650 KHz and then the 0 & 1 pulse duration as RAW data.

From rtl_433 support, try several options from rtl_433, like change the sample rate, since by default it's 250K :

rtl_433 -s 1024k -f 345M  ...

and see if you have any improvement, try to play also with -Y option ( minmax, autolevel, classic ... )

rtl_433 -s 1024k -Y minmax -f 345M ... 

[ifuchs]

@ProfBoc75 Thanks. I tried as you suggested and ran this: rtl_433 -s 1024k -Y minmax -f 345M -w grage3.ook I then used the ook to sub utility, transferred the .sub to the F0 and transmitted it with no effect. I wasn't sure if it mattered that I did the capture as .ook vs. .cu8. Anyway, I am open to further suggestions.

[ProfBoc75]

@ProfBoc75 Thanks. I tried as you suggested and ran this: rtl_433 -s 1024k -Y minmax -f 345M -w grage3.ook I then used the ook to sub utility, transferred the .sub to the F0 and transmitted it with no effect. I wasn't sure if it mattered that I did the capture as .ook vs. .cu8. Anyway, I am open to further suggestions.

you can use .cu8 extension, but you have to convert it to ook, like this :

rtl_433 -s 1024k -Y minmax -f 345M -w grage3_345M_1024k.cu8
rtl_433 -s 1024k -r grage3_345M_1024k.cu8 -w grage3_345M_1024k.ook

Try also other options, like this :

rtl_433 -s 1024k -Y autolevel -f 345M -w grage3_345M_1024k.cu8

It's also a good idea to keep the frequency and the sample rate into the file name, this help rtl_433 too.

[ifuchs]

@ProfBoc75 Here is my latest attempt: ` rtl_433 -s 1024k -Y autolevel -f 345M -w grage4_345M_1024k.cu8 rtl_433 version 22.11 branch at 202211191645 inputs file rtl_tcp RTL-SDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "rtl_433.conf"... Trying conf file at "/Users//.config/rtl_433/rtl_433.conf"... Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"... Trying conf file at "/etc/rtl_433/rtl_433.conf"... Registered 191 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ] Found Rafael Micro R820T tuner [R82XX] PLL not locked! Sample rate set to 1024000 S/s. Tuner gain set to Auto. Tuned to 345.000MHz. baseband_demod_FM: low pass filter for 1024000 Hz at cutoff 102400 Hz, 9.8 us

---

time : 2023-05-19 13:29:59 model : Honeywell-Security id : 8f347 channel : 10 event : a0 state : open contact_open: 1 reed_open : 1 alarm : 0 tamper : 0 Battery : 1 heartbeat : 0 Integrity : CRC

[Repeated 10x] ^CSignal caught, exiting!

(base) sam-MBP-13:~ $ rtl_433 -s 1024k -r grage4_345M_1024k.cu8 -w grage4_345M_1024k.ook rtl_433 version 22.11 branch at 202211191645 inputs file rtl_tcp RTL-SDR Use -h for usage help and see https://triq.org/ for documentation. Trying conf file at "rtl_433.conf"... Trying conf file at "/Users//.config/rtl_433/rtl_433.conf"... Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"... Trying conf file at "/etc/rtl_433/rtl_433.conf"... Registered 191 out of 223 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217-223 ] Test mode active. Reading samples from file: grage4_345M_1024k.cu8 baseband_demod_FM: low pass filter for 1024000 Hz at cutoff 102400 Hz, 9.8 us

---

time : @1.459960s model : Honeywell-Security id : 8f347 channel : 10 event : a0 state : open contact_open: 1 reed_open : 1 alarm : 0 tamper : 0 Battery : 1 heartbeat : 0 Integrity : CRC

---

[Repeated 10x]

(base) sam-MBP-13:~ $ subghz_ook_to_sub.py grage4_345M_1024k.ook Total packets in file 12

This .sub was transferred to the Flipper and played to no effect.

Thanks for your help and your patience.

`

[ifuchs]

Anyone have any further suggestions to getting this replay to work?

[gdt]

This seems like "not a bug report". Feel free to open a discussion.