piWebCAT

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:

Client (javascript)   <  ajax commands>   RPi server (PHP code)         <serial link>  radio

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

Priority data

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.