For all the lip service the world’s governments pay to “space belonging to the people”, they did a pretty good job keeping access to it to themselves for the first 50 years of the Space Age. Oh sure, private-sector corporations could spend their investors’ money on lengthy approval processes and pay for a ride into space, but with a few exceptions, if you wanted your own satellite, you needed to have the resources of a nation-state.
All that began to change about 20 years ago when the CubeSat concept was born. Conceived as a way to get engineering students involved in the satellite industry, the 10 cm cube form factor that evolved has become the standard around which students, amateur radio operators, non-governmental organizations, and even private citizens have designed and flown satellites to do everything from relaying ham radio messages to monitoring the status of the environment.
But before any of that can happen, CubeSat builders need to know that their little chunk of hardware is going to do its job. That’s where Alan Johnston, a teaching professor in electrical and computer engineering at Villanova University, comes in. As a member of AMSAT, the Radio Amateur Satellite Corporation, he has built a CubeSat simulator. Built for about $300 using mostly off-the-shelf and 3D-printed parts, the simulator lets satellite builders work the bugs out of their designs before committing them to the Final Frontier.
Dr. Johnston will stop by the Hack Chat to discuss his CubeSat simulator and all things nanosatellite. Come along to learn what it takes to make sure a satellite is up to snuff, find out his motivations for getting involved in AMSAT and CubeSat testing, and what alternative uses people are finding the platform. Hint: think high-altitude ballooning.
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
India’s Chandrayaan-2 mission to the Moon was, in a word, ambitious. Lifting off from the Satish Dhawan Space Centre on July 22nd, the mission hoped to simultaneously deliver an orbiter, lander, and rover to our nearest celestial neighbor. The launch and flight to the Moon went off without a hitch, and while there were certainly some tense moments, the spacecraft ultimately put itself into a stable lunar orbit and released the free-flying lander so it could set off on its independent mission.
Unfortunately, just seconds before the Vikram lander touched down, an anomaly occurred. At this point the Indian Space Research Organisation (ISRO) still doesn’t know exactly what happened, but based on the live telemetry stream from the lander, some have theorized the craft started tumbling or otherwise became unstable between three and four kilometers above the surface.
In fact, for a brief moment the telemetry display actually showed the Vikram lander completely inverted, with engines seemingly accelerating the spacecraft towards the surface of the Moon. It’s unclear whether this was an accurate depiction of the lander’s orientation in the final moments before impact or a glitch in the real-time display, but it’s certainly not what you want to see when your craft is just seconds away from touchdown.
But for Chandrayaan-2, the story doesn’t end here. The bulk of the mission’s scientific goals were always to be accomplished by the orbiter itself. There were of course a number of scientific payloads aboard the Vikram lander, and even the Pragyan rover that it was carrying down to the surface, but they were always secondary objectives at best. The ISRO was well aware of the difficulties involved in making a soft landing on the Moon, and planned their mission objectives accordingly.
Rather than feel sorrow over the presumed destruction of Vikram and Pragyan, let’s take a look at the scientific hardware aboard the Chandrayaan-2 orbiter, and the long mission that still lies ahead of it.
Model rockets are a heck of a lot of fun, and not a few careers in science and engineering were jump-started by the thrilling woosh and rotten-egg stench of an Estes rocket launch. Adding simple instrumentation to the rocket doubles the fun by allowing telemetry to be sent back, or perhaps aiding in recovery of a lost rocket. Sending an instrument-laden rocket into a tornado is quite a few notches past either of those scenarios, and makes them look downright boring by comparison.
A first and hopefully obvious point: just don’t do this. [ChasinSpin] and [ReedTimmer] are experienced storm chasers, and have a small fleet of purpose-built armored vehicles at their disposal. One such vehicle, the Dominator, served as a mobile launch pad for their rocket as they along with [Sean Schofer] and [Aaron Jayjack] chased what developed into an EF4 monster tornado near Lawrence, Kansas on May 28. They managed to score a direct hit on the developing tornado, only 100 feet (30 meters) away at the time, and which took the rocket to 35,000 ft (10.6 km) and dragged it almost 30 miles (42 km) downrange. They lost touch with it but miraculously recovered it from a church parking lot.
They don’t offer a lot of detail on the rocket itself, but honestly it looks pretty much off-the-shelf, albeit launched from an aimable launchpad. [ChasinSpin] does offer a few details on the instrument package, though – a custom PCB with GPS, IMU, a temperature/humidity/barometric pressure sensor, and a LoRa link to send a data packet back every second. The card also supported an SD card for high-resolution measurements at 10 times per second. Check out the launch in the video below, and be sure to mouse around to get a look at the chaotic environment they were working in.
Even if this isn’t as cool as sending a sounding rocket into an aurora, it’s still really cool. We’re looking forward to seeing what kind of data this experiment collected, and what it reveals about the inner workings of these powerful storms.
While we’ve come a long way in terms of opening up the world of radio control to open source software, a good deal of the hardware itself is still closed up. You can flash a cheap RC transmitter with a community developed firmware, in fact there’s a decent chance that’s what it ships with, but the hardware itself is still an immutable black box. That might be fine if you’re just flying an RC plane or quadcopter, but what if you’ve got something a bit more advanced in mind?
From his personal experience, [Alireza] found that traditional RC transmitters have their limits when you start using them for robotics. You’ll often want input schemes or devices which would never occur to the remote’s designers, and you’ll almost certainly want to have more channels and functions than the original hardware will allow. One of the big advantages with the Alpha V1 is that the front and back of the controller are simple acrylic panels, meaning you can easily cut openings or drill holes in them to add more hardware without having to deal with the (relatively) ergonomic shapes of a traditional transmitter.
Of course, that’s only one half of the equation. When you add new hardware, you’ll need to make the software aware of it. To that end, [Alireza] says he and his team have developed a library of adaptable firmware modules which should make it very easy to add in new components without having to get bogged down with software configuration. In fact, he says the goal is to allow the user to add new hardware to the Alpha V1 without requiring them to write a single line of code.
The link uses standard WiFi hardware in a slightly unusual way to create a digital data link that acts more like an analog system, with a preference for delivering low latency video and a graceful drop-off when signal quality gets poor. A Raspberry Pi Zero, Alfa NEH WiFi card, external antenna, battery, and a 3D printed enclosure result in a self-contained unit. Two are needed: one for each end of the link. One unit goes on the drone and interfaces to the flight controller, and the other is for the ground station.
A companion android app allows for just about any old Android phone to serve as video feed, on-screen display of telemetry data, and touchscreen interface.
The software is DroneBridge (GitHub repository) and it implements Wifibroadcast which uses WiFi radios, but without the usual WiFi functionality. A Raspberry Pi is the usual platform, but there’s also an ESP32 port. The software is capable of even more, but so far suits [GlytchTech]’s needs just fine, and he was able to refine his original Watch_Dogs-inspired hacking drone with it.
Ever since I first learned about radiosondes as a kid, I’ve been fascinated by them. To my young mind, the idea that weather bureaus around the world would routinely loft instrument-laden packages high into the atmosphere to measure temperature, pressure, and winds aloft seemed extravagant. And the idea that this telemetry package, having traveled halfway or more to space, could crash land in a field near my house so that I could recover it and take it apart, was an intoxicating thought.
I’ve spent a lot of time in the woods over the intervening years, but I’ve never seen a radiosonde in the wild. The closest I ever came was finding a balloon with a note saying it had been released by a bunch of schoolkids in Indiana. I was in Connecticut at the time, so that was pretty cool, but those shortsighted kids hadn’t put any electronics on their balloon, and they kind of left me hanging. So here’s a look at what radiosondes are, how they work, and what you can do to increase your chances of finding one.
[William Osman] set out to prove that unlike expensive commercial data logging rigs, he could get the same results for under twenty bucks. He wanted to build a wireless three-axis accelerometer for a race car project, allowing engineers to make modifications to the suspension based on the data collected.
The hardware consists of an Arduino Pro Mini connected to a three-axis accelerometer, and an nRF24L01 wireless module. Power is supplied by the race car’s 12 V, changed to 5 V by a linear regulator with the Pro Mini in turn supplying 3.3 V. The base station consists of an Arduino and another nRF24L01 module plugged into a laptop.
The telemetry system is based on COSMOS, an open-source, realtime datalogging platform put out by Bell Aerospace. COSMOS consists of fifteen separate applications depending on how you want to view and manage your telemetry. You can download [William]’s COSMOS config files and Arduino sketch on Google Docs.