Topics

Balloon Mail successful WB8ELK balloon recovered by W7QO

Bill Brown
 

I did a remote video link to Hank W4HTB at the Bowling Green, KY hamfest this Saturday to demonstrate to their audience how to launch a Pico Balloon with a 36" diameter mylar party balloon. This time Alan Adamson W7QO sent me one of his latest Peach-2 micro APRS transmitters for the demo. We launched it from my backyard about 20 miles south of Huntsville, AL in 25 knot winds. It ended up in a tall tree in my front yard for several minutes until Bev KK4RPQ grabbed it with a rake while standing on a ladder. It took off horizontally barely missing another row of trees and slowly bobbed up and down above the treetops in turbulence before finally gaining some altitude.

Unfortunately I messed up the internal valve in the balloon due to using a too-large diameter straw to release excess helium so this flight did not go superpressure and float but instead started a slow descent after getting to 18,000 feet. It was traveling over 100 mph at times.

It flew almost directly over Alan W7QO's house and landed about 20 miles east of him just north of Athens, GA. Alan located it today about 60 feet up in a tree and managed to retrieve it today. It is currently transmitting from his backyard in order to see how much longer the single-cell AAA battery lasts. The total payload weight with battery was about 18 grams but could be lightened even further to about 15 grams or so.

So the message here is:  "Balloon-Mail offers same-day delivery to a treetop near you, but you'll likely need a chainsaw."

- Bill WB8ELK
 

 

Mark Conner N9XTN
 

So did Alan need a chainsaw, or did he use some other creative means?

NSTAR has had two tree landings in about 50 flights.  One was retrieved by climbing (Paul KD4STH did the honors).  The second was in a tree where we were able to hook a line with a 20 ft collapsible painter's pole (which we carry on all chases now), grab the load line, then bend the tree over until we could reach the rest of the flight train - that one fell in a group of tall but spindly trees.  

73 de Mark N9XTN

On Mon, Oct 6, 2014 at 2:12 PM, wb8elk@... [GPSL] <GPSL-noreply@...> wrote:


I did a remote video link to Hank W4HTB at the Bowling Green, KY hamfest this Saturday to demonstrate to their audience how to launch a Pico Balloon with a 36" diameter mylar party balloon. This time Alan Adamson W7QO sent me one of his latest Peach-2 micro APRS transmitters for the demo. We launched it from my backyard about 20 miles south of Huntsville, AL in 25 knot winds. It ended up in a tall tree in my front yard for several minutes until Bev KK4RPQ grabbed it with a rake while standing on a ladder. It took off horizontally barely missing another row of trees and slowly bobbed up and down above the treetops in turbulence before finally gaining some altitude.

Unfortunately I messed up the internal valve in the balloon due to using a too-large diameter straw to release excess helium so this flight did not go superpressure and float but instead started a slow descent after getting to 18,000 feet. It was traveling over 100 mph at times.

It flew almost directly over Alan W7QO's house and landed about 20 miles east of him just north of Athens, GA. Alan located it today about 60 feet up in a tree and managed to retrieve it today. It is currently transmitting from his backyard in order to see how much longer the single-cell AAA battery lasts. The total payload weight with battery was about 18 grams but could be lightened even further to about 15 grams or so.

So the message here is:  "Balloon-Mail offers same-day delivery to a treetop near you, but you'll likely need a chainsaw."

- Bill WB8ELK
 

 



Bill Brown
 

The vast majority of our flights end up in treetops. I'd say about 80 percent of them. Handsaws, chainsaws, machetes, hatchets, slingshots, bows and arrows, long poles and potato cannons are all part of our balloon recovery inventory. We like to encourage Shane N4XWC to chase since he has all kinds of tree-climbing equipment and has climbed 90 feet up on numerous occasions to make a recovery. I think he passed the climbing rope test with flying colors in high school gym class !! The only recent exception to that rule was an ozonesonde that we were chasing that landed on the road right in front of us a couple of weeks ago. The new ozonesondes have GPS receivers onboard. For those in EOSS that need a tracking fix between EOSS launches, contact me and I'll let you know when they launch these from Boulder and how to tune them in.
 
I haven't heard how Alan recovered it as yet...but he was going to bring a saw along with him.
 
- Bill WB8ELK
 
 

