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

Allow configuration of hamlib (net rigctld) in RX only systems to set reporter band automatically over LAN. #539

Closed
barjac opened this issue Sep 16, 2023 · 9 comments

Comments

@barjac
Copy link

barjac commented Sep 16, 2023

The summary explains this adequately I think.

However long explanation:
The main system running TX/RX instance of FreeDV is wired to the radio via USB.
Hamlib rigctld daemon on localhost communicates with FreeDV.

Another instance of FreeDV running on another system could also receive the rig frequency, mode etc. from the main system over the LAN, however FreeDV does not currently cater for the configuration of this.

I already run a logging program alongside FreeDV that uses the same data via localhost:4532

Can configuration be added to facilitate this by adding settings hostname/IP:port and a way to enable this?

This also depends on #527 being fixed as the main reason for this would be to enhance that feature.

@tmiw
Copy link
Collaborator

tmiw commented Sep 17, 2023

You should theoretically be able to provide the IP address of the other machine instead of localhost/127.0.0.1 in the Hamlib settings, i.e. "192.168.1.123:4532". Assuming Hamlib is okay with that setting, FreeDV should then pull the frequency/mode every 5 seconds or so. Is that currently producing an error or some other undesired behavior on either machine?

@barjac
Copy link
Author

barjac commented Sep 18, 2023

As I see it there is only provision to enter a host:port in the PTT section, which for a receive only machine is greyed out with 'Use Hamlib PTT' unselected.
Selecting 'Use Hamlib PTT' to un-grey that section causes FreeDV to complain that it can't connect to the rig via Hamlib as it's looking for a serial device. Even using 'Hamlib Dummy' as the radio it is the same. :(

Also just tried enabling PTT to enter the host:port and then disabling it again - no complaints but no joy either. 4532 is open on both machines.

@tmiw
Copy link
Collaborator

tmiw commented Sep 19, 2023

Using "Hamlib NET rigctl" for the radio name shouldn't need a serial device, especially if you choose "CAT" for PTT instead of DTR or RTS. YMMV if you're choosing some other radio name instead, though. Can you confirm that it's still expecting a serial device with "Hamlib NET rigctl"?

@barjac
Copy link
Author

barjac commented Sep 19, 2023

These two images are with and without 'Use Hamlib PTT' selected. However this request is not related to PTT as this machine does not have any TX audio settings and does not use any PTT.

In 'monitoring' mode neither does it have a 'Report Frequency' in the main dialogue as it's not reporting.

It does appear to be requiring serial info when the 'Use Hamlib PTT' is checked.

This PTT settings dialogue seems to be the wrong place for this to be configured.

Screenshot_20230919_190147

Screenshot_20230919_190249

@tmiw
Copy link
Collaborator

tmiw commented Sep 20, 2023

I used my laptop and a M1 Mac Mini for a quick test with my Flex 6300:

  1. Open SmartSDR on the Mac Mini and enable CAT control (I normally use "Kenwood TS-2000" for the radio type and "localhost:5001" as the "serial" port in FreeDV.)
  2. Instead of opening FreeDV on the Mac Mini, run rigctld -m 2014 -r "localhost:5001" (2014 is the rig type for the TS-2000. rigctld -l will show all supported radios and their IDs.)
  3. On the laptop, open FreeDV and do the following configuration:
    a. Tools->Audio Config: Set both devices in the Transmit tab to "none".
    b. Tools->PTT Config: Use "Hamlib NET rigctl" as the radio type and "10.0.1.224:4532" (the IP for the other machine and rigctld's default port) for the "serial" port.
  4. Press Start. After doing so, FreeDV Reporter and the main FreeDV window look like this:
Screenshot 2023-09-19 at 11 26 43 PM

(Ignore the lack of audio in the waterfall.)

and on the other system:

Screenshot 2023-09-19 at 11 33 00 PM
  1. Change frequency on the other machine/radio:
Screenshot 2023-09-19 at 11 34 02 PM

After about ~5 seconds, FreeDV on the laptop shows the new frequency:

Screenshot 2023-09-19 at 11 34 18 PM

A few notes:

  1. Step 1 can be skipped if not using a SDR radio (with Step 2 being adjusted to use /dev/tty... instead of "localhost" and a port number).
  2. "PTT Config" and associated verbage could probably be renamed to something like "Radio Control Config" now that FreeDV has rig control. Does that sound reasonable?
  3. The macOS and Windows versions of FreeDV use Hamlib 4.5.5. Is it possible that the version you're using may not support your use case?

Anyway, I just realized that the use case may be that you want to be able to view FreeDV Reporter from another machine with the FreeDV application and additionally have the application do the automatic band filtering without needing to push Start or show up a second time (even as "RX Only"). The above steps, if they can be made to work on your setup, will probably get you at least the band following but you'll still have a second "RX Only" entry that you may not want. Regardless, it's probably a good idea to at least get the above working before considering adding anything specific for your use case as I imagine a proper rigctl connection across a LAN will be a prerequisite.

@barjac
Copy link
Author

barjac commented Sep 20, 2023

Thanks for your explanations.

OK I have now discovered the issue that I was having. Read on ;)

Reading the above many times I realized that I was not doing anything wrong and it was just not working.
I tested klog which I knew had worked remotely and that was not working either.
I turned off all machine firewalls etc.etc.
Then I finally checked the IP of my main machine! It is normally, ALWAYS fixed at 192.168.1.65 and it was 192.168.1.182!
I am using a fresh install of Mageia 9 in which I had forgotten to fix the IP. Argghhh!

Having fixed that I was very surprised to find that it works exactly as I was asking in this issue.
The laptop (SDR monitor) does now track the main machine, the reporting works when enabled and the reporter band tracking also works fine with or without reporting enabled, so monitors do not duplicate calls in the reporter. It's perfect! So nothing to do :)

What is not perfect (for my use case) is the confusing terminology in the configuration which you have mentioned so I won't close this yet. Also why is the 'PTT config' in a totally separate dialogue, could it be moved to a tab in the other settings?

This is the monitoring laptop not reported, with the main instance reported and it's band filtered by the 'track current frequency'. Its demonstrating UTC too :)

Screenshot_20230920_200845

@tmiw
Copy link
Collaborator

tmiw commented Sep 21, 2023

What is not perfect (for my use case) is the confusing terminology in the configuration which you have mentioned so I won't close this yet. Also why is the 'PTT config' in a totally separate dialogue, could it be moved to a tab in the other settings?

Consolidating config dialogs is going to be a bigger effort but for now, I created #550 to adjust the labeling a bit. Let me know if those proposed changes sound reasonable.

@barjac
Copy link
Author

barjac commented Sep 21, 2023

I think this can be closed then.

@tmiw
Copy link
Collaborator

tmiw commented Sep 21, 2023

Done. :)

@tmiw tmiw closed this as completed Sep 21, 2023
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

2 participants