Log4OM

Hi,

I'm going a little stir-crazy over this, any insights would be appreciated. The configuration that's at issue is this:
Yaesu FT-2000 on real COM6
VSPE (splitter) COM6 -> virtual COM9
Log4OM CAT running via OmniRig, OmniRig is connecting to COM9 to access the FT-2000 CAT data
Also running Spectravue/SDR-IQ as a panadapter for the FT-2000 (IF-2000 board installed). Spectravue is also connecting to virtual COM9 via its External Radio Setup for FT-2000 frequency data

Spectravue works happily, pulling frequency data from the FT-2000 over COM9 (the frequency readout is always correct and responsive) however OmniRig + Log4OM doesn't like this arrangement at all; they are very unhappy sharing virtual COM9 with Spectravue; the frequency display in Log4OM is frequently reading incorrectly e.g. it regularly shows odd readings like "114.001" and "0.103" (when the VFO frequency is 14.005). This is causing repeated "Out of Band" warnings with all that follows e.g. loss of Cluster Scanner functionality etc.

Previously I was using Simon Brown's SDR-Radio software in lieu of Spectravue and SDR-Radio and like Spectravue, SDR-Radio was happy i.e. correct frequency readings and responsive. The OnmiRig+Log4OM setup wasn't particularly happy with that arrangement either however, though it was better than what I'm seeing with Spectravue. SDR-Radio was also getting its frequency data via OMNIRIG in that case (Spectravue doesn't utilise OmniRig).

When I stop Spectravue (and previously SDR-Radio), the frequency problem goes away, so it's reasonable to assume the issue is with data being taken from virtual COM9 into OmniRig and then onto Log4OM i.e. there's some kind of conflict giong on where Spectravue is winning and OmniRig / Log4OM is coming in a poor second...

I've exhausted several hours tweaking the "poll int" and "timeout" settings in OmniRig but to no real avail - it's "less bad" with these values set to 1500ms and 4000ms respectively but it's still pretty much unusable. The CAT data rate is set to 38,400 for COM6 and COM9. I've tried different virtual comm port software but it made no difference. I've increased the execution priority of various processes e.g. OmniRig, Log4OM and so on but to no avail...

Have I got this whole arrangement set up in a cock-eyed fashion or something? It seems odd that the splitter isn't supplying data "fairly" to all comers... Does anyone have any suggestions about what else I can try here? I appreciate it's probably as much to do with OmniRig as Log4OM but it's making Log4OM very difficult to use as without a reasonably stable CAT frequency, alot of the Log4OM features are compromised...

I don't understand why you are connecting Spectravue or SDR-Radio Consul to the com port, when I was using the SDR-IQ I just set the IF frequency to that of the IF2000

I thought Spectravue had provision for connecting to a logging program built in the same as Simon did with SDR-Radio .com?

Also what version of Omnirig are you using

Hi Terry,

I hope you're well. Thanks for the quick reply.

Spectravue (v3.38) facilitates connection to (inter-alia) an SDR-IQ via an External Radio setup configuration; that setup does involve setting the IF frequency for the IF-2000 but also enables configuration of additional functionality that includes functionality to read the VFO frequency from the FT-2000 so Spectravue can display the FT-2000 VFO frequency on the waterfall/2D plot and so on. The displayed frequency tracks as you tune around and you can also set the FT-2000 VFO frequency by clicking on the Spectravue spectrum display...

Spectravue doesn't seem to have provision for connecting to a logging program that I can see. I've switched to Spectravue as SDR-Radio (in v2) has become a bit heavyweight for use just as a panadaptor display and v1 had a few issues that won't be resolved as v2 has now superseded it. I've since realised as well that Spectravue has a number of nice additional features that make it particularly good for panadaptor use.

I'm running the latest OmniRig version available from VE3NEA's website - v1.16

One other thing I've noticed in the last few hours; in Log4OM, VFO A is far worse affected than VFO B; VFO B actually tracks quite well (I've the FT-2000 configured so VFO B tracks frequency with VFO A) although it does occasionally go off but nothing like as often as VFO A... Presumably this would be because Spectravue is only reading VFO A data..?