-----Original Message-----
From: Mark Conner mconner1@... [GPSL] Cc: GPSL list
Sent: Mon, Oct 6, 2014 2:29 pm
Subject: Re: [GPSL] Balloon Mail successful WB8ELK balloon recovered by W7QO

 
So did Alan need a chainsaw, or did he use some other creative means?

NSTAR has had two tree landings in about 50 flights.  One was retrieved by climbing (Paul KD4STH did the honors).  The second was in a tree where we were able to hook a line with a 20 ft collapsible painter's pole (which we carry on all chases now), grab the load line, then bend the tree over until we could reach the rest of the flight train - that one fell in a group of tall but spindly trees.  

73 de Mark N9XTN

On Mon, Oct 6, 2014 at 2:12 PM, wb8elk@... [GPSL] <GPSL-noreply@...> wrote:


I did a remote video link to Hank W4HTB at the Bowling Green, KY hamfest this Saturday to demonstrate to their audience how to launch a Pico Balloon with a 36" diameter mylar party balloon. This time Alan Adamson W7QO sent me one of his latest Peach-2 micro APRS transmitters for the demo. We launched it from my backyard about 20 miles south of Huntsville, AL in 25 knot winds. It ended up in a tall tree in my front yard for several minutes until Bev KK4RPQ grabbed it with a rake while standing on a ladder. It took off horizontally barely missing another row of trees and slowly bobbed up and down above the treetops in turbulence before finally gaining some altitude.

Unfortunately I messed up the internal valve in the balloon due to using a too-large diameter straw to release excess helium so this flight did not go superpressure and float but instead started a slow descent after getting to 18,000 feet. It was traveling over 100 mph at times.

It flew almost directly over Alan W7QO's house and landed about 20 miles east of him just north of Athens, GA. Alan located it today about 60 feet up in a tree and managed to retrieve it today. It is currently transmitting from his backyard in order to see how much longer the single-cell AAA battery lasts. The total payload weight with battery was about 18 grams but could be lightened even further to about 15 grams or so.

So the message here is:  "Balloon-Mail offers same-day delivery to a treetop near you, but you'll likely need a chainsaw."

- Bill WB8ELK
 

 



Alan Adamson
 

Ah it wasn't too dramatic....

I ran out saturday afternoon and managed to catch an inflight beacon that the aprs infrastructure didn't... That got me close.

Then I took my Sat cross yagi and just put the 2mtr elements no it. when I was within about 1.5 miles of the last beacon that I caught, I found a high spot and DF'd it until I got a full beacon. Then drove right to the area.

Made sure it was still live and beaconing and that I had a good fix and from there, I simply went back home.... it was close to dark and it was an area I wasn't familiar with so I figured some night research was in order.

I learned two *invaluable things* about tracking.

a) SLOT TIME is your total friend... I'm going to use it *all the time now*... I knew that it should beacon at 48 seconds past the minute so that was incredibly useful when trying to DF it... The Wife would give me the count down and poof there is was. Sometimes I couldn't decode it, but that's because it was off the back of the beam.

b) sending crs/speed was also worth it's weight in gold. I had just added that and Bill tested it first. Compressed telem with crs/spd and altitude... This drew a line on aprs.fi with the expected path since the last beacon and that line helped us get within DF range and proximity. Speeding of speeds... I questioned my implementation at first... as it was pegged at 99mph on aprs.fi... So I looked at winds aloft... Bill picked a really good day for low altitude *jet stream*. It was 70-80kts at 10-12k that day!!! Sheesh, I'm glad I wasn't flying an airplane, going west would have taken *forever* with those winds.

so yesterday I drove out and walked into get a visual and assess what might need to be done to recover it. I originally thought I could get it yesterday, it was in a 6 inch diameter tree - not exactly climbable, and about 50-60' up. Took me a bit to find it as it was pretty dense where it was and the sun angle didn't help.

I had brought a few tools to use to get it and ran back to grab a rope saw hoping that I could simply get the tree off it's stump and push it down... Well, that didn't exactly go as planned. There was a knot right were I cut and I was able to push it over about 45 degrees, but nothing further. So back home again. Beacon time approx 28hrs so far.

