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

Re: [tracker2] New telemetry format - request for comments

Expand Messages
  • 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 1 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 2 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.