<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/16/2023 11:06 AM, Michael Ford
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1027050759.1792968.1702742767480@mail.yahoo.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div class="ydp626a44cyahoo-style-wrap"
style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px;">
<div dir="ltr" data-setdir="false"><br>
</div>
<div dir="ltr" data-setdir="false">You bring up an interesting
use case: the ability to use two or more modes from one radio
set on one frequency. This obviously allows someone to enjoy
multiple modes without going to the expense or complications
of running multiple radios.</div>
<div dir="ltr" data-setdir="false"><br>
</div>
<div dir="ltr" data-setdir="false">The suggestion you passed
along is to have the 500Hz VARA signal on a 1500Hz center and
the ~200Hz Packet signal on a 1700Hz center, which has
overlap. In my experience, VARA doesn't detect Packet well
before transmitting and will step on it. So where the two
protocols do not share a frequency space well together, it may
be better to separate them to avoid adverse impact on the
packet community.</div>
<div dir="ltr" data-setdir="false"><br>
</div>
<div dir="ltr" data-setdir="false">That being said, there's
plenty of room in the passband to accommodate Stephen's use
case. So why not shift packet off of its 1700Hz center
frequency to be out of the way of VARA? Both Soundmodem and
Direwolf (if not others) support such a configuration.<br>
</div>
<div dir="ltr" data-setdir="false"><br>
</div>
</div>
</blockquote>
<p><br>
</p>
<p>Back from my 60 meters APRS-over-VARA road trip Saturday. It
was a spectacular success. Nearly constant tracking over the 220
mile drive both day and night. </p>
<p>An added unexpected bonus for the test was Denis WB8SKP near
Paducah, Kentucky sending me APRS messages to the 60M mobile. His
QTH is about 450 miles to the southeast of my home, and farther
from the trip route. His first message popped up on my mobile
Panasonic Toughbook CF-51 mid-day when I didn't think 60M NVIS
propagation would support that long a haul. We exchanged several
messages back and forth. Later, hours after sunset, he
successfully contacted me again with messaging both ways. He was
tracking me directly off RF - not from the Internet via my igate
-- for nearly the whole trip. <br>
</p>
<p>My thinking on the tone/frequency choices for VARA APRS is as
follows:</p>
<ol>
<li> IBM once referred to "the tyranny of the installed base"
when their PS/2 family of PCs with a new kind of expansion slots
failed to redefine PC architecture away from their
wildly-successful PC/AT "ISA" ("Industry Standard Architecture")
expansion slot designs that everyone cloned and made millions of
expansion cards for. HF APRS has a similar problem.<br>
<br>
HF APRS on 30 meters has been done on standard AX.25
200-hz-shift HF packet for nearly FORTY years now. A lot of the
igates and gateways on 30M still use classic TNC hardware like
TNC-2s, MFJ-1270s, Kantronics KAMs, etc who's audio tones for
200-hz shift are fixed at 1600/1800 Hz; i.e. 1700 Hz center
frequency. <br>
<br>
The actual RF HF mark/space frequencies for 30M packet APRS have
always been 10.149.200 / 10.149.400 MHz. This has required
tuning an HF/SSB transceiver to 10.147.60 MHz USB to yield the
correct audio tones. <br>
<br>
[In the early days, when many assumed HF/SSB below 20 meters
should always be on LSB, many actually set the radio dial
frequency to 10.151 LSB (i.e. outside the ham band) and trusted
to God or something that their carrier suppression was really
good in order to place the 1600/1800 Hz tones on the correct RF
frequencies INSIDE the band limits. Many transceivers that
wouldn't transmit when the dial frequency was outside the ham
bands had to be hacked with the "general-coverage-transmit" mod
to work.] <br>
<br>
Bottom line: The 10.147.600 USB dial frequency is totally and
unchangeably embedded in HF APRS operating conventions. <br>
<br>
</li>
<li>Further re-reinforcing the current RF frequencies vs audio
tones convention is that the TinyTrack III (still the cheapest
and simplest way to generate APRS transmissions) emits fixed
1600/1800 Hz tones in HF mode.<br>
<br>
</li>
<li>The VARA-HF "soft TNC" generates an unchangeable tone spread
centered around 1500 Hz. <br>
<br>
</li>
<li>If VARA is going to become part of a multi-mode igate,
piggybacking on the existing packet APRS, using the same radio,
unavoidably it will be 200 Hz "off frequency" relative to packet
APRS.<br>
<br>
</li>
<li>In my experience, the carrier detect/TX inhibit of VARA is
actually quite good. In fact, it has a good implementation of
random delay before transmit when a detected signal goes away. <br>
<br>
During my 60m test, wobbly unstable harmonics of switching-mode
DC-DC power converters somewhere in my car periodically drifted
across the passband of my 60m receiver. Whenever they became
audible, the VARA transmit was disabled. <br>
<br>
On my <b>30</b>-meter combined packet/VARA igate, VARA shows a
carrier-detect (CD) whenever either on-freq packet APRS bursts
or the "just-below-but-audible" robust packet bursts happen. <br>
<br>
</li>
<li>The total volume of traffic on HF APRS is low enough that
collisions between packets, either of the same mode or of
different modes, is relatively rare. Further, given the
repetitive nature of APRS beaconing, an occasional lost packet
or two is not a major issue.<br>
<br>
</li>
<li>Further, a large portion of the current ham population simply
doesn't understand the relationship between audio frequencies
and the resulting RF frequencies on SSB. Expecting them to
offset the variable generated packet audio tones in applications
like the UZ7HO Soundmodem or DireWoif to 1500 Hz center freqs,
and then offset the radio dial frequency correspondingly is
unrealistic. Not to mention that the classic hardware TNCs,
Tiny Tracks, etc CAN"T BE CHANGED! Trying to get uptake for a
new audio tones and RF dial setting convention would be
hopeless....<br>
<br>
</li>
</ol>
<p>In light of all these issues, I concluded we must continue to
live with the 1600/1800 packet tone pairing! The simplest
compromise was to JUST LIVE with the VARA center frequency being
200 Hz lower than the packet center frequency. <br>
</p>
<p>For classic packet-only operation on both 30 and 60 meters, for
years I had been receiving through 500 Hz Collins mechanical
filters on Yaesu FT-857s with their IF shifts moved from the usual
700 Hz CW pass-band center to around 1700. </p>
<p>Now the "multi-mode" igates are receiving through FT-891s with
their DSP continuously-variable IFs set to around 650 Hz bandwidth
and IF-shifted slightly low. It works perfectly and dramatically
reduces AGC activation and receiver sensitivity reduction from
ambient noise, compared to the usual default 2.3 Khz USB
bandwidth. </p>
<p>As far as I know, the FT-891 is the least-expensive 100-watt HF
radio to have a fully-variable DSP IF system - on periodic
promotion specials from Yaesu they can be had for USD $550-600.
The FT-891 has a HORRIBLE multi-layer menu structure, but they are
excellent performers for digi-modes projects, SSTV, etc. <br>
</p>
<p><br>
</p>
<hr width="100%" size="2">Stephen H. Smith wa8lmf (at) aol.com <br>
Skype: WA8LMF<br>
EchoLink: Node # 14400 [Think bottom of the 2-meter band]<br>
Home Page: <a class="moz-txt-link-freetext" href="http://wa8lmf.net">http://wa8lmf.net</a><br>
<br>
"Studio B" Ham Shack on Wheels<br>
<a class="moz-txt-link-rfc2396E" href="http://WA8LMF.net/Aliner"><http://WA8LMF.net/Aliner></a><br>
<br>
-- APRS over VARA --<br>
<a class="moz-txt-link-rfc2396E" href="http://wa8lmf.net/VARAforAPRS.htm"><http://wa8lmf.net/VARAforAPRS.htm></a><br>
<br>
60-Meter APRS! HF NVIS APRS Igate Now Operating<br>
<a class="moz-txt-link-rfc2396E" href="http://WA8LMF.net/map/"><http://WA8LMF.net/map/></a><br>
<br>
Flying Digipeater!<br>
<a class="moz-txt-link-rfc2396E" href="http://WA8LMF.net/FlyingDigi"><http://WA8LMF.net/FlyingDigi></a><br>
<br>
<br>
<p><br>
</p>
<p> <br>
</p>
<p><br>
</p>
<p> <br>
</p>
</body>
</html>