Texting Without Cell Towers, Power Grid, or the Internet: IoT meets AX.25 Aboard an Arboreal Space Elevator

Similar projects worth following
TrillSat is an experimental, solar-powered, robotic radio relay with a 2m/AX.25 to WiFi/XMPP gateway and multi-user PBBS with in-session APRS beaconing over a single VFO. It has a weatherproof, temperature-controlled, low-cost design and uses a capstan hoist to climb a single, nylon tether to achieve high elevation for line-of-sight VHF, using the same drive motor for pendular tilt of a solar tracker. This kinematic constraint and catenary of the tether restricts the angle to an arcing, spiral axis for near dual-axis efficiency which is aligned using an accelerometer, Hall-effect, and LDR sensors. To counter the axial sway, the craft includes a passive ball damper, slow PWM startup routines, experimental sway-cancellation, gyroscopic reaction wheel and inertial stabilizer. An inductive Qi coil allows smartphone charging and a dock for a future LoRa "space pod". It includes mechanical energy re-capturing for motor assist and an experimental haptic Morse Code system.


Not everyone can afford to send spacecraft aboard rockets into space, and the space elevator is still science fiction due to materials that have yet to be invented. CubeSats are making progress, but they are tiny and still cost prohibitive for an individual.  Their small surface area limits the amount of solar energy that they can gather unless sophisticated unfolding techniques are used.

High altitude, specifically Height Above Average Terrain (HAAT), is necessary for certain line-of-sight radio transmissions, and if we can get a craft high enough, it can be both an analog of a spacecraft and a teaching tool.  Amateur radio operators know, for instance, that even a relatively small and inexpensive 5-watt, 2-meter HT (handie-talkie) can reach the International Space Station. In fact, they have such a radio onboard to communicate back down to us.  One of my favorite authors, Arthur C. Clarke, was also an oft-forgotten radio specialist/physicist and helped to invent the communication satellite and inspire the space-elevator.  He had a talent for predicting the future and wrote about interesting spaceships with onboard intelligence and docking space pods, all of which have intrigued me for years.  While high-altitude platform stations, geostationary or moored balloons are intriguing, these types of aerial objects are heavily regulated in my country, especially where I live.  Like lighthouses that warn ship captains of rocky coasts, it is understandable that our aircraft pilots need to know where aerial hazards are at all times.

I grew up and still reside near the main airport in St. Louis, the old Lambert Field where Charles Lindbergh was one stationed, and he once lived just down the street from where I am today.  My grandfather loved airplanes and frequently recounted the regret he felt when he had to burn a captured Japanese Zero in WWII, and I went to the airport with him often to watch the passenger planes land and meet my father, as he traveled a lot. While it was convenient for traveling, the thought probably never occurred to them that proximity to an airport placed severe restrictions on what we could actually fly in the air.  This was an unfortunate irony as a kid, since I loved aeronautics;  my neighborhood was of large percentage McDonnell Douglas aerospace engineers (now Boeing, near the site of where the Mercury space capsules were constructed), and one of my classmates became a NASA astronaut, and I watched in awe as he installed the Dextre robotic arm aboard the ISS.  My parents and grandparents, however, were not engineers and had little math and science background.  Three of them were elementary school teachers, masters of the English language and the arts, inspiring limitless possibilities within me if I put my mind to it.  My father was not a teacher, and English was not his strength.  But he was an explorer himself, an artist/designer at heart, and through his creations, I saw him bring to life some of those possibilities.  One day, out the blue, he built a kite out of gift-wrapping paper, a style that I had never seen before, and it flew beautifully.

But, while they couldn't help me with my algebra, they provided me with the encouragement, freedom, and tools at an early age...

Read more »


A copy of the first released tarball of the TrillSat source code, licensed under GPL 3.0, including the OpenSCAD 3D part generator, along with the C, Lua, Python, and BASH sources for the 4 interoperating CPUs and the electrical schematic.

gzip - 2.08 MB - 06/02/2018 at 03:36



