[aprssig] Interesting Findings - 300 Baud AX.25 on VHF-FM APRS

Sat Apr 2 09:37:35 EDT 2016

Great testing!  Very good discussion.

You are correct to be concerned about the length of the packet.  Mobile
flutter is a typical 20 to 30 dB phenomena.  When the signal has 30 dB or
more of margin, there is no problem.  But when one starts getting down
lower, then mobile flutter will still take 20 dB or so off the stationary
performance.  Generally people notice that an FM voice qso range of a
repeater is DOUBLE the range of the same site to an APRS Mobile.

> Using a minimal packet with just position, a WIDE1-1 path,
> and TXD set to 250 mS, the 1200-baud packets took
> around 2 seconds while the 300 baud ones took 2.5-3 seconds.

So, I am confused by this.  My experience is that a 1200 baud APRS packet
is more like 0.5 to 1 second.  I cannot see how it can be 2 seconds long.
That is 240 bytes.  Taking off the 30 byte TXD delay leaves over 200 bytes.
A nominal APRS packet with 1 hop is only 51 and a Mic-E comes in half that.

I do agree, that with the shorter packets, the long TXD is what swamps the
time, so for comparing a 1200 baud and 300 baud Mic-E, I would expect the
actual air time to be about a 2 to 1 difference and not the 4to1 due to
baud rates.

I also wonder if pre-and de-emphasis would improve the performance of the
higher tones in the 1200 baud packet and possibly bring the performance
back to about the same.  In fact, since pre/de-emphasis affects the signal
by over 6 dB, maybe, by not doing it, is where you are losing the 4 dB in
measured performance?

On the other hand.... maybe at 300 baud, the bit is long enough to survive
a phase changing "pop" whereas a 1200 baud bit is about the same width as a
phase "pop" and so always gets hit?

Very interesting things to consider.  Maybe a final comparison while mobile
will eventually answer it.

Bob, WB4APR

On Sat, Apr 2, 2016 at 3:20 AM, Stephen H. Smith via aprssig <
aprssig at tapr.org> wrote:

> I am anticipating a possible APRS public service event in mountainous
> terrain on a non-144.390 channel. Thus no existing digipeater infrastucture.
>
> On a whim, I decided to experiment with 300-baud HF-style packet on VHF-FM
> (instead of the usual 1200-baud mode) to determine what, if any, advantage
> could be gained in marginal signal situations.
>
> For my table-top closed-circuit test, I used one of my Acer netbooks
> running the UZ7HO Soundmodem soundcard software TNC. The Soundmodem program
> can be instantly switched between the 300-baud mode normally used on HF,
> and the 1200-baud mode normally used on 2M.  Further, it has a built-in
> display of successfully-decoded packets.
>
> I routed the audio-out of the netbook through one of my homebrew
> interfaces into the external modulation input of my IFR-1500 service
> monitor, and set the deviation of this "transmitter" to exactly 3.0 KHz.
> The IFR-1500 has a digitally-controlled  attenuator on it's RF generator
> that can vary the RF output in exact 1 dB steps.  The IFR's generator was
> hardwired to the antenna port of the receiving radio with a 3-foot BNC-BNC
> cable.
>
> At the receiving end, I used a Yaesu FT-1500 FM monobander transceiver. I
> coupled the non-deemphasized raw discriminator output of the 6-pin mini-DIN
> "data" port of this radio through a second interface into the audio-in of a
> Winbook 7" Windows tablet running Windows 8.1 and another copy of the UZ7HO
> Soundmodem. The internal "Realtek HD" audio system on this tablet is
> actually an excellent performer; far better than most built-in PC sound
> systems.
>
> My test consisted of manually punching off beacons on the sending-end
> Soundmodem, while watching the internal "decoded packets" monitor of the
> receiving-end Soundmodem display. I arbitrarily defined "perfect" reception
> as 50 successive beacon packets without a miss. I gradually reduced the RF
> generator output in 1dB steps until packets started being missed at the
> receiving end.   I moved the RF level up and down around the "fail" point
> several times to verify the repeatability of the threshold level.  The
> results were striking:
> .
> .
> In the 1200-baud mode, -109 dBm (.795 uVolts) was required for "perfect
> copy". At this point, the un-modulated generator carrier was yielding soft
> "fine-grained" hiss in the FT-1500's receiver, but no "pop corn" noise.
> I.e. something resembling 20 dB quieting in a classic SINAD test.
>
> In the 300-baud mode, only -113 dBM (.501 uVolts) was required for
> "perfect copy".   At this RF level, the unmodulated generator "dead
> carrier" was yielding rather severe "pop corn" noise similar to about 10 dB
> quieting on a classic SINAD test.
> .
> .
> In other words, just switching from 1200 baud to 300 baud bought a 4 dB
> improvement in receive performance. I would expect something like this on
> HF/SSB, especially with a DSP variable-bandwidth IF system that can be
> screwed down around the width of the transmitted signal.
>
> I was surprised that it worked in such a similar manner on FM.  The
> Soundmodem's internal audio DSP incorporates does incorporate
> variable-bandwidth AUDIO filters keyed to the selected baud rate.
> _________________________________________________________
>
> With a short compressed-mode APRS posit format  (not mic-E) generated by
> UIview, I discovered that the transmission-time penalty for using the
> slower more noise-immune 300 baud mode was actually very small.   Using a
> minimal packet with just position, a WIDE1-1 path, and TXD set to 250 mS,
> the 1200-baud packets took around 2 seconds while the 300 baud ones took
> 2.5-3 seconds.
>
> In real life, I will be using a TinyTrak III in Mic-E mode, making the
> transmitted strings even shorter.  I intend to set the Primary mode to 1200
> baud while the Secondary mode will have identical settings but at 300 baud.
> _______________________________________________________
>
> The UZ7HO Soundmodem is ideal for this kind of operation.   It is capable
> of operating like a dual-port TNC with TWO completely separate software
> modems internally.  Each one can be set to any speed from 300 baud through
> 2400. Normally these are used separately with the left and right channels
> of a STEREO-input soundcard to create something similar to a KAM dual-port
> hardware TNC.
>
> However the program also offers a mode where both modems can take their
> input from a SINGLE audio input, and the two decoded streams can be output
> through a single AGWpe-compatible TCP/IP port, and at the same time to a
> KISS-over-IP port.
>
> By setting one of the modems to 1200 baud and the other to 300 baud, the
> program can "automagically" receive either baud rate from a single radio
> with no manual switching required.  All I have to do is switch the mobile
> TinyTrack from Primary to Secondary mode!
>
> Further, the latest version of the Soundmodem now offers a built-in
> rudimentary digipeater. This is a basic literal callsign-matching
> non-N-n-decrementing digi suitable for the basic WIDE1-1 "fill-in" digi
> function. (You can enter a list of multiple callsigns to literally match;
> i.e. something like "MyDigicall=WA8LMF,WIDE1-1,TMP1-1" )  This list is
> separate for each of the two modems.
>
> Running the Soundmodem alone on the cheap ($65) Windows tablet can
> instantly create a digi that will repeat either 300-baud or 1200-baud
> automatically.
> _____________________________________________________________
>
> Stephen H. Smith    wa8lmf (at) aol.com
> Skype:        WA8LMF
> EchoLink:  Node #  14400  [Think bottom of the 2-meter band]
> Home Page:          http://wa8lmf.net
>
>  _______ Windows 10 Outrages! _______
>    <http://WA8LMF.net/Windows10_Info>
>
> 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>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160402/9ad4ccae/attachment.html>