The Linux Throwie: A Non-Spacefaring Satellite

Throwies occupy a special place in hardware culture — a coin cell battery, LED, and a magnet that can be thrown into an inaccessible place and stick there as a little beacon of colored light. Many of us will fondly remember this as a first project. Alas, time marches inevitably on, and launching cheerful lights no longer teaches me new skills. With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). It’s a little kooky, yet should still deliver a few years of occasional remote access if you leave it somewhere with sunlight.

A short while ago, I described the power stages for this solar-powered, cloud accessible Linux server. It only activates on demand, so a small solar cell and modest battery are sufficient to keep the whole show running.

Where we left off, I had a solar cell that could charge a battery, and provide regulated 12 V and 5 V output. For it to be a functional device, there are three high level problems to solve:

  1. It must be possible to set up the device without direct physical access
  2. You must be able to remotely turn it on and off as needed.
  3. It needs to be accessible from the Internet.

The funny thing is, this hardware reminds me of a satellite. Of course it’s not meant to go into space, but I do plan to put it somewhere not easy to get to again, it runs off of solar power, and there’s a special subsystem (ESP8266) to tend the power, check for remote activation, and turn the main computer (Raspberry Pi 3) on and off as necessary. This sounds a lot like space race tech, right?

As I have a bit more code than usual to share with you today, I’ll discuss the most interesting parts, and provide links to the full firmware files at the end of the article.

Device Setup

Device setup is a good place to start, and it has two components: the operating system on the Raspberry Pi 3 (in this case Raspbian Stretch Lite), and the low-power systems that control whether the Raspberry Pi 3 is turned on or off. In both cases, we handle this by scanning for a wireless network with known SSID (say from your mobile phone).

In Raspbian, this is pretty easy – we open up /etc/network/interfaces and set the priority of our configuration network to a high number:


network={
ssid = "setup network name"
psk = "setup network password"
priority = 999
}

For our power control hardware, there is a module available in NodeMCU called ‘end user setup’ that allows you to connect to the ESP8266 remotely, scan for networks, and connect to one of them, saving the credentials. All we need to do is selectively run a program containing it when a certain hotspot is in range:


function listap()
dofile('setup.lua')
end

scan_cfg = {}
scan_cfg.ssid = "setup network name"
scan_cfg.show_hidden = 1
wifi.sta.getap(scan_cfg, 1, listap)

Then in setup.lua, we run end user setup. This causes the ESP8266 to act as a hotspot named ‘SetupGadget’ followed by a few hex digits:


enduser_setup.start(
function()
print("Connected to wifi as:" .. wifi.sta.getip())
end,
function(err, str)
print("enduser_setup: Err #" .. err .. ": " .. str)
end
)

tmr.alarm(1,1000, 1, function() if wifi.sta.getip()==nil then print(" Wait for IP address!") else print("New IP address is "..wifi.sta.getip()) tmr.stop(1) node.dsleep(2000000) end end)

With this set up, we can connect the server and controlling hardware to a new wireless network without direct physical access. Solar power requires light, this is likely going to be on my roof, and I don’t relish the idea of climbing up to get it any time I need to reset my home WiFi password. If you have a really tall roof, build yourself a directional waveguide antenna — I’ve been able to get a range of over 100 meters this way, through several concrete buildings. There’s also Brian Benchoff’s 3D-printable ESP8266 dish antenna.

Remote Power Control

Next, we need to be able to remotely turn the server on or off. We’ll do this with MQTT pointed at a domain name that resolves to a cloud VPS. The only thing you’ll need on that VPS is the mosquito MQTT broker, so no sense in paying for a high-end server. Note that there are ways to implement some basic security here, but for the sake of brevity, I’ll leave that as an exercise for you to explore on your own.

Note that our hardware is only active occasionally – I’ve set it to wake up every 15 minutes or so to check the MQTT broker. To make sure it receives messages, the sender needs to set the “retain” flag when sending the activation command. This guarantees that the message will be there when the ESP8266 wakes up and checks for new messages, as long as we don’t replace it with some other retained message. A short example in Python for an MQTT broker at domain.com, and topic solarserver:


import paho.mqtt.client as mqtt #import the client
broker_address="domain.com"
client = mqtt.Client("P1") #create new instance
client.connect(broker_address, port=1883) #connect to broker
client.publish("solarserver", payload="activate", qos=0, retain=True)

On our ESP8266, we check for the command ‘activate’ and then run a program that turns on the Raspberry Pi 3:


ClientID = 'Node001'
m = mqtt.Client(ClientID, 120)

