I just moved from 1.64 to 2.01 and Log4OM seems to be having issues with CAT control. I can change band but changing to a specific frequency doesn’t work. Oddly enough, N1MM seems unaffected. Nothing else has changed (really); if I just reinstall 1.64 CAT works again. I am happy to open a bug with Log4OM also, but any thoughts? Any logs I can look at? Thanks, Tim W8TGB
EDIT: I cannot control the radio at all. Log4OM notices the band/frequency change but cannot change it.
Just came here to say this, I had noted in 2.00 Log4OM and VarAC did not work while wsjt-x did, can now confirm all the hamlib controlling apps I’m using appear to be functioning correctly in 2.03, thanks!
When Log4OM connect, WSJT and it fight for Data On/Data Off and I can see the box toggling between the two, disconnect Log4OM from CAT and it stays Data On as desired.
Actually it appears to just be a Log4OM issue of some sort, I shut down WSTJ-X and it still toggles Data On/Data Off but at a much slower rate.
Trimmed out the log snippet - This is resolved. VFO MODE (supports dual VFO) was checked on Log4OM (and had been before) so it was toggling data on/off in the wfview window when it was querying the other VFO I think?
Ah OK, I didn’t try dual vfo when I tested log4om, I will have a look.
One of the problems that I am discovering is that when multiple apps are connected to rigctl, they can send conflicting commands. Generally log4om is quite well behaved and just sends \get_vfo_info VFOA every second
Okay, this does appear to be something with VFO Mode in Log4OM because un-checking it in the CAT interface portion of Log4OM allows changing the frequency to work. So, I’ll open a bug with them. But they will likely want to know what v2 does differently than v1, because I didn’t change any configuration parameters in Log4OM (VFO Mode was checked before). Thanks and 73, Tim W8TGB
wfview 2.x had no knowledge of VFO mode, so it would definitely confuse it. I have now implemented VFO mode and it seems to work well. This will be in the 2.04 release.