Loading ...
Sorry, an error occurred while loading the content.

New telemetry format - request for comments

Expand Messages
  • 'Scott Miller'
    As previously mentioned on the APRSSIG, I m working on a user-defined format for expanded telemetry functions to use in my own trackers. I m not requesting at
    Message 1 of 4 , Jun 29, 2007
    • 0 Attachment
      As previously mentioned on the APRSSIG, I'm working on a user-defined format
      for expanded telemetry functions to use in my own trackers. I'm not
      requesting at this point that the format be adopted as part of the APRS
      spec, but as long as I'm going to go to the trouble to develop the format
      and code to support it I'd like to get input from others who might be
      interested in using it.

      The format is a compromise between human-readability and efficiency. It
      consists of a series of optional tagged sections that may be present in any
      order. One section of each type is allowed per message. Section tags are
      single, case-sensitive characters. Section content is case-insensitive
      hexadecimal numbers. Proposed section types are:

      Sequence number - Up to 16 bits (4 digits), monotonically incremented by the
      sender with each transmission.

      Group number - Up to 16 bits, most likely only 4 or 8 bits in practice.
      Distinguishes groups of values when a station needs to report more values
      than will fit in a single report. Groups may share sequence numbers - i.e.,
      all groups representing readings for the same point in time could report the
      same sequence number.

      Interpretation reference - Up to 16 bits. Takes the place of separate unit,
      label, and coefficient messages. A centrally managed registry of telemetry
      definitions will be maintained, possibly in a yet-to-be-defined
      machine-readable format. A number of well-known definitions may be
      pre-defined to match existing hardware or common configurations.

      Binary values - Each hex digit represents 4 binary states. Numbering starts
      with the least significant bit of the first hex digit - i.e., the LSB of the
      first digit is sensor #1, and the LSB of the second digit is sensor #5.

      8-bit values - 2-digit hex numbers.

      12-bit, 16-bit, and 24-bit values - 3, 4, and 6-digit hex numbers,
      respectively.

      Some examples, keeping in mind that section identifiers are tentative:

      s04aEb8C4312d015A
      (sequence 4, binary values 1110, 8-bit values 8C, 43, 12, 16-bit value 015A)

      i6Es10g0a04101207E31
      i6Es10g1a136A00010
      (format 6E, sequence 10, with a bunch of binary values split between two
      messages)

      dFC01004EAC03
      (16-bit values FC01, 004E, AC03 with no sequence number)

      s3Fb035F134A0Ea7E
      (equivalent to a standard APRS telemetry message, with sequence number, 5
      8-bit values, and 8 digital inputs)

      a7
      (a minimal report including only 4 binary values)


      This format is intended to make it easy to add additional sensors. I intend
      to use it on the Tracker2 to allow Dallas 1-wire devices to be added
      on-the-fly with no configuration - for example, if you plug in DS2450 quad
      ADC, you'll automatically get 4 new values reported.

      Comments?

      Scott
      N1VG
    • 'Scott Miller'
      Sorry for the cross-post, but it occured to me that this might be of interest to T2 users, and not many are members of the APRS SPEC list to which this was
      Message 2 of 4 , Jun 29, 2007
      • 0 Attachment
        Sorry for the cross-post, but it occured to me that this might be of interest to T2 users, and not many are members of the APRS SPEC list to which this was posted.
         
        Scott
      • Jason Winningham
        hey Scott, In general, I like it. I m not following on the APRSSPEC sig, but here are some thoughts: IMO, field separator/identifier characters should not be
        Message 3 of 4 , Jul 2, 2007
        • 0 Attachment
          hey Scott,

          In general, I like it. I'm not following on the APRSSPEC sig, but
          here are some thoughts:

          IMO, field separator/identifier characters should not be letters a-f;
          stay away from hex digits to avoid confusion.

          should there be field number identifiers? I don't know what you have
          in mind for 1-wire sensor chains, but what would happen, for
          instance, if sensor #2 in a 5 sensor chain dropped out? How would I
          know what my data meant? That may not be likely or even worth
          worrying about...

          "interpretation reference". Maybe some of these should be reserved
          for "well known" and others user-defined? e.g. high bit = 0, well
          known issued by some working group; high bit - 1, user defined.

          -Jason
          kg4wsv
        • 'Scott Miller'
          You re right about the field separators - I ll have to think about good values for them. As for field number identifiers, I d only really thought about it for
          Message 4 of 4 , Jul 2, 2007
          • 0 Attachment
            You're right about the field separators - I'll have to think about good values for them.
             
            As for field number identifiers, I'd only really thought about it for the purposes of assigning labels and coefficients - you'd want a clear numbering scheme.  But with dropped sensors, I think it'll just have to be up to the client to remember what goes where.
             
            And yes, I'd intended for a subset (maybe the first 256 at least) to be reserved for "well-known" templates.
             
            As for the template contents, I'm tempted to make it a Javascript API or something.  That way the calculations could be arbitrarily complex - the decoder function just gets the raw values, and returns a list of names, values, and units.  You'd be able to model relationships between sensors that way, too - for example, a barometer reading might need a temperature reading to be interpreted properly.  I'd rather not have to implement a descriptive language to encode all of the possibilities.
             
            Maybe a Python script.. it's easy to embed Python, I understand...
             
            Scott
             

            From: tracker2@yahoogroups.com [mailto:tracker2@yahoogroups.com] On Behalf Of Jason Winningham
            Sent: Monday, July 02, 2007 7:39 AM
            To: tracker2@yahoogroups.com
            Subject: Re: [tracker2] New telemetry format - request for comments

            hey Scott,

            In general, I like it. I'm not following on the APRSSPEC sig, but
            here are some thoughts:

            IMO, field separator/identifie r characters should not be letters a-f;
            stay away from hex digits to avoid confusion.

            should there be field number identifiers? I don't know what you have
            in mind for 1-wire sensor chains, but what would happen, for
            instance, if sensor #2 in a 5 sensor chain dropped out? How would I
            know what my data meant? That may not be likely or even worth
            worrying about...

            "interpretation reference". Maybe some of these should be reserved
            for "well known" and others user-defined? e.g. high bit = 0, well
            known issued by some working group; high bit - 1, user defined.

            -Jason
            kg4wsv

          Your message has been successfully submitted and would be delivered to recipients shortly.