<div dir="ltr"><div>On Sun, Feb 12, 2017 at 1:44 PM, Nick G4IRX <span dir="ltr"><<a href="mailto:g4irx9@nowindows.net" target="_blank">g4irx9@nowindows.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>On 12/02/2017 08:27, Kenneth Finnegan wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why was 50Hz vs 60Hz handled for houses? I'm a bit at a loss where that would be an issue.<br></blockquote><br></span>Electrical machines? For example clocks that reference the mains frequency or use synchronous motors won't keep the correct time.<br>Whilst North America uses 60Hz, over here in the UK and Europe it's 50Hz.</blockquote></div><div><br></div><div>This is true, but wouldn't it be a safe bet that if an APRS house station is plotted in the UK they're probably running on 50Hz and if it's plotted in the US it's running on 60Hz? Where would it be unclear if a house is running on one or the other based on its geography? Maybe midland Japan? And in what scenario would it be tactically important to correctly know what frequency a house is running on anyways? I'm just trying to understand why anyone else would care.</div><div><br></div><div><br></div>On Sun, Feb 12, 2017 at 1:50 PM, Jason KG4WSV <span dir="ltr"><<a href="mailto:kg4wsv@gmail.com" target="_blank">kg4wsv@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Reduction in readability compared to what?<br></div><div></div></blockquote><div><br></div></span><div>As opposed to _not_ having a space (or comma in the case of station capabilities) and having it jammed against the next chunk of data, be it comment or some other comment/status-legal data.  I'm a big fan of having packets human readable where practical, and our brains are trained to use space as a "word" delimiter.</div></div></div></div></blockquote><div><br></div><div>Then put a space at the end. I didn't specify that it has to be jammed up against the next chunk; I only said that it's terminated by anything other than A-Z. Spaces would meet that definition. Commas would meet that definition. Forward slashes would meet that definition. </div><div><br></div><div>The two paragraphs on the altitude extension in APRS101.PDF doesn't talk about what comes after aaaaaa. How is that any different?</div><div><br></div><div>If you want to require data extensions in position comments to be delimited by spaces, that's a separate argument from what each data extension means.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="gmail-m_467554785796771411m_4265331239923365516gmail-"><div class="gmail_quote">All fields should be start with either the appropriate APRS data type identifier or field separator and end with either a field separator or the end of packet. </div></span></div></div></blockquote><div><br></div><div>So if a station capability parser encounters ",PWR=SB&," what should the parser do with the ampersand? </div></blockquote><div><br></div></span><div>Unless there's more uses of & than I see after a quick perusal of the spec, I'd probably ignore it, possibly along with the entire field. The capability spec seems to clearly intend for a comma to be the field separator, so i'd [call] it an illegal field since it includes & before the , and & is not in the field spec you're proposing.  Or did I miss something?</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It seems like you're talking about the tokenizer, which I wasn't talking about. I'm only talking about how to parse this field.<br></blockquote><div><br></div></span><div>I really don't see how you can differentiate the two problems too much, since you need to know when the field stops so you can stop parsing it.  The spec doesn't provide much help with this sort of question, so default to space.</div></div></div></div></blockquote><div><br></div><div>Parsers typically take an input string, tokenize it into individual fields, identify the individual fields, and pass each of them to the appropriate parsers. I'm only talking about this last step where we're looking at a field starting with "PWR=", so you could have already found the delimiters on both ends. Knowing that a field contains "PWR=SB&", why would you discard it as invalid? I specified that the list of power sources ends by anything other than A-Z, so the parser should come back with "Solar, batteries" having correctly surmised that the list ends after B.</div><div><br></div><div>If you were instead implementing a linear parser, You'd encounter "PWR=", parse the list of power sources until you encountered something other than A-Z, then look for the next field delimiter, then move on with the next field. I don't see the problem here.</div><div><br></div><div>I specifically don't talk about how this field got delimited from the previous or next field because:</div><div>* The method for that is different for capability packets and status/position packets</div><div>* I suspect the delimiter is very hazy for status/position packets, depending on how forgiving you want to be.</div><div>* I don't think every data extension spec should repeat the specification on how they get delimited in the whole packet. That's how you end up with half a dozen almost-the-same-but-not-quite conflicting specs.</div><div><br></div><div class="gmail_extra"><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<div class="gmail_quote"><br></div></div></div>