Animation of TRILLSAT-1 in WebM VP9 format, showing the rocking, orbiting motion (rough estimates only, exaggerated for clarity). This file is about 88% smaller than the original animated GIF.

video/webm - 1.11 MB - 06/07/2018 at 06:12



Full electrical schematic, version 1.

Portable Network Graphics (PNG) - 2.03 MB - 04/07/2018 at 06:47



A simplified diagram of the power regulation circuit controlled by ATtiny 1634 (Huckleberry)

Portable Network Graphics (PNG) - 271.62 kB - 04/07/2018 at 07:35



Circuit Board B (annotated) - This is the solar and battery power regulation board controlled by ATtiny 1634 (Huckleberry)

JPEG Image - 627.42 kB - 04/07/2018 at 07:04


View all 60 files

  • 1 × 14-Watt X-Dragon Solar Charger (Extracted SunPower solar cells and USB charge controller)
  • 2 × iKits 10,200 mAh USB Powerbanks (Extracted NCR18650B cells and USB charge controller)
  • 2 × Inland 1.7mm PETG Filament White 1kg
  • 1 × Clear Acrylic Sheet 18" × 24" x .100", High-gloss, UV-resistant
  • 1 × Baofeng UV-5RA 2m/70cm radio and headset (Extracted amateur radio transciever and headset magnet)

