[aprssig] making AGWPE work with an Icom IC-7100

[Stephen H. Smith]

***  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
>     transmitting).
>


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 
concluded:



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 
7100.

[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 
software.

[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:
     http://wa8lmf.net/6-Pin-MiniDin-Data-Connector

With either of these, you wouldn't use the "sound card" built into the 7100 at 
all.



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 
milliseconds.

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
Skype:        WA8LMF
EchoLink:  Node #  14400  [Think bottom of the 2-meter band]
Home Page:          http://wa8lmf.net

Live Off-The-Air APRS Activity Maps
    <http://wa8lmf.net/map>

Long-Range APRS on 30 Meters HF
    <http://wa8lmf.net/aprs/HF_APRS_Notes.htm>