Space Dorothy appears on Weather Radar

On August 6th, 2015, PiBalloonIII was launched from the Trinity Valley Community College in Terrell, TX. Launch took place at approximately 11:15AM. The balloon drifted south, towards Athens, and then cut west for a burst near Ennis. Burst happened at ~2:33PM, and the payloads were on the ground shortly thereafter.

Space Dorothy was two draw-string bags filled with ~150 ping pong balls. A 5″ foil tail was attached to each ping pong ball to help with reflectivity. The bags were mounted above the parachute, so they would be turned up-side-down when the balloon burst.

This map shows the launch from Terrell, the burst point, landing site (final K5UTD-11 position), and the debris field based on local area reports. Several residents called after seeing my phone number written on the side of ping pong balls.


This album shows the differential reflectivity between horizontal and vertical polarization on weather radar. At the 1.5° tilt, the altitude was approximately 8kft. At the 2.5°, 3.6° and 4.5° tilts, the approximate altitudes of the beam were 12kft, 17kft, and 21kft respectively.

As you can see, there is a cluster of debris that intersects the expected flight path of the ping pong balls shortly after burst. Because the ping pong balls have little mass and a foil tail, they took much longer to descend than the primary payloads.

Despite original looks at the radar being inconclusive, a further analysis of the Level 2 data proved to be quite useful. The filtering on the WSR-88D most likely filtered out most of the ping pong balls on the Base Reflectivity and Base Velocity products, but the Differential Reflectivity appears to have far less filtering, allowing these reflections to be seen. Apparently 152 ping pong balls can actually appear on weather radar.

These images were rendered with GR2Analyst. The data was pulled from KFWS on 8/6/2015 between 1900 and 2030 UTC.

PiBalloonIII Flies For a Third Time!

On Thursday, August 6, we will be launching a student payload, PiBalloonIII, and Space Dorothy. This launch is part of a STEM outreach camp.

Space Dorothy

space dorothy

We plan on dumping 152 ping-pong balls from the edge of space. Each ball will be labeled with “REWARD!” and my phone number. In addition, the ping-pong balls will have a small hole, and a foil tail. There’s a decent chance that the ping-pong balls will reflect weather radar. Space Dorothy is being assembled by the students.

Radio Payloads

There will be two radio payloads on this launch, PiBalloonIII and the student box.

  • Primary Tracking/Telemetry (Student Box): K5UTD-11, 144.34MHz, Arduino-powered telemetry
  • Backup Tracking: KE5GDB-11, 144.39MHz
  • SSTV: 144.5MHz, Martin 2
  • Crossband Repeater: 147.5MHz downlink, 446.050MHz pl110.9 uplink

Launch Details

We will try and launch from the Trinity Valley Community College in Terrell at about 10:15AM. Wide area communications will be on the Flamethrower (146.7- pl110.9/441.925+ pl110.9). The simplex chase frequency is 446.1.

PiBalloon III/PHAB-11 – Another Success!

PiBalloon III (on the PHAB-11 string) had a successful flight on Saturday, July 11. Launch was at 9:30AM from Bonham High School, and landing was at 12:23 in Sherman. The balloon narrowly missed a populated area, and some high-tension power lines. The average descent rate was 3500ft/min. Conversely, the ascent rate was 675ft/min.

The Launch

The balloon launching went off without a problem. We laid the balloon out, and connected it to the hydrogen tank, but waited for PiBalloonIII to be fully operational before filling began. Once the crossband repeater, SSTV, and APRS were all verified, we inflated the balloon. When the balloon was filled, we rigged the payloads, and walked it over to the field. The PARK Balloon group uses a method called a tethered launch, where a rope is fed through the ring on the balloon. This allows a final check on all of the payloads to be run before the balloon is let go. When we’re ready for launch, one end of the rope is let go, and it slowly feeds through the ring allowing a jolt-free release.

Payload Performance

All systems functioned as intended, with the exception of one experimental tracker (W5ADC-7). Based on the data received over the APRS network, the GPS was not in “high altitude mode,” and capped out around 40,000ft. The other two trackers (KE5GDB-11 and W5ADC-11) functioned exactly as intended.

The crossband repeater sustained a lot of traffic! There were about a dozen check-ins, and a constant chatter about the balloon.

The slow-scan TV package sent amazing photos from the edge of space.

Pi Camera Photos


Watching the Balloon Come Down

