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

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

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