Using Two Party Balloons for the Payload

Using Two Party Balloons for the payload

So, you can get a bit more free lift out of the system, and perhaps a bit more altitude, by using two party balloons in tandem to fly the payload.  In my most recent flight, my payload was 18g, and I wanted 5g of free lift.  Using the float calculator (assuming helium), I came up with these numbers:

Scenario	Float Altitude
(1) 36" mylar, 18g payload, 5g free lift	Projected: 7630
(1) 36" mylar, 9g payload, 2.5g free lift (each doing 1/2 the work)	Projected: 8860
(1) 36" mylar, 9g payload, 2.5g free lift (each doing 1/2 the work)	Flight 1 Actual: 9156

The third row is an edit following the first flight, confirming the expectation that we would have a much nicer altitude with two balloons.

How to attach them

Consulting with Dave/VE3KCL, who is also flying dual balloons, he said he was using a Tyvek tape. I don't think I found exactly what he's using.  I found this:

I sealed the upper balloon with the Tyvek tape.  Note the attempt to keep the stem and valve section very flat.  I then found the center line of the lower balloon, and put a strip of Tyvek tape along the seam edge facing me.  I tried to keep the tape on the seam, and not extending down onto the balloon proper.  I then pressed the upper balloon into the tape.  The picture below shows the strip of tape attached to the lower balloon, and the upper balloon attached to the sticky side, facing me.  There is a little bit of the tape from the lower balloon extending past either side of the upper balloon, providing a sticky surface on each end.

I then placed a second strip of tape on the lower balloon closest to me, again trying not to hit the inflatable section of the lower balloon, and capturing the upper balloon. The front and back strips are stuck to each other on the end, and via the upper balloon in the middle.

Secondary connection

Dave also makes a secondary connection between the two balloons.  The runs a loose cord down from the upper to the attachment point at the bottom of the lower balloon.  I didn't do that for fear that the string rubbing on the lower balloon might cause problems.

Caveat

Note, in retrospect I would not have used two different color balloons.  They probably have different thermal characteristics.

Antenna length thoughts

Antenna length for the WSPR tracker

So, there are a few factors that impact the ideal length of the antenna for the WSPR tracker.  The classic wavelength formula is:

wevelength = 984 feet / Frequency in MHZ

This is adjusted by the velocity factor of the wire, which is also impacted by whether or not the wire is insulated.  I found several resources discussing wire length.  Conventional wisdom seems to be to adjust by between 4-5%.  W7NAT likes 5%.  This would be for ground-mounted antennas.

However, we're using very thin wire,  and we're in free space.  I'm going to try a full 1/4 wave with no adjustment.

Antenna scenario	Element length (inches)
20m 1/4 wave dipole for 14.0971.  No Adjustment.	209.4
20m 1/4 wave dipole for 14.0971.  4% adjustment for insulation.	201.0
20m 1/4 wave dipole for 14.0971.  5% adjustment for insulation.	198.9

Buglets

Buglets

I spent a fair amount of time writing code when it wasn't convenient to test it right away.  As a consequence, I had a pile of stuff to test the other night, and ran into a gazillion little buglets. Everything, so far, has been pretty easy to fix.

Watchdog Timer & Supercap charging

I implemented a watchdog timer, and sprinkled calls to refresh it throughout my code. Later, I implemented a routine at initialization to assure that the Supercap is charged up beyond a certain voltage before allowing the code to proceed.  The first thing we do is turn on the GPS, and I envisioned a situation where the GPS would brown out, repeatedly, as we're trying to charge the supercap and get going.  Well, I added a routine that was basically like this:

volts = getvolts();
while (volts < 3500) {      // Keep charging if less than 3500 microvolts
   deepsleep(5);        // Hibernate for 5 seconds
   volts = getvolts();
}

Well, the code worked a little too well.  I forgot to add a line to refresh the watchdog timer in the middle of that.  My timer pops after about 14 seconds, if it isn't refreshed. The entire board was rebooting during the charge-up phase.  It was a simple matter to call my "WATCHDOG_REFRESH()" macro to the middle of the loop.

GPS Reset

A few people running Pico trackers have had problems with the GPS freezing up, and basically not working for an entire day, until the sun went down, and the board rebooted overnight.  I added counter to keep track, and reset the GPS if it takes "too long" to get a lock.   

While I was testing something else, I left the tracker running on my desk.  I turned later, to find that I had exceeded my "too long" threshold, and the tracker had reset. Unfortunately, I neglected to reset my counter in the GPS Reset routine, so it kept getting called over and over, once the time was exceeded.  It was a simple matter to zero the counter after the reset.

Geofencing default

In testing my geofencing code, I discovered that the default if a coordinate was not in one of the polygons was "not allowed".  I found a #define in the code I had borrowed, and changed the default in my test environment.  Unfortunately, I forgot to port the one-line "#define" line into my Eclipse environment.  So, the geofencing in the code "worked", because it got back a "not allowed", and didn't transmit.

Revenge of geofencing

Well, I thought I fixed it, but I didn't.  I ran into another issue.  The geofence routine returns "true" if you are allowed to transmit in the coordinates passed to it.  I was setting a variable called "fenced" to the value of the geofence subroutine.  I basically had the value backwards.  I had to reverse the returned value from the call to make it behave as expected.  

Oversleeping

My deepsleep() routine always seemed to sleep about 1 second too long.  I didn't worry about it, since I was waking up the GPS 30-45 seconds before transmit time, and the one second didn't matter.Well, when I added the watchdog timer, I had to modify deepsleep() to sleep in 5 second chunks, and wake up to reset the watchdog.

Well, long story short, it turns out that the HAL routine to sleep is 0 based.  So, to sleep for 1 tick, you call it with a "0".  So, when I called it with "5", it actually slept for 6 seconds.  

In the original code, this wasn't a big deal.  No matter what length of time I intended to sleep, I just slept one extra second.  However, when I broke my sleep into 5 second intervals (which were really 6), the problem multiplied. 

Another easy fix.  Just subtract 1 from the sleep time, and voila, it worked much better

WSPR transmit DT

During testing, I noticed the DT column showed that my WSPR packets were about 2.4 seconds off my laptop.  I was pretty confident that I was syncing to GPS right in the tracker.  Upon conversations with Alan/W7QO, I was reminded that the WSPR protocol calls for the transmission to start at 1 second after the even numbered minute, not at 0 seconds.  That accounted for one second right there.

I'm still chasing the other 1.4 seconds of error.  It could well be my work laptop is not well synchronized to GMT.