5.4  FT920  - Problems encountered

I add the short following section to make the reader aware of differences among these radios

 and difficulties with documentation.

Five byte commands

All the CAT manuals refer to a single byte (hex) Opcode and four parameters P1, P2, P3 and P4.

For the FT818 and FT847 they are tabled in the order P1  P2  P3  P4  Opcode.

   They must be transmitted in the order:    P1  P2  P3  P4  Opcode

For the FT920, they are tabled in the order:   Opcode P1  P2  P3  P4

   They must be transmitted in the order  P4  P3  P2  P1  Opcode

I had huge difficulty with this until I looked at the FT100MKV manual which is much clearer on the subject!

Example: Mode setting command:

The FT818 manual specifies:  P1  **  **  **  07    where 07 is the opcode byte (and * means don't care)

P1 is the mode selecting code, eg:   02 = CW  08 = FM  etc

I configure as  tu00000007    
                      ie  tu  00  00  00  07 where the mode code from the button is mapped into digits t and u.

The bytes are observed on scope decode to go out to the radio in the order:

                  P1  P2   P3   P4   Opcode   ie   02  00  00  00 07 (for CW)

The FT920 manual specifies:    0C  P1  **   **  ** where 0C is the Opcode and P1  is the mode code.
(mode codes are totally different from the FT818 and include separate codes for VFO A and VFO B.  )

The bytes are actually sent in the order P4  P3  P2  P1  Opcode  

and so I must configure as:   000000xx0C     (I use xx to allow hex code mapping)

Received frequency data

To read in the 2 x 14 bytes VFO  frequency, mode etc  we use 00 00 00 03 10  (configured as 0000000310)

The manual says VFO A frequency is in bytes 2 to 5.  -  In piWebCAT we are zero-indexed and specify 1 to 4.

The answermask is   #28:01:04:FF:bbbbbbbb    28 bytes to receive, extract 04 bytes starting at byte 01
The bytes are mapped to the following lower case letters: bbbbbbbb.
 (The FF bit mask is unused as it is only for single byte extraction)

I found the download manual to be unclear on the format of the received frequency.

It s actually in binary, ie  14.123450 Mhz is1412345 (to 10Hz) and is received from the radio as 00158CF9.

... I discovered this  - not from the manual, but from my Siglent  scope's serial data decode facility

I have to use bbbbbbbb to force conversion from binary to decimal. (BCD would use xxxxxxxx)

Note that:

Frequency setting for the FT920 is in BCD (binary coded decimal)  .. not binary as frequency read above.

Frequency setting and reading for the FT100MP MkV are both in BCD (The manual is MUCH better)

... all perfectly manageable once you know the correct formats.

FT920 - recall VFO command

This is sent as 00 00 00 P1 05    where, from the manual:

          P1 = 00 is VFOA   and   P1 = 01 is VFOB

I may be missing something here, but my findings were :
                                 P1 = 0 does nothing.  P1 = 01 toggles between VFOA and VFO B

This means that I therefore provide a Swap A/B button but no VFO buttons.
The Swap buttons toggles between the two VFO datasets in VFO A.
I do not use the allocated Swap button because this has built inVFO A/B functions which require
configuration access to specifically VFO A and VFO B, and this doesn't appear to be available.

See -   IMPORTANT  special buttons

FT920  Split on/off:  

 The manual says send as 00 00 00 P1 01  where P1 = 00 is OFF and P1 = 01 is ON.

               My findings were that this switches Tx between VFOA and VFOB  
                       (which is not exactly split on/off !!)

FT920 band switching.

There appears to be no band switching command.

The only way to use the band switching buttons was to configure each with a start frequency for each band as shown:

Band buttons are a group and so use fields nset and nans to send data and to match against received data.

We still link to catcodes with code = BAND.   The data in field nset is the start frequency for the band (NOT a band code)

catcodes is configured to send the data (eg: 3720000) as a frequency   (because, as stated above  - there is no band command?)

piWebCAT quickly responds to the frequency change by recognising the new band and changing its tuning scale.

There was a problem here: If you change band by just changing frequency via CAT, no mode change occurs.
The FT920 continues with the operating mode of the the old band and in fact adopts the mode for the new band.

(The radio does in fact store a mode for each band, and if you change bands with the radio's band switches,

 the stored mode for the new band is applied )

piWebCAT's solution to the band change problem:


When a band is first selected (in a piWebCAT session), the frequency will be from in the button's table above.

piWebCAT is repetitively reading the FT920 frequency.

At each read, I check the frequency against band limits and then store it for the current band.  
So piWebCAT has a record of the latest frequency for each band (modified on the radio or by piWebCAT's tuners.)

If we leave this band and then return to it, piWebCAT examines the nset field.
If this is > 10000, then this indicates that we are configured to change band by frequency (not by band code).

piWebCAT uses the stored latest band frequency to change band rather than the configured start frequency.


Mode is repetitively read from the radio and is stored by piWebCAT for each band.
I have to lookup the nset value rather than use the nans (which matches received data)
because they are different for the FT920.

On band change, if we are using piWebCAT's stored band frequency as described above,
then we use piWebCAT's stored band mode.
This mode is sent to the radio, 2 seconds after sending the frequency.