[aprssig] Telemetry format

'Scott Miller' scott at opentrac.org
Mon Apr 9 14:51:47 EDT 2007


I'm going to be adding some new telemetry capabilities to my devices that
don't fit well in the established telemetry format.  The existing format has
a few limitiations, in particular:

- 8-bit resolution.  Yeah, you can report values of 0-999, but the spec says
0-255.  This could be fixed with a spec revision.
- Too rigid.  You get 5 analog values and 8 digital - no more, no less.
- Too verbose.  It's good for readability, maybe, but it takes 20 bytes of
text to convey 5 bytes of analog telemetry, and 8 bytes to convey 1 byte of
digital values.

The mechanism of using separate unit and coefficient messages is also kind
of clunky, and I haven't often seen it done right.  I'm going to be working
on a new, user-defined format for my own stuff, but I'd like some input from
other telemetry users.  Might as well make the format as useful as possible
for everyone.

I'm planning for the new format to support an arbitrary number of analog and
digital values, up to the length allowed in the packet payload.  It'll use a
non-decimal encoding, probably Base 64 or plain old hexadecimal.  I need
support for at least 10-bit readings, but 16 bits would allow more
flexibility. As an example, a variable-length list of hex values could be
prefixed with a character indicating the sample type - say, 'a' for 8-bit,
'b' for 16-bit, and 'd' for digital.  The existing format could be condensed
to:

a1122334455d00 (compare to 111,222,333,444,555,bbbbbbbb)

Not counting the sequence number prefix.  This would allow a lot of
expansion, smaller packets, and a decent level of human-readability.

I'm still working on ideas for the coefficient and unit problem.  I'd like
to have a solution that works on RF-only systems, but an alternative might
be to have a profile designator that refers to a published set of
coefficients and units.  Not an ideal solution, but if it was managed right,
you could have a master list available in a single location that clients
could retrieve as needed.  A handful of standard, pre-defined profiles
should take care of the majority of telemetry users anyway.  Considering how
unusual it is to actually see the units and coefficients working right now,
it probably wouldn't be any worse.

Comments?

Scott
N1VG







More information about the aprssig mailing list