Today I grabbed a bow saw and went back. It was still happily beaconing away, but I noticed that that processor had reset - more on that in a minute. Ran the bow saw over the cut a few times and was able to kick the tree off the stump... Once off, I was able to lift it up and pull it back about 5 ft and it started to continue to fall... Last bit required me to push it down further. At this point I was able to walk up and assess the mess. The tracker was tangled in the branches, and the balloon was free, but making the tangle worse. I managed to get everything out, power shut off to the tracker and headed home. Beacon time 50hrs and still at 1.4v

Once back, 2 things I determined. The tracker had actually reset each morning at approx 730am.... This I've now determined was due to moisture as it was an exposed launch. But I plan to test it out to make sure. The Balloon... Bill I don't know what you did the to fill stem, but I can't blow it out, I can't push a fill tube up into, it's a tiny ball mess up inside that I can image how was created. I'm sure it's partially pulled inside out as well. But I'm going to see if I can't at least get it to the point where I can blow it back up to see if the envelop had any imperfections.

This was new - experimental code... until I got everything working with this design, I've been running the processor at full speed - 32mhz. In that mode, the processor draws 8.5mA of current. But the M3 ULP cores have the ability to both scale the clock to various rates, and select internal LDO's built into the chip. Some of those rates will only draw uA of current even in run mode the trade off being clock rate. This was a test of going from the 1.8v LDO to the 1.5v LDO and from a 32mhz clock to an 8mhz clock. This dropped the run current from 8.5mA to 1.2mA run current (when it's in stop mode it's only drawing about 1.5uA)

Calculated run time on a single AAA battery at a 60 second beacon rate was for 84hrs. It was well on it's way there. However the resets didn't help it any as each would put the gps in high current mode and I have no idea how many of those happened in those morning *moisture* times.

Assuming it check out, it will get relaunched. But it's going on a diet. We'll see how low I can get it, it should be possible to launch it *protected* at around 13grams... Then we'll try this single cell code one more time :)...

Alan

On 10/6/2014 3:41 PM, wb8elk@... [GPSL] wrote:
The vast majority of our flights end up in treetops. I'd say about 80
percent of them. Handsaws, chainsaws, machetes, hatchets, slingshots,
bows and arrows, long poles and potato cannons are all part of our
balloon recovery inventory. We like to encourage Shane N4XWC to chase
since he has all kinds of tree-climbing equipment and has climbed 90
feet up on numerous occasions to make a recovery. I think he passed
the climbing rope test with flying colors in high school gym class
!! The only recent exception to that rule was an ozonesonde that we were
chasing that landed on the road right in front of us a couple of weeks
ago. The new ozonesondes have GPS receivers onboard. For those in EOSS
that need a tracking fix between EOSS launches, contact me and I'll let
you know when they launch these from Boulder and how to tune them in.
I haven't heard how Alan recovered it as yet...but he was going to bring
a saw along with him.
- Bill WB8ELK
-----Original Message-----
From: Mark Conner mconner1@... [GPSL] <GPSL-noreply@...>
Cc: GPSL list <GPSL@...>
Sent: Mon, Oct 6, 2014 2:29 pm
Subject: Re: [GPSL] Balloon Mail successful WB8ELK balloon recovered by W7QO

So did Alan need a chainsaw, or did he use some other creative means?

NSTAR has had two tree landings in about 50 flights. One was retrieved
by climbing (Paul KD4STH did the honors). The second was in a tree
where we were able to hook a line with a 20 ft collapsible painter's
pole (which we carry on all chases now), grab the load line, then bend
the tree over until we could reach the rest of the flight train - that
one fell in a group of tall but spindly trees.

73 de Mark N9XTN

On Mon, Oct 6, 2014 at 2:12 PM, wb8elk@... <mailto:wb8elk@...>
[GPSL] <GPSL-noreply@...
<mailto:GPSL-noreply@...>> wrote:



I did a remote video link to Hank W4HTB at the Bowling Green, KY
hamfest this Saturday to demonstrate to their audience how to launch
a Pico Balloon with a 36" diameter mylar party balloon. This time
Alan Adamson W7QO sent me one of his latest Peach-2 micro APRS
transmitters for the demo. We launched it from my backyard about 20
miles south of Huntsville, AL in 25 knot winds. It ended up in a
tall tree in my front yard for several minutes until Bev KK4RPQ
grabbed it with a rake while standing on a ladder. It took off
horizontally barely missing another row of trees and slowly bobbed
up and down above the treetops in turbulence before finally gaining
some altitude.

