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

RE: Telemetry - wrong decoding

Expand Messages
  • Krzysztof SQ5NWI
    Here in attachment you have also SR5NRF telemetry detailed configuration which may be helpful. The problem observed on latest development release. -- Regards,
    Message 1 of 9 , Jul 30, 2012
    • 1 Attachment
    • 113 KB
    Here in attachment you have also SR5NRF telemetry detailed configuration
    which may be helpful.
    The problem observed on latest development release.
    --
    Regards,

    Krzysztof
    SQ5NWI


    -----Original Message-----
    From: Krzysztof SQ5NWI [mailto:sq5nwi@...]
    Sent: Monday, July 30, 2012 9:28 AM
    To: 'aprsisce@yahoogroups.com'
    Cc: 'SQ5MRF'
    Subject: Telemetry - wrong decoding

    Lynn,

    my friend just started telemetry on his WX/Digi/I-Gate station and found
    that there is an issue with APRSIS32 presentation of telemetry data.
    To illustrate the problem I attach screen form application window and to
    compare here is the link to corresponding time frame from aprs.fi

    http://aprs.fi/telemetry/?call=SR5NRF&date_start=2012-07-29+07%3A20%3A07&dat
    e_end=2012-07-30+07%3A20%3A07

    If something needs to be more clarified, please ask.
    --
    Regards,

    Krzysztof
    SQ5NWI
  • James Ewen
    ... It would have been easier if you included the raw data as below, as well as listed what the issue was. Here s the data that corresponds to the screen shot
    Message 2 of 9 , Jul 30, 2012
    • 0 Attachment
      On Mon, Jul 30, 2012 at 1:28 AM, Krzysztof SQ5NWI <sq5nwi@...> wrote:

      > my friend just started telemetry on his WX/Digi/I-Gate station and found
      > that there is an issue with APRSIS32 presentation of telemetry data.
      > To illustrate the problem I attach screen form application window and to
      > compare here is the link to corresponding time frame from aprs.fi
      >
      > http://aprs.fi/telemetry/?call=SR5NRF&date_start=2012-07-29+07%3A20%3A07&dat
      > e_end=2012-07-30+07%3A20%3A07
      >
      > If something needs to be more clarified, please ask.

      It would have been easier if you included the raw data as below, as
      well as listed what the issue was. Here's the data that corresponds to
      the screen shot from APRSISCE/32.

      :SR5NRF :PARM.U1,,,I2,Temp
      :SR5NRF :UNIT.Volt,,,mA,C
      :SR5NRF :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64
      T#098,132,000,000,016,179,00000000
      T#097,132,000,000,016,179,00000000

      Here's the data as displayed by APRSISCE/32.

      Seq: 97
      U1 13.464 Volt
      ,:0.0 ,
      I2: 0.00 mA
      Temp: 94.08 C
      Chan 5:25.5
      Bit1:off Bit2: off
      Bit3:off Bit4: off
      Bit5:off Bit6: off
      Bit7:off Bit8: off

      The labels all look good, and the calculations are spot on.

      --
      James
      VE6SRV
    • Lynn W Deffenbaugh (Mr)
      Let me see what s going on here, also starting from the most recent raw packet and telemetry definnitions: 2012-07-30 13:12:46 UTC:
      Message 3 of 9 , Jul 30, 2012
      • 0 Attachment
        Let me see what's going on here, also starting from the most recent raw packet and telemetry definnitions:

        2012-07-30 13:12:46 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF   :PARM.U1,,,I2,Temp
        2012-07-30 13:12:46 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF   :UNIT.Volt,,,mA,C
        2012-07-30 13:12:46 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF   :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64
        2012-07-30 13:12:51 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1:T#159,132,000,000,016,181,00000000

        Sequence #159:
        Chan Label Units Equation  Raw   Calculated
         1    U1   Volt  0.102v+0  132   13.464
         2               0.1v+0    000   0.00
         3               9.76v+0   000   0.00
         4    I2    mA   5.88v+0   016   94.08
         5   Temp   C    0.5v-64   181   26.5
        

        http://aprs.fi/telemetry/?call=SR5NRF shows (Nice of Hessu to suppress undefined values, but it would also be nice to see the sequence number being presented):

        U1: 13.464 Volt (TLM: 132 EQN: 0,0.102,0)
        I2: 94.080 mA (TLM: 16 EQN: 0,5.88,0)
        Temp: 26.500 C (TLM: 181 EQN: 0,0.5,-64)

        APRSISCE/32 shows this:





        It appears that my label and units parsers have an issue with ,,, and it's pulling one of the commas as the label and units of the 2nd channel causing labels and units to be offset by 1.  The calculations are correct, but the labeling is off by one.

        I'll see what I can do to have this fixed in the next release. Thanks for bringing it to my attention, but it would have been faster if you had just said what you thought was wrong, not just that "they're different".

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


        On 7/30/2012 9:09 AM, James Ewen wrote:
        On Mon, Jul 30, 2012 at 1:28 AM, Krzysztof SQ5NWI <sq5nwi@...> wrote:
        
        
        my friend just started telemetry on his WX/Digi/I-Gate station and found
        that there is an issue with APRSIS32 presentation of telemetry data.
        To illustrate the problem I attach screen form application window and to
        compare here is the link to corresponding time frame from aprs.fi
        
        http://aprs.fi/telemetry/?call=SR5NRF&date_start=2012-07-29+07%3A20%3A07&dat
        e_end=2012-07-30+07%3A20%3A07
        
        If something needs to be more clarified, please ask.
        
        It would have been easier if you included the raw data as below, as
        well as listed what the issue was. Here's the data that corresponds to
        the screen shot from APRSISCE/32.
        
        :SR5NRF   :PARM.U1,,,I2,Temp
        :SR5NRF   :UNIT.Volt,,,mA,C
        :SR5NRF   :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64
        T#098,132,000,000,016,179,00000000
        T#097,132,000,000,016,179,00000000
        
        Here's the data as displayed by APRSISCE/32.
        
        Seq: 97
        U1 13.464 Volt
        ,:0.0 ,
        I2: 0.00 mA
        Temp: 94.08 C
        Chan 5:25.5
        Bit1:off Bit2: off
        Bit3:off Bit4: off
        Bit5:off Bit6: off
        Bit7:off Bit8: off
        
        The labels all look good, and the calculations are spot on.
        
        

      • Krzysztof SQ5NWI
        Thank you James for much more precise input data. Yes, Lynn, now I see that it was sent by me too hurry and it was better to find more time this morning or
        Message 4 of 9 , Jul 30, 2012
        • 0 Attachment
          Thank you James for much more precise input data.

          Yes, Lynn, now I see that it was sent by me too hurry and it was better to
          find more time this morning or later to describe precisely what is wrong
          than only to mark that questions for further explanations are welcome. ;-)
          SQ5MRF who is owner of SR5NRF initially turned his and my attention to
          readability of APRSISCE/32 telemetry details window.
          Trying to correlate values it came to be clear that they don't match to
          labels.

          Thank you for your analysis effort.
          --
          Regards,

          Krzysztof
          SQ5NWI

          From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf
          Of Lynn W Deffenbaugh (Mr)
          Sent: Monday, July 30, 2012 3:27 PM
          To: aprsisce@yahoogroups.com
          Subject: Re: [aprsisce] Telemetry - wrong decoding

          Let me see what's going on here, also starting from the most recent raw
          packet and telemetry definnitions:

          2012-07-30 13:12:46 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF  
          :PARM.U1,,,I2,Temp
          2012-07-30 13:12:46 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF  
          :UNIT.Volt,,,mA,C
          2012-07-30 13:12:46 UTC: SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF  
          :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64
          2012-07-30 13:12:51 UTC:
          SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1:T#159,132,000,000,016,181,00000000
          Sequence #159:
          Chan Label Units Equation Raw Calculated
          1 U1 Volt 0.102v+0 132 13.464
          2 0.1v+0 000 0.00
          3 9.76v+0 000 0.00
          4 I2 mA 5.88v+0 016 94.08
          5 Temp C 0.5v-64 181 26.5

          http://aprs.fi/telemetry/?call=SR5NRF shows (Nice of Hessu to suppress
          undefined values, but it would also be nice to see the sequence number being
          presented):

          U1: 13.464 Volt (TLM: 132 EQN: 0,0.102,0)
          I2: 94.080 mA (TLM: 16 EQN: 0,5.88,0)
          Temp: 26.500 C (TLM: 181 EQN: 0,0.5,-64)

          APRSISCE/32 shows this:





          It appears that my label and units parsers have an issue with ,,, and it's
          pulling one of the commas as the label and units of the 2nd channel causing
          labels and units to be offset by 1.  The calculations are correct, but the
          labeling is off by one.

          I'll see what I can do to have this fixed in the next release. Thanks for
          bringing it to my attention, but it would have been faster if you had just
          said what you thought was wrong, not just that "they're different".

          Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


          On 7/30/2012 9:09 AM, James Ewen wrote:
          On Mon, Jul 30, 2012 at 1:28 AM, Krzysztof SQ5NWI <sq5nwi@...> wrote:

          my friend just started telemetry on his WX/Digi/I-Gate station and found
          that there is an issue with APRSIS32 presentation of telemetry data.
          To illustrate the problem I attach screen form application window and to
          compare here is the link to corresponding time frame from aprs.fi

          http://aprs.fi/telemetry/?call=SR5NRF&date_start=2012-07-29+07%3A20%3A07&dat
          e_end=2012-07-30+07%3A20%3A07

          If something needs to be more clarified, please ask.

          It would have been easier if you included the raw data as below, as
          well as listed what the issue was. Here's the data that corresponds to
          the screen shot from APRSISCE/32.

          :SR5NRF :PARM.U1,,,I2,Temp
          :SR5NRF :UNIT.Volt,,,mA,C
          :SR5NRF :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64
          T#098,132,000,000,016,179,00000000
          T#097,132,000,000,016,179,00000000

          Here's the data as displayed by APRSISCE/32.

          Seq: 97
          U1 13.464 Volt
          ,:0.0 ,
          I2: 0.00 mA
          Temp: 94.08 C
          Chan 5:25.5
          Bit1:off Bit2: off
          Bit3:off Bit4: off
          Bit5:off Bit6: off
          Bit7:off Bit8: off

          The labels all look good, and the calculations are spot on.
        • Lynn W Deffenbaugh (Mr)
          I have it fixed in my local version. The fix will be in the next development release, whenever I have a chance to button up some partially completed stuff.
          Message 5 of 9 , Jul 30, 2012
          • 0 Attachment
            I have it fixed in my local version.  The fix will be in the next development release, whenever I have a chance to button up some partially completed stuff.



            Also, APRSISCE/32 displays the same number of decimal digits as were included in the EQNS definition for each value.  So, for the EQNS:

            SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF   :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64

            Channel 1 will have 3 decimals (0.102), channel 2 will have 1 (0.1), channel 3 will have 2 (9.76), channel 4 will have 2 (5.88), and channel 5 will have 1 (0.5).  It appears that aprs.fi uses 3 decimals for each parameter, so you'll still see a difference in our presentation, although the numbers should match the units and labels in the next release.

            Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

            On 7/30/2012 9:46 AM, Krzysztof SQ5NWI wrote:
            Thank you James for much more precise input data.
            
            Yes, Lynn, now I see that it was sent by me too hurry and it was better to
            find more time this morning or later to describe precisely what is wrong
            than only to mark that questions for further explanations are welcome. ;-)
            SQ5MRF who is owner of SR5NRF initially turned his and my attention to
            readability of APRSISCE/32 telemetry details window.
            Trying to correlate values it came to be clear that they don't match to
            labels.
            
            Thank you for your analysis effort.
            

          • Krzysztof SQ5NWI
            Thanks Lynn for rapid fix. :-). -- Regards, Krzysztof SQ5NWI From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh
            Message 6 of 9 , Jul 31, 2012
            • 0 Attachment

              Thanks Lynn for rapid fix. :-).

              --

              Regards,

               

              Krzysztof

              SQ5NWI

               

              From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh (Mr)
              Sent: Monday, July 30, 2012 3:57 PM
              To: aprsisce@yahoogroups.com
              Subject: Re: [aprsisce] Telemetry - wrong decoding

               

              I have it fixed in my local version.  The fix will be in the next development release, whenever I have a chance to button up some partially completed stuff.



              Also, APRSISCE/32 displays the same number of decimal digits as were included in the EQNS definition for each value.  So, for the EQNS:

              SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF   :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64

              Channel 1 will have 3 decimals (0.102), channel 2 will have 1 (0.1), channel 3 will have 2 (9.76), channel 4 will have 2 (5.88), and channel 5 will have 1 (0.5).  It appears that aprs.fi uses 3 decimals for each parameter, so you'll still see a difference in our presentation, although the numbers should match the units and labels in the next release.

              Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

              On 7/30/2012 9:46 AM, Krzysztof SQ5NWI wrote:

              Thank you James for much more precise input data.
                
              Yes, Lynn, now I see that it was sent by me too hurry and it was better to
              find more time this morning or later to describe precisely what is wrong
              than only to mark that questions for further explanations are welcome. ;-)
              SQ5MRF who is owner of SR5NRF initially turned his and my attention to
              readability of APRSISCE/32 telemetry details window.
              Trying to correlate values it came to be clear that they don't match to
              labels.
                
              Thank you for your analysis effort.

               

            • Krzysztof SQ5NWI
              Lynn, let s consider a bit more how to present telemetry values. You can agree or not, but for me it is not the best solution to correlate channel number of
              Message 7 of 9 , Jul 31, 2012
              • 0 Attachment
                Lynn,

                let's consider a bit more how to present telemetry values.

                You can agree or not, but for me it is not the best solution to correlate
                channel number of decimals with multiplier number of decimals and I like
                Hessu approach, but I would set decimals constantly to 2 as 3 seems too much
                at least to me.
                For me it is difficult to imagine measurements requiring such accuracy.
                Anyway, using multiplier base we can also limit too much the length of the
                value decimal part which in some cases can be useful to have two digits.

                Here in our example for SR5NRF station we have 3 decimals for channel 1
                because (following SQ5MRF statement) it is necessary to minimize sent value
                inaccuracy.
                For example if channel 1 TLM value is 132 and EQN is 0,102 we have value
                13,464 and for shorter multiplier like 0,1 we would have 13,2, so de
                difference can be meaningful I believe so he decided to use this 3 digits
                multiplier.

                All this is rather discussion about what I like more and what I like less,
                so I'm not going to force my approach.
                Please, treat this as subjective point of view and use it if worth in your
                opinion.
                --
                Regards,

                Krzysztof
                SQ5NWI

                From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf
                Of Lynn W Deffenbaugh (Mr)
                Sent: Monday, July 30, 2012 3:57 PM
                To: aprsisce@yahoogroups.com
                Subject: Re: [aprsisce] Telemetry - wrong decoding

                I have it fixed in my local version.  The fix will be in the next
                development release, whenever I have a chance to button up some partially
                completed stuff.



                Also, APRSISCE/32 displays the same number of decimal digits as were
                included in the EQNS definition for each value.  So, for the EQNS:

                SR5NRF>APNW01,TCPIP*,qAS,SR5NRF-1::SR5NRF  
                :EQNS.0,0.102,0,0,0.1,0,0,9.76,0,0,5.88,0,0,0.5,-64

                Channel 1 will have 3 decimals (0.102), channel 2 will have 1 (0.1), channel
                3 will have 2 (9.76), channel 4 will have 2 (5.88), and channel 5 will have
                1 (0.5).  It appears that aprs.fi uses 3 decimals for each parameter, so
                you'll still see a difference in our presentation, although the numbers
                should match the units and labels in the next release.

                Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

                On 7/30/2012 9:46 AM, Krzysztof SQ5NWI wrote:
                Thank you James for much more precise input data.

                Yes, Lynn, now I see that it was sent by me too hurry and it was better to
                find more time this morning or later to describe precisely what is wrong
                than only to mark that questions for further explanations are welcome. ;-)
                SQ5MRF who is owner of SR5NRF initially turned his and my attention to
                readability of APRSISCE/32 telemetry details window.
                Trying to correlate values it came to be clear that they don't match to
                labels.

                Thank you for your analysis effort.
              Your message has been successfully submitted and would be delivered to recipients shortly.