Polling settings

1

I have noticed considerable lag between the WFview cursor and IC7300 cursor when manually tuning the radio at 25ms polling settings. Adjusting polling to 5ms seems to ameliorate this somewhat but when I shutdown the program and restart it the polling resets to 25ms. I understand it does so because it is computed from the interconnect baud rate rather than being saved on shutdown. Is there a way to save the polling value? I’ve noticed no lag when tuning from the WFview screen which led me to believe the lag is due to the program polling the radio. Any help appreciated. And thanks for making this program available, it is awesome.

2

Hi Dave,

If you turn on CI-V transceive on the radio, the tuning should be nearly instantaneous, even with polling at 200ms. Otherwise, yes, there will be a lag.

In case you are curious, the polling period is the period between various parameters that we poll, and the timing isn’t divided evenly. This is because we prioritize the metering function and whatever things the user is doing (such as changing a level or commanding a frequency). All communication, whether it be polling or user commands, are fed into the same precision-timed queue.

Here is what goes on the queue for polling:

insertPeriodicCommand(cmdGetTxRxMeter, 128);

insertSlowPeriodicCommand(cmdGetFreq, 128);
insertSlowPeriodicCommand(cmdGetMode, 128);
if(rigCaps.hasTransmit)
    insertSlowPeriodicCommand(cmdGetPTT, 128);
insertSlowPeriodicCommand(cmdGetTxPower, 128);
insertSlowPeriodicCommand(cmdGetRxGain, 128);
if(rigCaps.hasAttenuator)
    insertSlowPeriodicCommand(cmdGetAttenuator, 128);
if(rigCaps.hasTransmit)
    insertSlowPeriodicCommand(cmdGetPTT, 128);
if(rigCaps.hasPreamp)
    insertSlowPeriodicCommand(cmdGetPreamp, 128);
if (rigCaps.hasRXAntenna) {
    insertSlowPeriodicCommand(cmdGetAntenna, 128);
}
insertSlowPeriodicCommand(cmdGetDuplexMode, 128);

The slow periodic commands get run every 20 polling intervals. This is because we generally get updates from CI-V Transceive on the radio for frequency and mode immediately, and the other parameters typically change less frequently. For example, the attenuator or preamp might toggle on and off when a user changes bands.

The s-meter (or power meter, or whatever else the user has asked for as a secondary meter) are polled every other polling cycle (even cycles).

User commands are sent every odd cycle, and cause the slow periodic commands to skip a turn.

It took a lot of fiddling to come up with all this, but the end result is that wfview should feel very responsive to user input but also keep up with whatever is going on at the radio. The other output of this work was that we can respect the radio’s timing and CPU capabilities and not clobber it with requests that it can’t answer. CI-V is generally asynchronous and half-duplex, and thus it takes some care to not step on the radio’s own output.

Check your CI-V Transceive, and also that wfview says “IC-7300” in the lower-right corner.

Thanks,

–E
de W6EL

3

Thanks Elliott that did the trick! And thanks for all the effort you’ve put into making this program available, it’s a real winner.

1 Like