[Enhancement/Bug] Full-Duplex / Linear Transponder support and optimization of Rig Control

[JF9SOM]

Description:

I have been testing the Ground Station with some LEO satellites and found some issues regarding rig control, especially for linear transponder operations.

1. Lack of Full-Duplex / Linear Transponder Mode

Currently, the "Radio Type" in the settings only allows "RX," but for linear satellites, we need a "Full-Duplex" or "RX/TX" mode.

• Requirement: In linear transponders (especially inverted ones like FO-29), we need a feature where adjusting the Downlink frequency automatically compensates the Uplink frequency ($f_{down} + f_{up} = \text{constant}$) to stay on the transponder's passband. GPredict handles this perfectly, but it's currently missing here.

2. Unstable Rig Control (PTT/VFO "Blinking" Behavior)

During tracking, the rig behaves as if the PTT is being toggled or the VFO is being reset every few seconds.

• Observation: While GPredict updates frequencies smoothly, this software seems to send commands that cause the rig to "blink" or momentarily interrupt.
• Suspected Cause: It's possible that the rig-control module is sending set_vfo or set_mode commands along with every frequency update, or it's switching between VFO A and B inefficiently.

3. Missing Debug Logs for Frequency Updates

Even with LOG_LEVEL=DEBUG enabled, I can see the state transitions (e.g., connected -> tracking), but the actual Hamlib commands (like F or m) being sent to rigctld are not appearing in the logs. This makes it difficult to troubleshoot what is causing the "blinking" behavior.

Suggested Improvements:

1. Add "Full-Duplex" Radio Type: Support simultaneous Doppler correction for both Uplink and Downlink.
2. Implement Frequency Tracking: Add a toggle to link RX and TX frequencies for linear transponders.
3. Optimize Command Loop: Ensure only necessary frequency update commands are sent to avoid rig instability (e.g., only send F command if frequency has changed).
4. Enhance Debugging: Add detailed logging for every command sent to rigctld (e.g., DEBUG - rig-control - Sending: F 145950000).

I am happy to provide more logs or test any fixes!

[sgoudelis]

Can you give me a description of the stack you are using, software/hardware ?

[JF9SOM]

Sure! Here are the details of my software and hardware stack:

Hardware:

• Transceiver: Yaesu FTX-1
• Host OS: Ubuntu 22.04 LTS (running on a dedicated PC)
• Connection: USB CAT control via /dev/FTX1CAT (udev aliased)

Software & Services:

• Hamlib: Version 4.7 (Custom build installed in /opt/hamlib/4.7/)
• rigctld: Running as a systemd service with the following configuration:
  • Model: 1051 (FTX-1)
  • Baud rate: 38400
  • Network: Listening on port 4532

Service Configuration (systemd):

[Service]
ExecStart=/opt/hamlib/4.7/bin/rigctld \
  -m 1051 \
  -r /dev/FTX1CAT \
  -s 38400 \
  -T 0.0.0.0 \
  -t 4532

Additional Context:
I am running the Ground Station via Docker Compose. While rotctld (for my rotator) works perfectly now, rigctld shows the "blinking/PTT" behavior described earlier. GPredict, using the same rigctld instance, performs frequency updates smoothly without any PTT or VFO instability.

Let me know if you need any specific debug outputs from Hamlib!

[sgoudelis]

In the releases page you will find 0.2.10, please test it out, I have made many changes to how rig control works, in the Rigs page you can define certain new parameters, please check them out, each mode has an explanation, I think you are looking for Duplex and Split mode. I am not sure this fixes your issue, but I think it is a step to the right direction. Let me know how it goes.

EDIT: also I changed the location of the logconfig.yaml, it is now inside the docker volume the app uses. Its in configs/log_config.yaml

[JF9SOM]

Technical Report: Frequency Tracking Failure and Disconnection on Yaesu FTX-1

First of all, I would like to thank you for the suggestions regarding the rig configuration changes. I have tested the system with Radio Mode set to duplex and TX Control Mode set to auto.

However, the results confirmed the same phenomenon as yesterday: the Uplink (UP) frequency did not follow the Downlink (DOWN) changes, and the system disconnected unexpectedly when I manually rotated the Downlink VFO dial.

Based on the logs, I believe the root cause of this failure is as follows:

---

1. Observations from Test Results

• Manual Tuning Conflict: The moment the Downlink VFO dial is rotated manually, the application detects a frequency change via the f (get_freq) command.
• Tracking Failure: Although the app calculates the new Uplink frequency, the synchronization fails to reflect on the radio's display.
• Unexpected Disconnection: Immediately after attempting to sync, the rig state changes to stopped and the connection is terminated.

2. Root Cause Analysis (Based on Logs)

The logs reveal a fundamental mismatch between the application's control logic and the capabilities of modern transceivers like the FTX-1.

A. Inappropriate Command Sequence (F and I Alternation)

The application attempts to control the two frequencies by alternating between:

• TX -> F [Freq] (Setting the frequency of the current VFO)
• TX -> I [Freq] (Setting the "Split" or "Background" VFO frequency)

This "pseudo-duplex" approach, which relies on legacy split-mode commands, is highly unstable for satellite operations on modern hardware.

B. Collision during Manual Interrupts

When the VFO dial is rotated, a collision occurs between the radio's internal state (reporting the new frequency) and the application's attempt to write the I command. Because the app lacks explicit VFO addressing (e.g., specifying VFO A or VFO B), the rigctld backend encounters a state conflict, leading to the session crash.

