kopia lustrzana https://github.com/Hamlib/Hamlib
initial release
git-svn-id: https://hamlib.svn.sourceforge.net/svnroot/hamlib/trunk@1067 7ae35d74-ebe9-4afe-98af-79ac388436b8Hamlib-1.1.4
rodzic
7fbfa8a745
commit
51f3497fbf
|
@ -0,0 +1,351 @@
|
|||
|
||||
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?
|
||||
|
Ładowanie…
Reference in New Issue