Version: June 6, 2002 This document provides some data on translating commands from the TS-2000 to/from hamlib. It shows the sequence that should be used to acheive a particular function result. Sometimes a particular sequence should be called. --D. Edmons, kd7eni Note: As a standard convention, I *always* send lowercase to the ts-2000. Replies are *always* in uppercase. One then can determine the source of any string. -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- api_func() "TS-2000_string" ts2000_function() -------------------------------------------------------------------------------- rigerr() "?;" 1) syntax error 2) command not executed 3) transient error 4) bug? some commands cannot be sent twice--see 2)--or rig will send this. "tx;" is one of them! note: should retry at least once! if 4) don't apply "E;" 1) communication error "O;" 1) processing incomplete for_each_opened_rig() none rig_init() "id;" ts2000_init() "ID019;" ts2000_get_id() ? Note: rig_init() should check several things and set a global status. These are as follows: "sc;" Rig is *not* multitasking for 80% of all commands If "SC1;", on either main or sub *both* must be halted before most commands will function. These may be restored after command is executed or not if the command superceeds scan mode. "fr;"/"ft;" or "if;" If in memory mode, the rig won't always act appropriately to serial port requests. "qr;" if quick memory set, same as previous "sr2;" *never* do this or somebody'll be real angry! "ai;" Check if autoinformation is on! If so, you will get continuous output from the 2k (TS-2000). To turn it off: "ai0;", and on: "ai2;" "?;" If this occurs, one of the above may be the cause. Also, the user may have a menu currently selected using the rig front panel. I currently don't know any way to get this info from the rig. I highly reccomend that a message be sent to the user if "?;" occurs on more than one retry, that he/she must deselect this manually. There is no other way. (I've enabled "ai2;" and no string is sent when menu button is pressed or released unless an option is changed "ex...;") rig_open() see rig_init() rig_close() rig_cleanup() none rig_get_freq() Independent of PTT/CTRL rig_set_freq() "fa...;", "fb...;" main receiver only "fc...;" sub reciever only rig_get_mode() rig_set_mode() "if...;" CTRL receiver only Reads multiple paramaters at once. "oi...;" !CTRL receiver only Reads multiple paramaters at once. "md...;" Changes the operating mod of the current receiver (main or sub) ts2000_sub_pwr() ts2000_get_info() if/oi rig_get_vfo() *Main* only rig_set_vfo() "fr...;", "ft...;" These can force split mode if not driven the same. Sending "fr...;" after "ft...;" can change "ft...;" to match "fr...;" Use "fr...;" first and then "ft...;" and things should work ok even if you use this select 'split' mode. If split mode is entered, setting "fr...;" will not take it out. Always both and in the sequence noted in the middle column. These should be set in rig_set_vfo() unless split frequency is being changed. *Sub* only Both "ft...;" and "fr...;" alway match and split not available. Setting vfo_b is not an error but reads back as vfo_a which would be an error. "dc...;" Changes PTT/CTRL to main or sub. rig_get_ptt() "dc;" rig_set_ptt() "dc...;" The modes are as follows: "dc00;" PTT on main (and CTRL) "dc01;" PTT on main (CTRL on sub) "dc10;" PTT on sub (CTRL on main) "dc11;" PTT on sub (and CTRL) rig_get_rptr_shift() rig_get_rptr_shift() "os...;" sets simplex, +, or - offset for E-type use: "os3;" rig_get_rptr_offs() rig_get_rptr_offs() "of...;" sets offset frequency in Hz rig_get_split_freq() *Main* only rig_set_split_freq() First test "fr;" and "ft;" and use the following accordingly: rig_get_split() rig_set_split() rig_get_vfo() rig_set_vfo() acts on CTRL transceiver only note: always set receive first and rig behaves better "fr0;" set receive on vfo_a "ft1;" set transmit on vfo_b "fr1;" set receive on vfo_b "ft0;" set transmit on vfo_a "ft2;" mem "ft3;" call rig_get_rit() rig_set_rit() rig_get_xit() rig_set_xit() "rt...;" RIT on/off, read "xt...;" XIT on/off, read "rc;" clears offset (=0 Hz) "if;" Get much info for CTRL including xit/rit on/of + offset in Hz ts2000_get_rit_hz() "oi;" Get much info for !CTRL including xit/rit on/of + offset in Hz If CTRL is on main, "if;" reads main and "oi;" reads sub. One still needs "dc;" to determine which transceiver has CTRL selected at any given moment! Proceedure: As far as I can tell, do as follows: 1) turn on xit or rit "rt1;" or "xt;" 2) read current offset ("if;") 3) clear offset if desired "rc;" 4) ensure main is selected "dc00;" 5) "ru12345;" (or "rd12345;" for negative offset) "ru;" will add 10Hz, "ru00001;" will add 1Hz 6) if offset is already correct, 4),3) may be skipped rig_get_ts() rig_set_ts() "st...;" depends on current mode rig_power2mW() none rig_mW2power() none rig_get_dcs() rig_set_dcs() rig_get_ctcss() rig_set_ctcss() "tn...;" get/set tone freq "cn...;" get/set ctcss freq "qc...;" get/set dcs freq rig_get_dcs_sql() rig_set_dcs_sql() rig_get_ctcss_sql() rig_set_ctcss_sql() "ct...;" enable/disable ctcss "to...;" enable/disable tone (3=noop!) (use 0 or 1) "dq...;" enable/disable dcs Note: sending "ct1;" results in "to0;" and "dq0;" being set. These are exclusive of the others, but all may be off as determined using minicom and setting "ai2;" :) I may have the enable verses set freq backwards with respect to the c/c++ function. rig_poweroff() "ps0;" turn rig power off "sb0;" turn sub-receiver off (set to VFO mode first--you have been properly warned.) If left in scan, then powered off, main is still affected as if sub is still scanning! This is better read as sub-display off. However, you can't switch CTRL to sub to place it in vfo mode.... (You've switch power off...) ;) rig_poweron() "ps1;" listed but *not* functional (tell user to manually intervene.) The b2000 may? "ps;" either on or no reply! silly huh? "sb1;" turns sub-receiver on (display and controls now work). rig_get_level() ??? rig_set_level() // caveats will be listed as found... // This isn't set-level stuff is it? what was I thinking? "to0;" "to0;" Second command is an error! "to1;" "to1;" Second command is an error! "to2;" Toggles current ( curr=!curr ) "to3;" doesn't toggle ( curr = curr ) NOOP correct preceedure: send("to;", reply); // request current if( reply!=request) send("to2;", NOREPLY); "ct0;" same as above but '2','3' not avail! "ct1;" Correct command can be sent but error occurs if rig is already in requested mode. "?;" should then be ignored. (applies to "to...;" also.) rig_has_level() ??? rig_has_set_level() ??? rig_has_func() ??? rig_has_set_func() ??? rig_get_func() ??? rig_get_mem() "mr...;" memory read rig_set_mem() "mw...;" memory write each memory has a tx and rx, so you may do split memory. rig_mv_ctl() "fa...;", "fb...;", "fc...;" vfo freq "ft...;", "fr...;" vfo select (A, B, mem, call) "mc...;" memory channel select rig_set_bank() none (only 300 memories) Note: There is a related function: "pm...;". There are five of these "programable memories". The manual barely even mentions it. I don't know of any way to access these other than with the "pm...;" As far as I have been able to determine, the menu A/B settings etc get saved but *not* the channel memories! These may be related or similar to the five or ten satellite memories etc?? To set the programable memory use "pi...;" and use "pm...;" to recall it. Values are 0-5. "pi0;" is not valid, but "pm0;" is. rig_set_channel() ?? see rig_get_mem() ?? rig_get_range() rig_get_trn() "ai;" auto info get state rig_set_trn() "ai0;", "ai2;" auto info on/off rig_get_info() unknown related: "if;", "oi;" get info for main, sub "id;" 019 => TS-2000 -------------------------------------------------------------------------------- End of functions documented in hamlib-1.1.0.pdf. -------------------------------------------------------------------------------- Other notes of interest. "dc00;" PTT/CTRL both on main receiver (e.g. selects main as current!) "dc11;" PTT/CTRL both on sub receiver (e.g. selects sub as current!) "sb1;" Power up/down sub-receiver "mf0;", "mf1;" The ts2k (TS-2000) may send these to switch between menuA and menuB. It isn't possible to see if the user has pressed the menu button. However, after the button is pressed a second time the rig sends the "ex...;" command the user changed. The rig will set what the user selects immediately in the rig, but doesn't send them out the port until menu is deselected. I use "mf0;" (menuA) for VHF settings and "mf1;" (menuB) for HF settings. "?;" When this occurs the previous command should always be retried. However, several of the things as in rig_init() may be the culprit. If this occurs, then check more closely as in rig_init() before retrying or it may be a waste of time. Additionally, some commands send this if the current mode is not compatible with the one just sent. This is just common sense usually. Note: there are exceptions to this. see BUGERR in ts2k.h and "to...;" "ct...;" above... (also occurs on "tx;" if sent twice) "pk...;" Packet clusters are received when: 1) TNC on sub 2) sub freq set to station sending packet clusters 3) "cm1;" sent to rig Sending "pk;" to the receiver retreives the PCT data. If you send the ";" again, the rig sends the data again. Up to 10 are saved in temporary memory pushing out the oldest. But, true to form, there is a bug. When PCT is active "qr...;" should recall past data. It don't. Moreover, "qr...;" actually writes the quick memory to the current VFO rather than the PCT. There appears to be no way to fully use this without going to the TNC directly using "tc 0;". Again, true to form, once the TNC is active, you must use the panel menu to turn the TNC off and there is no way to fully use this in software. The B2000 must have better firmware and slightly different hardware. Else, there's something Kenwood isn't telling us! TNC summary: "pk...;" retreive last PCT data "cm...;" enable/disable PCT "tc ..;" (note space) TNC ext/int (sortof) "ex055...;" enable (*cannot* disable) TNC Once "tc 0;" is set, the serial line is an active TNC port and not the rig port. Since the TNC don't have an exit or quit command, it stays active until user goes to menu(55) and turns it off! Sending a ";" doesn't help but "\n" is the TNC end of line and shows your errors. ("\nEH?\ncmd:") Sending any full command stops the rig from replying to single ";"'s (after "pk...;"). The "ai...;" command does not seem to be related even though the manual says it is. (Original paperback, not new pdf) ("ai...;" seemed to bring the rig out of its confused stat when "qr...;" was sent, but I don't what happened. PCT would not function via the panel but I didn't think to try "cm...;" Avoid the TS-2000 if you have more than a casual interest in its digital modes and want your rig in the attic! Kenwood seems very disinterested in making firmware updates available under linux. Any suggestions?