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

15226Re: [tracker2] Re: OT USB Telemetry

Expand Messages
  • Scott Miller
    Feb 7, 2013
      I mean I came up with a more flexible format for telemetry, and I'm
      trying to talk Hessu into supporting it. If aprs.fi can handle it,
      that's what most of my users need and other clients would probably
      follow suit.

      My proposed format is variable-length, more efficient, and lets you
      specify profiles for metadata - either a standard pre-defined profile
      (e.g., T3 profile with 1 temperature, 1 count, and 5 voltage readings)
      or a profile you'd create yourself on the site. Because from what I've
      seen, most folks don't need equations and labels on the air, they just
      want the data presented nicely online.


      On 2/7/2013 7:59 PM, James Ewen wrote:
      > On Thu, Feb 7, 2013 at 8:48 PM, Scott Miller scott@...
      > <mailto:scott%40opentrac.org>> wrote:
      > > I'm still hoping to convince Hessu to implement a more flexible
      > > telemetry format. I've got one designed. Might just have to implement
      > > it myself and see if it gets any traction.
      > In what way? The APRS telemetry format is defined in the APRS
      > protocol, not by Hessu. We have tried to get Hessu to support a new
      > RANGE statement back in December of 2011. It does not require any
      > changes to the APRS protocol as it is simply an APRS message. It would
      > however need to be interpreted by aprs.fi, or any other APRS program
      > that displayed telemetry data graphically.
      > ******************
      > ---------- Forwarded message ----------
      > From: James Ewen ve6srv@... <mailto:ve6srv%40gmail.com>>
      > Date: Wed, Dec 28, 2011 at 12:21 PM
      > Subject: [aprsfi] Graphing Limits (was Any way to delete telemetry data?)
      > To: "aprsfi@... <mailto:aprsfi%40googlegroups.com>"
      > aprsfi@... <mailto:aprsfi%40googlegroups.com>>
      > Cc: "WB4APR@... <mailto:WB4APR%40amsat.org>" WB4APR@...
      > <mailto:WB4APR%40amsat.org>>
      > On Wednesday, December 28, 2011, Russ Crisp rcrisp@...
      > <mailto:rcrisp%40gmail.com>> wrote:
      > > Is there a way to delete data stored on aprs.fi? I'm asking about
      > telemetry data,
      > > but this could extend to other types.. I disconnected a sensor, and
      > the resulting
      > > odd value that was sent briefly really skews off the charts..
      > Are you looking to just remove a brief "blip" of data from the
      > database, or mask out a telemetry channel completely?
      > Masking random values on an unassigned telemetry channel is easy by
      > just defining the equation with all zeroes. I'm guessing however that
      > you want to remove or edit out a section of data where your indoor and
      > outdoor temperature values went to 0 (scaled to -100° F).
      > http://aprs.fi/telemetry/?call=K4RCC-6&date_start=2011-12-27+16%3A00%3A00&date_end=2011-12-28+00%3A00%3A00
      > Removal of the "out of range" data would require deletion of the full
      > telemetry strings from the aprs.fi database, or modification of the
      > values stored in the telemetry strings to a "normalized" value. I do
      > not believe Hessu provides any access to this type of database
      > manipulation. Providing access to the database in such a manner is
      > fraught with peril as well. It is better to simply leave the database
      > as a historical record of what was heard rather than trying to
      > sanitize the data to meet our desires.
      > A better way to "correct" this issue would be to create an APRS
      > telemetry definition extension that provides hard graph limits for the
      > telemetry value. Hessu's graphing routines auto-scale the graphs to
      > fit the available data.
      > With an APRS graph range definition, one could conceivably set manual
      > limits on the graphs, and if data were to range outside those limits,
      > the resultant graph would simpy go off scale.
      > Current APRS telemetry definitions are as follows:
      > PARM.P1,P2,P3,P4,P5,B1,B2,B3,etc Where Pn and Bn are the parameter names
      > UNIT.U1,U2,U3,U4,U5,L1,L2,L3,etc Where Un are the units for analog
      > ports and Ln are the labels for the bits
      > EQNS.A1,B1,C1,A2,B2,C2,A3,B3,C3,etc Where the An,Bn,Cn are the
      > coeficients for each of the five analog channels,
      > BITS.XXXXXXXX,Title-up-to-23-chars The x's specify the state of the
      > bits that match the BIT Labels.
      > T#sss,111,222,333,444,555,xxxxxxxx This is the on-air format for the
      > UI packet, where sss is the serial number followed by the five 3 digit
      > analog values and the eight binary values.
      > By adding one more definition statement, one could conceivably define
      > the limits of each graph. Only the analog values would need to be
      > defined as the bit states can only have but two values.
      > RNGE.L1,U1,L2,U2,L3,U3,L4,U4,L5,U5 Where Ln and Un are the lower and
      > upper graph limits respectively. A null value in any parameter
      > location would be interpreted as an auto-ranging request.
      > It would be then possible to have fully auto-ranging graphs (as we see
      > now at aprs.fi), graphs with set minimum and maximum values defined by
      > the user, or a hybrid where one of the range limits are defined and
      > the other is auto-ranging.
      > The addition of this fifth definition statement would not affect the
      > current operation of any client or website, and would be ignored
      > unless the client or website actively looked for and implemented the
      > graph range limits.
      > I have found myself wishing for a function such as this for quite some
      > time. Looking at the graphs over a long period where there's an
      > anomaly such as you are seeing can make it difficult to visualize the
      > rest of the "normal" data. Looking at a short time period graph can be
      > just the opposite where the auto ranging feature can show you too much
      > detail. On my battery voltage graphs, I'd like to have the graph
      > showing 0-15 volts at all times. I don't care too much about the 1/10
      > of a volt fluctuations, but rather would like to see the general
      > voltage across that range. If the graph is in the upper part of the
      > range, I know that my battery state is probably acceptable.
      > Thinking along these lines further, it might be nice to also have the
      > ability to select how the data is presented in the graphs. It would be
      > interesting to able to select RAW, SCALED, and RANGED data in the
      > graphs. RAW would graph the raw data (0-255), SCALED would use the
      > EQNS definition to present the data as it is seen now at aprs.fi, and
      > RANGED would implement the RNGE definition and set the minimum and
      > maximum axis values as per the new definition.
      > This would allow one to see the raw data if desired to be able to
      > assist in fault finding with their telemetry capture or definitions,
      > as well as to see all the scaled data after being adjusted according
      > to the EQNS definition, and finally the range limited graphs with
      > minimum and maximum limits as defined with the RNGE definition.
      > It's sure easy to sit here in my nice comfy chair and dream up more
      > work for others!
      > --
      > James
      > VE6SRV
    • Show all 20 messages in this topic