Help, can't capture reliable 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 ) 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 two long "messages" on 2 frequencies (868 and 869).

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.

[jdow]

This group might not be much help for you. It is related to Simon's "SDR-Radio (v3)" software. You seem to be fussing with the rtl433 tool. Merbanan's rtl433 github site would be where I would start in my quest for decoding help from people using the SW. It looks like the "Discussions" tab is still quite active.

When you speak of "characters" 51200 sounds obscenely large unless that is the raw sampling rate data fed to the internal decoder. And 869.202 MHz is "unusual". I presume that's not a second harmonic. I also presume this is regarded as a medical device. In the US that would leave it subject to the HIPAA rules which might require the data to be encrypted. Good luck digging the data out.

{^_^} Joanne

[ViaRadioGuy]

Hi, thank you so much.

Yes it is a "medical device" (telecare), I "decoded" another trigger model before, I couldn't get the full SN, but with a database and some brain power, the full SN can be deduced.

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.

Thank you anyway.