One of the coolest parts about this flight was that we nearly intercepted it on the descent. Landon (N5AET) and I were able to see the balloon come down. I was able to take the video recorded from the balloon and locate my vehicle (or maybe the one just in front of us).

(BEWARE: Clenching may occur as power lines become visible!)

Flight path in final few minutes:


A still from the video above:








How it looked from the chase vehicle (taken about 10 seconds later):


Final Thoughts

This was a fantastic launch with great results. The pictures were amazing; both the real-time SSTV and the ones pulled from the SD card later on. We had a little fun with the SSTV when the balloon was in “descent mode,” and will probably continue the tradition. It was a pleasure to launch with the PARK Balloon group, and I’m very thankful for the opportunity.

PiBalloonIII – Another Flight!

On July 11th, PiBalloonIII will be flying with the PARKBalloon group. This is the second of four possible flights for this hardware configuration.

This payload features SSTV, a crossband repeater, and an APRS tracker.

  • APRS: KE5GDB-11 on 144.39MHz (change to .34 is possible)
  • Slow Scan TV: 144.5MHz – Martin 2
  • Crossband Repeater: 446.050MHz Uplink (110.9PL); 147.5MHz Downlink

Launch is at 9:00AM out of Bonham. I’ll post an update when the details are finalized.

More details on the payload can be found here.

PiBalloonIII – A Success!

Well, mostly.

The launch took place earlier than scheduled; at 0932L the balloon was released in some moderate winds from Forney High School. Everything ran ahead of schedule, we arrived at the high school early, the students from DeSoto and Lancaster arrived early, and subsequently the balloon was launched early.

All pre-flight checks went OK. Everything was beaconing properly, APRS data looked good, and the crossband repeater was repeating. There were five payloads that seemed to be functional: Primary Tracking, Telemetry, Secondary Tracking, Slow-Scan Television (SSTV), and the Crossband Repeater.

Once the rigging was complete, the students huddled in a corner and began inflating the balloon. It took nearly all 21 students with their hands in the air to prevent the balloon from making contact with the building when gusts of wind would take control of the balloon. Upon inflation, we zip-tied the payload string to the balloon, and walked it out to the practice football field. After a quick run-down of launch procedure (essentially “release slowly!”) we let the balloon up by feeding the payload string hand-over-hand. At times, the wind was so strong, the string was barely 30° above the ground.

It’s in the air!

Shortly after launch, we realized that the Pi-based tracker was not updating its position. It was sending the same packet over and over. Although not good, it does indicate that the problem was upstream of the TNC, most likely a communication issue with the GPS. Unfortunately, my code is not self-recovering from a GPS connect/disconnect issue. It can easily handle a position unlock, but if the gpsd daemon stalls, it will not recover. I imagine that there was a loose connection that caused this particular problem. Fortunately, the primary tracker functioned exactly as intended.

The telemetry looked good. At the launch site, the balloon measured a pressure of 981mb, an external temperature of just over 30°C and a relative humidity of 47.6%. Tony (W5ADC) was able to calculate the ascent rate – just over 1200ft/min, or 6m/s. With the balloon in the air, the chase began.

Tony (W5ADC), John (KC0L), and myself took off just after the balloon launched. The students loaded up, and went to a local park to play around while the flight took place. Tony, John and I stopped in Seagoville to run flight predictions, talk on the crossband repeater, and plan out our chase. After about 45 minutes of waiting, we determined it would be wise to head towards Ferris.

I made numerous contacts through the crossband repeater. In this mode, it will repeat things heard on 446.050MHz out on 147.5MHz. I talked to AF5MI in Carrolton, K5LUO near OKC, W5TXG near Palestine, and KD5OUG in Richardson. Next time I’d like to work “Balloon DX” through the repeater.

Bursting Point

We made it to Ferris rather quickly, and kept heading south on 45. Believe it or not, bladder instinct led us to our next waiting point, a Shell/Sonic combo just outside the city of Palmer. John, Tony and I spent about twenty minutes at this location while the students were rounded up and caught up with us. The balloon peaked at 85,000 feet, and made a quick descent following the same winds that took it up.

Space Launch 1 Flight Path

The bus driver was kind enough to follow the chase vehicles as we weaved our way through Palmer out to some country roads. John had a slight lead, and informed us that the balloon would be very easy to access, and was nicely strewn out in a field. His assessment was correct; the balloon was 30 yards from CR813 and was waiting for us in a slightly muddy field.

