11.3  piWebCAT - main control page startup

This section assumes some prior reading of the database configuration sections.

Part of the data held in database tables is needed on the client.
eg for buttons:   whether active, caption, colour, mode of action (toggled, grouped etc)
                        and communication with the server  (code, abx, data values to send)

Similarly, the client needs to hold data for sliders, data lookups, meter calibrations,

timing control, the current radio, the list of radios for the selector  etc etc

This data must be extracted at startup from the server based MYSQL database tables

and sent to data arrays on the client. (PHP arrays on the sever are converted to JSON format
for transmission to the client where they generate matching javascript arrays.)

For buttons and sliders, a data array entry is required for all 97 buttons and 29 sliders.

This is because unused buttons must still be represented in the array as inactive in order to
present them as inactive and greyed out to the user.

The server therefore builds full arrays of inactivated items and then selectively overwrites the active
items with configuration data from the database tables.

Eight tables are involved (not catcodes).  

Three of these table have separate RS232, Icom CIV and Hamlib versions.

For buttons, the downloaded data array will be used in conjunction with a

 fixed-coded button table. This has an entry for every button as below:

const BTN_075        = 75;

const BTN_076        = 76;

const BTN_SWAPAB = 79;

Every button has a number. First we define numeric constants for

these numbers.  Most have the form: BTN_nnn. These are buttons whose function and appearance can be user defined.
A few buttons with fixed internal functions have text identifiers,

The fixed coded button table is of the form:

[BTN_075,        "btn075",        0],

[BTN_076,        "btn076",        0],

[BTN_VFOA,        "btnVFOA",        0],

[BTN_VFOB,        "btnVFOB",        0],

[BTN_SWAPAB,        "btnSwapAB", 0],

Left column is btnno in database and the click reference.
Middle column is the button's id on the web page,

Right column stores the state of a toggling button.

For sliders, the downloaded data array will be used in conjunction with a

fixed-coded slider table. This has an entry for every slider as below:

[SLIDER_IF_WIDTH, "sliderIfWidth", "textIfWidth", "capIfWidth"],

[SLIDER_008,             "slider008",           "text008",    "cap008"],

[SLIDER_009,             "slider009",           "text009",            "cap009"],

 SLIDER_008   is IF-shift in some of my configurations. It has a non-specific numeric name
because it is NOT used as an identifier within the program code and so is free to be configured

for some other function if YOU wish.

Using IF width as the example:

  • SLIDER_IF_WIDTH is a number constant ( = 7 ) used to identify slider on position change etc
                                and also is listed as sliderno in the database table.
  • sliderIfWidth is the id of the slider - used to control it from code.
  • textIfWidth   is the id of the text data field to the right of the slider.
  • capIfWidth    is the id of the identifying caption to the left (if no on/off button)

Note that this fixed button and slider labelling in client is based on the use of the controls for my
original FTdx101D development setup. It includes spares  ie: SLIDER_SPARE_D.

In the database, the user can change the function and identification of sliders and buttons.
The above labels do not change .... but they are internal to the code and so unseen.

I conveniently revert to this original setup for development purposes.

Once the web page has loaded, the control of the startup sequence is coded in clientinit.js.

The sequence is summarised below:

Ajax routines are mentioned - these are the link to the server (see: Ajax, MYSQL)

When piWebCAT is up and running, there are eight asynchronous processes running on timers.
Their intervals are specified in the timing table. They are referred to in the sequence below.

Start up task sequence

  • catcontrol.php (mainly HTML) is downloaded and rendered as the visual webpage.

      A large number of javascript files are imported from the server, including jQuery,

      some jQuery plugins and all the necessary G3VPX developed files.

      At this stage the visual page is populated with G3VPX original FTdx101D controls.
      The page includes the tpopup windows - initially hidden: log, memory pad and extra buttons.        

  • Empty data arrays are defined in client javascript for data from eight database tables
  • Function ajaxGetMyRigArray() reads the single record settings table to get the
    name/identifier of the radio (eg: FTdx101D)  This is the link to all the other tables.
  • Function ajaxGetRadiosArray() is called to load the radios from the rigs database table.
    - this provides a list of radios for the drop down selector and also data for the current radio,
    ie serial port data (baudrate etc),  catcomms (Icom CIV or ASCII)
    connection, ie whether RIG (direct to radio)  or ENCAT (via EncoderCAT).
  • VFOB display is hidden if vfobvis = 'N'.
  • The serial port, connection and catcomms data is written to the page footer.
  • ajaxSerialInit(...) initialises the RPi serial port with baudrate, stopbits, charbits and parity.

      (It also sets the serial port to RAW mode to prevent alteration of Icom CIV binary data)

  • The remaining six data arrays are populated from the database (ie: buttons, sliders etc)
  • setRadioOptions() inserts the list of radios into the drop down radio selector.
  • setButtonCaptions() uses the buttons data array to replace ALL the buttons captions,
    set their colours and to set them active or inactive.
  • setSliderCapions() sets slider active status and their labels (where no on/off buttons).
  • getVfoAB()  reads the current VFO selection from the radios
  • The radio selector is set to display the current radio.
  • Eight timing values are loaded from the timings array.
  • The 10ms ajax queue read timer is started. (repetitive tasks are queued to avoid data collisions)
  • The Tx meter buttons are initialised,  Tx button selection is set to A  (leftmost)
  • A VFOA or VFOB click is emulated according to the current selection on the radio.
  • The repetitive task timers are started for ongoing piWebCAT operation.
  • initTunerA()  stores the x/y coordinates of the blue mouse/thumbwheel tuner.
  • initRxTuner() stores the x/y coordinates of the the tuning scale area.

The final start up events are performed by the just started repetitive tasks.

  • The frequency is read from the radio.
  • The current band is derived form the frequency.
  • The appropriate band tuning scale is installed and the read marker set.

Band and VFO change

Note that some of the above sequence is performed on band change.
(VFO change will often cause a band change)

In particular, the slider and buttons states are reloaded from the radio because many modern
radios store a complete set for each band.
The buttons and sliders are unresponsive for a few seconds while the new settings are
loaded from the radio.  The client stores the most recent setting for each VFO so that

on VFO swapping repeated reload from the radio is not needed.  See: Dual VFO switching.

When operating split frequency mode between two bands, the control reload does not occur.
The frequency shows the transmit band frequency but the tuning scale stays on the receive band
with the marker coloured olive at the band edge.