[aprssig] Amount of "padding" before and after data at 1200 baud?

[Jim (List)]

How much would depend on the software decoding.

Good software should be able to pick up on the preamble within a few ms, others may take 10's.

I've always set up systems by ear (unscientific, but works!), listening to the received audio and setting TXDELAY enough to be able to just hear the preamble, which probably makes it about 50ms over the radio's RX detection time. Never needed more than 150ms.



Jim, G1HUL

-----Original Message-----
From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Alan
Sent: 21 July 2017 18:28
To: 'John D. Hays'; APBIDDLE at mailaps.org
Cc: 'TAPR APRS Mailing List'
Subject: Re: [aprssig] Amount of "padding" before and after data at 1200 baud?

<<<TXDelay is radio (model) specific -- based on the transmitter rise time.

Fully understood how you GET the delay.  No matter the transmitter, the goal is to have a few ms of clean, stabile idle signal "come out the back" before the data is sent.  How much is needed is also dependent on the other station receiver, but given the quirks of DSP rigs, I want to avoid just brute forcing it with TXDelay=TXTail=500 ms which does work, but is not especially friendly.

73s,

Alan
WA4SCA


<-----Original Message-----
<From: John D. Hays [mailto:john at hays.org]
<Sent: Friday, July 21, 2017 11:56 AM
<To: APBIDDLE at mailaps.org
<Cc: TAPR APRS Mailing List <aprssig at tapr.org>
<Subject: Re: [aprssig] Amount of "padding" before and after data at 1200 <baud?
<
<TXDelay is radio (model) specific -- based on the transmitter rise time.
<
<On Fri, Jul 21, 2017 at 8:44 AM, Alan <wa4sca at gmail.com <<mailto:wa4sca at gmail.com> > wrote:
<
<
<	In adjusting the TXDelay and TXTail parameters, is there a
<recommended number of ms before and after the data that you want actually <transmitted?  With conventional rigs, it is relatively simple to take a guess, and <tweak it slightly until it is reliable.
<
<	In working with DSP rigs, not only is the internal latency significant, but
<in some cases not entirely reproducible.  That is, you can send a series of <beacons, and the timing will vary from one to the next.  I can look at the actual <output, and would like to know what the minimum recommended times are <so that I can insure that without just brute forcing long unneeded <transmission times.
<
<	73s,
<
<	Alan
<	WA4SCA
<
<
<	_______________________________________________
<	aprssig mailing list
<	aprssig at tapr.org <mailto:aprssig at tapr.org>
<	http://www.tapr.org/mailman/listinfo/aprssig
<<http://www.tapr.org/mailman/listinfo/aprssig>
<
<
<
<
<
<--
<
<
<________________________________
<
<John D. Hays
<Edmonds, WA
<K7VE
<
<
<
< <http://k7ve.org/images/Facebook-26.png>
<<https://docs.google.com/uc?export=download&id=0B16WvG35kZ7SUFYwZl
<dBMmJXeWs&revid=0B16WvG35kZ7STXlkYm1oMkpHYzVxOUlxVEtXc1dqMXZ
<hdjZFPQ>   <http://k7ve.org/blog>   <http://twitter.com/#!/john_hays>


_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig