[aprssig] [RFC] Power Source Data Extension

[Kenneth Finnegan]

On Sun, Feb 12, 2017 at 1:44 PM, Nick G4IRX <g4irx9 at nowindows.net> wrote:

>
> On 12/02/2017 08:27, Kenneth Finnegan wrote:
>
>> Why was 50Hz vs 60Hz handled for houses? I'm a bit at a loss where that
>> would be an issue.
>>
>
> Electrical machines? For example clocks that reference the mains frequency
> or use synchronous motors won't keep the correct time.
> Whilst North America uses 60Hz, over here in the UK and Europe it's 50Hz.


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.


On Sun, Feb 12, 2017 at 1:50 PM, Jason KG4WSV <kg4wsv at gmail.com> wrote:

> Reduction in readability compared to what?
>>
>
> 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.
>

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.

The two paragraphs on the altitude extension in APRS101.PDF doesn't talk
about what comes after aaaaaa. How is that any different?

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.


>
>
>> 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.
>>>
>>
>> So if a station capability parser encounters ",PWR=SB&," what should the
>> parser do with the ampersand?
>>
>
> 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?
>

>
>> 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.
>>
>
> 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.
>

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.

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.

I specifically don't talk about how this field got delimited from the
previous or next field because:
* The method for that is different for capability packets and
status/position packets
* I suspect the delimiter is very hazy for status/position packets,
depending on how forgiving you want to be.
* 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.

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170212/e44044b3/attachment.html>