The students hopped off the bus, and helped gather up the payload bits. The landing, although mostly soft, was enough to knock some batteries out of their holder on the primary tracker. The chase was completed after a trip to CiCi’s in Lancaster.

Data Analysis

My favorite part of the launches is the data. I love seeing where the balloon can be heard, and watching the telemetry stream in through the flight. This flight had the telemetry basics covered, but not overdone: internal temperature, external temperature, pressure, and humidity. Altitude was handled by the GPS.

The basics:

  • Launch: 9:32AM
  • Burst: 10:54AM
  • Landing: 11:20AM
  • Flight Time: 1:48
  • Max Altitude: 84,486ft
  • Lowest Temperature: -47.9°C
  • Lowest Pressure: 25mb

Even though my primary tracker had failed to accomplish its primary function, it was still useful for ranging the balloon. A handful of IGates were able to directly receive packets from the balloon: N5DTX-5, K5UTD, KB5ASY-4, AF5I-1, WD5DDH-1, WB5QLD, N5HYH-5, AE5PL-10, KE5UUO, W5LHG, N8QVR-10, KC5AFM-1, W5AMZ-1, KD5UMO-1, N5YSQ, KA5WMY-10, W5NGU-4, W5ROX, KA5WMY-5. Remember, to IGate a packet, you must have a good signal from the balloon. This means >-110dBm (or so). The image below represents the areas in which the balloon was definitely heard via RF, and you probably could have talked through the crossband repeater or received SSTV images.

The temperature data is ever so slightly skewed by the color of the temperature sensor: black. As seen in the chart below, the temperature rapidly dropped on the descent and ultimately reached a minimum value of nearly 20°C less on the descent than it did on the ascent. I believe this is caused by the air rapidly moving over the sensor, giving the sun and the internal electronics less of a chance to skew the data.



Another aspect of the data to analyze is the pressure/altitude correlation. The GPS read a max altitude of 85,000 feet, and the lowest measured pressure was 25mb. Using formulas provided by NOAA, I plugged in our meager 25mb to produce a theoretical maximum altitude of 73,499 feet. It’s a good thing our altitude data came from a GPS, as the NOAA formula and our sensor produced over a 15% error between the two numbers.

The humidity data was rather boring, other than inconsistent amounts of moisture at various altitudes. I’m sure the people that paid close attention in Skywarn school would like me to make a Skew-T chart out of this data, but you’ll have to do it yourself.

The data can be downloaded here.

A Successful Launch

All things considered, this launch was very successful. First and foremost, the students enjoyed themselves and learned a lot in the process. On the balloon, there were no catastrophic failures, as the only issue was a GPS failure on the secondary tracker. The Byonics TinyTrak4 once again proved that it is a solid piece of equipment, and that I’m not yet qualified to make flight-ready trackers myself. The GoPros did a great job, and took plenty of photos of the areas surrounding the metroplex. We couldn’t have asked for a better recovery location, and a better chase team to help find it.

Thanks to everybody that made this launch and recovery possible! It was a very enjoyable experience, and I look forward to the next one.

PiBalloon III – Launch on July 1st


Launch on Wednesday, July 1st, before noon. Location TBD. Chasing encouraged.

  • APRS Primary: K5UTD-11 on 144.34MHz
  • APRS Backup: KE5GDB-11 on 144.39MHz
  • Slow Scan TV: 144.5MHz – Robot 36
  • Crossband Repeater: 446.050MHz Uplink (110.9PL); 147.5MHz Downlink

Launch Details:

This launch is part of an Intro to Space camp being hosted at UT Dallas. High school students interested in STEM will be coordinating launch aspects, and assembling the primary payload. We will be launching on Wednesday, July 1st, some time before noon. The students will chose the launch site a day or two before the launch. Upper level atmospheric conditions will dictate the launch site.

Payload Details:

The primary tracking payload will be built by the students. It will consist of a TinyTrak4, GPS, Arduino, and a handful of weather sensors. It will operate under the K5UTD-11 SSID, and beacon a position once every 15 seconds, and a telemetry packet once every 15 seconds.

The secondary tracking will be handled by a RaspberryPi and a TNC-Pi. The “signal” chain will be a USB GPS to gpsd, which is then read by a python script, and sent to the aprx daemon. The aprx daemon transmits a position every 10 seconds.

