<div dir="ltr">Honestly, from my perspective, we have plenty of technical people in this community that could come up with a very nice, elegant protocol. But I think that's the easy part; in order for it to go anywhere, we would need an "ambassador" with enough charisma and influence to convince the big companies like Kenwood, Icom, Yaesu, to adopt a new protocol in their hardware. That's the magic that Bob brought to the table, I think; he had the technical know-how combined with the charisma to pitch his invention to the world.<div><br></div><div>This is where I struggle with where to help, personally. I feel like I could help in the technical space, but when it comes to approaching a company like Kenwood, I confess that idea intimidates me a lot.</div><div><br></div><div>- Wes W8WJB<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 12, 2022 at 3:04 AM Heikki Hannikainen <<a href="mailto:hessu@hes.iki.fi">hessu@hes.iki.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Fri, 11 Feb 2022, Weston Bustraan wrote:<br>
<br>
> I can say that it was not easy to navigate the many exceptions and and <br>
> oddities in the APRS 1.0.1 spec when implementing a parser, and OpenTRAC <br>
> seems much more consistent, but the OpenTRAC spec does not seem to be <br>
> fully complete. For example, I would expect that any new protocol that <br>
> would supplant APRS would be supporting a UTF-8 character set instead of <br>
> just ASCII.<br>
<br>
Yes! Implementing all variations and details of APRS is quite difficult <br>
indeed, as there are so many completely different position formats, and <br>
various quirks in which order extension fields should be decoded in, and <br>
the specifications do not detail all of those. It is unnecessarily complex <br>
and an awful lot of work.<br>
<br>
Just last week there was a question on the Facebook APRS group, where one <br>
user was sending uncompressed APRS position packets, *without* a <br>
timestamp, but with a '@' packet type identifier which indicates a <br>
timestamp would follow. Their igate appliance requires the user configure <br>
a raw packet string template, and it's a little bit difficult to do that <br>
correctly for someone new to APRS. Aprsdirect parsed the position from the <br>
packet just fine, even though it was technically incorrect. <a href="http://aprs.fi" rel="noreferrer" target="_blank">aprs.fi</a>, and <br>
likely many other decoders, would try to parse out a timestamp after the <br>
'@' and fail. From the user's point of view, it looked like <a href="http://aprs.fi" rel="noreferrer" target="_blank">aprs.fi</a> is at <br>
fault. To add to the confusion, the remainder of the packet (after a <br>
suitable number of invalid timestamp bytes) happened to look like a <br>
perfectly valid *compressed* packet and <a href="http://aprs.fi" rel="noreferrer" target="_blank">aprs.fi</a> managed to decode that to <br>
some random coordinates on the correct continent! Now I'm wondering <br>
whether I should ignore all data after an invalid timestamp, or just keep <br>
skipping the invalid timestamp like it's been doing so far.<br>
<br>
We have a fairly complete decoder (by OH2KKU and myself), but still not <br>
fully complete (Area Objects? DF?), and quirks like this come up every now <br>
and then. It would not be very motivating to get to implement another <br>
custom packet encoder and decoder, and it is likely that slightly <br>
incompatible encoders and decoders would be produced by different <br>
developers.<br>
<br>
If a replacement is actually planned, I would propose battling against the <br>
NIH syndrome, and using an existing low-level serializer which is widely <br>
used elsewhere, such as Protocol Buffers <br>
(<a href="https://developers.google.com/protocol-buffers" rel="noreferrer" target="_blank">https://developers.google.com/protocol-buffers</a>). It is widely used <br>
outside Google and it's open source. The encoded on-the-wire (well, <br>
on-air) format is tight with little overhead and message formats can be <br>
extended without breaking existing decoders. Integer types use efficient <br>
variable-length encoding, so for a timestamp one could use int64 which <br>
would not actually use 64 bits in the packet until we actually reach such <br>
a date which requires it.<br>
<br>
With Protocol Buffers one writes a schema file which describes the data <br>
format. A supplied compiler (protoc) compiles the schema file to C code, <br>
which is then included in the application to encode and decode packets. <br>
Compilers are available for Java, Python, Objective-C, C++, Kotlin, Dart, <br>
Go, Ruby, and C#, with more languages to come. A very simple example <br>
format would look like this:<br>
<br>
message aprspacket {<br>
string srccall = 1;<br>
int64 timestamp = 2;<br>
optional float latitude = 3;<br>
optional float longitude = 4;<br>
optional int32 course = 5;<br>
optional int32 heading = 6;<br>
optional int32 altitude = 7;<br>
optional string comment = 10;<br>
optional string object_name = 11; // set a value to make it an object<br>
}<br>
<br>
Naturally you can have nested structures too - in a real world there would <br>
be a top-level packet structure with optional position, text message, <br>
weather and telemetry structures below it.<br>
<br>
The upside of this is that whoever implements an application does not need <br>
to actually write the low-level encoder or decoder - the protobuf compiler <br>
builds it from the schema file. Developers download the schema file, <br>
compile their application with it, call the generated encoder/decoder <br>
functions/methods (aprspacket_unpack_message(), aprspacket_pack_message()) <br>
and get nice structures out.<br>
<br>
Adding support for new fields in a new protocol version? Download a new <br>
schema file and recompile, find decoded value in output structure.<br>
<br>
Adding a new custom field to experiment with? Add it in the schema field <br>
with a suitable large random field identifier in a "reserved for <br>
experimentation" range and experiment - other apps will ignore it. Want <br>
to deploy it in the field for others to use? Submit a request to the <br>
Protocol Committee which allocates an identifier and releases a new <br>
version of the schema file.<br>
<br>
The decoders will ignore any new fiels that might be added to packets by <br>
apps which have been built with a new version of the schema, so old apps <br>
will not blow up when they receive packets from new apps. Protobuf 3.5 <br>
also retains these unknown fields in the decoder output structure, and <br>
re-encodes them if the structure is serialized again, so an old app can <br>
even re-encode and forward a packet with fields it does not implement.<br>
<br>
For embedded systems there's <a href="https://github.com/nanopb/nanopb" rel="noreferrer" target="_blank">https://github.com/nanopb/nanopb</a> : "It is <br>
especially suitable for use in microcontrollers, but fits any memory <br>
restricted system.".<br>
<br>
That said, I find it quite unlikely to find momentum for a completely new <br>
protocol encoding format, given the large amount of legacy hardware out <br>
there, and the difficulty of migration and backwards compatibility on RF <br>
side. Fragmentation would be really bad and a lot of old things would <br>
never be upgraded. Maybe this sort of thing could be used in the LoRa <br>
world which is still in development - it would speed up the development of <br>
new things quite a lot if the encoder/decoder code would be generated, not <br>
written by hand.<br>
<br>
- Hessu<br>
<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div>