m:connect("domain.com", 1883, 0, function(client)
print("connected")
client:subscribe("/solarserver", 0, function(client) print("subscribe success") end)
end)

m:on("message", function(client, topic, data)
print(topic .. ":" )
if data ~= nil then
print(data)
if data == "activate" then
dofile('active.lua')
m:close()
end

end
end)

The program ‘active.lua’ raises a GPIO high to enable the 5v line to the Raspberry Pi 3, and monitors the battery voltage. If the battery voltage drops too low, or a shutdown command is received, it will cut power (shutting down first is a good idea).

Digging Deeper Into SSH Tunnels

What good does it do us though, if we can turn the device on but not access it? As I plan to move this device around for software demos, it would be great if I didn’t have to worry too much about firewalls, routers, and other drudgery that it might be behind. This is where we explore reverse SSH tunnels.

Normally, you establish an SSH connection because you want secure shell access to a remote machine, and have a certificate or username+password pair along with the address of the machine. In this situation, the address of the client and state of its network (the routers it is behind and so on) is not usually important, but the address of the server is assumed to be known and all port forwarding and firewall settings configured to accept the traffic.

In a reverse SSH connection, the server initiates a connection to the client that is used to allow the client to connect back to the server. On initiating the connection from server to client, you specify a port. When logged into the client, you use SSH to log in to localhost on that port, and the traffic will be sent to the server, allowing you to log in.

We’ll need to automate this process for it to be useful. The first step is to create a user (your_username in this example) with restricted access on your VPS. Our server will be automatically logging in to it, doing this with the root account is probably a terrible idea if you have anything there you remotely value. Note the password for this new user.

Next we power on the Raspberry Pi 3 (we’ll assume you use Raspbian Lite here), set a new root password, install autossh to manage the connection, create a new user (same name as the VPS user) with a certificate, and finally copy that certificate using SSH-copy-id to our VPS:


$apt-get install autossh
$useradd -m -s /bin/bash your_username
$su – your_username
$ssh-keygen -t ed25519
$ssh-copy-id your_username@(VPS IP address) -p 22

Then we run raspi-config to enable the SSH server and have that user automatically logged in at boot. Now we’re set up to log in to our VPS over SSH with certificates instead of a username+password pair, which is easier to automate. Let’s establish a reverse SSH tunnel from our Raspberry Pi 3 to test it:


$autossh -M 0 your_username@(VPS IP address) -p 22 -N -R 8081:localhost:22 -vvv

If that succeeds, you ought to be able to establish an SSH connection to your Raspberry Pi from your VPS via the command:


$ssh your_username@localhost -p 8081

Assuming that works as intended, we move on to creating a service that establishes that connection a few seconds after the network interfaces go up. We’ll do this with systemctl, but first we need to create a short shell script for systemctl to call. Create a file autossh.sh, make it executable (e.g. with chmod), and populate it with:


sleep 15
autossh -M 0 your_username@(VPS IP address) -p 22 -N -R 8081:localhost:22 -vvv

The ‘sleep 15’ waits for 15 seconds after network interfaces go up during boot. Without this, I found that the script runs slightly too early, and I cannot resolve the VPS host. There are more elegant ways to fix this, but this was the easiest. Now we create the service that runs this script with:


$systemctl edit --force --full autoautossh.service

We then enter the following, then save the file:


[Unit]
Description=My Script Service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=pi
WorkingDirectory=/home/your_username
ExecStart=/bin/bash /home/your_username/autossh.sh

[Install]
WantedBy=multi-user.target

Then we enable it and test it. After the second command, the reverse SSH tunnel should be operational and you can try it – if it doesn’t work now, it won’t work on boot either:


$systemctl enable autoautossh.service
$systemctl start autoautossh.service

If you have access now, then it ought to automatically establish the reverse SSH tunnel after boot, and also automatically re-establish it if it gets broken. If you’re having trouble with poor network connections, you might investigate Mosh as an alternative to SSH.

The case should probably be white, given that it’s going to be sitting in the sun a lot. Two solar panels fit nicely, so now it uses 0.6W of solar panels. Hot glue is to fill the small gap between the panels and the case, and for cosmetic effect, of course.

At this point, you’re more or less done: just plug the 5 V output of your power stages into your Raspberry Pi and put it in a weatherproof box. When you send a retained message ‘activate’ to your MQTT topic, the server will turn on within fifteen minutes or so. I recommend testing it and listening to the MQTT topic a while to make sure it all works as expected and so that you have an idea how long the battery lasts.

