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.
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.