All,
attached is a git patch for adding the Yaesu FT-DX1200 radio to the yaesu
backend as model 134. I am humbly asking for this to be included in
hamlib.
I've tested this using a 1200 radio, using both rigctl and cqrlog. The
ft-dx1200 cat commands are a mix of ft-950 and ft-2000 radio commands, so
neither of those models will work correctly with the 1200. It was tested
and build against the master branch from github on 4/3/2015, on an Ubuntu
14.04 server.
Let me know if you have any questions.
thanks
Dave
kk6df at arrl.net
From cc0351fddc245b6223ae6c21dc6e29c5422fc822 Mon Sep 17 00:00:00 2001
From: David Fannin <dfannin@sushisoft.com>
Date: Sat, 4 Apr 2015 09:23:49 -0700
Subject: [PATCH 1/2] adding yaesu ft-dx1200 model to yaesu backend
Rather than use an oversize buffer and let the reads time out I have
set the expected length to what should come back. This means that
lengthy timeouts are not required every time a response is read.
Also added undocumented split set/get and PTT on/off.
On the FT450 one must select the target VFO using the VSn; command
before attempting to change the frequency. Ths change does that and
reverts the current VFO if necessary.
The TT Argonaut back end was falling over if the rate of returned data
varied because some commands were coded to have shorter than actual
responses, this is not necessary as by increasing the timeout all
characters can be read as expected.
Also fix direct reading and setting of mode per VFO.
PowerSDR accepts a ZZID; command which changes the result of
subsequent ID; commands to ID900;. Since there seems no way of telling
PowerSDR to revert to the true TS2000 ID of ID019; we have to accept
ID900; as a TS2000.
Allow for SmartSDR Kenwood compatible IDs of 904 - 907 as TS-2000
synonyms.
Got a confirmation from Kenwood that the "TY" command returns "TYE 00"
or "TYK 00" for European or USA firmware.
So here's a patch that implements it for the TS590S.
The kenwood_transaction() function expects a buffer large enough for
the null terminated command response less the Kenwood command
terminator (';') but the read_string() call must allow an extra byte
for that same terminator.
I was debugging termios.c and this patch fixes two small problems--two
debug printf format problems and another one that causes an extra char
to be read on timeout.
The extra char problem is easily duplicated by using the "w" command
under rigtctl. Most all other commands use fixed-length response
strings which don't exhibit the problem. But since "w" does not know
how long the response should be it loops until it times out. Every time
it times out it would return 1 extra character (this was 100% repeatable
on two different rigs).
Turns out it was a simple typo in the code as the read was using the
write event instead of the read event.
Buffer size is now an input parameter only as the return data length
is implicit since a null terminated C string is returned. Better
precondition checks are impelmented.
There was an inconsistency in whether the CAT terminator character is
included in returned messages. It now follows the comment in
kenwood_transaction() i.e. strips of the terminator and returns a
message length that reflects that.
Using the priv->info buffer causes security checks on Mac OS X >= 10.9
because the source and destination of an internal strncpy can end up
being the same. It is bad practice anyway as it's undefined behaviour.
Allows for a single ';' for verification with the Elecraft XG3 single
character commands.
Allow for rig specific instance data (needed by the Elecraft XG3 that
is a bit different from the rest of the Kenwood/Elecraft group).
Do not send a startup command to turn off AI mode to the Elecraft XG3
as it doesn't have that command or mode.
Restore the positive RTTY mode enabled check to the Elecraft K2 as it
appears that the MD6; and MD9; comamnds are valid even when RTTY mode
is disabled on the rig.
For Kenwood transceivers the FA/FB/FC command smust be used to get a
VFO frequency, the IF command returns the Tx frequency when
transmitting. The function kenwood_get_freq_if() doesn't adjust for Tx
status or assign the frequency to a specific VFO.
The K2 initialization was checking if RTTY mode was available by
sending an MD6; command and they querying the mode to check if it
worked. The latest kenwood routines now fail if an invalid command is
sent to the K2 initialization need only try the MD6; command to see if
RTTY is available on the rig.
The function kenwood_cmd doesn't add value and it uses a reply buffer
that is not required. Also the use of a reply buffer disables the
verification of commands that have no reply feature. Substituted
kenwood_simple_cmd calls that do the job correctly without a reply
buffer.
Added delay to busy retry loop when sending commands to rig.
Implemented retries on wrong length repies from rig also with a delay.
These rigs can opt to ignore set type commands when they are
busy. This means that sending a set command like FAnnnnnnnnn; to set
the frequency can fail. The rig should send "?;" when busy but since
no reply is normally expected it is not convenient to read for a reply
after a set command since it will block until timeout. This change
sends an "AI;" command after a command that is not expected to reply,
this should guarantee a reply of some sort allowing any busy reply to
be read without blocking and initiate a retry of the original set
command. The "AI;" command is chosen because it is available on all
rigs AFAIK and at least on Elecraft is guaranteed to be processed even
when the rig is busy.