12.8  Client server communications after startup

After startup, data transfers use ajaxdata.js on the client accessing wcajaxdata.php on the server

All transfers are directed through function:

      sendWebcatMessage(param, rxab, task, code, jobdata, opasync)

This uses an Ajax call similar to the sliders example above.

There are a number of ongoing, repetitive, asynchronous tasks that must use this data route.
Their individual repetition periods are specified in milliseconds in the timing table.

They are:

  • getMoxStatus  -   We need to switch piWebCAT to transmit mode if microphone PPT is pressed.  
  • smeterCAT  --      Read the meter (Smeter or a transmit meter with a repitition rate high enough
                               for an effective display).
  • getFreqMainCat - piwebCAT needs to respond to tuning actions on the radio - but this is not its
                             normal operation and so 200mS is satisfactory.
  • getFreqSubCat   - less important   - I use 500mS
  • checkBandMain  - monitor the current frequency and change the band display etc if necessary.
                            (band change will trigger reading of mode, DNR setting, roofer selection etc etc)  

                                 1000mS is adequate

  • checkModeMain -  check for a radio initiated mode change (eg: 2000ms)
  • checkSetFreqMain - Mouse drag and thumbwheel tuning actions change the variable:  freqSet

                          This task examines freqSet every 50ms and sends changes to the radio.

Note that piWebCAT does not read the current band from the radio.

It reads the frequency and checks it against band limits.

For example: I do not have a 4m band  radio. But, for testing purposes, when I wind the frequency

on the IC7000 upwards from 50 Mhz, piWebCAT's tuning display flips to the 4m tuner when I hit 70 Mhz.

In addition to the repetitive traffic described above, button and slider messages to the server occur

at random times.

A javascript queuing system is therefore used in ajaxdata.js on the client to avoid data collisions.

The queue has one read and one write slot for each of:

      MOX, meter A and B, frequency A and B, Button A and B, slider A and B and data X.
A new incoming message will replace a waiting unsent message

The queue is interrogated every 10ms in a circular fashion for messages to send..

This queuing system ensures that all messages are dealt with without data collisions.