Feature Request: Frequency hopping different durations per frequency

[leonwilly]

It would be nice if you could specify how much time to spend on each frequency. If sensor A at 315MHZ broadcast a signal over 3 seconds while sensor B on 433MHZ broadcast a signal in 3 burst over milliseconds. One could spend two seconds on 433MHZ band hop over to 315MHZ for one second and then back.

[zuckschwerdt]

Using hoping you always might loose transmissions. I'd say it's better to stay on each frequency long enough to have a decent chance of capturing at least one transmission. I.e. receive every other transmission with a higher probability opposed to quickly hopping at the risk of truncating a reception and having less than 33% chance (2s:1s) to get a 315 MHz transmission here?

[dgrostoto]

I guess there is a use case behind this request (which might interest me also) : Such a use case could be : receive normal transmissions, let's say at 433Mhz for a quite long period of time then periodicaly go to another frequency for a short period of time for jam detecting and go back to 433Mhz after. However, as zuckschwerdt pointed out, there's always a risk of losing normal transmissions when hoping. Moreover this could lead a white elephant concerning configuring delay between hops.

Thus a better solution could be to have a external way to change frequency, for instance by inputing data to rtl_433 executable. This leaves the power to user when deciding to change frequency, which can be triggered to user goodwill ( future transmissions timings etc...) Pros : no more truncated data thus no bug to resolve here (if so, the user is responsible). no complex configuration and associated coding does not break existing behavior (retro compatibility) may add other live controls when needed Cons : Add an input interface which is not existing yet AFAIK, choose an interface usable with different OSes.

[zuckschwerdt]

Good idea. Maybe the user can even add logic like "hop after successful reception, but always after at most 1 minute" or such. With the refactoring towards an API this will certainly be possible. Refactoring is ongoing and will perhaps take to the end of the year.

[dgrostoto]

In fact, I may need such API before the end of the year. So i may code something (kiss and dry as much as possible ) in the following weeks. I'm not sure how it can interfere with the expected refactoring, Anyway i will propose my work for those interested.

[zuckschwerdt]

We could add the option of using -H multiple times and the time given will be the "stay time" on a frequency. But you'd need to be careful to use the same number of -f as -H. Also we could add a user signal to force a frequency hop. That way e.g. killall -USR1 rtl_433 would hop.

[dgrostoto]

Note It seems there is no SIGUSR1 nor 2 on MS Windows (i got it here https://stackoverflow.com/questions/16429480/what-is-equivalent-to-sigusr1-2-signals-in-windows-using-python ). It would break compatibility accross OSes.

[dgrostoto]

May i suggest widely supported type of communication ? On linux/BSD systems we have system V IPC mechanisms on MS Windows there is nearly ten IPC possibilties ( https://docs.microsoft.com/en-gb/windows/win32/ipc/interprocess-communications ). Amoung those I found 3 in common : sockets (TCP/UDP), RPC, and pipes. Sockets are common use but somewhat overkill for what we need here. RPC not appropiated and complex to use. So i think the best is pipes which is quite simple to use. May i suggest a minimalist input data such as "f [frequency to hop to]" exemple "f 868.9" as input to order rtl_433 to change frequency ?

[zuckschwerdt]

The signal handler on Windows will only handle CTRL-C. This feature would be Linux/MacOS only, like SIGINFO (CTRL-T) for stats.

[zuckschwerdt]

Good analysis. Yes some type of command input is planned, likely it will be JSON ({"setFrequency":433920000}), but that will have to wait on the refactoring.

[dgrostoto]

Do you mind if I propose a little minimalist code using pipe to support dynamic frequency hoping while waiting the refactoring ? Considering the refactoring, can you tell me which is the pull request or issue to discuss with ? (i have some suggestion such as using MQTT as input using subscribe to a dedicated topic called parameters for instance)

[zuckschwerdt]

If it's easily implemented go ahead and PR. Just two things: I wouldn't want any hacks that break the abstraction and refactoring and I don't want to add features that we can't support in the long run.

Refactoring is the ongoing effort to put the main handling into r_api.c and offer it as an API. Also thinning out the rtl_433.c CLI to offer the possibility to add more rtl_433-like CLI's and such.

[zuckschwerdt]

With the latest 3 commits you now have:

• multiple hop times with -H, one for each frequency (uses the last if too few)
• hop on successful event with -E hop
• hop on signal USR1

These are all experimental and undocumented for now. Please test and comment.

[eadmaster]

can i hop very fast between frequencies and auto-pause the hopping if some signal is detected? (basically i'd like to have a scanner for multiple frequencies that does not break transmissions)

[merbanan]

In theory one could base the hopping on the current detected SNR. That is not implemented though. Patches welcome.

[zuckschwerdt]

It could be a sensible default to only hop once the current channel is clear for x seconds.

[deviantintegral]

It appears that at least -E hop is still functional, but not documented. Given it's been a few years, is it time to document all three options mentioned in https://github.com/merbanan/rtl_433/issues/1105#issuecomment-511349122?

[zuckschwerdt]

At the end of the -h help there is:

  [-E hop | quit] Hop/Quit after outputting successful event(s)

But we someday (soon) need some friendly documentation pages explaining use-cases and scenarios with examples.

[deviantintegral]

Nice! I think it just got missed being added to https://github.com/merbanan/rtl_433/blob/master/conf/rtl_433.example.conf#L230-L232.

Those docs currently say false is the default. Should we document those as acceptable values, or only point users towards hop quit and unspecified?

[zuckschwerdt]

Oh, thanks! I'll correct that now.

[zuckschwerdt]

I'd rather not add confusing defaults/fallbacks. Globally we treat "true", "yes", "on", "enable" as a 1(which is "quit" here) and other values parse as int, e.g. "false", "no", "off", "disable", ... will be 0.