piWebCAT

7.4  piWebCAT - Database table - timing

piWebCAT's client to server requests are:

• Timer driven repetitive tasks   ( eg: frequency change, meter updates)
• User driven tasks such as button and slider actions.

To avoid errors due to data collisions, all client > server tasks are managed in a queue.

The queue has six data types in 17 slots. The slots are polled cyclically for requests.

The six data types are:

• MOX        Radio Tx/Rx status. Responds to radio MOX and PTT. Read only.
• METR        A meter read request (S meter or Tx meter)  Read only, A and B slots.
• FREQ        Frequency request. 4 slots, Read or write for VFO A or B  
• BUTN        Buttons  - 4 slots. Read state or set state.  Read or write for VFO A or B.
• SLDR        Sliders  - 4slots.  Read state or set state.  Read or write for VFO A or B.
• DATA        Other CAT data requests .... not VFO specific.

The queue is scanned cyclically every 10ms (  timing table readqueue field)
If a request is found, the request is processed and deleted from the queue.
  - the next 10ms scan starts at the next point in the queue so that infrequent requests
    are not missed amongst other very frequent request types.

On fast drag or thumbwheel tuning, the next request may be generated while the previous
request is still unsent in the queue slot. The new request simply overwrites the existing one.

So we lose one but we always send the latest.

The queue is designed such that we do not lose button click and slider change requests.

Designing for speed
For most CAT software, the overriding factor for speed limitation for repetitive tasks is the response
time of the radio.

piWebCAT has the potential extra delay of every message being sent and returned via a longer pathway.

All requests arise from the client code (web browser).

The data path is:

     Client code  < LAN >  RaspberryPi server code   < serial link >   radio

Because this was a potentially critical timing issue, my initial design stage was simply an S meter
and tuning system to establish feasibility. There was no database use at that stage - I just used
fixed coded settings for the FTdx101D. The results were promising, so the development continued.
The system was gradually refined.
The addition of queuing system was vital to avoid data collisions and to avoid losing the relatively
infrequent button and slider requests.

My current timings are in the table below:

Values are in milliseconds. Setting to zero stops the timer.

The timing table fields:

• rig                The current radio   - drop down selector (from rigs table)
                 Must have same spelling throughout all the tables.
• mox        Checking interval for radio's Rx / Tx status. 1000ms is adequate response to PTT.
• leds        The update stepping interval for read-only LEDs buttons.   See: LEDs buttons.
• meter        S meter and Tx meter reading interval. 100ms is good. The meter needle is slightly more
                 jerky than on the Ftdx101D but quite acceptable. I have programmed in some digital
                 damping on meter decay.
• freqcur        The interval for reading the radio's active VFO frequency from the radio  
                 This does not need to be very fast. If we are controlling with piWebCAT, it is the write to
                 the radio interval that needs to be small to give good tuning action.
                 If we are tuning on the radio, piWebCAT's response does not need to be fast.
• freqzz        The interval for reading the radio's background frequency from the radio....can be slower.
• modecur        Interval for checking mode change of currently selected VFO on the radio.
                 Used after band and VFO A/B change. Updates appropriate buttons of Mode group
                 and red text mode indicator to left of frequency readout.
• modezz        Interval for checking mode change of dormant (unselected) VFO on the radio.
                 Used after band and VFO A/B change.
                 Updates red text mode indicator to left of frequency readout. (NOT the mode button group)
• chkband        Interval for checking for band change on the radio.
                 Band switching was a little tricky to develop. For detailed explanation see Band switching        
• chksetfreq        This interval is used when tuning the radio from piWebCAT. It needs to be fairly
                 short to give good response. I use 50ms. As stated above, some incremental changes
                 may be missed .. but only as a result of fast moving tuning and so this not a problem.

               The mouse drag or mousewheel tuning events update a variable:  freqSet.
               The chksetfreq timer monitors freqSet and queues any change for sending to the radio.

• disable        Drop down selector Y or N. Y disables all the task repetition timers except readqueue.
                 Used for development / testing. See below:
• readqueue        The interval between message queue polling episodes. As stated above, the queue
                 is scanned cyclically until a message request is found. The next interval starts scanning
                 where the last poll finished to avoid button and slider requests being missed.

Use of the disable field

Under normal piWebCAT operation, there is continuous repetitive network traffic.

ie:   meter read, frequency and mode check, PTT checks. Updates for controls configured in 'sync' mode etc.

To view this traffic:  
Click R mouse on the browser and select Inspect element. (Firefox developer and Chrome are good)
Selecting the network tab reveals a fast moving list of client-server network transactions.
You can freeze one with L mouse click and then look at headers  and response.
This is hit and miss as they move too fast to make a first shot selection.

If you set timing.disable to Y, then all the repetitive traffic stops. You can clear the list (dustbin icon)
Then, you can test the configuration of individual buttons and sliders.
  - One button click will show one transaction record which you can inspect.