Unfortunately I messed up the internal valve in the balloon due to
using a too-large diameter straw to release excess helium so this
flight did not go superpressure and float but instead started a slow
descent after getting to 18,000 feet. It was traveling over 100 mph
at times.

It flew almost directly over Alan W7QO's house and landed about 20
miles east of him just north of Athens, GA. Alan located it today
about 60 feet up in a tree and managed to retrieve it today. It is
currently transmitting from his backyard in order to see how much
longer the single-cell AAA battery lasts. The total payload weight
with battery was about 18 grams but could be lightened even further
to about 15 grams or so.

So the message here is: "Balloon-Mail offers same-day delivery to a
treetop near you, but you'll likely need a chainsaw."

- Bill WB8ELK




Mark Conner N9XTN
 

Yes to both.  (a) is valuable in flight too.  Normally we have a receiver on our primary non-39 APRS frequency running open squelch.  This gives us an idea of how we're doing on signal strength, and if we notice a failure to decode by the TNC, we listen even more to the audio.  Knowing a packet is coming up helps us do "other things" while we're waiting on the next beacon.  

(b) is definitely worthwhile too - I wouldn't do without it unless I absolutely had to.

Another item to consider is using the hhmmss format for the time spec.  This helps reconstruct logs afterwards, especially data collected from others.  It's really handy to have a good time stamp right in the packet instead of relying on others' clocks.  I can't remember if that's part of the APRS compressed format or not.  We generally run more towards the "plain" format, which is harder on the TX/battery budget but has more flexibility.

73 de Mark N9XTN

On Mon, Oct 6, 2014 at 4:28 PM, Alan Adamson akadamson@... [GPSL] <GPSL-noreply@...> wrote:


I learned two *invaluable things* about tracking.

a) SLOT TIME is your total friend... 

b) sending crs/speed was also worth it's weight in gold.  

Leo Bodnar <leo@...>
 

Mark,

That's what all B-flights do as well.  There is no compressed timestamp available in APRS specification so i just dreamt up my own.

There are encoded time and datestamps in each realtime and backlog message sent from B-**.  Without them there is no way to untangle APRS timing mess.  

There are stations sending packets with 30-60 minutes delays and aprs.fi dutifully lists them under delayed times.  
The worst I had was 18 hours delayed packets from some unlisted igate in Russia.

For example, last B-64 packet was:

2014-10-06 07:10:43 UTC: M0XER-4>APRS64,LD9TK,WIDE2*,qAR,LA9UI-2:!/)IQ1Q_7)O W{h)/A=040836|+fI7&W=r!,|

...note "W{h)" in front of /A=040836 - this is an encoded GPS date/time stamp.  It decodes to "10th of October, 07:10:41" 

Cheers
Leo

On 6 Oct 2014, at 22:51, Mark Conner mconner1@... [GPSL] wrote:

Another item to consider is using the hhmmss format for the time spec.  This helps reconstruct logs afterwards, especially data collected from others.  It's really handy to have a good time stamp right in the packet instead of relying on others' clocks.  I can't remember if that's part of the APRS compressed format or not.  We generally run more towards the "plain" format, which is harder on the TX/battery budget but has more flexibility.

Alan Adamson
 

Thanks Mark. I encode both the date and time in a compressed format in both my live beacons and my log beacons (similar to how Leo does it as I just saw his response to same) - this isn't apart of the aprs spec, but helps me when I push to snus.

While there is a time format version for compressed posit/telemetry the date/time are not compressed but just ascii.

Further, Hes at aprs.fi, when he gets a posit from aprs.si, doesn't use any form of the date/time, he uses his own.

As luck would have it... Hes, I, Bill Brown, Bob Bruninga and a couple people have just been discussion this very issue in hopes of finding a way to push historical posit to the aprs.fi environment to *fill* in the track.... We'll see where that whole conversation goes - hopefully somewhere good.

Alan

On 10/6/2014 5:51 PM, Mark Conner wrote:

