2.11 Learning guide: Transceiver-H-A

2.11 Learning guide - Transceiver-H-A (--vfo) Transceiver-H-A-NV (non --vfo)

This is a very limited Hamlib configuration.
Start piWebCAT in a web browser by entering the IP address 192.168.1.117 (or your changed value).

Click the Config button.
The configuration page always opens in the buttons editor (table: buttonshl for HAMLIB)

Select radio Generic Hamlib TRX A from the drop list selector. (Should be selected by default on new card).

Click the radios button on the button bar.

The radios table shows IC7000-H (H = HAMLIB) and Transceiver-H-A B and C. All four are Hamlib configured.

You are dealing with Transceiver-H-A now, but you might as well apply your settings to all three of A, B and C.

For each of A to C you need to enter:

The radio's Hamlib code as determined above.
vfomode = Y (selector edit) Transceiver-H-A uses --vfo mode which rigctl needs for a dual VFO system.
All commands contain VFOA or VFOB (sometimes as a dummy)
eg: \set_level VFOA NR # In piWebCAT the # is substituted with the value from the slider control.
Transceiver-H-A-NV has vfomode = N. Commands are of the form: \set_level NR #
connection = USB or SERIAL (Icom CI-V is SERIAL)
catcomms = HAMLIB - to connect via the Hamlib rigctld system.
civaddr if using an Icom rig. Enter in hex format eg: 0x70 as above for the IC7000.
rigfix = nofix
baudrate - This applies to USB connections as well as serial (I have to specify it in my FTdx101D)
stopbits = 1 or 2, charbits = 8, parity = none for most radios.
vfobvis = Y Whether VFOB to be displayed ( maybe = N for single VFO radio)
afswap = N initially. See section 1.6 Audio gain swapping

Editing a piWebCAT configuration table:

Editing is inline - simply click on the row for editing and then click the cell (otherwise you'll edit the id column)

Here, in the radios table, all fields except hamlib, description, civaddr and command are droplist selectors.

Click the button to save your edit. (Hint: Hover the mouse over the buttons to reveal their functions)

Configuration editors

I am quite deliberately discussing the tables and their data on this minimal configuration of Transceiver-H-A

... in order to keep things simple !!

Note that all the database table records for a radio have the same rig field (eg: Transceiver-H-A )
and that this must also match the rig field of the radio's single record in the radios table.

If you misspell this field then that record is lost from view in piWebCAT. (You can retrieve with MySQL Front.)

Fortunately, when you add a new record to a table for a radio, piWebCAT automatically populates the rig field

with the identifier of the current rig - so you don't get the chance to misspell it.

Now explore the other table edit buttons on the button bar (ie: buttonshl, carcodeshl etc)

These access the configuration tables and are restricted to the selected radios (which is very convenient!)

Have a good look at how the controls are configured.

Some import guidance with this:

buttonshl table - This has data held by the client. (Extracted from server MySQL database at startup)
ie: btnno (unique id) button appearance, behaviour etc and the data to send to the server.
The code field (eg: BAND) indicates the job.
vx is A or B if current-vfo specific, otherwise X.
The data for grouped buttons (eg: BAND, action = G) is always in fields nset and nans.
The data for other buttons is in fields seton, setoff, anson and ansoff
catcodehl table - This has data used on the sever.
readmask and setmask are the read and write commands from server to Hamlib rigctld
(or direct to the rig for non-Hamlib configuration).
The # character is substituted by the data from the client button configuration.
answermask with Hamlib is only used with rig commands (if no Hamlib alternative)
code = FREQ In catcodeshl this is the frequency read and write command.
Most of the time, the calls from client to server \set_freq arise from user tuning actions.
Some arise from band switching or UP/DOWN buttons.
Calls to \get_freq are repetitive timer driven actions at intervals in the timers table.
Band switching See buttonshl table. Many radios do not have a band switching CAT command,
so we have to send a frequency in order to change band.
piWebCAT detects the frequency change and switches band on the display.
We send frequency here in this generic setup because it should work with most radios.
piWebCAT remembers the last frequency on each band and so will return to the last
used frequency on returning to a band.
slidershl table This table conifigures 25 sliders (and four text data items).
It contains both client and server data.
(Unlike buttons which have separate tables, ie: button client data in table buttonshl and
server data in table catcodeshl.)

Server data is similar to catcodeshl but with numeric data: eg \set_level VFOA NR #
Client fields min and max define the range of data as read / sent to / from the radio.
piWebCAT matches the min and max value to the full range of slider travel.

Fields mult, divide, offset and decpoint scale the numeric data for presentation to the
right of the slider. Field units is optional units display.
Field lookup (Y or N) determines whether a lookup table should be used when

the relationship between incoming data and display value is non-linear,
eg: 1 2 3 4 displaying as 50Hz 100Hz 200Hz 400hz.

timings table This defines the repeat intervals at which different repetitive tasks are queued on the
client for transmission to the server.
The shorter readqueue interval is the polling rate for sending from the queue.
Note that the use of this managed queue was vital in maximising use of the
client <> server data bandwidth.

Now explore these table editor buttons selecting with the button bar (ie: buttonshl, carcodeshl etc)

The editors work on data filtered to present only the selected radio (which is very convenient!)

Now, with the radio switched on, click the top bar Control button.
piWebCAT should link to your radio and display the VFO frequencies and modes.
Band and mode switching should be operational.

Note that you have to wait 2 seconds or so after band change for the display to stabilise before you can tune
and operate other controls. This interval is longer with many controls configured.

If you switch bands simply by changing VFO, then once you have visited each band, the stabilisation is
much faster. This is because piWebCAT remembers the complete last control set for each VFO.

Note that IF width is on this minimal display.
This is because Hamlib reads and writes IF width and band in a single command.
This gives piWebCAT coding some work to do in correctly processing the dual data returns.

Mode and IF Width share common commands

Note that Hamlib combines mode and IF Width into single \get_mode and \set_mode commands.
This adds some complexity, as I have to separate and combine the two values.
The detailed explanation of this is in Section: 8.12 rigctl mode and bandwidth

Note the MOX button. It should be able to perform T/R switching.

It should respond to T/R switching from the radio.
I include it at this stage because Tx / Rx status is tested after band change.

Mode button group

MODE button and button groups caution.

My FTdx101D has fifteen modes.

piWebCAT, here has seven mode buttons configured as a group linked to seven of the fifteen modes.

If I do all my mode selection on piWebCAT, then there is no problem.
If, on the rig, I select a mode that has no corresponding piWebCAT button, then the message
box below will appear as piWebCAT starts or when the such a mode is selected.

The message only appears once and then is supressed until you restart piWebCAT.

A similar generic message box will appear if the problem arises in other button groups.
The box occurs on start up. The box will appear if the unrecognised condition is subsequently selected

but only if the button group has active=S which is sync mode for regular updates.