[aprssig] making AGWPE work with an Icom IC-7100
Stephen H. Smith
wa8lmf2 at aol.com
Sun Jan 18 14:32:37 CST 2015
*** SEE BELOW ***
On 1/18/2015 10:53 AM, Andrew P. wrote:
> VOX doesn't appear to work. I can cough at the radio and it will key up, but
> forcing beaconing won't key it (even though I'm still receiving packets just fine).
> Time to tinker some more. Thanks for the advice, both of you.
> Andrew, KA2DDO
> Greetings, all.
> This is going to be a weird question, but has anyone gotten AGWPE to work
> with an Icom IC-7100 radio? I thought this was the only radio hookup I was
> getting successful PTT operation with (using fldigi and flrig, according to
> the setup directions for the 7100), but using the same setup for AGWPE, I
> can hear packets just fine (better than with the hardware TNC I have
> connected to another radio), but I can't get the 7100's transmitter to key
> up (even though AGWPE blinks the task bar lights to indicate it is
I assume you are trying to use the USB "sound card" embedded in the IC-7100.
Having downloaded the Icom manuals and "driver" package for this radio I have
1) The manuals are remarkably un-informative about the use of the USB sound
system and how it interacts with the rest of the radio.
2) Traditionally, sound card apps have applied PTT and/or CW keying and/or
RTTY direct FSK keying to radios via the HANDSHAKING lines of a COM port. (The
TXD / RXD data conductors are not even used)
Typically the "DTR" (Data Terminal Ready) or "RTS" (Request To Send) pins are
used for PTT or CW are forced HI or LO by the sound card app as needed, while
the incoming "CD" (Carrier Detect) or "DSR" (Data Set Ready) lines are used to
bring COR/squelch into the computer if used. [DSR and CD are both references
to archaic dialup modems attached to a com port.] The "interface" is simple
transistor switches or opto-isolators between the serial port pins and the
radio PTT/CW key/FSK connectors.
By contrast, the IC-7100 CI-V interface transmits actual data strings
(commands) for "TRANSMIT ON" and "TRANSMIT OFF" over the DATA conductors of the
real or virtual COM port. These are in addition to hundreds of other possible
commands for band, mode, filter settings, read meters, recall memories, etc.
3) The virtual serial interfaces over USB on the 7100 are created by the same
Silicon Labs (Silabs) CP=210x serial-over-USB driver and chipset used by the
Kenwood TH-D72 handheld and the Yaesu SCU-17 external interface unit. These is
nothing special or proprietary to Icom about the interface.
4) The combination of two virtual serial ports and the audio "sound card"
device passed over one physical USB connection appears to be virtually
identical to the Yaesu SCU-17 interface. The SCU-17 contains a USB hub to
support three devices over one USB cable, two Silabs USB-serial "dongle" chips
(one connected to a physical DB-9, the other used internally for the usual
DTR/RTS keying of PTT, CW and RTTY FSK), and a C-Media audio chip.
In my XP and Win7 systems, plugging the SCU-17 device in causes 4 separate
devices to appear in the Windows Device manager: USB Hub, "USB Audio Codec"
(the "sound card"), and two "CP210x USB-to-UART-Bridge COM Port" devices. The
hub and the audio device are native to Windows (no special driver needed) while
the virtual COM ports require installing a Silabs driver.
*** Are you seeing something similar with the FT-7100 ?
5) FLdigi works because the companion FLrig interface drivers mediate between
the generic "wiggle a COM port handshaking line to key" type of PTT and Icom's
screwball proprietary CI-V command interface.
AGWpe (or the UZ7HO Soundmodem which emulates AGW with superior performance)
only do the classic "dumb hardware" type of PTT keying using the RTS or DTR
handshake lines (not sending explict commands over the TXD/RXD data conductors)
of a serial port.
Unless the radio's internal VOX system can be made to respond to audio from the
internal USB "sound card" , there will be no easy way to make applications
that lack the translation to Icom's proprietary control scheme work with the
[FWIW the Yaesu FT-817/857/897 actually DO provide a "DATA VOX" function for
the rear-panel mini-DIN "data" port that is completely separate from the voice
VOX for the MIC jack, configurable from the hundreds of menu items in these
radios. The IC-7100 manuals don't seem to indicate if there is a similar
feature buried somewhere in the 7100 with a menu to enable it.]
5) You could set AGW/UZ7HO/any-other-soundcard-app to do the usual DTR or
RTS "wiggle" of a separate COM port (real or via USB<-->serial dongle) on the
PC, and then couple that to the PTT line of the 6-pin mini-DIN data port on the
IC-7100. The mini-DIN accepts classic "pull-to-ground to transmit" PTT keying.
A single $1.00 opto-isolator will do the job, and provide a positive
hard-keyed PTT scheme that will work with virtually ANY ham sound card
[I've always been uneasy with the data-string command-interface type of scheme
for PTT that sends one string to command "PTT ON" and a separate string to
command "PTT OFF". If the application or OS on the PC locks up or crashes on
transmit (RFI, software bugs, etc), you are stuck on transmit with no way to
send the command to unkey. ]
6) Or you could use an external tone-keyed (i.e. VOX-like) interface like my
design here ( http://wa8lmf.net/ham/tonekeyer.htm ) or it's commercial
counterpart, the Tigertronics Signalink. These devices need NO comport of any
kind for keying. You would plug either into the 6-pin mini-DIN "data port" on
the back of the 7100.
Details on the so-called "data port", which is actually just TX and RX radio
audio and a PTT line, is standardized across all the Japanese radio mfrs.
Details on the mini-DIN interface is here on my website:
With either of these, you wouldn't use the "sound card" built into the 7100 at
7) Even if you can come up with some kluge of intermediate software
protocol conversions to let AGW or the UZ7HO Soundmodem "talk to" the IC-7100's
CI-V command interface, the time delay between when the soft TNC says "TX" and
when the radio actually responds will probably be horrendous.
Due to the protocol conversions and the need for the radio to parse commands it
receives, it could easily run to hundreds of milliseconds. This will force you
to set TXD (Transmit Delay) in the packet modem software to hundreds of
RX-to-TX and then TX-to-RX turnaround time is not an issue with modes like
RTTY, PSK31, SSTV, etc but is a MAJOR issue in packet-based modes where you
want absolutely as little time possible between "no longer listening" and the
beginning of RF output to minimize the chances of on-the-air collisions of
packets. Ideally, you want less than 50-100mS TX delay on packet systems.
(My hard-key tonekey design will issue a PTT low less than five milliseconds
after the audio packet tones begin, and unkey when the tone stops in about the
same amount of time.)
Stephen H. Smith wa8lmf (at) aol.com
EchoLink: Node # 14400 [Think bottom of the 2-meter band]
Home Page: http://wa8lmf.net
Live Off-The-Air APRS Activity Maps
Long-Range APRS on 30 Meters HF
More information about the aprssig