The SSTV transmitter will be driven by the RaspberryPi running the secondary tracking. The Pi will take a picture with a Pi Camera, process the .png into a .wav file, and play the audio to a radio via the soundcard. This can be run simultaneously with the APRS, as the APRS radio is controlled by the TNC-Pi, not the soundcard on the Pi.

The crossband repeater will be a Yaesu FT-530.

Power Management:

The payloads will be divided into three separate power groups: primary tracking, secondary tracking, and non-essentials. Primary tracking will consist of the TinyTrak4, GPS, Arduino, sensors, and a Baofeng UV-5R. Secondary tracking will be the RaspberryPi and another Baofeng UV-5R. The non-essentials will include the crossband repeater and the SSTV transmitter (you guessed it; another UV-5R!).

Each group will be powered by three or four Li-SO2 D cells. This will give us 10.8v or 14.4v to play with, at 9.2Ah.

Communications Plan

We will use the following frequencies depending on balloon location.

County Repeater Frequency
Collin/Rockwall UT Dallas 145.43- pl110.9
Dallas/Ellis/Kaufman Flamethrower 146.7- pl110.9
Denton/Wise Rosston 145.49- pl85.4
Tarrant K5FTW 146.94- pl110.9
Elsewhere Simplex 146.54

Using APRS to Determine Repeater Coverage

Here at the University of Texas at Dallas, we operate a repeater on 145.430MHz (K5UTD-R). For 5 years, it sat on the top of a 50′ tower, on a 50′ roof, giving us about 100′ feet above ground level. The end goal is to relocate this repeater to a higher tower on campus. This would make use of an antenna that is ~250′ AGL (if not a little more), as opposed to 100′ AGL. Moving this repeater took a lot of time and coordination, so in the mean time, I determined I would experiment with the APRS network to get a general idea of how coverage will change.

Is this an exact science? Not at all. The predicted coverage relies on many different variables; some are in my control, but most are not. The general principle is that you can make use of stations beaconing their positions, and compare the position packets you hear on one antenna with packets heard on the other. This will loosely correlate with the changes in repeater coverage when the transition is complete. This takes advantage of the APRS network, and the fact that many radio operators run GPS-based tracking systems in their cars. Data from these systems can be received on 144.39MHz.

The basic premise of this experiment is not to see where the repeater can be heard, but rather what the repeater can hear. As mentioned above, this experiment takes advantage of radio operators persistently beaconing their position using systems similar to what they will use for voice communications.

To get an estimate of what the repeater can hear in the “pre-move” and “post-move” configurations, I collected two datasets at two separate times. The first dataset was using an antenna on the roof of the Engineering and Computer Science building. The antenna had similar height and gain to the old repeater antenna. Due to hardware constraints, I could not simultaneously run two IGates to collect data on both antennas. This is one source of error.

The IGate operated on the rooftop tower from Jan 26 to Feb 18. This gave me about 3 weeks worth of data to work with. The IGate operated with the larger tower from Feb 26 to March 8. This was only about a week and a half worth of data.

In this particular setup, the IGate consisted of a Raspberry Pi with the TNC Pi addon board. The radio was an Icom IC-229H, and would beacon two packets every 10 minutes (status/position). The APRX daemon was used to internally log and gate the packets to the internet. The log files are what I used to produce the map seen below.

Parsing the log file is no easy task. As you would have expected, there is a library written in Perl to parse APRS packets, so I wrote the script in Perl. I wrote several filters to only give me packets that I locally received. The filters discarded packets that have been digipeated, came in over the APRSIS servers, were not position packets at all, or had a distance greater than 150 miles. I also wrote in a filter that discarded packets with a speed greater than 100mph, as planes will skew the data.

The Perl script was written to spit out a KML file. It would take several minutes to run, as the log file is >113MB, but would result in a 6MB KML file ready for Google Earth.


The image above is what the script produced. These are the packets that were heard directly from the transmitting station. The blue dots represent the packets heard on the new, higher antenna, while the red dots represent the packets heard on the older, lower antenna.

Obviously the higher antenna heard packets much further out than the lower antenna, with one exception. There is a 60° slice of the old coverage area to the south that is not covered by the higher antenna. This is because the antenna is side-mounted on the north side of the new tower. Aside from that, the higher antenna appears to cover much more of the metroplex than the lower antenna.

