option priority (commando line vs. rtl433_conf)

[pswiatki]

I hit an oddity when capturing raw data: my devices operate on 868.65 MHz, so I used -f 868M in the commando line. No luck, the filenames created indicated the frequency in use was the one I had in the rtl_433.conf file (433.92 MHz). How is that possible? Shouldn't the commando line options take precedence?

By the way: I noticed a separate file was created for each signal. Do I correctly understand that the algorithm monitors the RF level and only grabs those periods where the level is above a certain threshold? Since I had the -S all option active, I could see every decodable transmission displayed on the console. What about other RF activity that is not decodable in rtl_433. I am interested in LoRa, specifically. Would those packets also be recorded (as raw IQ samples, naturally)?

[zuckschwerdt]

If you have multiple frequencies given (in a .conf file or the command line) then rtl_433 will hop between these. You likely don't want to specify a frequency in the .conf file (and 433.92M is the default anyway).

You are correct about the -S option, it will grab frames with a high RF level. It works for short and "loud" transmissions only.
If you want to record something like LoRA you would need to record some fixed time (to keep file sizes manageable): rtl_433 -w g001_433.92M_250k.cu8 -T 30s

[pswiatki]

Thank you very much, @zuckschwerdt for the answer. Well, if a mix of command line parameters and lines in a .conf file) constitute the list of frequencies, then I understand. It shouldn't splice those items together, though. Needless to say: I had only one frequency in both locations (which just happened to be different) - in this case the application seemed to prefer the one from .conf over the command line.

What you said about the -S option is very interesting. Loud tranmissions, I guess, I get (30+ dB over the noise floor). Does short mean that the buffer for samples of such signal isn't really big, so that, if the level stays high for "too long", then the samples will silently be dropped (and capture cut)?
As far as my specific use case is concerned: I can utilize -T option, but after a set time the application would exit, right? Yes, I could call it from a script, but chances are the transmission would be active at the time between two subsequent calls.
It would be much better to have something for continuous capture in chunks, i.e. it would just dump to a file at each interval but continue capturing to a new file. That was I could have files of manageable size and still be able to stitch together what I am interested in. The problem is I have no idea how often the meter transmits and how long each TX event lasts. Sure, it will probably be no longer than a few seconds, but when it happens and if it is autonomous, or must be triggered by polling from some server on the LoRa network - remains a mystery. I shall try to add such a capture mode to rtl_433 to get what I need.

[zuckschwerdt]

Default hop time is 10 minutes, good chance you didn't ecounter the hop to 868M yet.
Any .conf or command line arguments are read as a single long stream of options, there is no possibility for a preference.

The sample capture mode and esp. the write mode could use improvements. The sample ring buffer is in samp_grab.c
One problem with long transmission could be that after some time the signal is seen as the noise floor.

[pswiatki]

OK, maybe I phrased it incorrectly: if hopping is to occur, then the contents of .conf and command line are merged (consequently creating a list of frequencies in my case). I shall remove frequency from the .conf then.
Interesting remark on noise floor detection. I wonder if a long term trend analysis of the noise floor level could change something here. After all, it is unlikely for the floor to jump up e.g. 30+ dB all of a sudden. But yeah, I get the signal could be weaker and then who knows - maybe not so easy to handle this situation (of a longer transmission).