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

T3-Mini and ADS-GM2 Problems in Balloon Flight

Expand Messages
  • ky7dr
    I recently flew a tracker built with a T3-Mini on a balloon flight. Had some issues. I ve put all of the relevant info that I have into a web page:
    Message 1 of 12 , Jul 25 9:12 AM
    • 0 Attachment

      I recently flew a tracker built with a T3-Mini on a balloon flight.  Had some issues.  I've put all of the relevant info that I have into a web page:


      http://ky7dr.com/dreams/dreams20140723.html


      2 problems noted there:


      1. Rapid, nearly continuous transmissions for a period during ascent and for a period during descent, and

      2. Loss of GPS data at altitude.


      If anyone has any insight into these problems, I'd like to hear from you.


      David, ky7dr

    • Jason KG4WSV
      your profile switching is broken - looks like you are constantly flipping back and forth if 10k and
      Message 2 of 12 , Jul 25 10:13 AM
      • 0 Attachment
        your profile switching is broken - looks like you are constantly flipping back and forth if >10k' and <50mph.  Forget speed, use altitude only.

        your power supply is probably inadequate.  Those batteries are not rated for large current loads; your GPS alone may have exceeded the rating.  It definitely won't run the radio as well.

        could be stray RF causing problems, too.  depends on physical layout, etc.


        -Jason
        kg4wsv
      • David Rush
        Jason: Thanks for the input. I agree that the packet diarrhea problem is likely rooted in a profile-switching problem. I agree that I should fly with just the
        Message 3 of 12 , Jul 25 12:07 PM
        • 0 Attachment
          Jason:

          Thanks for the input.

          I agree that the packet diarrhea problem is likely rooted in a
          profile-switching problem.

          I agree that I should fly with just the altitude switch on flights.
          I'll also leave off the checkbox to transmit when switching, to be extra
          safe.

          But I would still like to understand why it was profile switching before
          the balloon got to 10k ft and before it every hit 50 mph. Profile
          switching when one of those conditions was met but not the other is
          clear why it would go into "profile oscillation" for minutes at a time.
          aprs.fi reported rate limiting me when the balloon was at 2777 feet
          going 6 mph, if I'm reading the data correctly.

          Current draw on the T3-Mini while feeding the GPS was averaging under 80
          ma, when tested on the bench, which is well within the capacity of the
          battery and I believe within spec for the regulator on the T3-Mini.
          Battery voltage still looked good (7.9V or more) throughout the "NO FIX"
          event. If there was excess current draw wouldn't I see a voltage drop?

          Would the GPS need more current at altitude than on the ground? I can't
          imagine why. On ground testing for hours with a 9V alkaline the GPS was
          still working down to below 6.5V (as reported by the T3-Mini).

          The radio was powered by its own internal lithium-ion battery. The 9v
          lithium powered only the T3-Mini directly, and indirectly the GPS.

          I have added some pics and little bit of info about the construction of
          the in-flight tracker to the same page.

          David, ky7dr

          On 2014-07-25 13:13, Jason KG4WSV kg4wsv@... [tracker2] wrote:
          > your profile switching is broken - looks like you are constantly
          > flipping back and forth if >10k' and <50mph.  Forget speed, use
          > altitude only.
          >
          > your power supply is probably inadequate.  Those batteries are not
          > rated for large current loads; your GPS alone may have exceeded the
          > rating.  It definitely won't run the radio as well.
          >
          > could be stray RF causing problems, too.  depends on physical layout,
          > etc.
          >
          > -Jason
          > kg4wsv
          >
          >
          > Links:
          > ------
          > [1]
          > https://groups.yahoo.com/neo/groups/tracker2/conversations/messages/16718;_ylc=X3oDMTJyN2RkMnY2BF9TAzk3MzU5NzE0BGdycElkAzE3NDQ2MDAwBGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAMxNjcxOARzZWMDZnRyBHNsawNycGx5BHN0aW1lAzE0MDYzMDgzOTE-?act=reply&messageNum=16718
          > [2]
          > https://groups.yahoo.com/neo/groups/tracker2/conversations/newtopic;_ylc=X3oDMTJmYjdtMjdhBF9TAzk3MzU5NzE0BGdycElkAzE3NDQ2MDAwBGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzE0MDYzMDgzOTE-
          > [3]
          > https://groups.yahoo.com/neo/groups/tracker2/conversations/topics/16716;_ylc=X3oDMTM3dnRoaDJpBF9TAzk3MzU5NzE0BGdycElkAzE3NDQ2MDAwBGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAMxNjcxOARzZWMDZnRyBHNsawN2dHBjBHN0aW1lAzE0MDYzMDgzOTEEdHBjSWQDMTY3MTY-
          > [4]
          > https://groups.yahoo.com/neo/groups/tracker2/info;_ylc=X3oDMTJmZTV2Nzh1BF9TAzk3MzU5NzE0BGdycElkAzE3NDQ2MDAwBGdycHNwSWQDMTcwNTA2MzEwOARzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzE0MDYzMDgzOTE-
          > [5]
          > https://groups.yahoo.com/neo/groups/tracker2/members/all;_ylc=X3oDMTJnY2JkaWR2BF9TAzk3MzU5NzE0BGdycElkAzE3NDQ2MDAwBGdycHNwSWQDMTcwNTA2MzEwOARzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxNDA2MzA4Mzkx
          > [6]
          > https://groups.yahoo.com/neo;_ylc=X3oDMTJlamRjYW43BF9TAzk3NDc2NTkwBGdycElkAzE3NDQ2MDAwBGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTQwNjMwODM5MQ--
          > [7] https://info.yahoo.com/privacy/us/yahoo/groups/details.html
          > [8] https://info.yahoo.com/legal/us/yahoo/utos/terms/
        • James Ewen
          On Fri, Jul 25, 2014 at 10:12 AM, david@rushtone.com [tracker2]
          Message 4 of 12 , Jul 25 1:53 PM
          • 0 Attachment
            On Fri, Jul 25, 2014 at 10:12 AM, david@... [tracker2] <tracker2@yahoogroups.com> wrote:

            > I recently flew a tracker built with a T3-Mini on a balloon flight.  Had some issues.
            >
            > 1. Rapid, nearly continuous transmissions for a period during ascent and for a period during descent, and
            >
            > 2. Loss of GPS data at altitude.
            >
            >
            > If anyone has any insight into these problems, I'd like to hear from you.

            As you have already described in your webpage, you had seriously broken profile switching. If your payload was below 10,000 feet AND travelling less that 50 MPH it would stay in profile 1. If your payload was above 10,000 feet AND travelling less than 50 MPH, it would stay in profile 2. In any other situation, your payload would be profile switching like crazy.

            As Jason said, profile switch on altitude only.

            The ADS-GM2 from Argent should have been preloaded with firmware to work above 60,000 feet. However, the fact that the GPS stopped and started sending valid fix data either side of 32768 feet makes me suspicious of the firmware being used in the GPS.The DOD limit is 60,000 feet, but 32768 is a round number in hex. Scott might have more insight into this behaviour.

            Now onto other issues...

            One should NEVER fly anything with WIDE1-1 in the path. Most people argue that this gives the best chance of hearing the payload on the ground. The statistical probability of having a payload land on the ground, ONLY within range of a WIDE1-1 fill-in home station is so low, that the benefits of using such a path are far outweighed by the cost associated with flying WIDE1-1 at altitude.

            With profile switching, and changing to a no hop path, you spared the ground network a lot of congestion.

            You might try to argue that the last time the payload was heard without a digipeater was from 4407 feet. K4RTZ-1 is a full digipeater, and it was 30 miles away. There were no digipeaters closer.

            Bouncing through the digi, the packets got to the APRS-IS for another 1381 feet, down to 3026 feet.

            However, look at your buddies last heard:

            !3219.12N/08332.61W3077/011/A=002653

            He was able to hear your payload direct down another 373 feet. Get your chase and recovery crews in place, and you'll have a better chance of hearing the packet direct rather than via the APRS-IS.

            So, what about all the packet switching problems?


            Pre-launch and immediately post launch: Worked as intended, transmitting every 30 seconds with a path of WIDE1-1,WIDE2-1.
            Balloon released approx 11:00 am EDT from rural Georgia (USA).
            From your buddy's log, it looks like you launched at 15:01 (according to his clock)
            11:02:32 First packet on aprs.fi, telemetry packet T#039, showing WIDE1-1,WIDE2-1 path
            At 15:02, T#39 was heard by your buddy, which we can see at 11:02:32 in the APRS-IS log.
            11:03:10 First position packet on aprs.fi, 8.5V 66C HDOP01.0 SATS10
            Here's your first mistake... you are ignoring the data in front of you.

            2014-07-23 11:03:10 EDT: KY7DR-3>APOT30,W4MM-15,WIDE1,KE4LTT-2*,qAS,N4AU:!3156.51N/08327.02W3203/004/A=000761 08.5V 67C HDOP00.9 SATS10
            2014-07-23 11:03:10 EDT: KY7DR-3>APOT30,W4MM-15*,WIDE1*,KW4B-1*,WIDE2*,qAR,KC2NYU-1:!3156.51N/08327.02W3203/004/A=000761 08.5V 67C HDOP00.9 SATS10 
            
            There are two copies of the same packet in your APRS-IS log. Why is that? If you look closely, the second packet has a 'space' character added onto the packet, making it look different than the first to the anti-dupe routines. One of the stations handling the second copy is broken.

            Position packets generally coming in about every 30 sec or more, as expected. Altitude generally going up, but sometimes dip down briefly.

            Is your balloon playing yo-yo? Nope, so there has to be another reason for the up/down issue.

            2014-07-23 11:03:53 EDT: KY7DR-3>APOT30,WIDE1-1,WIDE2-1,qAR,AE4XO:!3156.54N/08326.91W3082/011/A=001236 08.5V 66C HDOP01.5 SATS09 
            2014-07-23 11:04:29 EDT: KY7DR-3>APOT30,WIDE1-1,WIDE2-1,qAR,AE4XO:!3156.60N/08326.85W3036/005/A=002244 08.5V 66C HDOP01.0 SATS10 
            2014-07-23 11:05:00 EDT: KY7DR-3>APOT30,W4MM-15,WIDE1,K4GKJ-15,WIDE2*,qAR,AE4S:!3156.54N/08326.91W3082/011/A=001236 08.5V 66C HDOP01.5 SATS09 [Duplicate position packet]
            aprs.fi flags the issue for you... Duplicate position packet. The original packet from 1236 feet was held by AE4S for 67 seconds before being forwarded to the APRS-IS stream. This delay is longer than the anti-dupe filter, so the packet makes it into the stream, but Hessu notices it and flags it as being a duplicate.
            11:05:44 Start seeing packet diarrhea, with "Rate limited (< 5 sec)]" in the aprs.fi log, altitude 2777 feet.

            
            2014-07-23 11:05:44 EDT: KY7DR-3>APOT30,K4EGA-1,WIDE1*,WIDE2-1,qAR,KD4YDD-1:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10
            2014-07-23 11:05:45 EDT: KY7DR-3>APOT30,W4CSG,W4LEE-1,WIDE2*,qAR,WB4BXO-6:!3156.63N/08326.81W3123/005/A=002777 08.5V 66C HDOP01.0 SATS10 [Rate limited (< 5 sec)]
            2014-07-23 11:05:46 EDT: KY7DR-3>APOT30,K4EGA-1,W4TL-3,WIDE2*,qAR,N4TAW:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10 
            2014-07-23 11:05:49 EDT: KY7DR-3>APOT30,WIDE1-1,WIDE2-1,qAR,AE4XO:!3156.68N/08326.74W3087/006/A=003913 08.5V 66C HDOP01.0 SATS10  [Rate limited (< 5 sec)]
            
            You can't blame the payload for what you see here. Look at what your buddy heard from the payload.

            7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.63N/08326.81W3123/005/A=002777 08.5V 66C HDOP01.0 SATS10 "
            7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:> Columbus High School Dreams P1,,,2"
            7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10 "
            7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:T#040,085,000,000,000,000,000000008.5V"
            7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.68N/08326.74W3087/006/A=003913 08.5V 66C HDOP01.0 SATS10 "
            7/23/2014 15:06,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.69N/08326.73W3102/000/A=004337 08.5V 66C HDOP01.0 SATS10 "
            The 2777 and second 3370 altitude packets are delayed packet, caused by improperly configured and maintained i-gates. WB4BX)-6 and N4TAW are delaying packet deliver to the APRS-IS stream, which causes untold grief for everyone.


            11:05:45 Altitude 3370 (550 ft/second rise?)

            Between which two packets?

            11:10:19 Comment packet indicates we're still in profile 1, as expected
            11:10:25 Altitude 9139 ft
            11:10:26 Altitude 3370 ft (where I have seen that number before?), 8.5V 63C HDOP01.4 SATS10

            2014-07-23 11:10:26 EDT: KY7DR-3>APOT30,K4RTZ-1,WIDE1*,WIDE2-1,qAR,K4DBN:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10 [Rate limited (< 5 sec)]
            KD4DBN is delaying delivery of packets to the APRS-IS, but by almost 5 minutes. Another improperly maintained i-gate.

            11:11:02 Altitude 9697 ft
            11:12:14 Altitude 10902 ft
            11:12:18 Comment packet indicates we're in profile 2, as expected

            Here's where your profile switching issues will come into play, but with all the delayed packets and modified packets, it is very hard to determine which issue is which.

            11:12:19 Telemetry packet T#050
            11:13:07 Altitude 12071 ft
            11:13:09 Comment packet indicates we're in profile 1 (not expected at this altitude)

            2014-07-23 11:13:05 EDT: KY7DR-3>APOT30,qAR,KQ4KK-5:!3157.44N/08326.06W3067/015/A=012059 08.5V 67C HDOP00.9 SATS10  [Rate limited (< 5 sec)]
            2014-07-23 11:13:07 EDT: KY7DR-3>APOT30,W1KFR-1*,WIDE2-1,qAR,W1KFR:!3157.44N/08326.06W3079/015/A=012071 08.6V 67C HDOP00.9 SATS10 [Rate limited (< 5 sec)]
            2014-07-23 11:13:09 EDT: KY7DR-3>APOT30,WB4GNA-7,WIDE1,W4LAW-6,W4KCO-3*,qAR,KA4EMA-3:> Columbus High School Dreams P1
            
            You can see the profile switching happening. the first packet has no path, the second 2 seconds later is using a path. Your speed is <=50 MPH, so of course the profile will switch. Then profile 1 will determine that the altitude is >10,000 feet, so the profile will switch.

            11:13:11 Telemetry packet T#058
            11:20:37 Altitude 20790 ft
            11:30:32 Plausible position packet, Altitude 31564 ft, 8.4V 61C HDOP0.10 SATS09

            7/23/2014 15:30,KY7DR-3>APOT30:!3202.82N/08323.49W3017/024/A=032753 08.4V 61C HDOP01.0 SATS09 
            2014-07-23 11:30:15 EDT: KY7DR-3>APOT30,qAR,AE4XO:!3202.82N/08323.49W3017/024/A=032753 08.4V 61C HDOP01.0 SATS09  [Location changes too fast (adaptive limit)]
            
            This would be your last good fix before the GPS crapped out. Your buddy heard it direct, and AE4XO pushed it to the APRS-IS stream. aprs.fi flags it as bad due to the garbage it had received prior to this packet. Hessu can't always determine which packets are good, and which are bad.

            11:30:46 Started getting "NO FIX" packets (8.4V 60C) amongst position packets w/out "NO FIX"
            11:34:37 8.4V 61C HDOP0.10 SATS09 (last non-NO FIX packet for a while)
            11:50:37 Got one "NO FIX" packet reporting 8.3V 32C, and another reporting 8.4V 40C

            All the position packets seen mixed into the NO FIX packets are all delayed packets. Look at your buddy's log to determine what was actually heard on RF.

            12:34:24 First non-NO FIX packet in a while (first in an hour), Altitude 32785 ft (highest I've found), 7.9V 23C HDOP00.8 SATS11

            The payload is on it's way back down.

            12:34:30 Telemetry packet T#238
            12:34:56 Last "NO FIX" packet received, 7.9V 23C

            Delayed by bad i-gates

            12:36:00 Altitude 31566, 7.8V 28C HDOP00.7 SATS12
            12:36:56 Telemetry packet T#253
            12:37:07 Telemetry packet T#000 (counter to 255 wrapped, I presume)

            Yes, it's a circular counter.

            12:40:01 Altitude 27279, 7.7V 33C
            Lots more packet diarrhea going on...

            With lots of delays and mangled packets too!

            12:50:00 Altitude 16501 ft, 7.7V 44C HDOP00.7 SATS13
            13:00:07 Altitude 7384 ft 7.9V 51C
            13:21:50 Screen shot of my ground tracking station (APRSDroid) after touchdown, Altitude 351 ft, 8.2V 57C HDOP00.7 SATS12
            14:16:48 Last position packet on aprs.fi log, Altitude 3026 ft, 8.1V 55C HDOP00.7 SATS13

            What's the lesson here? As always, one cannot base their observation of the RF network based on the limited and seriously distorted view that can be had when observing the APRS-IS stream.

            Even if people kept their equipment operating properly, the APRS-IS stream is highly filtered. 

            If you want to delve into what your payload was doing, do your investigation using your buddy's log, NOT the APRS-IS stream.

            Every one of the packets your buddy copied was direct from the payload, except for one.

            There are a few missing packets in your buddy's log, probably due to a chase vehicle, or other asset transmitting over top of the payload, but the information logged by your buddy is accurate.

            You can glean missing packets out of the APRS-IS log to fill voids in your buddy's log, but you really have to watch for delayed or damaged packets when doing so.

            All that red in the aprs.fi log is there to try and get you to pay attention to it. Read what it says, and try to determine why the packet has been flagged as bad. As I said, sometimes there's enough bad data that aprs.fi flags the good data as bad. You really have to watch for that, it takes a great deal of analysis to determine which packets are actually bad, and which are good.

            --
            James
            VE6SRV
          • Randy Love
            James, It ain t always the Igates fault. It could possibly by any of the digipeaters between the balloon and suspect Igate. ( Had that here in my area. A
            Message 5 of 12 , Jul 25 2:09 PM
            • 0 Attachment
              James, 

              It ain't always the Igates fault. It could possibly by any of the digipeaters between the balloon and suspect Igate. ( Had that here in my area. A UI-View powered digi in SE Ontario running a KPC3+ in kiss mode. )

              Only analysis of the local RF network around that Igate and the digi's involved will determine the true source of the delayed packets in that case.

              Randy
              WF5X



              On Fri, Jul 25, 2014 at 4:53 PM, James Ewen ve6srv@... [tracker2] <tracker2@yahoogroups.com> wrote:
               

              On Fri, Jul 25, 2014 at 10:12 AM, david@... [tracker2] <tracker2@yahoogroups.com> wrote:

              > I recently flew a tracker built with a T3-Mini on a balloon flight.  Had some issues.
              >
              > 1. Rapid, nearly continuous transmissions for a period during ascent and for a period during descent, and
              >
              > 2. Loss of GPS data at altitude.
              >
              >
              > If anyone has any insight into these problems, I'd like to hear from you.

              As you have already described in your webpage, you had seriously broken profile switching. If your payload was below 10,000 feet AND travelling less that 50 MPH it would stay in profile 1. If your payload was above 10,000 feet AND travelling less than 50 MPH, it would stay in profile 2. In any other situation, your payload would be profile switching like crazy.

              As Jason said, profile switch on altitude only.

              The ADS-GM2 from Argent should have been preloaded with firmware to work above 60,000 feet. However, the fact that the GPS stopped and started sending valid fix data either side of 32768 feet makes me suspicious of the firmware being used in the GPS.The DOD limit is 60,000 feet, but 32768 is a round number in hex. Scott might have more insight into this behaviour.

              Now onto other issues...

              One should NEVER fly anything with WIDE1-1 in the path. Most people argue that this gives the best chance of hearing the payload on the ground. The statistical probability of having a payload land on the ground, ONLY within range of a WIDE1-1 fill-in home station is so low, that the benefits of using such a path are far outweighed by the cost associated with flying WIDE1-1 at altitude.

              With profile switching, and changing to a no hop path, you spared the ground network a lot of congestion.

              You might try to argue that the last time the payload was heard without a digipeater was from 4407 feet. K4RTZ-1 is a full digipeater, and it was 30 miles away. There were no digipeaters closer.

              Bouncing through the digi, the packets got to the APRS-IS for another 1381 feet, down to 3026 feet.

              However, look at your buddies last heard:

              !3219.12N/08332.61W3077/011/A=002653

              He was able to hear your payload direct down another 373 feet. Get your chase and recovery crews in place, and you'll have a better chance of hearing the packet direct rather than via the APRS-IS.

              So, what about all the packet switching problems?


              Pre-launch and immediately post launch: Worked as intended, transmitting every 30 seconds with a path of WIDE1-1,WIDE2-1.
              Balloon released approx 11:00 am EDT from rural Georgia (USA).
              From your buddy's log, it looks like you launched at 15:01 (according to his clock)
              11:02:32 First packet on aprs.fi, telemetry packet T#039, showing WIDE1-1,WIDE2-1 path
              At 15:02, T#39 was heard by your buddy, which we can see at 11:02:32 in the APRS-IS log.
              11:03:10 First position packet on aprs.fi, 8.5V 66C HDOP01.0 SATS10
              Here's your first mistake... you are ignoring the data in front of you.

              2014-07-23 11:03:10 EDT: KY7DR-3>APOT30,W4MM-15,WIDE1,KE4LTT-2*,qAS,N4AU:!3156.51N/08327.02W3203/004/A=000761 08.5V 67C HDOP00.9 SATS10
              2014-07-23 11:03:10 EDT: KY7DR-3>APOT30,W4MM-15*,WIDE1*,KW4B-1*,WIDE2*,qAR,KC2NYU-1:!3156.51N/08327.02W3203/004/A=000761 08.5V 67C HDOP00.9 SATS10 
              
              There are two copies of the same packet in your APRS-IS log. Why is that? If you look closely, the second packet has a 'space' character added onto the packet, making it look different than the first to the anti-dupe routines. One of the stations handling the second copy is broken.

              Position packets generally coming in about every 30 sec or more, as expected. Altitude generally going up, but sometimes dip down briefly.

              Is your balloon playing yo-yo? Nope, so there has to be another reason for the up/down issue.

              2014-07-23 11:03:53 EDT: KY7DR-3>APOT30,WIDE1-1,WIDE2-1,qAR,AE4XO:!3156.54N/08326.91W3082/011/A=001236 08.5V 66C HDOP01.5 SATS09 
              2014-07-23 11:04:29 EDT: KY7DR-3>APOT30,WIDE1-1,WIDE2-1,qAR,AE4XO:!3156.60N/08326.85W3036/005/A=002244 08.5V 66C HDOP01.0 SATS10 
              2014-07-23 11:05:00 EDT: KY7DR-3>APOT30,W4MM-15,WIDE1,K4GKJ-15,WIDE2*,qAR,AE4S:!3156.54N/08326.91W3082/011/A=001236 08.5V 66C HDOP01.5 SATS09 [Duplicate position packet]
              aprs.fi flags the issue for you... Duplicate position packet. The original packet from 1236 feet was held by AE4S for 67 seconds before being forwarded to the APRS-IS stream. This delay is longer than the anti-dupe filter, so the packet makes it into the stream, but Hessu notices it and flags it as being a duplicate.
              11:05:44 Start seeing packet diarrhea, with "Rate limited (< 5 sec)]" in the aprs.fi log, altitude 2777 feet.

              
              2014-07-23 11:05:44 EDT: KY7DR-3>APOT30,K4EGA-1,WIDE1*,WIDE2-1,qAR,KD4YDD-1:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10
              2014-07-23 11:05:45 EDT: KY7DR-3>APOT30,W4CSG,W4LEE-1,WIDE2*,qAR,WB4BXO-6:!3156.63N/08326.81W3123/005/A=002777 08.5V 66C HDOP01.0 SATS10 [Rate limited (< 5 sec)]
              2014-07-23 11:05:46 EDT: KY7DR-3>APOT30,K4EGA-1,W4TL-3,WIDE2*,qAR,N4TAW:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10 
              2014-07-23 11:05:49 EDT: KY7DR-3>APOT30,WIDE1-1,WIDE2-1,qAR,AE4XO:!3156.68N/08326.74W3087/006/A=003913 08.5V 66C HDOP01.0 SATS10  [Rate limited (< 5 sec)]
              
              You can't blame the payload for what you see here. Look at what your buddy heard from the payload.

              7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.63N/08326.81W3123/005/A=002777 08.5V 66C HDOP01.0 SATS10 "
              7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:> Columbus High School Dreams P1,,,2"
              7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10 "
              7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:T#040,085,000,000,000,000,000000008.5V"
              7/23/2014 15:05,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.68N/08326.74W3087/006/A=003913 08.5V 66C HDOP01.0 SATS10 "
              7/23/2014 15:06,"KY7DR-3>APOT30,WIDE1-1,WIDE2-1:!3156.69N/08326.73W3102/000/A=004337 08.5V 66C HDOP01.0 SATS10 "
              The 2777 and second 3370 altitude packets are delayed packet, caused by improperly configured and maintained i-gates. WB4BX)-6 and N4TAW are delaying packet deliver to the APRS-IS stream, which causes untold grief for everyone.


              11:05:45 Altitude 3370 (550 ft/second rise?)

              Between which two packets?

              11:10:19 Comment packet indicates we're still in profile 1, as expected
              11:10:25 Altitude 9139 ft
              11:10:26 Altitude 3370 ft (where I have seen that number before?), 8.5V 63C HDOP01.4 SATS10

              2014-07-23 11:10:26 EDT: KY7DR-3>APOT30,K4RTZ-1,WIDE1*,WIDE2-1,qAR,K4DBN:!3156.66N/08326.76W3069/007/A=003370 08.5V 66C HDOP00.9 SATS10 [Rate limited (< 5 sec)]
              KD4DBN is delaying delivery of packets to the APRS-IS, but by almost 5 minutes. Another improperly maintained i-gate.

              11:11:02 Altitude 9697 ft
              11:12:14 Altitude 10902 ft
              11:12:18 Comment packet indicates we're in profile 2, as expected

              Here's where your profile switching issues will come into play, but with all the delayed packets and modified packets, it is very hard to determine which issue is which.

              11:12:19 Telemetry packet T#050
              11:13:07 Altitude 12071 ft
              11:13:09 Comment packet indicates we're in profile 1 (not expected at this altitude)

              2014-07-23 11:13:05 EDT: KY7DR-3>APOT30,qAR,KQ4KK-5:!3157.44N/08326.06W3067/015/A=012059 08.5V 67C HDOP00.9 SATS10  [Rate limited (< 5 sec)]
              2014-07-23 11:13:07 EDT: KY7DR-3>APOT30,W1KFR-1*,WIDE2-1,qAR,W1KFR:!3157.44N/08326.06W3079/015/A=012071 08.6V 67C HDOP00.9 SATS10 [Rate limited (< 5 sec)]
              2014-07-23 11:13:09 EDT: KY7DR-3>APOT30,WB4GNA-7,WIDE1,W4LAW-6,W4KCO-3*,qAR,KA4EMA-3:> Columbus High School Dreams P1
              
              You can see the profile switching happening. the first packet has no path, the second 2 seconds later is using a path. Your speed is <=50 MPH, so of course the profile will switch. Then profile 1 will determine that the altitude is >10,000 feet, so the profile will switch.

              11:13:11 Telemetry packet T#058
              11:20:37 Altitude 20790 ft
              11:30:32 Plausible position packet, Altitude 31564 ft, 8.4V 61C HDOP0.10 SATS09

              7/23/2014 15:30,KY7DR-3>APOT30:!3202.82N/08323.49W3017/024/A=032753 08.4V 61C HDOP01.0 SATS09 
              2014-07-23 11:30:15 EDT: KY7DR-3>APOT30,qAR,AE4XO:!3202.82N/08323.49W3017/024/A=032753 08.4V 61C HDOP01.0 SATS09  [Location changes too fast (adaptive limit)]
              
              This would be your last good fix before the GPS crapped out. Your buddy heard it direct, and AE4XO pushed it to the APRS-IS stream. aprs.fi flags it as bad due to the garbage it had received prior to this packet. Hessu can't always determine which packets are good, and which are bad.

              11:30:46 Started getting "NO FIX" packets (8.4V 60C) amongst position packets w/out "NO FIX"
              11:34:37 8.4V 61C HDOP0.10 SATS09 (last non-NO FIX packet for a while)
              11:50:37 Got one "NO FIX" packet reporting 8.3V 32C, and another reporting 8.4V 40C

              All the position packets seen mixed into the NO FIX packets are all delayed packets. Look at your buddy's log to determine what was actually heard on RF.

              12:34:24 First non-NO FIX packet in a while (first in an hour), Altitude 32785 ft (highest I've found), 7.9V 23C HDOP00.8 SATS11

              The payload is on it's way back down.

              12:34:30 Telemetry packet T#238
              12:34:56 Last "NO FIX" packet received, 7.9V 23C

              Delayed by bad i-gates

              12:36:00 Altitude 31566, 7.8V 28C HDOP00.7 SATS12
              12:36:56 Telemetry packet T#253
              12:37:07 Telemetry packet T#000 (counter to 255 wrapped, I presume)

              Yes, it's a circular counter.

              12:40:01 Altitude 27279, 7.7V 33C
              Lots more packet diarrhea going on...

              With lots of delays and mangled packets too!

              12:50:00 Altitude 16501 ft, 7.7V 44C HDOP00.7 SATS13
              13:00:07 Altitude 7384 ft 7.9V 51C
              13:21:50 Screen shot of my ground tracking station (APRSDroid) after touchdown, Altitude 351 ft, 8.2V 57C HDOP00.7 SATS12
              14:16:48 Last position packet on aprs.fi log, Altitude 3026 ft, 8.1V 55C HDOP00.7 SATS13

              What's the lesson here? As always, one cannot base their observation of the RF network based on the limited and seriously distorted view that can be had when observing the APRS-IS stream.

              Even if people kept their equipment operating properly, the APRS-IS stream is highly filtered. 

              If you want to delve into what your payload was doing, do your investigation using your buddy's log, NOT the APRS-IS stream.

              Every one of the packets your buddy copied was direct from the payload, except for one.

              There are a few missing packets in your buddy's log, probably due to a chase vehicle, or other asset transmitting over top of the payload, but the information logged by your buddy is accurate.

              You can glean missing packets out of the APRS-IS log to fill voids in your buddy's log, but you really have to watch for delayed or damaged packets when doing so.

              All that red in the aprs.fi log is there to try and get you to pay attention to it. Read what it says, and try to determine why the packet has been flagged as bad. As I said, sometimes there's enough bad data that aprs.fi flags the good data as bad. You really have to watch for that, it takes a great deal of analysis to determine which packets are actually bad, and which are good.

              --
              James
              VE6SRV


            • Jason KG4WSV
              I m glad James pointed out the infrastructure issues here in the southeast; I d forgotten. We launch out of Huntsville and frequently see APRS-IS issues due
              Message 6 of 12 , Jul 25 2:13 PM
              • 0 Attachment
                I'm glad James pointed out the infrastructure issues here in the southeast; I'd forgotten.  We launch out of Huntsville and frequently see APRS-IS issues due to broken infrastructure resulting in late packets (I want to say one problem station is in SC? or maybe around Chattanooga?).

                The RF data is definitely better than the IS data.

                Looks like they've increased the specs on those 9V lithium batteries since I last read a datasheet.  I don't know which one you're using, but the two most common ones should be OK as long as they don't get too cold (which will result in a voltage drop, which can be fatal if it goes too low).

                Other issues that sometimes crop up are the TX delay needs to be increased when the radio gets cold.  Of course, the result is opposite of what you're seeing here - no packets get through, since the slow PLL stabilization mangles the start of the packet.

                -Jason
                kg4wsv
              • James Ewen
                On Fri, Jul 25, 2014 at 3:09 PM, Randy Love rlove31@gmail.com ... This is indeed a possible scenario because the issue is in the KPC-3+ TNC failing to deliver
                Message 7 of 12 , Jul 25 2:17 PM
                • 0 Attachment
                  On Fri, Jul 25, 2014 at 3:09 PM, Randy Love rlove31@...
                  [tracker2] <tracker2@yahoogroups.com> wrote:

                  > It ain't always the Igates fault. It could possibly by any of the digipeaters between
                  > the balloon and suspect Igate. ( Had that here in my area. A UI-View powered digi
                  > in SE Ontario running a KPC3+ in kiss mode. )

                  This is indeed a possible scenario because the issue is in the KPC-3+
                  TNC failing to deliver packets from RF to the computer port in a
                  timely manner. When a KPC-3+ is operating as a stand alone digipeater
                  the issue does not manifest itself.

                  > Only analysis of the local RF network around that Igate and the digi's
                  > involved will determine the true source of the delayed packets in that case.

                  Correct, and there are so many problems down that way that I'm not
                  even going to start analyzing the issues and determining who's at
                  fault.

                  I people would pay attention to what's happening in their local area,
                  and correct problems as they crop up, it would be far better.
                  Unfortunately many people are in the "set it and forget it" mindset.
                  Then you get people who get upset that someone might be trying to help
                  them fix a problem with their station when they can see everyone
                  perfectly fine!

                  --
                  James
                  VE6SRV
                • dsiminiuk
                  No kidding! I discovered a local mobile in the Dallas area, sending 0/0 for lat/lon, MicE SPECIAL , with path WIDE1-1,WIDE3-3. I ve sent him an email...
                  Message 8 of 12 , Jul 25 2:23 PM
                  • 0 Attachment
                    No kidding!

                    I discovered a local mobile in the Dallas area, sending 0/0 for lat/lon, MicE "SPECIAL", with path WIDE1-1,WIDE3-3.

                    I've sent him an email...

                    Daniel
                    K2DMS


                  • Randy Love
                    That s extra SPECIAL rite thar! WF5X On Fri, Jul 25, 2014 at 5:23 PM, k2dms@k2dms.com [tracker2]
                    Message 9 of 12 , Jul 25 2:47 PM
                    • 0 Attachment
                      That's extra 'SPECIAL' rite thar!

                      WF5X


                      On Fri, Jul 25, 2014 at 5:23 PM, k2dms@... [tracker2] <tracker2@yahoogroups.com> wrote:
                       

                      No kidding!


                      I discovered a local mobile in the Dallas area, sending 0/0 for lat/lon, MicE "SPECIAL", with path WIDE1-1,WIDE3-3.

                      I've sent him an email...

                      Daniel
                      K2DMS


                    • Scott Miller
                      I went back and forth a few times with Globaltop last week, discussing the altitude problem and struggling with a language barrier. I think I ve communicated
                      Message 10 of 12 , Jul 27 10:37 PM
                      • 0 Attachment
                        I went back and forth a few times with Globaltop last week, discussing the altitude problem and struggling with a language barrier.  I think I've communicated the problem now, and we're waiting for another round of tests and responses from their engineers.  I've got more of the Gms-hpr receivers (used in the ADS-GM2) on the way, but I'm going to use this batch for ground applications only.  I'll let you know as soon as I have a definitive answer - and hopefully a test report from a GPS simulator.

                        Scott

                        On 7/25/2014 9:12 AM, david@... [tracker2] wrote:
                         

                        I recently flew a tracker built with a T3-Mini on a balloon flight.  Had some issues.  I've put all of the relevant info that I have into a web page:


                        http://ky7dr.com/dreams/dreams20140723.html


                        2 problems noted there:


                        1. Rapid, nearly continuous transmissions for a period during ascent and for a period during descent, and

                        2. Loss of GPS data at altitude.


                        If anyone has any insight into these problems, I'd like to hear from you.


                        David, ky7dr


                      • Matthew Cook
                        DOD GPS requirements for altitude and speed were supposed be to written as 60,000ft AND 1000mph, however for what ever reason some GPS manufacturers
                        Message 11 of 12 , Jul 28 12:07 AM
                        • 0 Attachment
                          DOD GPS requirements for altitude and speed were supposed be to written as 60,000ft AND 1000mph, however for what ever reason some GPS manufacturers implemented their knobbling function as an OR :-(

                          For reference the Atmel uBlox MAX and NEO modules do not suffer this problem, we've tested numerous modules (versions 4 through 7) locally here for the past three years to over 125,000ft.

                          YMMV.

                          Matthew
                          VK5ZM

                          On 28 July 2014 15:07, Scott Miller scott@... [tracker2] <tracker2@yahoogroups.com> wrote:
                           

                          I went back and forth a few times with Globaltop last week, discussing the altitude problem and struggling with a language barrier.  I think I've communicated the problem now, and we're waiting for another round of tests and responses from their engineers.  I've got more of the Gms-hpr receivers (used in the ADS-GM2) on the way, but I'm going to use this batch for ground applications only.  I'll let you know as soon as I have a definitive answer - and hopefully a test report from a GPS simulator.

                          Scott


                          On 7/25/2014 9:12 AM, david@... [tracker2] wrote:
                           

                          I recently flew a tracker built with a T3-Mini on a balloon flight.  Had some issues.  I've put all of the relevant info that I have into a web page:


                          http://ky7dr.com/dreams/dreams20140723.html


                          2 problems noted there:


                          1. Rapid, nearly continuous transmissions for a period during ascent and for a period during descent, and

                          2. Loss of GPS data at altitude.


                          If anyone has any insight into these problems, I'd like to hear from you.


                          David, ky7dr


                        • Christopher Snell
                          The uBlox receivers certainly seem to be popular amongst the HAB crowd. The modules are tiny. I d love to see a T3 option with a uBlox integrated onto the
                          Message 12 of 12 , Jul 28 2:40 PM
                          • 0 Attachment
                            The uBlox receivers certainly seem to be popular amongst the HAB crowd.   The modules are tiny.   I'd love to see a T3 option with a uBlox integrated onto the PCB.

                            Chris
                            NW5W


                            On Mon, Jul 28, 2014 at 12:07 AM, Matthew Cook vk5zm@... [tracker2] <tracker2@yahoogroups.com> wrote:


                            DOD GPS requirements for altitude and speed were supposed be to written as 60,000ft AND 1000mph, however for what ever reason some GPS manufacturers implemented their knobbling function as an OR :-(

                            For reference the Atmel uBlox MAX and NEO modules do not suffer this problem, we've tested numerous modules (versions 4 through 7) locally here for the past three years to over 125,000ft.

                            YMMV.

                            Matthew
                            VK5ZM

                            On 28 July 2014 15:07, Scott Miller scott@... [tracker2] <tracker2@yahoogroups.com> wrote:
                             

                            I went back and forth a few times with Globaltop last week, discussing the altitude problem and struggling with a language barrier.  I think I've communicated the problem now, and we're waiting for another round of tests and responses from their engineers.  I've got more of the Gms-hpr receivers (used in the ADS-GM2) on the way, but I'm going to use this batch for ground applications only.  I'll let you know as soon as I have a definitive answer - and hopefully a test report from a GPS simulator.

                            Scott


                            On 7/25/2014 9:12 AM, david@... [tracker2] wrote:
                             

                            I recently flew a tracker built with a T3-Mini on a balloon flight.  Had some issues.  I've put all of the relevant info that I have into a web page:


                            http://ky7dr.com/dreams/dreams20140723.html


                            2 problems noted there:


                            1. Rapid, nearly continuous transmissions for a period during ascent and for a period during descent, and

                            2. Loss of GPS data at altitude.


                            If anyone has any insight into these problems, I'd like to hear from you.


                            David, ky7dr





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