Anyway, it was a major project to move the repeater, and a lot of fun to write the script and produce the map while we had downtime. This type of map is easy to produce, and can be done by modifying my script to suit your needs.

PiBalloonII is finished!

After a few months of gathering pieces, writing code, and actually building the payload, PiBalloonII is ready.

The subsystems of PiBalloonII consist of:

  • Raspberry Pi B+
  • uBlox NEO-6M GPS (UART/TTL level)
  • TI TMP513 Power Monitoring System (I2C)
  • DS18B20 Temp Sensor (1-Wire)
  • DHT11 Humidity Sensor (Proprietary)
  • BMP180 Pressure Sensor (I2C)
  • Dorji DRA818V 2M Transceiver (UART/TTL level)
  • 8xAA Ultimate Lithium batteries (in two 4xAA configuration)

Each of the sensors listed above is interfaced to the Pi with their respective protocol. Due to the nature of the sensors, some can update very quickly, while others can take up to two seconds. The barometer can update at 53Hz, while the humidity sensor can update once every two seconds. Because of this, it’s easiest for each sensor to maintain its own log file.

The GPS feeds a program called GPSD. This program makes it very easy to cross-interface multiple types GPS units, while also providing libraries to Python. As learned on the first PiBalloon, it’s best to set the GPS in high-altitude mode. I didn’t know such a mode was needed, and at 12,000 meters, the GPS started sending garbled data. The GPS purchased has a battery, so it’s easy enough to set the configuration on the computer and it will maintain the settings.

The TI TMP513 is the coolest sensor on the payload. It will measure voltage and current, while also providing up to three external temperature sensors. Here is a snippet of the TMP513 log file:

1417641807.10, 12.368, 318, 30.44, 27.00, 20.44, 318, 676
1417641808.31, 12.172, 680, 30.44, 27.38, 178.25, 318, 680
1417641809.27, 11.972, 683, 30.50, 28.19, 255.94, 318, 683
1417641809.93, 11.984, 689, 30.50, 28.25, 255.94, 318, 689
1417641810.58, 11.964, 606, 30.50, 27.62, 248.38, 318, 606
1417641811.68, 12.180, 304, 30.50, 29.25, 255.94, 304, 606
1417641812.74, 12.352, 311, 30.44, 27.00, 18.94, 311, 606
1417641813.42, 12.352, 323, 30.44, 27.00, 19.31, 323, 606
1417641814.08, 12.352, 312, 30.44, 26.94, 19.31, 312, 606
1417641814.76, 12.356, 312, 30.44, 26.94, 19.19, 312, 606

The first column is UNIX epoch time. All log files will share this property. The second column battery voltage, followed by current (in mA). The fourth column is the onboard temperature sensor on the TMP513, then a remote internal temperature sensor and a remote external temperature sensor. The last two columns are idle current and transmit current.

As you can see, a temperature of 255.94C is very unlikely, so I’m going to write it off as RFI problems on the remote sensor. Fortunately, we have a digital sensor for the external temperature readings, with almost no chance of RFI.

The DS18B20, DHT11, and BMP180 measure temperature, humidity, and pressure respectively. I much prefer the DS18B20 to the TMP513 for temperature readings at the moment, as I don’t yet fully understand how to calibrate the 513 and minimize RF interference.

The final item on the payload list is the Dorji DRA818V. This is our 2 meter transceiver. Originally I planned to fly two of these, but after much thought and some technical difficulties, I determined that we could move a similar amount of data, with little compromise, using only one radio. The compromise made pertains to the quality of the SSTV images. Because SSTV can’t use the transmitter continuously, I opted for a 36 second Robot 36 image instead of a 5 minute Scottie DX image. The visual difference is definitely noticeable, but it’s not worth the trouble of maintaining a second transmitter.

To save time, the scripts will compile APRS packets while the SSTV image is transmitting. Theoretically, I could reduce the cycle down to about 45 seconds, but I’m going to opt to keep it at 60 seconds to give the transmitter some time to unkey and cool (ever so slightly).

Using the Energizer Ultimate Lithium Batteries, I’m able to get a predicted 4 hours of use from 8 batteries. The Pi uses about 300mA, transmitter 750mA and we lose 100mA in the voltage regulators, so we can assume 1.25A of draw at any given time. After cross referencing the datasheets, I can predict we will see at least 4 hours, if not more from a given set of batteries.

