Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New feature that skips currently listened frequency if received sonde is above X meters #370

Open
j0uni opened this issue Aug 1, 2023 · 4 comments

Comments

@j0uni
Copy link

j0uni commented Aug 1, 2023

Basic idea behind this is that sondes that are high enough, aren't really that interesting in terms of hunting. A good station can "hang" to sonde that is "useless to listen" while that sonde being very high and at the same some other sonde is landing at the same moment and the precious data is lost.

I would like to see "auto-skip" feature that can be enabled from the settings by entering a limit in meters. Above the limit rdz will continue on other programmed frequencies. Eventually it returns to the frequency where it left and the same procedure continues if sonde is too high. Until it isn't and then rdz will lock until the sonde has landed (or signal lost).

@oh3bsg
Copy link

oh3bsg commented Aug 1, 2023

There could be also settings how many packages it listen before it will skip current channel. In this way rdz can be "multi channel"-receiver :)

@j0uni j0uni changed the title New feature that skips currently listeded frequency if received sonde is above X meters New feature that skips currently listened frequency if received sonde is above X meters Aug 1, 2023
@dl9rdz
Copy link
Owner

dl9rdz commented Aug 1, 2023

I have the second thing (next channel after X packets) on my TODO list, but with low priority, as you can actually do this (in a somewhat complicated way, by using the screen timeout timers in the display configuration (screenX.txt). In the screens file, you have two lines (on each screen):

timer=-1,-1,N
timeaction=#,#,0

The second value of timer is the rx timer, if you replace the (second) "-1" with a number T, then an action will be triggered after receiving T frames. The timeaction is then the action that is triggered, replacing the second '#' with a '+' would mean move to the next configured frequency.

There are some disadvantages (changing frequency will clear state information, which means that data that is not transmitted in every frame but less frequently (calibration data, battery level on RS41, also DFM is more complicated) is not preserved when changing frequency). If you set T to a value that is too low, a full reception of all data might not be feasible, in particular if you have a weak signal and not decoding 100% of all frames error-free. My long-term plan is to have feature to stay on frequency until all data is decoded (which may take some time), and only then skip to the next frequency. Possibly it might be feasibly to preserve per-frequency state information, but this needs to be done to make sure that no (old) state is used with a new sonde appearing on the same frequency. As I said, long-term plan on my TODO list. Adding altitude-depending behaviour would be easy.

@j0uni
Copy link
Author

j0uni commented Aug 1, 2023

Thanks for such deep description and quick reply.

The timer is almost good but ofcourse as it isn't altitude aware, it can be bad (being at "wrong" frequency when another sonde is at low altitude).

Maybe the "full dataset" could be achieved with just enough long hold on one frequency. Of course that is a blind method, but would maybe work 99% of time that way (say having the frequency listened for 30 seconds straight).

Also holding until full dataset is received can be bad too; what if we aren't receiving full dataset (signal being very weak constantly)? Then fall-out timeout would be needed too.

@DG0MG
Copy link

DG0MG commented Nov 24, 2023

I would also find an adjustable height limit very useful to switch off scanning.
On the one hand, you want to receive as many and distant probes as possible and you have to scan to do this. On the other hand, by switching up the frequency when the probe is close and already low, you lose important information about the landing location if you are the only one still receiving the probe, e.g. if it is below 1000 meters altitude.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants