[aprssig] mic-e: technical info or source code ??

[Kristoff Bonne]

Hi Scott,

On 29-05-13 23:26, Scott Miller wrote:
>> I must say, having a networking / internet background, I must say that
>> the ham community has a terrible track-record of documenting protocols
>> and technologies.

> It's awful.  I tried to do my part and provide some information on APRS
> and AX.25 here:
> http://n1vg.net/packet/index.php

Well, doing some development myself (I do some work on the GMSK modem 
for codec2), I do find myself "on the other side of the table" too.
But, sometimes, you have to say to yourself "now stop coding and start 
documenting".

The problem is that, if your are not really used to this and especially 
if english is not your native language- it does take up quite some time.

For that reason, I've now started to step away from formal "documents" 
and stared moving to distributing information via wiki's (e.g. on github).

As everybody can edit the documents, I kind-of count on the community to 
help develop the document.




>> I prefer a documents describing APRS or AX.25 100 times more then (say)
>> the officual D-STAR spec-document which is (hold your breath) a
>> stagering 8 pages!

> Last time I looked at it, it didn't even mention the scrambler
> polynomial.  Certainly not enough to implement the protocol on its own.

The only way I was able to more-or-less understand D-STAR was by a 
combination of the specs, the source-code of the pcrepeatercontroller of 
Jonathan G4KLX (long live opensource! ;-) ) and sniffing and analysing 
some traffic.


For me, my main concerning with the D-STAR specification is however not 
the amount of information in it, but the lack of "clear wording".

If you read (say) a IETF RFC document, you will see sentences like 
"MUST" or "MAY NOT" and the document clearly indicated what that means. 
It clearly shows the responsability of the components involved the 
interaction.
The D-STAR specification does not have that. It's more a "description of 
an implementation" instead of a proper protocol specification.
That creates a lot of uncertainty when dealing with software of 
different parites, and that is not good!



> Scott
> N1VG
73
kristoff - ON1ARF