FT856 CAT conflict LOG4OM2+FLDIGI and reading garbage

[IK0AOC]

I have a CAT conflict (collision and garbage in frequency reading on both programs) using VSPE as suggested on the user manual.
I have the same problem also with these tests:
Changing all CAT protocol on FLDIGI.
Changing Hamlib/Omnirig on LOG4OM.
I traced the flow and I discover conflicts on the serial output when both programs cycling requests data from the transceiver. I know that Yaesu protocol does not manage packets collision like Icom and probably this is the reason of the issue.
Unfortunately FLDIGI does not support the multithreated Omnirig protocol.
Enabling CTS/RTS on both interfaces seems a little better but does not resolve.
Any idea?
Thanks,
Enzo, IK0AOC, Rome

[G4POP]

Ciao Enzo,

You need to download the latest user guide, the detailed instructions and flow chart are accurate I just checked them a few minutes ago

[IK0AOC]

Thanks for the prompt answer.
Yes, I followed all steps on the latest manual and I can confirm that all works well between the two programs, but the garbage is still present.
Please load this file http://www.viamar.org/FLDIGI.MOV to see the issue.
When I close LOG4OM2 in Fldigi the problem stops immediately and the same in LOG4OM if I shutdown fldigi (the garbage in LOG4OM is less frequent but exists).
73, Enzo

[G4POP]

And in Log4OM what are you using Hamlib or Omnirig?

[IK0AOC]

Usually I use Omnirig but I tested both with same behaviour.

[G4POP]

You can't us Hamlib in both programs, Fldigi Hamlib and log4om must be Omnirig

An you created a 'Splitter ' in the Eterlogic VSP manager with one end the com port the radio is connected to and the other a GPS?

So both Fldigi and log4om are connecting to the VSP end of the splitter, NOT THE RADIO END?

Are Fldigi, Eterlogic and Log4om ALL running as an administrator?

[IK0AOC]

I used Hamlib in both program just to test the issue, but my actual configuration is Omnirig on LOG4OM2 and Hamlib on Fldigi.
I use a licensed 64 bit VSPE (WIN10 64)
The hardware port (COM10) is connected to the radio; I created a "splitter" with a virtual COM20 port. Both Omnirig and Hamlib are connected on COM20 (in any case if I try to connect to "real" COM10, it results busy as reserved from VSPE).
LOG4OM2, VSPE and Fldigi run with administrator privilege.
Thanks for your patience...
73, Enzo

[G4POP]

Try a different rig set up like an FT857 or 897

[IK0AOC]

Yes I tried also other similar radio with same result.

I've found a workaround while waiting for a better solution.
The problem is that using VSPE (or another serial splitter) the query commands (end echo) from two radios collides and the messages are damaged (YAESU CAT).
I tried also using another program instead of LOG2OM2 together with fldigi and the issue is the same. The yaesu protocol cannot manage well concurrent queries (in my case and with my FT857 RTX).
So i created in VSPE another splitter but read-only connected to the virtual port and I use this with LOG4OM so it receives the message from the radio but cannot request. It's complicated and dirty but works.
To be more clear:
COM10 is the hardware port connected to the radio
Created splitter COM10<->COM20 and this port is used by fldigi (Hamlib)
Created splitter COM20<->COM21 read-only and this is used by LOG4OM2 (Omnirig)

I hope someone can find something better.
73, Enzo IK0AOC

[K1wnt]

Enzo, I have the same issue with my yaesu ftdx 3000. When using fldigi and log4om the frequency display in both programs goes off frequency for just a split second periodically. Also have had multi log entries and incorrect band depending on if the call is logged during one of the periods.
I also created a read only splitter in the vspe as you suggested. This took care of the frequency display issue but it made the band map feature in log4om inoperable.

Has anyone come up with an alternate fix?

Thanks, Roger k1wnt