Another item to consider is using the hhmmss format for the time spec.
This helps reconstruct logs afterwards, especially data collected from
others. It's really handy to have a good time stamp right in the packet
instead of relying on others' clocks. I can't remember if that's part
of the APRS compressed format or not. We generally run more towards the
"plain" format, which is harder on the TX/battery budget but has more
flexibility.

James Ewen VE6SRV
 

There are a few things I can add to your "must-have" list. 

Because of the wonderful flexibility of these payloads, and having immediate access to the guy writing the code, think about these features. 

Send a series of tones on frequency immediately before sending your position report for DFing. The tones will be distinctive, allowing one to identify the payload transmission audibly, and if necessary, get a beam pointed at the payload before needing to decode the APRS data.  The OpenTracker line has a function called SQUAWK, which can be used to make the payload send alternating tones in a bee-doo bee-doo pattern. Very difficult to mistake for an APRS packet. 

Switch to an alternate frequency, and do the above. 

One of the hardest things to do when searching for a downed payload is to be able to differentiate your "braaaaaap" from other "braaaaps" out there.  The times slot helps, but there's always someone clobbering, or a far off digipeater making noise out there right when your payload should be up. Getting off the national channel and to a quiet frequency really helps. Oh yeah, get your search teams to turn off beaconing if they switch their APRS radios to the non-standard frequency. 

Of course, you would probably only enable these features once the payload has determined it is on the ground.  Look for altitude below a preset value, and/or look for 0 groundspeed. A combo of both, with some leeway on the speed due to GPS wandering is probably best. Kicking in the DF tones before landing might be an idea so even teams without beams can add in "heard reports" as the payload drops below their local horizon. If the teams are surrounding the payload, these heard reports might be enough to help figure out who's closer and who's further from the payload.  

Of course, Leo's probably not interested in any of this, since all of this is concerning recovering balloons after flight termination, and someone seems to have missed the memo about flights terminating, and just leaves them circling the Earth endlessly!


On Monday, October 6, 2014, Leo Bodnar leo@... [GPSL] <GPSL-noreply@...> wrote:


Mark,

That's what all B-flights do as well.  There is no compressed timestamp available in APRS specification so i just dreamt up my own.

There are encoded time and datestamps in each realtime and backlog message sent from B-**.  Without them there is no way to untangle APRS timing mess.  

There are stations sending packets with 30-60 minutes delays and aprs.fi dutifully lists them under delayed times.  
The worst I had was 18 hours delayed packets from some unlisted igate in Russia.

For example, last B-64 packet was:

2014-10-06 07:10:43 UTC: M0XER-4>APRS64,LD9TK,WIDE2*,qAR,LA9UI-2:!/)IQ1Q_7)O W{h)/A=040836|+fI7&W=r!,|

...note "W{h)" in front of /A=040836 - this is an encoded GPS date/time stamp.  It decodes to "10th of October, 07:10:41" 

Cheers
Leo

On 6 Oct 2014, at 22:51, Mark Conner mconner1@... [GPSL] wrote:

Another item to consider is using the hhmmss format for the time spec.  This helps reconstruct logs afterwards, especially data collected from others.  It's really handy to have a good time stamp right in the packet instead of relying on others' clocks.  I can't remember if that's part of the APRS compressed format or not.  We generally run more towards the "plain" format, which is harder on the TX/battery budget but has more flexibility.





--
James
VE6SRV

Alan Adamson
 

oh, I have a whole laundry list of descent functions. Most of what you wrote is included. I just haven't been focused on *descent* much... until Bill launched one at me :)...

Alan

On 10/6/2014 10:03 PM, James Ewen ve6srv@... [GPSL] wrote:
There are a few things I can add to your "must-have" list.


Because of the wonderful flexibility of these payloads, and having
immediate access to the guy writing the code, think about these features.

Bill Brown
 

On my homebrew APRS transmitters I put a very short beep before or after sending the APRS transmission when I'm flying it on a regular flight. That and knowing when it is timeslotted really helps to identify it. But in my latest code I have it so that it alternates frequency. It transmits every 30 seconds...once on 144.39 and then the next on 144.36 and so on. The end result is a once per minute transmission on 144.39 and also 144.36.

- Bill WB8ELK






