An update from high school student, Nolan, about getting his STEM project into space.

In our January Issue 66, we introduced you to a young secondary school student, Nolan Sobel-Read, who needed funding to build and launch a high-altitude weather balloon and take measurements high up in the stratosphere (That’s over 30km in altitude or roughly 100,000 feet!).

Nolan outlined the goals for the project and what electronics he needed. We were only too happy to help out, and started sourcing the parts Nolan needed.

As a trade, we’ve asked Nolan to document his journey so that we can share it with our readers who may want to do something similar or be inspired by the work that he’s doing.

The following is the most recent update on Nolan’s project progress. We will publish more throughout the next few issues as Nolan’s project progresses.

Hi Everyone! I haven’t written in a while, so here is an update on my balloon project!

In my last article I wrote about how Cameron Owen (my mentor, who is Company Director at SAPHI Engineering) and I were working on the code, and how progress should speed up soon.

While we’ve made a lot of progress, we have also encountered some hurdles. The hurdles are nothing that can’t be overcome and I thought it might be interesting to describe what some of them are and how we have approached solving them.

The main thing that has been taking a lot of time is getting everything to talk to each other, as well as having Artemis Global Tracker do two things at once.

As I’ve discussed earlier, we will be saving data in two different ways. The first (and primary) way is on an onboard microSD card, saving roughly once per second. This will save data from every sensor onboard. The secondary way is via satellite link, but this will only happen once every few minutes. Originally, we had the loop designed as the diagram shown here, but we encountered some problems.

The issue was that instead of the message being sent over satellite almost instantly, it often had to wait for a better satellite connection, or preparation on the software side to send. At times, this took five minutes or more.

Because of the way the loop was set up, the data was only logged to the SD card AFTER the message had sent. This caused major gaps in data on the SD card. Often, the delay was so long that by the time it had sent the data, it was time to send it again, further delaying the rapid recording of data on the SD logger.

To solve this, we developed two loops, and both are being coded into functions for compatibility. This means that the SD logger can continue logging every second, and the satellite message can take the time it needs.

Some other things that have taken some extra time involve the fact that the Artemis cannot use Float to string function dtostrf().

In simple terms, this is to be able to convert a whole bunch of numbers to a string (list of numbers), so that we can maximise the amount of bytes used for data. We found this out only after having spent several hours trying to convert it to suit Artemis… Oh well, we’re getting there.

Also, I don’t think I’ve mentioned it yet, but we’re using a quiic connector to connect the SD logger to the Artemis, as this is very handy and compact. We were having trouble fitting everything and the breadboard was getting quite messy, so this solved that problem easily.

This is all for now. Hopefully, the code will be done soon so we can start working on the more physical side of the payload and balloon. I will provide updates in a later issue.

Thanks readers for your support, and especially to Cameron (https://saphi.engineering/) for all your help and enthusiasm!