Log4OM

Is it possible to add USB-D mode to Log4OM via the config files?

When clicking on a spot for DIGITAL Log4OM sets USB mode. But the IC-7300 cannot receive audio when on USB mode and has to be on USB-D mode for all digital modes.

I don't see the enumerated list of modes in the config files so was wondering if this is at all possible.

I did find it possible to modify the bandplan to set up FT8 bands which is handy for 30M and such rather than FT8 spots changing the rig to CW.

de Mike W9MDB

Are you using the Omnirig IC-7300 DATA.ini because that appears to provide USB-D

These are the command lines in the ini file

[pmDIG_U]
; These lines select USB-D for USB digital mode
Command=FEFE94E0.2600.01.01.FD
ReplyLength=15
Validate=FEFE94E026000101FD.FEFEE094FBFD

Dont forget to select the digital choice in the Log4OM Options/Cat & Cluster

No...not using OminRig....using hamlib net rigctl.

Tried adding USB-D to the bandplan xml file and Log4OM gets an error as it's not in the enumerated mode list.

Mike

That won't do it!

You either need a Hamlib rig file which has been modified, I dont think there is one, for USB D or use Omnirig

Omnirig also provides display of both Vfo's which Hamlib does not, so why not use it?

Because Omnirig doesn't do what I want and it's no longer supported.

I use FLRig and I can hook up as many rigs and com ports and apps as I want. I current have Log4OM, FLDigi, WSJT-X, and another app all talking to FLRig....OmniRig can't do that and isn't supported by very many applications...

Hamlib supports both VFOs...much better if vfo mode is used via rigctld instead of the non-vfo mode programmed into Log4OM (it's just the --vfo switch and adding the target VFO to the netrigctld command as the 1st argument). No reason Log4OM can't do both VFOs...using FLRig and vfo mode also avoids the VFO swapping that was probably seen and why VFOB isn't supported now.

Hamlib also has a new application rigctlcom (which I wrote) which operates on a virtual port offering TS-2000 emulation which Log4OM can also use now.

I know it was mentioned before about dropping hamlib support and I hope that has been reconsidered.

Hamlib is supported in V2 as it's in V1. Unfortunately i don't have any 2-VFO rig capable radio so i'm in real difficulties when testing Hamlib as i cannot reproduce anything.
Maybe a remotely available rig with RIGCTLD exposed through router can be used for testing, but it's complex to achieve

All we need is to add the VFO to the rigctld call. And allow Log4OM to call for VFOB instead of restricting it...or make it an option you have to enable.

So, rather than send "f" you send "f VFOA" or "f VFOB". This bypasses VFO swapping where possible.
You can test this on any rig.
BTW...the 4.0 version of hamlib is backwards compatible and has a lot more capability.
But you can't do "f VFOB" ???? What rig doesn't support a VFOB or Main/Sub?? (which is translated to VFOA/B vernacular in hamlib).

Mike

Also need USB-D added to the mode list so we can just change the bandplan.

Mike

My FT897 has a single VFO, as well as my FT817

Both reports only to queries to VFO A.
The "problem" is not sending "f VFOB" message, it's managing the return accordingly.

We'll work on that for V2

About USB-D i need to check what hamlib reports. I was working with V3, is there a V4 officially released somewhere? (assuming hamlib may have an official resource)

No, there's not a full release yet...but WSJT-X is using the 4.0 library from github.
Lots of rigs have been added and it's very stable right now. I'm working on some major modifications to extend mode capability and we're waiting for those to make an official release as we though those mods might break backwards compatibility but those changes have turned out to be compatible.
Hopefully it would be a minor update to add USB-D, VFO
https://github.com/Hamlib/Hamlib

Then 897 does toggle VFOs and allows you to read either. Looks like the 817 code in hamlib uses the cache and doesn't take the VFO swap into account so perhaps that needs to be fixed. I can do that if you'd like to test it.
If you test rigctl you should find the 897 works with swapping VFOs via "V" and reading the freq from both.
On the 817 though you'll have to wait for the cache timeout which is 50ms....so doing it from rigctl should work but from a program polling both A & B it would return A only until 50ms has elapsed.

I'll make a patch and put it on my github page if you want to test it.

I also see get_vfo is not implemented for either....sometimes we put in a memory mode to remember A/B internally but that assumes the user doesn't mess with the rig.