All of the code can be found on GitHub.


DORJI Modules – Radio on a Chip

The DORJI modules (DRA818V and DRA818U units) came in yesterday. These modules are full transceivers. They are programmed via UART, don’t require a power cycle between frequencies, have a sleep mode, and can provide 500mW or 1W.

Programming these units is not exactly easy. They use 3.3v TTL levels, so your typical USB to Serial adapter won’t work, as those use RS232 levels (-12v & +12v). TTL levels are typically 0v to 5v, or 0v to 3.3v. Fortunately I intend on using these with a Raspberry Pi, so I will already have a UART (serial interface) that provides 0 and 3.3v levels.

Minicom, screen, PuTTY, and various other terminal clients were giving me a very rough time with these units. The initial handshake command is “AT+DMOCONNECT” with the carriage return and line feed characters. With the terminal programs I listed above, each character was individually sent, and I was commonly seeing “+DMOERROR” as I was trying to type out AT+DMOCONNECT. Python was the tool that finally worked.

import serial
ser = serial.Serial(‘/dev/ttyAMA0’, 9600, timeout=2)

Assuming this all ran correctly, you should see an acknowledgement from the module.

Ultimately this is very exciting, as it’s giving me a full transmitter and receiver on a platform that can be dynamically programmed from a Raspberry Pi. The dynamic frequency changing will allow me to send Slow Scan TV, then send APRS packets, kerchunk repeaters, and then do the whole process again.

PiBalloon II – Design Ideas

In August, I built and flew a Raspberry Pi powered high altitude weather balloon. The Pi was ideal, as it provided a low power Linux platform in a credit-card sized package. Using Python, BASH, and caffeine, I was able to produce 1200 baud APRS packets to be sent through the audio jack to a Baofeng UV-3R. The Pi also took pictures using a webcam, and sent them out using Slow Scan Television (SSTV). This was sent through a Wouxun KG-UVD1 using VOX. This system worked very well, but there are plenty of design improvements to be made, so I need to start from scratch.

PiBalloon II it shall be called.

I came across a new balloon box as I was walking through a biology centric building on the UTD campus. 2014-09-24[1]I didn’t have a banana for reference, but I did have a Pi B+. The box (externally) is 7x7x5.5 inches, giving me the perfect amount of room for a GPS module, Raspberry Pi, 2 D cell lithium batteries, a webcam, and these Baofeng-on-a-chip modules [DRA818V is the search term, if the link dies].

The Baofeng-on-a-chip modules are programmable via UART and can transmit at 27 or 30dBm (500mW/1W). I haven’t received mine yet, but I expect China Air Mail to provide in a week or two. Because they’re programmable via UART, it is theoretically possible to send SSTV on 144.5 and APRS packets on 144.39 using the same module. Admittedly, you can’t get APRS while SSTV is running, but it still has a lot of potential. My favorite idea is to program in the top 15 repeater pairs and the top 5 PL tones, and go down the list kerchunking repeaters from the edge of space. One could also program the Pi to announce its status on their favorite repeater using a speech synthesizer. “This is your Pi speaking. Our current altitude is 82,348 feet, and ascending. It’s a little chilly outside at -37 degrees celcius. Batteries are looking good. Go ahead and put your seatbacks and tray tables in the upright and locked positions, as we expect burst at any minute now.” The possibilities are endless with a radio that can be programmed in real time by a Raspberry Pi.

Similar to the last launch, I’d like to monitor several different parameters and send them out using APRS. I plan on building another 1-wire thermal sensor network using the Maxim DS18B20’s or similar. This time I’ll be using the real sensors, not the unreliable parasitic power units. The TI ADC didn’t perform well either on the previous launch, so I’ll most likely load up an ATmega chip to handle battery voltage monitoring. Ideally I can just feed data back to the Pi using a UART or other GPIO interface.

TI offers this chip called the TMP513. Check it out. It interfaces using I2C, and can measure battery voltage, three temperature sensors (and a fourth internal sensor), and even has a GPIO pin. Mouser has them in stock for <$5. If I can figure out how to use this chip, I’ll swap out the 1-wire network and the ATmega in favor of this. It has potential.

There is a possibility of a December launch. This group requests that the payloads be <2lbs and <12″ on any face. Size isn’t a problem, but weight might be. Hopefully the PiBalloon II will come out under that constraint.

Stay tuned for more updates on this project.