Delay switching radio to a cluster spot

[n0stl]

Hello Everyone,
Just started using LOG4OM and came across of very annoying delay between double clicking cluster spot and actual radio switching to the spot's frequency and mode. First I though it was because of a lookup on QRZ, but turning this feature off did not improve the performance.
The delay is not consistent varies between 0.1- 1second. Please advise. Thanks

[K7PT]

Gee, 100 milliseconds is quick and 1 sec is nothing, probably the overhead of the software doing it's job.

How long does it take your rig to execute the command?

Hope your not expecting it to anticipate your second click.

[n0stl]

Thanks for comments. Sorry, I should have explain my question a bit better.
On this very PC I also have DX4WIN and WriteLog which switch from cluster spots (upon double click) the same radio via the same MicroKeyer consistently with no noticible delay.
I do not run the loggers simulteneously so, I do not see a conflict of ports or radio control commands lagging.
However, it appears that upon double clicking the spot, unless the LOG4OM retrieves some look up data it does not let the radio switch to the commanded frequency. Like I said it is inconsistent - anywhere from being lucky 0.1 - 0.2s up to 1s or even more.
It appears to be a great feature to have more QSO info, but it seems like can be updated later.
So does anyone know what causes this annoying delay?
Thank you in advance

[G4POP]

Are you using Hamlib?

[IW3HMH]

What is your CAT software?
We're constantly polling the rig for actual informations, but 1 sec is a "long" time, while 0,1 sec is a "good" time.
The strange thing is this variability.

Can you enable debug log and check timings on the txt log file?

[n0stl]

As it is being pointed in the manual that OmniRig appeared to be a preferred choice so, I went with OmniRig.
My polling there at first was 500ms, then I reduced it down to 200ms - no change was noticed.
However, it seems like the delay is quite less if the radio does not change the band but just a frequency within the current one.
My radio is IC7600 (not using USB COM port, just only sound) with all COM ports provided by MicroKeyer.

[n0stl]

Daniele, Terry thanks for the CAT and debug suggestions. I will try to log the timing if possible.
I just thought, it may have been something very simple I missed in the setup which is causing this delay issue.

73 de Vlad, N0STL

[G4POP]

Have you tried updating the com port driver for your CAT interface lead?

[NN7D]

I am using an IC7600 and experience no delay in switching freq or band. But I am using the ICOM provided Silicon Labs USB to UART Bridge driver.

Doug

[n0stl]

I am using an IC7600 and experience no delay in switching freq or band. But I am using the ICOM provided Silicon Labs USB to UART Bridge driver.

Doug

Thank you everyone for your advices. The root of my problem was in the way how IC7600 interface is designed. It provides a "crippled" USB-COM port which has no keying ability (no RTS/DTR), but just allows to do CI-V. So if you want CW or RTTY hardware keying - additional COM ports to be used. That's what I attempted to achieve by using my MicroKeyer - just to utilize the keying/PTT part.
Well, since I had to start this additional interface, I thought that in order to keep the setup uniform, I decided to use Microkeyer's ports for everything including the CI-V. The rationalle was that IC7600 CI-V port would not conflict as long as it is not being used. Well partially that was a good assumption, but there is the residual effect - this annoying delay, which brought me to the forum here.
To make the story short, if an ICOM radio with a built in USB-COM is used, make sure the CI-V uses only that one - no delay anymore!!!!
So, just to recap, here is the setup assignment of my IC7600:
Windows 7
COM4 (internal IC7600 port) - used for CI-V
COM5 (created by Microkeyer) - used RTS/DTR for CW/hardware PTT keying
COM6 (created by Microkeyer) - used for RTTY FSK
Sound - IC7600's USB sound CODEC.
Please note if IC7600 (or other USB sound ICOM radios) is used - the use of Windows 7 is a MUST, because Windows XP does not have controls over recording input of this sound card (poor XP USB sound driver or whatever).
73 and thanks to you all!