As promised, here is the full firmware source code. Dig through it an leave any questions you have in the comments section below. I’d also love to hear what you’d use a Linux throwie for?

41 thoughts on “The Linux Throwie: A Non-Spacefaring Satellite

  1. Why? It’s near enough to habitation that it can connect to Wifi (which has a range of <100m for a standard ESP8266) , but for some reason you want/need this thing to be self powered, and outside. And to only occasionally be active. The use case is getting pretty obscure – What is the actual purpose of this device? (And no 'because one can' crap please).

      1. The ‘dead drop’ use case sounds fun. I could think of much lower power implementations too! I may follow up on that.

        Regarding various questions about why I build anything: I get asked this a lot, usually by people who think my hobbies are rather quaint.

        The truth is, I’m at the point in my career where I mainly produce decisions, not things or code. Ten hours a day, 6-7 days a week, I have to justify why a given technology is used or a block of code is written. It’s a lot of work and rewarding in it’s own way, but my nature is to build things, not manage people. I’ll always feel more at home in a lab or workshop than in the boardroom.

        So for one glorious moment every few weeks, I think to myself “Why? That’s a question for philosophers and cowards!”. I scrape together a few hours, heat up my soldering iron, and try to build something out of technologies I find exciting.

        Occasionally a practical use case emerges — but that’s not really the point. There’s always a story though, I think it’s important to share stories about how things are made, and it means a lot to me that you take the time to read them.

        That might sound a bit silly to some of you (and I’m willing to accept that), but it’s the truth. Why do I build things in my spare time? Your guess is as good as mine — because for once, I don’t really know.

        1. “Why? That’s a question for philosophers and cowards!”
          This quote getting printed out and going above my workbench.

          I constantly find myself trying come up with reasons to explain to people why I do things like get my Ham License in the days of internet, build satellite listening stations or devices that record and report useless environmental data. My favourite one so far is “There are people who spend hours watching strangers play sports on TV. Can you imagine that? Why?”

          1. Some people never get the “why” in what motivates others. I hear this most often from those who rarely try to do more than what is asked. I have accepted that those types and I will most likely never understand each other as I cannot understand their reasoning when it comes to why they don’t…

        2. All I have to say is, “bravo sir, extremely well done write up!”

          Knowing what it’s going to be used for isn’t nearly as precious as the information that you have taught. The hackers ethos is to take that information and adapt it to our own projects at hand.

          Thanks, I know it takes much more time to write something up than just do it, and I appreciate it.

    1. I can think of a BUNCH of uses for this device, if you can’t you aren’t thinking along the same lines as the author but that doesn’t mean it’s useless. You could deploy these in a hostile area to collect information and simply pass it off to you via stealth as you pass by w/ your phone’s wifi adhoc network on. You could deploy a series of them to create a mesh network to allow a wifi robot to traverse an area. I think I’m gonna make one and try it out. I have everything I need here already laying around.

    2. I can see all sorts of potential use cases that could build off of this. Weather station. Fires up, checks weather, reports in, powers down. Something on the roof of a vehicle to track when it is within a specific area. Connects to home wifi and sends a beacon letting my spouse know I’m home safely, does the same once I get to work to let her know I made it there. Something to monitor the level of my pool. Fires up, check water level, reports in, shuts down. Or in a garden, so monitor water or soil conditions. Just because nothing comes to mind for one person immediately, is no reason to dog on the guy for his project, because the next person that comes along might take this idea, and build off it, making something that a larger group would find use in. Seems like we are all too quick to discourage folks.

    3. How about a slow speed network, drop these things over an area, little glider wings to carry them off? If an edge of the network has access to the internet, the whole network eventually does. All kinds of applications.

    4. Here’s a use case: Warbombing. There’s wardriving, warcarting,warwalking, etc. But back in the early days of wifi where people would troll for wifi networks, etc, I used this idea occasionally as a bit of fun for a while. Now for this you throw this device somewhere inconspicuous but heavily trafficked and create an open wifi network, call it something like “Linksys”. Route all DNS queries, connections, everything to 127.0.0.1:80, so google.com points to 127.0.0.1:80, etc. Now serve up a malicious webpage of your choice. In my case, it was a combination of lemon party, the photoshopped fingers, goatse, etc and had an embedded mp3 of Rick Astley that would play upon loading.

      You can, of course, get even more nefarious if you give it a burner cell or relay to another wifi network and start injecting anything you want (but blocking, of course, any encrypted communications or vpn attempts). Or you could try and log credentials, etc.

    5. I’m with you, seems really boring. I got excited when I read the intro ’cause I do have use-cases for leaving little systems out in the wild. But by that I mean on a mountain peak or somewhere in the nat’l forest, not on my roof (!???). Use cases are repeaters for LoRa connectivity and such. But the interesting challenges are actually managing the power budget (the article doesn’t even do the most rudimentary calculation!), adding a decent antenna while concealing the whole thing, reducing cost & parts count so it’s small, cheap and disposable. Sigh.

      1. I did an energy budget, but the code seemed more interesting to me and the solar component of the energy budget is specific to my location and the arbitrary battery I used. Here’s a quick summary though which I hope you’ll find helpful:

        The server and other components consume about 2.2W when active but idle. The battery supplies about 7.5 W*h at about 85% efficiency through the voltage converters. That’s optimistically just under 3 hours of runtime on a full charge.

        The two solar panels generate 300mW each. Dry season is beginning in Vietnam, so I can expect 4.5 hours of sunlight if there are no physical obstructions (2.3 hours during rainy season). Efficiency varies by panel temperature and current load, the datasheet suggests both can easily drop efficiency by 30% (to do — add MPPT).

        Combining the two, a rough estimate is that I could use the server for 50 minutes a day during dry season, and 25 minutes a day during rainy season. In reality it’s a bit less. Insolation times are from previous measurements I’ve taken from a nearby rooftop — but that’s a story for another day.

        These calculations can be very different depending on your geographic location, battery used, and solar panel used. For example, I’m located near the equator where solar panels work reasonably well without solar trackers, temperature remains relatively constant, battery specifications are pure speculation, and weather patterns (in my area at least) make for fairly predictable insolation patterns.

        1. Add more solar capacity… so much that the supporting box and components will be in it’s shadow and protected from the worst of the heat and rain. LiIon batts degrade a lot if heated much and used. This way you get more power and more life and more reliability. Also the batt will only come into the equation if solar power is insufficient ie if the server is used during the peak of the day the bulk of it’s power will come from the solar cells hence the batts will remain fully charged.

    6. It’s near somebody’s home wifi just for initial setup and testing–I doubt it’s meant to be in such a situation permanently.

      If you don’t need it, don’t build it. But somebody might figure out a use for it. To make a pineapple with no need for an outlet, long life, and you wanted to stick it somewhere extremely hard to find (throw it on the roof!) this might be a good way.

      Also, because one can.

    7. “and no ‘becasue one can’ crap please:

      My view on “having a practice”.

      Do you know any runners?
      Maybe once or twice a year they run a big race.
      On race day, just after they finish a marathon – you might be impressed by their determination and perseverance. Maybe even inspired.

      Here’s the thing. It’s not just about race day. They are running four to six days a week. They likely run the same trail often. Nearly the exact same footsteps as last week, and the week before, and the week before…

      Just after one of their easy run days would you get in their face and say:
      “What’s the point – what’s the purpose of running this same six mile trail?”
      “The use case is pretty obscure – mankind has done this before. Hell – you’ve done this before”.

      I’m guessing not. Because when it comes to physical fitness – people intuitively know you have to train regularly to increase and maintain your fitness.

      (and if you’re cynical enough to think running a marathon is no bid deal… Prove me wrong. Get up, out of your chair right now and run one.)

      The thing is, studies have proven that regular, purposeful practice is the method to successfully foster human expertise in ANY ENDEAVOR. Whether your goal is physical fitness, intellectual/technical skill, or even some totally weird, off the wall unique thing.

      Even if they only purpose of this project is to keep the author’s technical skills sharp during it’s implementation – then it’s still an overall win – for them. It’s another project under their belt. A part of their overall practice. Maybe to them it was their big race day. Maybe to them it was their quick easy fitness run in the middle of the week. I can’t answer that.

      The science is out there. Go read it. Let it change your perspective. Use it to improve your life.
      Further Reading: “Peak: Secrets from the New Science of Expertise” by Anders Ericsson, Robert Pool

    8. I am currently in process of designing a scavenger hunt with designs including modules very much like this and was actively looking for just such a solution. I will have several Linux throwies in the community where my players will need to stand in a particular place and play an interactive fiction mini-game, complete a puzzle, or read a page to obtain the next clue. I think such things could also be great for self-guided tours with location-specific interpretive guides. Think road to Hana without the App. Just look for the low powered wifi signal with your gadget and enjoy our information. If you don’t like the look of interpretive plaques, this could be a great way to reduce the visibility, cost, and in a way, accessibility of adding curation to natural environments too.

  2. I’ve always wanted to create a circuit where you feed enough energy at a tuned RF to power a primary circuit, then another frequency to wake up a secondary circuit, then another for a tertiary, so that those three frequencies in sequence directly power a circuit to trigger something like a solid state relay to wake up the throwie. When idle, the throwie is for all intents and purposes, dead, zero current. I can see a simple LC accumulator circuit for the primary, but not sure for the secondary and tertiary.

    1. Why do you need three power stages? Just have one, and then a device that waits for a coded signal to be sent. Something like a low-power microcontroller, maybe low-power Bluetooth or a Nordic serial module for doing that. It can all be done receive-only. Then that switches on whatever-else that gets it’s power from wherever.

      You can beam a fair amount of power, particularly if you can get it done at short range. Enough to wake up an SSR, if you accumulate the power in a cap for a few seconds.

      Once it’s awake, you keep the SSR activated with power from the micro. You could use the Pi itself to do this, but it takes forever for them to power on. So instead have your little micro do it, perhaps powered from the Pi’s 5v supply. The point of that is, when the Pi sends a signal to the micro, it can drop the SSR and go back to no-power again. Waiting to be awoken by your RF energy.

      It’d be a nice option, if you wanted a stealth, literally zero-off-power computer. Since it’s passively powered at startup, undetectable passively, no emissions. Someone might be able to detect your tuned circuit if they were really looking, with some sort of bug-sweeper.

      You could build it into some small module, with the relevant connectors, so that it could work with any Pi or other computer. The RF coil could be placed away from the module if needed.

  3. This is pretty neat. I’ve been wanting to a “terrestrial satellite” project of some sort for a long time. There have been many balloon flights of a similar nature, transmitting WSPR signals on the HF bands, and even a buoy that somebody made to do the same. All GPS enabled and position reporting of course. I’d love to do one that instead sends useful environmental data, or even transmits pictures using SSTV.

      1. I’ve been so annoyed that none of the amateur satellites with a 2.4GHz transponder have enough bandwidth for wifi packets. Figured it’d be hysterical to beam up a few beacon frames (transverted to the uplink frequency, of course) and have ’em show up simultaneously all over the footprint.

        Power budget notwithstanding, I still think this would be fun. Othernet is running LoRa modulation in Ku-band, I wonder what other weak-signal modes could be received by non-hams…

  4. “With a nod to those simpler times, I’ve been working on the unusual idea of building a fully functional server that can be left in remote places and remain functional, like a throwie (please don’t actually throw it). ”

    Use the shell of an Amazon Dash, or equivalent.

  5. Most of the use cases that I could think of for this could be implemented using the ESP8266 alone. The addition of a full Linux system makes it less robust. Also, a single micro controller is far cheaper and lower power then the setup described, which is more in keeping with the spirit of the throwie.

  6. Try and hook up with someone from a parks or forestry service. They’d probably have lots of ideas for outdoor things that need to be monitored on occasion and that would be difficult to run power to. Maybe a county extension office too.

    1. Interesting.
      I’m a member-participant in a group who is attempting to turn an abandoned railroad in Queens NY in to a walking and bike trail, and I complained that I’d be attempted to offer my services to them, but I’m a programmer. And then I remembered this gizmo, and saw your post.

  7. Your idea is not unusual, but the lack of purpose is. For example, TrillSat is also a “non-spacefaring satellite” (tree-based and not roof-based) and also includes an ESP8266, one of the same DC-DC converters, and also controls power to a Linux-based Raspberry Pi (a Pi Zero W instead of a Pi 3). It uses XMPP (server written from scratch on the ESP) instead of MQTT:

    https://hackaday.io/project/120889-trillsat

    And TrillSat has a specific reason for being raised high into the air: line-of-sight VHF radio coverage to other stations. And it has a reason for including the Linux Raspberry Pi: AFSK modulation, KISS protocol, and AX.25 stack (which would be difficult to write on an ESP).

    TrillSat’s design looks (via 3D printed case), acts (via elevation/attitude control, inertial stabilizer), and serves the purpose of a real communication satellite (via multi-user communication relay).

    Your basic idea isn’t bad, but right now it’s too generalized, in my opinion.

  8. Can we swap for something more subtle like port-knock before initiating any MQTT. Aka your private library of memes, scanned 2600 mags, archives of Hackaday and censored knowledge could be found by anyone blasting a wake up frequency.

  9. Give me SSH and a recent build of Python 3 and I’ll do anything with it.. Python has native libs for most DB and protocols and you can put it all in jails and harden the kernel with grsec..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.