View all 40 components

  • Released Source Code Today

    Lee Djavaherian06/02/2018 at 05:21 0 comments

    Ok, the first version of the source code for TrillSat was released a couple of hours ago under GPL 3.0, and a copy of the source tarball was uploaded to the Files section of this project.  It includes the most important files, the OpenSCAD program that generates the STL files for 3D-printing (and animation), the electrical schematic, the C source files for the two ATtiny 1634 microcontrollers, the Lua source for the Huzzah ESP8266 running NodeMCU, and the Python 2/3 and BASH sources for the Raspberry Pi Zero W.  The README file also details several smaller changes that need to be made to various configuration files.

    The tarball doesn't contain the entire project, only the core craft design files, so I didn't include the 100+ pages of technical information which are available on my TrillSat home page at, since I wanted to keep the tarball small.  I also left out the STL and G-code files that I used to print the parts, since they consumed several megabytes (and are easy to generate using my OpenSCAD program and Slic3r), and I left out the KiCad source and library files as I only use it for the visual schematic and don't use any of its other features.

    The "Three-Tridant Orbital Mechanic" PWM drive system is now working, but it is very crude at this stage.  I created a new "Park" command which drives the Planetary Mass at different acceleration/deceleration values and speeds as it passes the Hall-effect switches, automatically switching between Sign-Magnitude and Lock-Antiphase on-the-fly to re-park the mass at sunrise position during the night (and lifting the entire weight of the craft).  It works in testing on a table, but I have not yet tested this system on the tether (and I will probably need to tweak the values to match different friction/torque requirements).

    I had to match the speeds of Sign-Magnitude and Lock-Antiphase to ensure smooth hand-offs, since Lock-Antiphase runs at twice the frequency of Sign-Magnitude, so I sped up Sign-Magnitude to compensate, rather than slow Lock-Antiphase down.  Lock-Antiphase has half the resolution, so slowing it down won't allow a perfect match with Sign-Magnitude during a non-linear acceleration, but Sign-Magnitude can have its resolution cut in half to match, which preserves the congruence.

    I also had some spontaneous ATtiny reboots during testing, since I moved my bypass capacitor too far away from the ATtiny after I replaced the last BLDC, and the supply voltage dropped below my brown-out detection threshold of 4.3 volts, so I lowered it to 2.7 volts which helped until I can get around to fixing the problem.

    The code is crude at this stage, but hopefully it will give others insight into solutions for several problems that I had to overcome:  how to take control over the UV-5RA flash memory and minimize writes to the flash using 16-byte blocks (something Chirp wasn't designed to do), how to create a crude XMPP server on a memory-constrained ESP8266 running NodeMCU, how to program a PBBS using AX.25 Unix programming techniques instead of the C library, how to craft the APRS message, and how to wrangle a custom radio interface using a Virtual UART and Virtual PTT line.

    It also shows the various ways to control the two very different types of motors under PWM (brushed and brushless) using a single microcontroller, maxing out both of its hardware timers and creatively using interrupts.  And of course, there are a lot of different types of IPC, job processing, multiprocessing and concurrency going on with 4 CPUs that interoperate.

    It is a fascinating experience for me, and I hope you find some of it useful.

  • Source Code Cleanup

    Lee Djavaherian05/21/2018 at 06:12 0 comments

    I've been cleaning up my various source code files and getting them ready for release in the next couple of weeks.

    I edited my OpenSCAD source to allow variables at the top of the code to change the output (to render individual parts for printing, display the entire assembly, display the exploded assembly, and perform an animation).  In my C, Lua, Python, and BASH code, I also made a pass through my config files to section out my private code, removed hard-coded values, and renamed some directories to more appropriate names.

    It takes time to think up appropriate names while programming (and pulls you out of your context), and this can break your concentration when you are involved in something complex.

    My paper notes are the same.  I have good spelling, penmanship, and drawing skills, but you'd never know that by looking through my technical notes, which are almost indecipherable, since I scribble train-of-consciousness as fast as I can think, and similarly, this doesn't allow me to access my spelling or fine motor skills, since I'm not focusing on them at the moment.  It really isn't writing or illustrating--it's a brainstorm data-dump: misspelled words and scribbly ideograms.  I then make a second pass over the material if I need to formulate a visual or literary language.  But it's kind of depressing looking at hundreds of pages of your own old, messy notes...

    My source code is the same way.  First I get it working (using whatever constructs are needed), then I make a second pass to refactor into more modular programming practices, abstracting away similarities, eliminating redundancies, etc.  But this takes time.  As proof-of-concept, my first release, Version 1.0, is always messy.  I don't use alpha/beta indicators or versioning to signify versioning, as every release is a beta as far as I'm concerned.  I just do the major.minor thing and start with 1 and then use the decimal values in sequence to denote future versions, only changing to a 2 if there is a significant improvement  (which has never occurred to date).

    When I was young, I was a perfectionist, and it was easy for others to see this in my work, but as I got older, I realized that I wasn't optimizing the "entire" structure, and so I began to apply my perfectionism to systemic and systematic processes and not visual ones, and this is sometimes hard for anyone but myself to recognize (an ugly shell with beauty inside, so to speak).  But the fact that someone like Leonardo da Vinci can draw and write beautifully in his notebooks while also expressing complex, abstract concepts (beauty throughout) is astounding, and I wonder how he achieved this ability (or perhaps it wasn't really what I think it is, I don't know).

    In some ways, though, when you force yourself to slow down and perfect something trivial, like the simple notes, the illustrations, the prose etc, it helps to clear the mind when you look back at that thing later, and may actually be a better way of doing things (more gains in the long run) than my messy "molding over several iterations" approach; I don't know, since I've never really tried it for anything sufficiently complex.  But it would take a person of the utmost skill to do such things.

    Several years ago, I created a BASH script which adds the appropriate GPL license files, extracts README documentation from my website, adds the version number, strips out my private code segments, packages everything into a tarball, and stores the released versions in an archive.  This allows me to program and test my code in place with all of my hard-coded customizations, and then I can just run the packager to generate the correct tarball for public release.

    But with the TrillSat project, I've encountered a situation that I haven't dealt with before:  this is my first "open-hardware" project containing an electrical schematic, 3D-printed parts, and source code...

    Read more »

  • BLDC/Gyrofan Is Back in Action

    Lee Djavaherian05/08/2018 at 11:01 0 comments

    I fully charged the two Lithium-ion battery banks (around 8.4 volts in series), but the BLDC problem that I mentioned in my previous log entry still occurred, so I wrote up a small amount of Python and C code to create a new XMPP command called "bldctest [testnumber]" so that I could activate the coils in different polarities for 2-second periods to troubleshoot.  Testnumber 1 is +U -V, 11 is -U +V, 2 is +U -W, 22 is -U +W, 3 is +V -W, and 33 is -V +W.

    I was then able to connect my multimeter to read the voltages at BLDC coil terminals U, V, and W and text the appropriate command to see what was going on.  It was soon apparent that the U coil wasn't working, and it was indeed only running on only 2 phases, as I surmised.  I tracked it down to a bad solder joint on the U coil L6234 enable pin (EN1 in this case) that was only receiving .5 volts instead of the full 5-volt logic coming out of the ATtiny 1634 (which I have running at 5 volts), which was too low to activate the L6234 logic gates/MOSFETs.  So I reheated the joint to correct the issue, and the Gyrofan is once again operational.  Thankfully, there doesn't appear to be any damage to the L6234 or the ATtiny...


    To ensure that this chip lock-up issue doesn't occur under intermittent solar power and burn out the motor again, I turned on brown-out detection on both ATtiny 1634's and set the threshold to 4.3 volts.  If the voltage drops below 4.3 volts (or 4.1 volts minimum) the chip will go into reset mode until the voltage is restored.  These ATtinys can operate at lower voltages, but since they should only be receiving power from my solar charger's 5v USB output (or via a 5v USB bypass line in test mode), I set the threshold fairly high.  This ensures that the solar charger output has at least ramped up to operating voltage and should be more stable.  If the high-current motor PWM drops this voltage below the threshold and resets the chips, I may try lowering it to 2.7 volts, but I'm hoping that my bypass capacitors will handle it and this won't be necessary.

    First, I set the High Fuse Byte to DC (11011100) to enable a BOD trigger level of 4.3 volts (typical):

    sudo avrdude -pt1634 -c linuxgpio -U hfuse:w:0xDC:m -C avrdude-sawyer.conf
    sudo avrdude -pt1634 -c linuxgpio -U hfuse:w:0xDC:m -C avrdude-huckleberry.conf

    Next, I set the Extended Fuse Byte to F5 (11110101) to enable Active, Idle, and Sleep Mode Brown Out Detection:

    sudo avrdude -pt1634 -c linuxgpio -U efuse:w:0xF5:m -C avrdude-sawyer.conf
    sudo avrdude -pt1634 -c linuxgpio -U efuse:w:0xF5:m -C avrdude-huckleberry.conf

    Since both AVRs, Sawyer and Huckleberry, share the same SPI programming lines except for their reset lines, I use two custom avrdude.conf files to program each chip, with only their reset lines differing between the files.

    Also note that there are two bugs in the latest released 6.3 version of AVRDUDE that have to be fixed before it will correctly program the ATtiny 1634:

    And AVRDUDE has to be compiled with the --enable-linuxgpio=yes option for bitbang support.  I use Arch Linux, so I just use the Arch Build System to make the corrections in the source and then recompile (and then I also edit the avrdude.conf file to add the other bug fix to the ATtiny1634 section).

    All TRILLSAT-1 hardware is now operational again.

  • Second BLDC is Installed (and giving me trouble, of course)

    Lee Djavaherian05/07/2018 at 06:09 0 comments

    The replacement BLDC has been soldered in place on Circuit Board C, and the new ZIF ribbon cable connector seems to work pretty well.  However, since I'm trying not to wire on top of the BLDC this time, I've just about run out of room for the circuit underneath the Gyrofan wheel.  Dang.

    The ZIF connector has about 1 mm clearance, and the larger 100 uF electrolytic bypass capacitors wouldn't fit, so I had to overlap the one for the L6234 over the BLDC board (which can be bent out of the way), and I had to move the one for the ATtiny 1634 several centimeters away, so it won't work as well as it did before.

    This BLDC is giving me trouble, however.  It has a different sound when it runs, stalls on slow-starts, and doesn't have as much torque as the first motor (it acts as if it is running on only two phases).  The motor wiring is not the cause since I've tried every combination of hall-effect sensors and coil patterns in software to rule out a motor miswiring on my part, and the 3 hall-effect sensors are being properly detected. 

    So I've narrowed it down to motor drive current:  it is either the L6234 circuit (perhaps the charge pump), the L6234 itself, or the ATtiny ports/wires driving the L6234.  I'm really hoping that when the first motor burned out that it didn't do a full short and also burn out part of the L6234.  And the ATtiny ports can also burn out if the L6234 loses its 7.4 volt supply voltage...  I really hope this isn't the case.

    There is another possibility that I didn't consider, though.  As I've been testing the motors indoors, I've been draining the Lithium-ion batteries, and they are now around 3.5 volts each.  In series, this equates to 7 volts, the minimum operating voltage of the L6234.  Perhaps it is not operating efficiently enough.

    So I opened up the Power Regulation box and soldered a wire to the 5v power input of the Lithium-ion charger board, which is supplied by the solar charger, and exposed this wire outside of the box in one of the wire channels between the Circuit Boxes and Battery Frame.  This allows me to access the wire to bypass the solar panel in cases where I need to charge the Lithium-ion batteries during testing.  There is no way to charge them when the case is closed up unless I have sunlight.  Now all I have to do is open up one of the wire channel access panels.

    I'll test again once they are fully charged to rule out any issues with the supply voltage.

    I decided to solder the bypass wire after the solar charger MOSFET thinking that, as long as the MOSFET was off, the current wouldn't feed back into the charger--but I forgot about the MOSFET body diode, and so it fed back anyway, lighting up the solar charger LED.  I'm hoping that the output stages of the solar charger's step-down converter include their own diode and this won't be a problem.  I'm not going to actually use the solar panel while charging the batteries over this bypass wire, and the voltages are the same, so I'm probably okay.

    So, if the battery voltage is not the problem, I will have to write some software code to pulse the coils in different patterns so that I can test them with the multimeter (but short enough durations as to not overheat the coil).  The most likely cause is that, when moving the wires out of the way to make room for the new motor, I probably agitated the wiring and created a bad connection somewhere, as my solder joints are fragile.

    And I also almost had a heart attack when, to my horror, I accidentally melted the plastic rotor mount of the  pristine BLDC when I was soldering... *sigh* ...but what can you do.  Luckily, it still fits within the Gyrofan mount, and the loss of mass was negligible.

    Please excuse the horrible circuit appearance of Circuit Board C--the hot glue makes it look worse than it really is.  I try to only apply hot glue to the areas that are mechanically the weakest, and I purposely...

    Read more »

  • BLDC Replacement and Failure Analysis

    Lee Djavaherian04/23/2018 at 03:51 0 comments

    I purchased an old, used Lite-On LDW-411S DVD+-RW drive (manufactured in 2003) that someone was selling on eBay and removed the BLDC motor to replace the one that I burned out a few weeks ago due to the chip lock-up/stall issue mentioned in my earlier log entry.  One of the problems of re-purposing old parts, however, is that drop-in replacements are harder to find (but I never expected to burn out my first one!).  Holes have been drilled for Gyrofan mounting, and small nuts have been epoxied behind the holes for easy assembly to the Gyrofan wheel.  I also had to be careful to ensure that the metal shavings from one of the holes that I drilled in the metal board (to widen it) didn't enter the motor, so I taped up the motor before drilling the holes. 

    This time around, though, I decided to de-solder the ZIF ribbon-cable connector from the drive's circuit board and will use this, in place of direct soldering, to more easily and quickly disconnect or replace the motor in the future.

    I tend to avoid analysis, deferring to logical deduction, but this was a good opportunity to see exactly what kind of motor I am dealing with, as there are many different types of BLDCs.  As you can see, it has 9 stator coils and the heat melted the plastic around the coils, wedging it against the magnetic rotor.

    I had to clear out a lot of the wiring on Circuit Board C to remove the old BLDC and will be more careful next time to wire around the BLDC to prevent its removal from being obstructed.  The heat from stalling out the old motor actually caused the black printing to melt onto the white PETG gondola backplane.

    Once the new BLDC is in place, I plan to get some video of both of the motors (the BLDC and the brushed DC screwdriver motor) under PWM control.  Then I'll start a pass through my Python, C, Lua, and OpenSCAD source code to get a version ready for open-source release.  Currently, my code has a lot of hard-coded customizations which first need to be generalized.

  • Took it outside today

    Lee Djavaherian04/08/2018 at 00:49 0 comments

    It was a sunny day today (but a little cold), so I went outside and took a photo of TRILLSAT-1 tied to a tree and decided to make it the main photo for this project.

  • Current Status and Testing

    Lee Djavaherian04/07/2018 at 06:40 0 comments

    Current Status

    I've spent about one year programming the core systems, and one year building, and it is now in the final stages of writing/perfecting the highest level algorithms and adjusting for real-world use.  The packet radio interface has been tested on-the-air and does work.  The PBBS system and APRS beacon has been tested in simulation (and works), but hasn't yet been tested over-the-air.  The TROT drive system has been tested on the indoor test frame, not in use outside on actual trees or weather conditions yet, but much of it is still under manual control.  The full size 2m/70cm antenna is only theoretical at this point but is simple to build, something I have left to the very end, but I will need to add an appropriate female SMA bulkhead adapter to extend the 50 ohm terminal outside the Radio Box.  The THUMP system is only about 50% completed, as the SIMTHEO algorithm does work, but inverting it and adapting it to the tethered accelerometer interrupt is mainly theoretical at the time of this writing.

    All electromechanical systems are functioning, and I have created a large set of XMPP commands to manually control the craft and read its sensors, but there are only a few autonomous robotics systems in place at the time of this writing.

    Working autonomous robotic systems

    • Solar Charge Mode:  The power regulation microcontroller (Huckleberry) can automatically monitor the voltages of the craft's battery banks and switch the craft's systems from one to another to charge one bank while using another.
    • Orbital Mechanics:  The Planetary Mass can slow start and park at different positions corresponding to sunrise, solar noon, and sunset.
    • Gyrofan:  The gyro can perform slow starts and hold itself at a specified RPM, using 3 Hall-effect sensors in conjunction with a quad comparator, increasing energy to hold its position by varying PWM and/or switching to different drive modes.  Although, due to a freak coincidence (explained later) the gyro BLDC motor windings overheated to the point where the motor has seized up and I have ordered a replacement, but have not yet soldered it in place.
    • Pitch and Roll angle--The system can compute the Pitch and Roll angles to within around .1 degree by calculating its angle with respect to gravity.

    Autonomous robotic systems that still need to be implemented

    • The system can solar charge itself, as mentioned above, and the CdS cells can read light levels, but I haven't yet applied Lambert's cosine law to estimate the angle of the sun and have the unit automatically set itself to that angle. I still need to line the LDR Tubes with an opaque material to prevent light leakage through the translucent PETG plastic.  This angle should be used by the Motor Control ATtiny (Sawyer) to reposition itself automatically, incorporating its internal timer.
    • The Pi needs to use the accelerometer data to increase the precision of the solar angle set by Sawyer.  If the Pi goes down, Sawyer can act independently.
    • I have not added active pendulum stabilization algorithms via the planetary mass or the gyroscopic reaction wheel (this is a luxury item that can wait until later).
      Sign-Magnitude and Locked-Antiphase PWM are working, but the Planetary Mass orbit still needs to automatically switch between modes depending on the point in the orbit.

    Results of testing so far:


    • The Gyrofan clearance is too tight in the fan duct and Circuit Board C.  The wiring channels are too narrow.  This makes it hard to assemble.
    •  The Gyrofan is ineffective at the speeds that I have tested.  I have not fully loaded the gyro mass, but I don't want to add any more, as it decreases the max solar panel tilt angle (which is already borderline).  But I am afraid to run it at faster speeds at this point (I don't want it to disintegrate and damage Circuit Board C).  Once the other algorithms on the craft are added and documented, I may try ramping...
    Read more »

View all 7 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates