apache-labs.com

I've got TCI working nicely with either fldigi and Thetis or log4om and Thetis, but if I have all three going, they seem to fight over control.

Is this a known issue?

Fldigi is using the TCI hamlib wrapper network service from github. All are using 40001 for TCI port on loopback.

Too many layers to know which of the combo is the issue.

I've tried many permutations trying to get the three to play nicely without any luck. Fldigi logging works fine, but it just doesn't have the ability to see if I've worked someone before and when like log4om has built in.

"Fight each other" is not specific enough to really understand what is going on. If you elaborate on this a bit perhaps some better answers might be forthcoming.

One thing is for certain: when attaching multiple software app's to Thetis, either by serial CAT, TCP/IP CAT, or TCP/IP TCI, it's a game of "last command wins".

If all of the app's are merely polling Thetis for information, or in the case of TCI merely accepting data pushed from Thetis, then there won't be any issues. However, as soon as one or more app's starts commanding Thetis to do something then, yes, they will fight for control, and Last Command Wins.

Perhaps you could revert to serial CAT for both Fldigi and Log4OM. If that works then we can, with some confidence, say that it's a TCI-related issue, and not necessarily a Last Command Wins issue.

What is the Hamlib TCI wrapper from github?
Link please?

I'll test it and see what's going on.

Here's the hamlib wrapper. https://github.com/ftl/tciadapter

Yeah Scott basically if I try to change frequency in fldigi, log4om or Thetis will try and overrule that. So the main issue is clicking on a signal and hitting QSY to bring it to the center offset in fldigi, thetis and/or log4om will bounce back to the original frequency.

E.g. 14.070 USB , all three are in sync. I click on something, say at 2500 on the waterfall and hit QSY which should bring it to 14.071 with that signall centered, in my case, on 1500. The frequency change gets overridden by the other apps.

This is also true if I just try and tune via fldigi directly.

Now, remove either log4om or fldigi from the triad and all is well, you can tune from either of two apps and it's smooth, add the third, either log4om or fldigi and it breaks.

Do you have the FLDigi option enabled under the Applications section?

kc2rgw wrote:E.g. 14.070 USB , all three are in sync. I click on something, say at 2500 on the waterfall and hit QSY which should bring it to 14.071 with that signall centered, in my case, on 1500. The frequency change gets overridden by the other apps.

This is also true if I just try and tune via fldigi directly.

Reading this, then it would seem that Log4OM is actively overriding Fldigi. Thetis is just along for the ride.

Is it safe to say that when all three are connected:

a) Changing frequency in Thetis see Log4OM and Fldigi both happily following along?

and

b) Changing frequency in Log4OM sees Thetis and Fldigi both happily following along?

If so then you must look to Log4OM as the source of the problem. In which case you might get better answers here: https://forum.log4om.com/

Unless we've got a Log4OM expert here to chime in?

Fldigi and Thetis. Either one can change, works smoothly

Log4OM and Thetis, either one can change and works smoothly.

Add all three and none stably change frequency. A digit changes and then it bounces back to the last state.

As to the fldigi options in log4om, I’ve tried it with and without the fldigi service enabled. I have the adif tracker enabled.

Must be something weird in the TCI-Implementation of fldigi or Log4OM.

Running here with TCI:
LogHX, JTDX, PA-Control, homebrew MacroTool

No problems with changing frequency.

73 Ernst