[aprssig] APRS freq spec questions
kennethfinnegan2007 at gmail.com
Sat Mar 28 23:16:05 EDT 2015
To answer one of my own questions on this, testing the T vs C access
commands with K4JH on his THD72a, it appears that I guessed correctly.
T100 will configure your radio to only encode a PL of 100Hz, where
C100 configures your radio to both encode and decode 100Hz. I would be
interested in seeing how radios respond to both at once ("T100 C127").
On Mon, Mar 16, 2015 at 2:17 PM, Kenneth Finnegan
<kennethfinnegan2007 at gmail.com> wrote:
> Greetings fellow APRSers,
> First, a quick note: my master thesis on APRS has been defended and
> accepted, so you can now retrieve the final draft of my thesis online
> here: http://digitalcommons.calpoly.edu/theses/1341/ There are still
> some issues/typos in that document, but it has been set in stone and
> I'm moving on with life.
> Having taken a hiatus from APRS and writing for a few months in the
> search for a job (which still hasn't born fruit yet...), I'm starting
> to again poke at my notes from my thesis where topics didn't make the
> cut for the limited scope of my thesis. I completely ignored the
> contents of APRS packets, so now that I'm FREE of the reigns of an
> academic institution dangling a piece of wallpaper over my head, I can
> start look at APRS with much smaller brush strokes.
> Let us talk about the frequency spec:
> http://www.aprs.org/info/freqspec.txt What follows is a few point by
> point interpretations, questions, and suggestions based on a casual
> reading of the 9 May 12 freq spec.
> The way I read it, the freq spec consists of a 10 octet frequency,
> followed by a number of optional five or ten octet modifiers. The spec
> seems to imply that these modifiers are limited to two, but that seems
> arbitrary and limiting to me. I would suggest that an arbitrary number
> of modifier fields be explicitly allowed. Clients MUST parse at least
> two fields, but may continue to parse modifier fields until they reach
> the end of the comment text or a modifier that they do not understand/
> appears to have a syntax error.
> The freq is expressed via "###.###MHz", or "###.## MHz" if the ones of
> kHz doesn't need to be specified. This seems odd to me to complicate
> this spec by allowing a space. When would a user only want to specify
> a frequency to 10kHz instead of 1kHz resolution?
> What is the expected behavior below 100MHz? Should the number be zero
> padded ("052.525MHz"), space padded (" 52.525MHz"), or left justified
> ("52.525MHz")? This last one violates the 10 octet rule for the
> primary frequency term.
> What is the expected behavior for frequencies >1GHz? Should they
> continue to be expressed to one hundredths of MHz? ("1286.200MHz" -
> This violates the ten octet rule) Should they be allowed to float the
> decimal place? ("1286.20MHz" - This is a bloodly mess for static
> parsers) Should they be allowed to specify their frequency in GHz to
> the least significant digit that isn't zero? ("1.2862GHz" - Often
> violates the ten octet rule and a freaking disaster for stupid
> parsers) I would suggest we allow higher frequencies to break the ten
> octet rule and keep everything in MHz.
> Edit: I now finally see the MICROWAVES section at the bottom... I
> don't know how I feel about this solution vs those considered above...
> This plus the delimiter issue (" ", "/", or "" after 7 octet data
> extensions) means to me that pretty much the only way to find the
> start of a freq spec is to scan the entire comment field for [0-9A-O
> ]?[0-9][0-9]\.[0-9][0-9][0-9 ][MG]Hz and start there...
> Moving on to the modifier terms... Every modifier term consists of a
> space, one identifier, and three octets of payload (with the exception
> of the rx freq term).
> I would suggest that FFF.FFFrx follow the same convention as the
> primary frequency in that it is always expressed in MHz, allowed to
> violate the ten octet rule for >1GHz frequencies, and follow the same
> conventions for <100MHz padding.
> There are three squelch access modifiers: T, C, and D. The case of
> this identifier specifies the channel bandwidth, so uppercase TCD
> indicates 25kHz channels, and lowercase tcd indicates 12.5kHz
> channels. I'm ok with limiting this to those two bandwidths.
> What is the difference between the T tone and C CTCSS terms? I'd guess
> that it means that a T repeater has tone access but carrier squelch,
> where CTCSS allows the users to both encode and decode PL. Is this
> What about repeaters with split PLs? (Which I deal with regularly due
> to passive intermod issues) I would suggest that we allow two access
> modifiers, where the first is the user encode frequency, and the
> second is the user decode frequency.
> For example, the W6BHZ VHF repeater (which has a 91.5Hz input and
> 127.3Hz output) would then be expressed as "146.760MHz T091 C127
> -060". The UHF side uses 127.3Hz on both input and output, and should
> be expressed as "442.300MHz C127 +500"
> A repeater using digital input and PL output would be "FFF.FFFMHz D023
> C127", PL input and digital output as "FFF.FFFMHz T127 D023", a
> repeater using identical digital codes be "FFF.FFFMHz D023" and split
> codes as "FFF.FFFMHz D023 D754" (not that I think anyone would want to
> do that... but that's a mechanism vs policy issue)
> Are all tone bursts >1kHz? 1750Hz is the only one I've heard of. I
> dislike the replacing a 1 with an l trick...
> I'm ok with limiting the +### and -### to 10kHz-9.99MHz splits.
> Anything beyond that includes a FFF.FFFrx modifier instead. Sucks to
> be a 23cm repeater on APRS, I guess... (i.e. W6PIY/1.2GHz becomes
> "1286.200MHz 1274.200rx C100") I'd be more comfortable with saying
> "implicit offsets are implicit" if the freq spec included that list of
> standard repeater offsets, but that's another whole can of worms...
> I look forward to any comments. I'm sorry I keep showing up just to
> stir the pot around here.
> Kenneth Finnegan, W6KWF
More information about the aprssig