<html><body><div style="color:#000; background-color:#fff; font-family:verdana, helvetica, sans-serif;font-size:16px"><div dir="ltr" id="yui_3_16_0_1_1427658595750_9542"> HamLab is new to me, but they may have some info too. This is an archive since the real page didnlt load for me. I no nothing more and they may have dissapeared for all I know.</div><div dir="ltr" id="yui_3_16_0_1_1427658595750_9606"><a id="yui_3_16_0_1_1427658595750_9622" href="http://webcache.googleusercontent.com/search?q=cache:MdepY6p1v2EJ:sourceforge.net/p/hamlib/news/+&cd=10&hl=en&ct=clnk&gl=us">http://webcache.googleusercontent.com/search?q=cache:MdepY6p1v2EJ:sourceforge.net/p/hamlib/news/+&cd=10&hl=en&ct=clnk&gl=us</a> </div><div dir="ltr" id="yui_3_16_0_1_1427658595750_9586"> </div><div dir="ltr" id="yui_3_16_0_1_1427658595750_9588">If you Google HamLab you get <strong id="yui_3_16_0_1_1427658595750_9592">Heat, Air and Moisture Laboratory</strong> in Germany.</div><div id="yui_3_16_0_1_1427658595750_9587"></div><div id="yui_3_16_0_1_1427658595750_9623"> </div><div id="yui_3_16_0_1_1427658595750_9625"><div id="yui_3_16_0_1_1427658595750_9624">--
<br>Regards, Steve Noskowicz
<br>Science & Technical Adviser
<br> http://www.challengerillinois.org/
<br></div></div><br> <div style="font-family: verdana, helvetica, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <hr SIZE="1"> <font size="2" face="Arial"> <b><span style="font-weight: bold;">From:</span></b> Kenneth Finnegan <kennethfinnegan2007@gmail.com><br> <b><span style="font-weight: bold;">To:</span></b> TAPR APRS Mailing List <aprssig@tapr.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Saturday, March 28, 2015 10:16 PM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [aprssig] APRS freq spec questions<br> </font> </div> <div class="y_msg_container"><br>To answer one of my own questions on this, testing the T vs C access<br>commands with K4JH on his THD72a, it appears that I guessed correctly.<br>T100 will configure your radio to only encode a PL of 100Hz, where<br>C100 configures your radio to both encode and decode 100Hz. I would be<br>interested in seeing how radios respond to both at once ("T100 C127").<br>--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a><br><br><br>On Mon, Mar 16, 2015 at 2:17 PM, Kenneth Finnegan<br><<a href="mailto:kennethfinnegan2007@gmail.com" ymailto="mailto:kennethfinnegan2007@gmail.com">kennethfinnegan2007@gmail.com</a>> wrote:<br>> Greetings fellow APRSers,<br>><br>> First, a quick note: my master thesis on APRS has been defended and<br>> accepted, so you can now retrieve the final draft of my thesis online<br>> here: <a href="http://digitalcommons.calpoly.edu/theses/1341/" target="_blank">http://digitalcommons.calpoly.edu/theses/1341/ </a>There are still<br>> some issues/typos in that document, but it has been set in stone and<br>> I'm moving on with life.<br>><br>> Having taken a hiatus from APRS and writing for a few months in the<br>> search for a job (which still hasn't born fruit yet...), I'm starting<br>> to again poke at my notes from my thesis where topics didn't make the<br>> cut for the limited scope of my thesis. I completely ignored the<br>> contents of APRS packets, so now that I'm FREE of the reigns of an<br>> academic institution dangling a piece of wallpaper over my head, I can<br>> start look at APRS with much smaller brush strokes.<br>><br>> Let us talk about the frequency spec:<br>> <a href="http://www.aprs.org/info/freqspec.txt" target="_blank">http://www.aprs.org/info/freqspec.txt </a>What follows is a few point by<br>> point interpretations, questions, and suggestions based on a casual<br>> reading of the 9 May 12 freq spec.<br>><br>><br>> The way I read it, the freq spec consists of a 10 octet frequency,<br>> followed by a number of optional five or ten octet modifiers. The spec<br>> seems to imply that these modifiers are limited to two, but that seems<br>> arbitrary and limiting to me. I would suggest that an arbitrary number<br>> of modifier fields be explicitly allowed. Clients MUST parse at least<br>> two fields, but may continue to parse modifier fields until they reach<br>> the end of the comment text or a modifier that they do not understand/<br>> appears to have a syntax error.<br>><br>> The freq is expressed via "###.###MHz", or "###.## MHz" if the ones of<br>> kHz doesn't need to be specified. This seems odd to me to complicate<br>> this spec by allowing a space. When would a user only want to specify<br>> a frequency to 10kHz instead of 1kHz resolution?<br>><br>> What is the expected behavior below 100MHz? Should the number be zero<br>> padded ("052.525MHz"), space padded (" 52.525MHz"), or left justified<br>> ("52.525MHz")? This last one violates the 10 octet rule for the<br>> primary frequency term.<br>><br>> What is the expected behavior for frequencies >1GHz? Should they<br>> continue to be expressed to one hundredths of MHz? ("1286.200MHz" -<br>> This violates the ten octet rule) Should they be allowed to float the<br>> decimal place? ("1286.20MHz" - This is a bloodly mess for static<br>> parsers) Should they be allowed to specify their frequency in GHz to<br>> the least significant digit that isn't zero? ("1.2862GHz" - Often<br>> violates the ten octet rule and a freaking disaster for stupid<br>> parsers) I would suggest we allow higher frequencies to break the ten<br>> octet rule and keep everything in MHz.<br>> Edit: I now finally see the MICROWAVES section at the bottom... I<br>> don't know how I feel about this solution vs those considered above...<br>> This plus the delimiter issue (" ", "/", or "" after 7 octet data<br>> extensions) means to me that pretty much the only way to find the<br>> start of a freq spec is to scan the entire comment field for [0-9A-O<br>> ]?[0-9][0-9]\.[0-9][0-9][0-9 ][MG]Hz and start there...<br>><br>> Moving on to the modifier terms... Every modifier term consists of a<br>> space, one identifier, and three octets of payload (with the exception<br>> of the rx freq term).<br>><br>> I would suggest that FFF.FFFrx follow the same convention as the<br>> primary frequency in that it is always expressed in MHz, allowed to<br>> violate the ten octet rule for >1GHz frequencies, and follow the same<br>> conventions for <100MHz padding.<br>><br>> There are three squelch access modifiers: T, C, and D. The case of<br>> this identifier specifies the channel bandwidth, so uppercase TCD<br>> indicates 25kHz channels, and lowercase tcd indicates 12.5kHz<br>> channels. I'm ok with limiting this to those two bandwidths.<br>><br>> What is the difference between the T tone and C CTCSS terms? I'd guess<br>> that it means that a T repeater has tone access but carrier squelch,<br>> where CTCSS allows the users to both encode and decode PL. Is this<br>> correct?<br>><br>> What about repeaters with split PLs? (Which I deal with regularly due<br>> to passive intermod issues) I would suggest that we allow two access<br>> modifiers, where the first is the user encode frequency, and the<br>> second is the user decode frequency.<br>> For example, the W6BHZ VHF repeater (which has a 91.5Hz input and<br>> 127.3Hz output) would then be expressed as "146.760MHz T091 C127<br>> -060". The UHF side uses 127.3Hz on both input and output, and should<br>> be expressed as "442.300MHz C127 +500"<br>> A repeater using digital input and PL output would be "FFF.FFFMHz D023<br>> C127", PL input and digital output as "FFF.FFFMHz T127 D023", a<br>> repeater using identical digital codes be "FFF.FFFMHz D023" and split<br>> codes as "FFF.FFFMHz D023 D754" (not that I think anyone would want to<br>> do that... but that's a mechanism vs policy issue)<br>><br>> Are all tone bursts >1kHz? 1750Hz is the only one I've heard of. I<br>> dislike the replacing a 1 with an l trick...<br>><br>> I'm ok with limiting the +### and -### to 10kHz-9.99MHz splits.<br>> Anything beyond that includes a FFF.FFFrx modifier instead. Sucks to<br>> be a 23cm repeater on APRS, I guess... (i.e. W6PIY/1.2GHz becomes<br>> "1286.200MHz 1274.200rx C100") I'd be more comfortable with saying<br>> "implicit offsets are implicit" if the freq spec included that list of<br>> standard repeater offsets, but that's another whole can of worms...<br>><br>> I look forward to any comments. I'm sorry I keep showing up just to<br>> stir the pot around here.<br>> --<br>> Kenneth Finnegan, W6KWF<br>> <a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a><br>_______________________________________________<br>aprssig mailing list<br><a href="mailto:aprssig@tapr.org" ymailto="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br><a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/listinfo/aprssig</a><br><br><br></div> </div> </div> </div></body></html>