"Lock Uplink" causes "slipping and reversing dial" on radios in "satellite mode"

[oschonrock]

I recently helped make the ICOM IC-821h work with gpredict via hamlib: https://github.com/Hamlib/Hamlib/issues/693

As the toolitip text says. Gpredict will read back both the uplink and the downlink and if it detects a change from what it wrote it will (correctly) conclude that the user has spun the dial and adjust both target frequencies - recalculate doppler etc...

If the radio implements "satellite mode" where the uplink and downlink are in lockstep (reverse or forward) then it is best to use that, because "locking uplink/downlink" inside the radio is a tighter loop and tracks much more smoothly than over serial comms.

The 821h the 910 etc are all capable of this. Aditionally the gpredict integration with the 821 via hamlib doesn't work unless in satellite mode (refer hamlib issue above for the discussion).

What happens in practice is that gpredict and the satellite lock step in the radio end up fighting each other. When you spin the dial, the radio takes "2 steps forward and 1 step back", because it is detecting "dial spin" on both uplink and downlink. I believe this is due to the comms delays involved. The effect is very pronounced when the "Cycle" setting is about 500ms and becomes less pronounced when you slow it down to about 2s or more.

Proposed solution: Introduce an option (on device settings or on radio control screen) to tell gpredict that the radio will be in "lockstep satellite mode", and if selected, then gpredict will only "detect dial spin and correct target frequency" via downlink, or uplink, it probably doesn't matter which, but not both.

The proposed solution may not eliminate the undesirable effect entirely, because there will still be a small delay between read and write over comms, but it should substantially improve it.

[csete]

Thanks for the feedback. Wouldn't gpredict work the way you propose if Lock is disabled?

[oschonrock]

Thanks for coming back to me.

Sorry. I had a paragraph in the issue text about that, but it somehow disappeared while editing it I think.

Unfortunately not. If you leave "L" disabled, then when you spin the dial, the "target uplink" frequency, top right in radio control window never changes at all. It changes on the radio, momentarily, due to the radio lockstep, but as soon as gpredict calcs and sends the new doppler corrected uplink frequency based on the "unchanged target frequency", the uplink frequency on the radio jumps back to where it was.

ie the uplink on the radio is effectively "stuck", when you spin the dial (it works if you change the uplink on radio control window by clicking the arrows, but this is all about the feedback from the dial).

Hope that's clear.

[mdblack98]

As a note about the behavior here....we have to avoid setting the VFOB frequency on some rigs while the dial is spinning....it can mess up the rig to swap the VFO where you end up spinning VFOB instead of VFOA. There is a "twiddle" option you can set which tries to do this. It sets a timeout for dial spin --twiddle_timeout=S --twiddle_rit=S Where S is in seconds. I think this will also correct VFOB in gpredict but not 100% sure about that. Hopefully in hamlib 4.3 this problem will be fixed another way with the detection of transceive packets and also a new broadcast capability for rig status/control.

[oschonrock]

Thanks Michael. I had seen those --twiddle options somewhere... they need to be passed to rigctld, right?

Interesting on the "spinning wrong dial"...

I will study that more closely. I have been trying to find a useful grep expression to see the communication between rigctld and gpredict on 6vs output of rigctld.

It seems I am getting the incoming commands from gpredict => rigctld, but not the answers,yet .

I was going to study those in some detail, and perhaps add some time stamping in order to really study what is going here in detail. It's not super obvious because it's a dynamic situation, clearly.

[mdblack98]

Yes...the twiddle needs to be passed to rigctld -- you can also set it from rigctl too with the P command.I may end up making twiddle the default in hamlib 4.3 with something like a 3-second timeout I think,. The -Z switch will give you times. There's a lot of info in the debug so understanding the flow is a bit difficult. Mike W9MDB

On Thursday, May 13, 2021, 07:30:30 AM CDT, Oliver Schönrock ***@***.***> wrote:  

Thanks Michael. I had seen those --twiddle options somewhere... they need to be passed to rigctld, right?

Interesting on the "spinning wrong dial"...

I will study that more closely. I have been trying to find a useful grep expression to see the communication between rigctld and gpredict on 6vs output of rigctld.

It seems I am getting the incoming commands from gpredict => rigctld, but not the answers,yet .

I was going to study those in some detail, and perhaps add some time stamping in order to really study what is going here in detail. It's not super obvious because it's a dynamic situation, clearly.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub, or unsubscribe.