11.4 piWebCAT operation - the data request queue
The web browser is here referred to as the client. Raspberry Pi is RPi
piWebCAT communicates with the radios using the following data path:
< > MYSQL database
All data transactions are initiated from the client using jQuery Ajax requests (see Ajax, MYSQL)
This means that we cannot use Icom transceive (radio-initiated data transfers).
The PHP code on the server lives to do each single request and then dies.
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 22 slots.
The slots are polled cyclically for requests bit in addition, certain data types are given priority.
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 Some other non-VFO specific requests
The queue is checked every 10ms (a database timing then deleted from the queue.
The next 10ms scan starts at the next point in the queue so that infrequent requests are not missed.
Frequency writes, other write items and meter reads are given extra high priority.
From a priority viewpoint, data types are categorised as follows:
- Frequency setting A rapid sequence of frequency setting messages only occurs when
the user is making a tuning action. (ie mouse wheel or drag tuning).
In addition, isolated frequency set messages occur from clicking the tuning scale
or on band changing. When the repetitive queue scan process finds a
frequency set message in the queue, it is given immediate priority.
This is appropriate because the user is totally focused on the rig frequency change
response during this process.( Button and slider responses can be momentarily
ignored because the user is unlikely to operate other controls exactly at the same
time as tuning.
- Buttons, sliders Button and slider rig setting actions by the user give rise to isolated single messages.
They can therefore be given high priority without risk of compromising the key
background task of meter display and control synchronisation with the rig.
- Meter updates Updates of S meter read (and transmit metering reads) from the rig are the main
ongoing background task needing a high priority. They occur all the time and so
their maximum priority has to be limited to alternate message sending slots in order
to allow the other background processes cocntrol syncing) to get a look in.
- Syncing controls This is the user-configurable synchronisation of selected on-screen buttons and sliders
to their corresponding controls on the rig. They have the lowest priority and are managed
cyclically to ensure that no control is repeatedly missed.