Help with rtl_433 not extracting data

[ViaRadioGuy]

Hello:

I won't bother you with all the process.

I have the task of extracting the serial number of medical alarm triggers (the label is worn off) basically, like the "I've fallen and I can't get up" meme.

My hardware is "Nooelec NESDR Nano 2+"

I started knowing 0 (I don't know too much now either :lol: ) but after fighting with some spectrum analyzers and RTL_433 I narrowed down the config/attributes and got solid reads of 3 bursts with 51200 hexadecimal characters each.
Turns out not all the serial number is on the radio signal, but enough to make a search on a database to get the full one or almost.
The trigger is MyAmie. Here is the command y use "rtl_433-rtlsdr.exe -f 869.202M -s 250k -v -A".
The result are 3 bursts of 51200 characters each after some shenanigans I get a partial serial number.


Now, my problem is the TX4 model, I have tested variations and values for rtl_433 for two days (different bandwidths, frequencies...) and I can't get a reliable read, sometimes I capture 30k or 20k characters from some triggers, but mostly 2 or none characters is the norm.
With the "MyAmie" model, thanks to the spectrum analyzer, it was clear there was 3 equal bursts.
The TX4 shows 2 short and 2 long "messages" on 2 frequencies (868 and 869, upper signal is from the same trigger).

I am fully lost, I have no idea how to get a proper capture for this trigger.

Why I need "code" instead of the raw signal? I feed that hexadecimal string to python and get a serial number.
At an extreme I suppose python can capture the raw signal and process it, but rtl_433 should be able to do the capture, but getting the "data" with rtl_433 is the easiest way.

Hoping for some help.
Thank you very much.

 

[Mobby1-Kenobby]

Hi ViaRadioGuy

I highly recommend this software program to get the data you require.

Releases · jopohl/urh

Universal Radio Hacker: Investigate Wireless Protocols Like A Boss - jopohl/urh

github.com

Cheers

 

[ViaRadioGuy]

Thank you very much.
Pretty cool program.
I have no idea what I am doing, I am using AI claude to decode the data and to solve the capture problems, I barely understand how any of this things works, for most people here solving this could be almost trivial, in fact I got lucky as hell with the MyAmie triggers, but the TX4 and now the "Pendant" (the new TX4) I am lost, I recorded .complex16s captures and even the AI claude had problems grabbing to the signal to demux it, the IA said: oh, rtl_433 demodulated it correctly... no, the OOK worked by luck, in reality is FSK, it is Manchester, no it isn't Manchester.... Its like the signal is very bad (but it is super clear and evident), the AI said it was very hard to hook the signal to the demux system, always swapping bits mid signal...

Note: I'm taking all captures (the previous from MyAmie too) without the antenna so it can't get any interference, only signals from things a few cm/in next to the dongle are registered in the spectrum analyzer.

The real problem here is capturing the signal, second the demodulation, once that is done I just have to feed data to the IA to "crack"
the code (if it can be cracked), for what I know, this triggers might ID themselves via RF with a different ID (an IP looking one, the base station names them with that so...) than the one used for inventory and printed in the back so all this work may be useless.


I uploaded .complex16s files recorded with URH with 1M Sps and 1M of bandwith to the IA, but they are too big (I think they will consume more tokens).
Is there an "easier" format or config to help in the demux step? just in case URH is recording so much data that the demux becomes harder.
Maybe reducing the bandwidth will avoid harmonics noise or capturing extra emissions on other frequencies??

 

[oaktree_b]

I would go ask on Github, they post requests they and the dev can tell you what they need from a signal to get a decode.

 

[ViaRadioGuy]

Hi, thank everyone so much.
I tried a lot of software configurations and techniques.

The signal seems to be unstable or something weird.
At the end I made recordings of the raw signal with hdsdr and upload them to claude which said it can follow the data and detect the missing bits...

At the end I sent it 10 consecutive signals, from 35 triggers and nothing, there was some structure, but the "data" was not easily decoded, probable rolling code.
I even tried to hook up the trigger via seal terminal and an FT232 board, but the micro-controller was some flavor of ARM of whatever and couldn't do it, besides that, the chances of the micro-controller being lock down are very high.

I flagged this task as probably impossible.


Now I am starting the research on another trigger model, I think I can read and decode it (with the AI, of course).
And a door/window sensor but it uses Zigbee, so I am not too sure about cracking that (have seen a bit
about hacking Zigbee and it's promising) anyway I would need a new SDR (not sure if regular wi-fi will work) and there is a serial header on the PCB...


I have to start a proper research on those.

Thanks.