C. Internal Validation Error (radiotype: rx)

The logs indicate that the system internally identifies the rig as 'radiotype': 'rx'. When the app tries to send a transmit-related frequency command (I), it likely triggers an internal validation error because it believes the device is a "receiver only," resulting in an immediate "Tracking Stopped" state.

3. Proposed Solution

To support modern transceivers like the FTX-1, the rig control logic should be updated to move away from the F/I alternation. Instead, it should use explicit VFO addressing:

• Downlink: V VFOA [Freq] (or \set_freq VFOA [Freq])
• Uplink: V VFOB [Freq] (or \set_freq VFOB [Freq])

This method is used by software like GPredict, which operates smoothly with the FTX-1 without causing disconnections or command collisions.

[sgoudelis]

Please sent me a log snippet when any of the above issues happen

[JF9SOM]

Log Snippet and Analysis

As requested, here is the critical log snippet showing the moment of failure during VFO tuning:

# 1. Frequency change detected from the rig (Downlink VFO dial rotated)
rig-control | -> f
rig-control | TX -> f
rig-control | f -> 435250750
rig-control | RX -> 435250750

# 2. App calculates new Uplink frequency and tries to send it using 'I' command
rig-control | TX -> I 145949250

# 3. Collision or validation error occurs (radiotype is 'rx', mismatch with TX command)
rig-control | {'frequency': 435250750, 'radiotype': 'rx', 'mode': 'USB', 'vfo': 'VFOB'}

# 4. Critical transition: The app stops tracking immediately after the 'I' command
tracker-worker | state transition: tracking -> stopped
tracker-worker | state transition: stopped -> stopped

Key Observations from the Log:

1. The 'I' Command Issue: The log shows TX -> I being used to set the Uplink frequency. For the FTX-1, sending I while the radio is reporting its state through f causes a command collision in rigctld.
2. The 'rx' Identify: Note that the radiotype is identified as 'rx'. When the tracker-worker attempts to sync the frequency, it seems to detect a mismatch between this "receiver-only" status and the "transmitter" command (I), triggering an immediate state transition to stopped.
3. The GPredict Comparison: When using GPredict with the same rigctld setup, it uses explicit VFO addressing (V VFOA / V VFOB), which avoids this collision and works perfectly with the FTX-1.

I hope this snippet helps in identifying the logic responsible for the tracking -> stopped transition.

[sgoudelis]

Try out version 0.2.11, use the new explicit mode, available now in the definition of your rig

[JF9SOM]

Feedback on v0.2.11: Explicit Mode Success and Further Improvements for Linear Satellites

Thank you for the quick update! I have confirmed that the new Explicit Mode in version 0.2.11 successfully controls VFO A and B independently on my Yaesu FTX-1. The previous disconnection issues during VFO operations have been resolved.

However, to make this software truly viable for linear satellite operations and digital modes (like FT4), I would like to propose two critical improvements:

1. Adjustable Polling/Update Interval (High Priority)

Currently, the frequency update interval seems to be fixed at approximately 2 seconds. This is too slow for:

• Digital Modes (FT4/FT8): Frequency shifts must be corrected more rapidly to maintain a lock.
• Linear Transponders: SSB/CW signals drift out of the passband if the Doppler correction is not smooth.

Request: Please add a setting to adjust the update interval (e.g., 100ms, 200ms, 500ms). A shorter cycle (around 100-200ms) is standard in software like GPredict to ensure seamless tracking.

2. Bi-directional VFO Sync (Uplink following Downlink)

While the Doppler correction works from the software side, manual tuning on the rig's Downlink VFO does not yet trigger a corresponding shift in the Uplink frequency.

For linear satellites, it is essential that:

1. The user tunes the Downlink VFO to find a signal.
2. The software detects this manual change.
3. The software automatically calculates and updates the Uplink VFO to maintain the correct transponder relationship (accounting for the inversion if applicable).

Summary of Requirements:

• Update Rate: Allow users to set a faster refresh rate (down to 100ms).
• Manual Tracking: Implement a logic where the Uplink follows manual Downlink VFO changes in real-time.

With these two features, this ground station software would become a powerful tool for modern satellite operators. Thank you again for your dedicated support!

[sgoudelis]

I am still considering how to do this, the interval issue is a problem.

[JF9SOM]

Suggestions for Addressing the Interval Issue

I understand that a high refresh rate can increase CPU load and cause serial communication instability or command collisions in Hamlib.

To simplify the implementation and reduce the technical hurdle, how about considering these approaches?

1. User-Configurable Interval (Per Rig Setting):
   Instead of a global change, add a "Polling Interval (ms)" field in the Rig configuration. This allows users to find the best balance for their own hardware (e.g., 500ms for general use, 100ms for FT4/Digital modes).

2. Threshold-based Updates:
   Only send the set_freq command if the calculated Doppler shift exceeds a certain threshold (e.g., > 5Hz or > 10Hz). This significantly reduces unnecessary TX commands while maintaining tracking precision.

3. Separate Threading/Async Tasks:
   If UI responsiveness is the main concern, isolating the rig communication into a dedicated worker thread or an independent async task could prevent the main application from lagging.

Even if 100ms is too challenging for the initial rollout, improving the current 2-second lag to 500ms or 200ms would already be a massive upgrade for linear satellite operators.