File: c:\cbproj\Remote_CW_Keyer\Hamlib_traffic_example.txt

TCP-Stream dump of a Hamlib session between WSJT-X (client) and wfview (server).
Lines beginning with a backslash, or just a single LETTER
      are usually the commands (client to server),
other lines are usually the response lines (server to client).
Not visible in this Wireshark dump: Each line ends with a '\n' character only.
Empty lines before a new command (client to server) added manually for clarity.
C++ style comments also added manually, when trying to understand what's going on.
LATER (when the Remote CW Keyer was fit enough to 'serve' e.g. WSJT-X),
other commands (get,set,check..) were copied here from the application's "Debug" tab.

\chk_vfo
0

\dump_state  // a poorly documented monster .. "use the source, Luke", e.g. wfview's "rigctld.cpp" !
1            // (1) this possibly is the "rigctld protocol version"
3081         // (2) some say this is the "radio model", others say it's a "radio number" or a "rig model". Buaah.
0            // (3) rigctld "rig state itu region" (forget it, a dummy, nobody uses this)
144000000.000000 1400000000.000000 0x620617fff -1 -1 0x16000000 0x0 // (4) first RX frequency range list
0 0 0 0 0 0 0 // (5) most likely a list entry with "all zeros" marks the end of the above list
144000000.000000 148000000.000000 0x620617fff 2000 100000 0x16000000 0x0 // (6..) first TX frequency range list
420000000.000000 450000000.000000 0x620617fff 2000 100000 0x16000000 0x0
1240000000.000000 1400000000.000000 0x620617fff 2000 100000 0x16000000 0x0
0 0 0 0 0 0 0 // (7) another list entry with "all zeros" to mark the end of the above list
0x620617fff 1     // (8..) this seems to be a list of supported "tuning steps", 2nd argument in Hertz,
0x620617fff 10    //  but what's that mysterious hexadecimal crap in the 1st argument, "modes" ?
0x620617fff 100   //  (discovered later: It's in fact a BITWISE COMBINATION in a 64-bit integer)
0x620617fff 1000
0x620617fff 2500
0x620617fff 5000
0x620617fff 6125
0x620617fff 8333
0x620617fff 10000
0x620617fff 12500
0x620617fff 25000
0x620617fff 100000
0x620617fff 250000
0x620617fff 1000000
0 0             // (9) marker for the end of the above "tuning step" list ?
0x6c0c 3000     // (10..) list with "modes" and "bandwidths" ?
0x6c0c 2400
0x6c0c 1800
0x20410201 9000
0x20410201 6000
0x20410201 3000
0x82 1200
0x82 500
0x82 200
0x600201060 15000
0x600201060 10000
0x600201060 7000
0x110 2400
0x110 500
0x110 250
0 0            // (11) marker for the end of the above "filter bandwidths" list ?
// (12), "channels", seems to have been removed in newer versions, breaking compatibility (lacking keywords or simple key=value pairs in this...)
9900           // (13) "max_rit" ?
9900           // (14) "max_xit" ? 
10000          // (15) "max_ifshift" ? 
0              // (16) "announces" ? ?
10             // (17) "preamp" ?
10             // (18) "attenuator" ?
0xffffffffffffffff // (19) "has_get_func" : sounds like a boolean but it's a "setting_t"...
0xffffffffffffffff // (20) "has_set_func" : also a "setting_t", which indeed is a SIXTYFOUR BIT integer. Aaaaargh ! ! ! 
0xffffffffffffffff // (21) "has_get_level": also SIXTYFOUR BITS, defined as RIG_FUNC_... in ?/include/hamlib/rig.h
0xffffffffffffffff // (22) "has_set_level": also an extremely microcontroller-unfriendly 64-bit-combination .
0xffffffffffffffff // (23) "has_get_parm"
0xffffffffffffffff // (24) "has_set_parm"
vfo_ops=0xff       // (25) WHOW, someone invented proper key=value pairs ! Hip-hip-hooray !
ptt_type=0x1
has_set_vfo=0x1
has_get_vfo=0x1
has_set_freq=0x1
has_get_freq=0x1
has_set_conf=0x1
has_get_conf=0x1
has_power2mW=0x1
has_mW2power=0x1
timeout=0x3e8
done          // (26) "done" seems to be a token, too. Where to find this in the Hamlib "manpage" ?

v                    // short form of a "get"-command: 
VFOA                 // response: "the current VFO is VFO a" (or something in that style)

V Main               // short form of a "set"-command
RPRT 0               // "RPRT" followed by a Hamlib error code, 0 = "no error"

f                    // short form of a "get"-command : what's the frequency ?
144300000            // here is our frequency in Hertz

V VFOA
RPRT 0

V Sub
RPRT 0

f
0

V VFOA
RPRT 0

s
0
VFOB

V Main
RPRT 0

m
USB
3000

V VFOA
RPRT 0

F 144300055.000000
RPRT 0

f
144300055

F 144300000.000000
RPRT 0

f
144300000

v
VFOA

s
0
VFOB

m
USB   // first response line for "m"=mode?
3000  // second response line for "m", possibly a bandwidth ?

t
0

// After this, WSJT-X didn't ask any other "questions" but kept the TCP/IP socket open endlessly.
// There doesn't seem to be something like a periodic connection check, "ping", or similar.
// The following fragments were copied from the Remote CW Keyer's "Debug" tab
// after e.g. WSJT-X tried to "QSY" to another band, or switch from RX to TX and back.
// The Hamlib server decorates each "command line" with a timestamp, RX/TX info, 
// and the length in bytes.



// Example: External Hamlib client wants to switch frequency (or band):
20:05:28.6 HLSrv0 [0018] F VFOA 144174000.000000\n  // set frequency of "VFOA" to 144.174 MHz
20:05:28.6 TX0 [0007] RPRT 0\n                      // Hamlib server says ok 
20:05:28.6 HLSrv0 [0007] f VFOA\n                   // WSJT-X asks "what's your frequency, VFOA" ?
20:05:28.6 TX0 [000A] 144050000\n                   // "VFOA" says "I'm still on 144.050 MHz"
20:05:28.6 HLSrv0 [0002] v\n                        // WSJT-X asks "who's the currently active VFO" ?      
20:05:28.6 TX0 [0005] VFOA\n                        // Hamlib server answer's "it's still me, VFOA"
20:05:35.1 HLSrv0 [0002] v\n                        // WSJT-X asks again: "Ahem.. who was that, VFO" ?
20:05:35.1 TX0 [0005] VFOA\n                        // Hamlib server answer's "it's still me, VFOA" 
20:05:35.1 HLSrv0 [0007] s VFOA\n                   // WSJT-X asks for the "split mode" of "VFOA"
20:05:35.1 TX0 [0007] 0\nVFOB\n
20:05:35.1 HLSrv0 [0007] f VFOA\n
20:05:35.1 TX0 [000A] 144050000\n
20:05:35.1 HLSrv0 [0007] t VFOA\n
20:05:35.1 TX0 [0002] 0\n