-----Original Message-----
From: James Ewen ve6srv@... [GPSL] <GPSL-noreply@...>
To: Leo Bodnar Cc: GPSL List
Sent: Mon, Oct 6, 2014 9:03 pm
Subject: Re: [GPSL] Balloon Mail successful WB8ELK balloon recovered by W7QO

 
There are a few things I can add to your "must-have" list. 

Because of the wonderful flexibility of these payloads, and having immediate access to the guy writing the code, think about these features. 

Send a series of tones on frequency immediately before sending your position report for DFing. The tones will be distinctive, allowing one to identify the payload transmission audibly, and if necessary, get a beam pointed at the payload before needing to decode the APRS data.  The OpenTracker line has a function called SQUAWK, which can be used to make the payload send alternating tones in a bee-doo bee-doo pattern. Very difficult to mistake for an APRS packet. 

Switch to an alternate frequency, and do the above. 

One of the hardest things to do when searching for a downed payload is to be able to differentiate your "braaaaaap" from other "braaaaps" out there.  The times slot helps, but there's always someone clobbering, or a far off digipeater making noise out there right when your payload should be up. Getting off the national channel and to a quiet frequency really helps. Oh yeah, get your search teams to turn off beaconing if they switch their APRS radios to the non-standard frequency. 

Of course, you would probably only enable these features once the payload has determined it is on the ground.  Look for altitude below a preset value, and/or look for 0 groundspeed. A combo of both, with some leeway on the speed due to GPS wandering is probably best. Kicking in the DF tones before landing might be an idea so even teams without beams can add in "heard reports" as the payload drops below their local horizon. If the teams are surrounding the payload, these heard reports might be enough to help figure out who's closer and who's further from the payload.  

Of course, Leo's probably not interested in any of this, since all of this is concerning recovering balloons after flight termination, and someone seems to have missed the memo about flights terminating, and just leaves them circling the Earth endlessly!


On Monday, October 6, 2014, Leo Bodnar leo@... [GPSL] <GPSL-noreply@...> wrote:


Mark,

That's what all B-flights do as well.  There is no compressed timestamp available in APRS specification so i just dreamt up my own.

There are encoded time and datestamps in each realtime and backlog message sent from B-**.  Without them there is no way to untangle APRS timing mess.  

There are stations sending packets with 30-60 minutes delays and aprs.fi dutifully lists them under delayed times.  
The worst I had was 18 hours delayed packets from some unlisted igate in Russia.

For example, last B-64 packet was:

2014-10-06 07:10:43 UTC: M0XER-4>APRS64,LD9TK,WIDE2*,qAR,LA9UI-2:!/)IQ1Q_7)O W{h)/A=040836|+fI7&W=r!,|

...note "W{h)" in front of /A=040836 - this is an encoded GPS date/time stamp.  It decodes to "10th of October, 07:10:41" 

Cheers
Leo

On 6 Oct 2014, at 22:51, Mark Conner mconner1@... [GPSL] wrote:

Another item to consider is using the hhmmss format for the time spec.  This helps reconstruct logs afterwards, especially data collected from others.  It's really handy to have a good time stamp right in the packet instead of relying on others' clocks.  I can't remember if that's part of the APRS compressed format or not.  We generally run more towards the "plain" format, which is harder on the TX/battery budget but has more flexibility.





--
James
VE6SRV

Leo Bodnar <leo@...>
 

Well of course it decodes to the *6th of October* when my script uploads it to spacenear.us ...


On 6 Oct 2014, at 23:34, Leo Bodnar leo@... [GPSL] wrote:

Mark,

That's what all B-flights do as well.  There is no compressed timestamp available in APRS specification so i just dreamt up my own.

There are encoded time and datestamps in each realtime and backlog message sent from B-**.  Without them there is no way to untangle APRS timing mess.  

There are stations sending packets with 30-60 minutes delays and aprs.fi dutifully lists them under delayed times.  
The worst I had was 18 hours delayed packets from some unlisted igate in Russia.

For example, last B-64 packet was:

2014-10-06 07:10:43 UTC: M0XER-4>APRS64,LD9TK,WIDE2*,qAR,LA9UI-2:!/)IQ1Q_7)O W{h)/A=040836|+fI7&W=r!,|

...note "W{h)" in front of /A=040836 - this is an encoded GPS date/time stamp.  It decodes to "10th of October, 07:10:41" 

Cheers
Leo