AZHAL-1 Flight
(Apr 2014)

Altitude: 93,248 ft

Flight: 2 hours, 26 min

Distance: 15 miles

AZHAL-1 was our 4th mission, and after a few hours of launch delay, was finally a successful flight for the weekend of 100+ world-wide launches for the Global Space Balloon Challenge (GSBC) (http://www.balloonchallenge.org/). We were shooting for 100,000 feet, but given the launch problem we had, we were happy to have made it up at all, let alone making 93k.

Hey kids: How cold do you think it is at various altitudes? How fast do you think the balloon falls after it bursts? Read on and find out.  Our new team for this mission: Arizona High-Altitude ‘Looners (AZHAL).

So we planned a launch for the Global Space Balloon Challenge last Saturday morning. The weather was looking gray and drizzly, and since we wanted to get decent pics and not just a gray cloud mass below, we almost scrubbed for weather. However, the satellite weather videos and forecasts were looking better for mid-day, so we planned on a 1pm MST launch. The balloon path predictions looked pretty good as well, with a rather short run (laterally) due to moderate winds-aloft.

We used a new balloon trajectory predictor as well (see above), written by Allen Jordan at NOAA. This program not only lets us use either a GFS or current-winds model, but also allows us to configure finely-granular ascent and descent profiles (rate vs. altitude), and will also run for up to 30-days in the past, which is great when you want to see what the prediction was for your somewhat-late or relocated-launch-site day. We also like the popular habhub predictor, but it seems to use fixed ascent/descent rates, and does not save any GFS history to allow you to run even an hour in the past, which is indeed a bummer. On our last launch, we did not load enough helium, but we had a good idea of our ascent rate from APRS data — would have been nice to re-run the habhub predictor (did not have Allen’s predictor back then) to find an estimated landing spot (our balloon was still at 70 Kft or so), but habhub would not let us use a 2-hour old launch time and we had to try a prediction by launching “now,” with rather different winds. The lack of history prediction is a big missing-feature in the habhub predictor, IMHO.

We got all set to go, planned our launch site (above), called in our NOTAM to the FAA, and went to meet the neighbors to see if they had any concerns with us launching just south of their house. They were quite nice and stopped over periodically to see how we were doing as we set up.

We got the payload all prepared, turned the electronics on, checked the radio transmitters, and connected a laptop to the balloon serial port to monitor logging data. Everything looked great, so it was time to fill the balloon.

We were only a bit late (at about 1:30) with our target launch time when we ran into a problem.

As we filled our 1200g Kaymont balloon, the brand-new-should-have-been-full helium tank ran out. It now seems like it only had about 80 cu-ft, and not the 219 cu-ft for which we paid. So we had a bunch of folks holding a half-full balloon in the heat, while we drove around a small town to scrounge some helium. We found an expensive source of helium, went back to the launch site, and continued filling the balloon.

Yeah, somewhere in the middle of filling we ran out of helium and had to go find more. But we didn’t let a little obstacle like that scrub our day. We solved the problem and had a successful flight — an important lesson to teach the kids.

We have since procured a tank pressure-gauge, which we wished we had on this launch day, to estimate how much helium we had in the tank. Yes, we will be gauging our tanks both before and after launch from now on. Even though it was a frustrating launch day due to a half-empty helium tank, a big thanks go out to Phoenix Welding Supply, who not only didn’t charge for the problem tank, but even fronted a tank for our next launch.

By the time we finally got the balloon filled, it started getting pretty windy and the gusts would lift the balloon, making it almost impossible to tell when we had proper balloon buoyancy to levitate our calibrated neck-lift weight. Because of this, the launch gas volume was a bit of a guess (it turns out that we probably put in a little bit more than planned — a first for us as we have put in too little on two previous runs).

Well, we finally did get it filled and launched about three hours late at 4pm MST. Whew.

Besides the helium fiasco, I realized (just moments after launch) that I forgot to turn on the still camera. That was a bummer. All hope of seeing something visual from the balloon now rested on the untried Mobius video camera. To make matters worse, we did not get live-video from the balloon at launch as we had hoped. Was it the 5.8GHz transmitter, or was the video camera dead as well? As it turned out, we did get some great video on the camera’s SD card, but we did not know that until after recovery. We grabbed some stills out of the video.

Above is a shot at 44 seconds after launch, and we are already up to 900 feet AGL (Above Ground Level), which is 2100 feet MSL (Mean Sea Level).

At about six minutes, we reach 7900 feet MSL. We are facing east over the town of Maricopa. Our landing spot is in the right-rear part of this picture. It was a very short flight laterally — only about 15 miles.

The tracking data from our APRS transmitters was awesome. We were toggling both Byonics transmitters to alternating frequencies, sending at a modest rate to the public 144.390 MHz APRS channel, and also to a quiet 144.920 channel at much-faster rate. Byon was receiving the 144.920 data in his chase car, logging it to his laptop, and also injecting data into the aprs.fi system by using his cell phone as a wifi hotspot. We could not have asked for a better tracking setup — thanks Byon!

On aprs.fi it looked like we were saturating the system, but most of the packets showing up there were internet-injected. On the quiet 144.920 channel, we sent clear-text-readable (non-MIC-E) packets so we could easily see latitude/longitude/altitude in the chase cars. On 144.390, we sent compressed MIC-E packets, which shortened our tx time, and also made it easy to look at the aprs.fi raw packet log and identify the two packet sources.

Up to 11,000 feet in 9 minutes. This is looking north at Estrella Mountain.

And 20,000 feet in 17 minutes, again looking north at Estrella Mountain.

30,000 feet in 27 minutes.

40,000 feet in 42 minutes. We are looking northeast, straight up Highway 347 (just right of pic center) and see Chandler/Gilbert/Mesa to the right, and Tempe/Phoenix to the left, somewhat obscured by clouds (gee, I still have an LP of that Pink Floyd album).

51,000 feet in 60 minutes. We are now facing southeast, and see Casa Grande in the lower center, and Interstate 10 heading diagonally to the right towards Picacho Peak. Tucson is way in the distance behind that.

70,000 feet in 87 minutes. Very cool clouds that afternoon — would have been a bummer if it was the gray overcast of the morning, so I guess it worked out well that we launched late.

Reade wrote a java program on his laptop that constantly grabbed aprs data and calculated a predicted landing position, displaying it on a 3D Google Earth map. It was pretty cool and turned out to be accurate as well.

91,600 feet in 117 minutes.

91,700 feet. If you look closely to the right of center, you can see a little horizontal mountain ridge — this is Newman Peak (about 4500 feet high). To the right of Newman Peak is Picacho Peak (a shade under 3400 feet) and we can still see the Interstate 10 angling up towards it. In front of these mountains is the City of Eloy. I got to know Eloy quite well as I drove around for two days looking for our (still-missing) LE-2 payload. As we move left we see Coolidge, then Florence, the Gila River, San Tan Valley, and just the southern part of Queen Creek. In the lower left you can see part of San Tan Mountain.

91,870 feet.

As we were sitting at a restaurant getting recharged, and watching the balloon’s progress on laptops and cell phones, we saw that the balloon popped at a bit over 93,000 ft (we were shooting for 100,000). That, plus the faster-than-expected ascent rate told us that we put more helium in the balloon than planned, but this was a difficult launch in windy ground conditions, so we were guessing on whether our neck-lift weight was indeed levitating. Oh well, 93k is still a pretty good run, especially considering that we were lucky have even made it up that day.

Above, we have descended to 80,000 feet and see our jack antenna bounce up into view! It only took one minute and fifteen seconds to drop over 13,000 feet.

The APRS data, shown above, matched our NOAA prediction and Reade’s LZ-Predictor pretty well. The radio beacons, both 2m and 70cm, also worked well. Unfortunately, our 70cm-to-2m voice repeater did not work as well as we had hoped — we got some scratchy messages through, but that was all. We have not heard from any other hams who may have tried it. If you tried to work it, please let us know.

In addition to Reade’s landing-zone predictor program guiding us, we also had good lat/long data of the landing spot from final aprs packets — Byon beat us to the payload as he was closer, but we drove right to the where we expected to find the payload, and could easily see it a few hundred feet behind a barbed wire fence in a farm field. Luckily the farmer was just driving out as we pulled in, and he kindly opened the field gate for us.

Just one broken leg on the Jack Antenna, and a bit of a dent in the styrofoam bottom of the main payload. Not bad considering that we hit about 18 mph.

So we had no Canon still-camera pics (since I forgot to turn it on), but we popped the SD card out of the little Mobius video camera and saw some great video on the laptop — well, I could not see it too well, as all the kids pressed in to see, but I did see the great footage later that night.

So how did our on-board experiments fare? This was a new control system, with a PIC programmed in C, an untried SD FAT file system, and a bunch of new custom drivers for all the sensors. It would indeed have been a bummer to pull the SD card out of the controller to find an empty log file — it turns out that logging was flawless, including not only the flight, but also the three hours prior to launch when it just sat and ran while we dealt with the helium emergency. We wrote the data as text in comma-delimited records, so we could open the file in Excel for analysis. Excel is a goofy program with confusing charting and such, but it is handy to be able to create new columns and create things like elapsed time, ascent/descent rates, moving average filters to smooth sensor data, and so on. Here is a summary of our experiment log:

Above is the ascent phase, showing atmospheric pressure in psi (pounds-per-square-inch) versus altitude in feet. No surprises here, of course, but pressure is a good backup for calculating altitude. The ascent time was 1 hour and 59 minutes from ground level (1230 ft MSL) to burst at 93248 feet MSL. The pressure sensor was an HSC device rated for 0 to 15 psi absolute pressure.

And this is the descent phase graph of atmospheric pressure versus altitude. There is a little bump at 50Kft, which is an anomaly. Descent lasted only 27 minutes from 93248 feet to landing (1182 ft MSL).

This is the ascent graph of external temperature, internal temperature, and relative-humidity versus altitude.

The external temp sensor was a simple voltage-output TMP36 unit, running into an ADC input on the controller. It is interesting how it has glitches that are rather regular; I suspect this is related to the ADC (and software loop) and not the sensor. These glitches could easily be filtered out in the controller before logging. I could also have filtered them out in Excel, but I thought the glitches made for an interesting graph.

Outside air hit freezing (32F, 0C) 15 minutes after launch, at about 18,000 feet. Notice how the external temp drops to a minimum ascent temperature of about -22F (-30C) at around 40,000 feet (and 45 minutes) — this altitude is about where we expect to reach the “tropopause” (for our Arizona latitude), the boundary between the troposphere layer below, and the stratosphere above. The graph clearly shows the expected temperature inversion as we ascended into the stratosphere. Cool. Literally.

EDIT: After talking with folks who really know about balloon launches, we find that our ascending external temperature sensor was likely reading higher-than-expected temperatures due to solar heating (it was a black sensor exposed to sunlight). A couple of notes on external temperature sensors: “thermistor” sensors are said to be the most inaccurate at the low temps of the upper atmosphere — our DHT22 external humidity/temp sensor also reports temperature, but uses a thermistor sensor, so we take those temp numbers with a grain of salt. The primary-external-temp TMP36 analog-output sensor uses semiconductor “band-gap” properties to determine temperature, and should be more accurate. The TMP101 temp sensor, which we wish to use on our next flight as an additional external temp sensor, uses the temperature-dependencies of a semiconductor diode to discern temperature. It seems that the -70F minimum that we sensed during descent should also have been seen during ascent — we need to shield the sensor from sunlight for the next payload.

The internal temp sensor was a TMP101 with an I2C interface — it is much more well-behaved than the external TMP36 sensor we need to digitize. Internal temp is simply a function of the outside air temp and the insulation in the walls of our payload. We tried to seal the payload up as best we could (cotton balls plugging cable holes etc), but it does need to breathe somewhat, otherwise our payload would explode when the pressure drops (just like the balloon). During ascent, the warm air inside the payload box is slowly sucked out due to the lowering pressure. Inside our box we hit freezing (32F, 0C) at about 59,000 feet (1 hour and 10 minutes into our flight) and the temp kept dropping.

Relative-Humidity (RH) was measured with a DHT22 sensor (which has an odd sort of one-wire interface). On this graph we also see a few data glitches — during logging, if data from a sensor was unavailable for that record, we just printed a question mark. Instead, we could have just used the previous data point, or a value extrapolated from the last couple of points. Maybe next time. RH was low at launch (~18%), peaked at bit near 10,000 feet and then humidity dropped to near-zero above 30,000 feet.

Here we see the descent phase, showing external temperature, internal temperature, and humidity versus altitude.

External temperature dropped considerably as we fell — why is that? I would have expected the inverse profile as ascent. We can see the lower limit of the TMP36 sensor bottoming-out at about -58F (-50C). If we extrapolate the curve a bit, it looks like the minimum descent temperature was approximately -70F (-57C) near 45,000 feet. The DHT22 humidity sensor, which is mounted on the exterior of the payload, was only rated to operate down to -40F (-40C), but continued to feed us data when it was out of spec. The DHT22 also provided external temperature, and tracked the TMP36 generally within a few degrees (sometime up to ten), and it also hit its lower limit of -40F when the TMP36 bottomed-out. So I think the temperature trend is real, I just don’t know why it would be colder coming down, except that there is more relative wind.

Internal temperature continued to drop during descent, probably since our near-vacuum payload started sucking in really cold air on the way down, and of course, is insulated, so even the warmer outside air closer to Earth will take a while to heat things back up. The drop continued to a minimum internal temp of 0F (-18C) about 12,000 feet before starting to warm up a bit. Our payload was still frozen when we opened it up.

Our last payload stayed warmer, so it seems that it was a bit tighter, and probably had less open space. Some folks recommend filling cavities with packing peanuts or something to displace the air volume and minimize how much cold air gets sucked back in during descent — this makes a lot of sense. Some other folks like to use hand-warmer packs, however, I think there are two problems with those: first, some of the units need oxygen to chemically heat, and, well, there is not much up there. Second, even if you use a non-O2 pack, by the time the heat could help, the air is so thin that there is just not a conductive mechanism to heat circuit boards and such. You could tape them to battery packs or cameras for a bit of direct conduction, just don’t expect them to keep the “air” toasty.

All of the electronics in our payload controller, including the GPS module, were rated to operate down to -40F (-40C), and the lithium batteries are good down to at least -4F (-20C). The pressure sensor, which is also inside the payload, has a calibrated range down to 32F (0C), but an operating range (with some error, I presume) down to -4F (-20C). The particulate sensor has an operating spec down to 32F (0C), so we pushed this out of limits. Some parts of our payload had no published temperature spec, including the Mobius camera and the vintage Geiger-Muller tube, but they both worked great.

The humidity on the way down was near-zero until about 25,000 feet, then peaked at about 90% RH around 10,000 feet (there were thin clouds around by landing time).

The ascent rate is plotted above in three units, feet-per-second, miles-per-hour, and meters-per-second. These are all the same curve, of course, but they plot together nicely on the same scale. Another unit that is not plotted here but is sometimes handy, is feet-per-minute (which is fps*60). It is interesting how the balloon ascent slows down a bit around 35,000 feet.

The descent rate was surprising — I knew the balloon would drop quickly after burst, but I did not realize just how fast until we finally got good log data on this flight. Seven seconds after burst the balloon was falling at 73 mph; by ten seconds it was at 122 mph. After 13 seconds of dropping the balloon hit 138 miles-per-hour! That was the peak rate, and it then slowed in the thickening air until the chute deployed. On our last mission we have pics of the chute not-open at 69Kft and open at 61Kft, which leads us to estimate that parachute deployment is at about 65,000 feet. The air was still somewhat thin up there and it took until about 48,000 feet until the graph shows us that the chute slowed it down nicely.

We crashed, er, landed, going about 18 mph, which is pretty fast, but the payload survived well, with just one broken leg on the jack antenna, and a dent in the bottom styrofoam. This was a five pound payload with a four foot HAB chute from Rocketman (http://www.the-rocketman.com/recovery.html). They publish a performance table that gives descent rates at four different weights, so we just take the two closest data points and plug that into a linear interpolation calculator with our actual weight, and find the expected landing velocity for our payload.

On our last mission, using this same chute, I suspected that we landed much faster than the predictions from the chute performance table, but I did not have detailed log data to calculate final velocity. On this mission, I have great log data and am quite certain that landing was indeed about 18 mph. But why did my calculated number tell me that it would be about 14 mph? Well, I made a critical omission to the parachute load: I did not include the weight of the balloon remnants. It would not likely be a complete balloon, but I just included 100% of the balloon weight and then my estimate changed to 17 mph. I like it when things make sense. Rocketman chutes are nice: they are light, strong, and deploy without needing a spreader ring. They even have an adjustment gizmo you slide up to shorten the cords and increase descent rate, handy if you have a much lighter payload and don’t want it to drift too far (there are no performance numbers published for the throttle, so you need to make an intelligent guess).

The Geiger-Counter experiment was very interesting. On the ground, we had a background radiation level of about 30 CPM (counts-per-minute), which would be from surrounding rocks, cosmic rays that penetrate the atmosphere, and whatever else contributes to background radiation. Most cosmic rays hit air molecules and dissipate as they break them apart. We expected increased radiation at altitude during ascent, and we indeed saw that. What was interesting is that there was a peak to the readings of about 680 CPM at 62,000 feet, and then it decreased above that. I suspect that the readings should have continued to climb with altitude. Perhaps the cold temperatures affect the avalanche process in the Geiger-Muller tube.

During descent, we saw the same peak to the data of about 670 CPM at around 66,000 feet. I am actually surprised that our 1950s-vintage Soviet Geiger-Muller tube survived without blowing a seal. This was a pretty cool little experiment.

The particulate sensor we used detects two ranges of particles: between about 1 and 2.5 micron, which is approximately what is categorized in industry and government charts as PM2.5 (typically combustion products), and sizes over about 2.5 micron which is roughly what would be called PM10 (typically dust). During ascent, we saw PM10 particulates increase over about 40,000 feet. It also looked like PM2.5 peaked a bit around 60,000 feet, but not markedly. I have no idea whether this makes sense or not, as we had little time to research this before the mission. It is possible that dust got in the chamber at launch, and just swirled around contributing to PM10 readings, though that would not explain a slight PM2.5 peak. Also note that when the balloon is drifting in a stable wind, there will not really be air movement through the test chamber, however there should be some air replacement as the direction and magnitude of the wind changes.

During descent, PM10 particulates show a strong peak down to about 15,000 feet — is that real or did the 138 mph tumble after burst just dislodge crap from the walls of the styrofoam chamber? Hard to say. PM2.5 seems to vary with no explainable pattern.

One experiment that gave us no real results was the ultraviolet sensor. We expected to see peaks and valleys in the data due to the balloon and chute shading it at here and there, but we expected an upward trend in the peak readings, and did not see that. One problem is that the UV photodiode is quite directional, and if it is not directly facing the sun, the sensitivity drops considerably. We need to re-visit this sensor to see if we can add some sort of diffusing/focusing lens to it. Next time.

Notes from Earl, N7EP:

The video is awesome. Watching the ascent through the clouds is like a beautiful lullaby, very relaxing and refreshing, It should be on YouTube or even better DogTV. I hope you know what that is?

I watched the launch using APRS.fi from several hours before launch to after retrieval. I was amazed at how well I could see what was going on watching my computer in Seattle. I didn’t know the reason for the launch delay, but kept seeing activity so knew it would probably happen. The hotspot feed to APRS.fi by N6BG made watching this possible. I even watched N6BG drive the road north of the landing site before going south to get it. And then I saw the balloon being walked to the vehicle until it was turned off.

I also updated the balloon track prediction based on the actual launch site and slightly delayed time. The actual landing site was ¼ mile east of the prediction. Very impressive.

I also verified your burst height by plotting the ascent rate and descent rate at the two highest elevations below the highest elevation on the APRS-11 data. This is an interesting algebra exercise to find the intersection of two lines for the AZ High Altitude Looners. The descending line is almost perpendicular to the ascending line and the lines are not actually straight, so the calculation is only approximate. I came up with the highest altitude of 93,240 feet, only 8 feet less than your data. I would have thought I would have been higher, but the -11 data has fewer data points to work with.

The 400 mW AF7EZ-11 APRS transmitter resulted in 514 packets on APRS.FI and the 70 mW AF7EZ-12 with 266 packets. The -12 had a gap in packets between 46000 and 36000 feet on descent. There were an insignificant number of repeats on the -12 from other APRS station. I’m not that familiar with APRS, but if we only had non N6BG packets to rely on, finding the landing site could be very difficult. The N6BG mobile packet node with the hot spot updates worked very well

My graphical analysis of the APRS ground tracks:
Launch to landing: 14.1 miles at 120 degrees.
Launch to burst: 10.4 miles at 117 degrees.
Burst to Landing: 3.7 miles at 130 degrees.
Maximum altitude: 17.66 miles

Looking over the flight data raised several questions and comments which I have listed below. Maybe they will give those very smart “Arizona High Altitude Looners”, AZHAL, something to do.

1. Most of the plots the baseline (horizontal) altitude scale makes the data look straight line or linear. The best example is the descending rate, with a compressed altitude scale until the parachute opens, and then less compressed afterward. It would be interesting to see this plot using a linear baseline, like a linear altitude scale.

2. Does the Styrofoam give off a gas or dust as the atmospheric pressure drops that would effect the particle measurement? Also, the balloons seem to have a coating of something like talcum power to keep them from sticking together. Is there any way to determine what the measured particles are?

3. The glitches in the plot are interesting. At first I thought it was probably a static spark from the rubber balloon or the Styrofoam box rising through the atmosphere, but I notice that all the glitches look like a loss of data and occur at regular intervals. So my guess is that it’s probably a software glitch
but the payload should be made as static proof as possible.

4. To prevent static sparks, the Styrofoam box could be covered in aluminum foil and all metal part connected with a common ground that doesn’t carry any signal or power current. Also, antennas should have all elements grounded by the receiver or transmitter or by the antenna design. Perhaps resolving why the crossband repeater didn’t function may resolve the static spark possibility. Most aircraft have a static discharge fixture?

5. I noticed on the Balloon Challenge web site that the FAA requires a Radar reflector?

6. A pre-launch check list might be in order.

All you folks at AZHAL should be proud. The launch was awesome. Gil, you are a hero. By AZHAL standards I am ancient at 79, but I still learned a lot. Thanks for a great Balloon Challenge,

Earl Palmer, EE, PE retired, GP, GGP, CC, N7EP, etc.

And a reply from Gil, AF7EZ:

Hi Earl:

Always good to hear from you; let’s go fly a balloon when you get back here next fall. You made some good points — let me address them:

1 – Yes, we need to improve our graphing capability. We just used the basic graphing tools in Excel, which are simplistic and designed for non-scientific analysis (Excel calls graphing/plotting “charting” — to me charting implies tables, but whatever). I have since found other graphing programs I want to try next time.
The non-constant-increment horizontal altitude scale is an artifact of our (GPS) data sampling, and the result of the minimal control we had over the Excel graphs, (er, charts). We will try to display the data better next time, but we did find the resultant graphs enlightening — it is difficult to see any sort of trend by staring at the raw data, so we are still happy that we got interesting and useful graphs from Excel.

2 – Yes, the styrofoam payload box could have affected our particulate measurements. We started with a reasonably-clean BRR-compartment interior, blown out with compressed air. Prior to launch, we closed up our payload and then proceeded to inadvertently kick up dust for three hours as we tried to fill our balloon, had to go find more helium, and then eventually got our balloon off the ground. So, there was indeed a lengthy time window for dust to be kicked up by our feet, combustion products to be ingested from the cigarette-smoking visitors, and dander from that giant pony-sized-wolf-dog that wandered by. If some turdmuck got into the BRR chamber before launch, it could have swirled around during ascent and contributed to higher particulate readings. The biggest change was after burst, when we saw a large increase in PM10 particulates, which could also be explained by dust that got in pre-launch, settled to the bottom, and was violently swirled into the chamber during the tumble (which reached 138 mph). Also, you are correct to point out the talcum powder from inside the balloon, which would be released at burst to create a small cloud — however, the payload would drop very quickly out of this talcum cloud, so I am unsure how much this would have affected the test chamber. Perhaps some up/down directional airflow ports into the test chamber, promoting more-current ascent and descent air samples to the sensor, would help with better numbers.

3 – The plot glitches on the analog temperature sensor are indeed interesting. Not only are they somewhat regular in time (indicating a software-loop timing issue), but they seem to drop a similar average amount, and only when the sensor gets quite cold, which is intriguing. The glitches on the humidity sensor are different, as they represent us logging an “invalid” data point, which just means the sensor was not ready, we got a checksum error, or whatever — we should have filtered these out in the payload.

4 – Your comments on static discharge are very interesting, and something that we did not consider. We need to look more closely at aircraft and radiosonde designs to make some sense of all this, and see how the payload design could be improved.
There is always something that we did not anticipate, and this indeed could be one of them. If some additional shielding is needed, we could easily add that to appropriate compartments with copper or aluminum foil tape (and though many will argue otherwise, aluminum can indeed be soldered with the right tricks).

5 – FAA radar reflector requirements are for larger payloads: this should not be required until the payload exceeds 12 pounds. There are various rules in CFR 101 with which we have complied to keep the FAA happy.  I will summarize our analysis of that elsewhere.  Thanks.