Hamlib/kenwood/ts2000.txt

352 wiersze
12 KiB
Plaintext

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?