RasPi Flow Meter In A Pinch – Part 2

META: Part 1 describes the problem I’m trying to solve here.

I need a way to monitor water flow through my water filter over several days, and I don’t want to sit and watch it.

So – I took a Raspberry Pi I’ve got and a little Python and hacked a solution together.  The basic idea was that I’d position a plastic cup below the output stream of the waste water, I’d put two wires into the cup, I’d put a voltage on one wire and attempt to see the voltage on the other.  I’d use the Raspberry Pi to check for the voltage once per minute and log the status to a file with a timestamp.  Later, I could graph the state of the voltage – DETECTED or NOT DETECTED – over time, and produce a graph showing when the waste water was running.  With that I could even get an approximate flow rate waste water, if I wanted, by measuring how long it takes to output a liter of waste water and multiplying by run time.

First – the cup.  The simple flow meter.  I poked a hole in the bottom so water drains out slowly, and poked a couple holes through the sides to hold wires in position close to each other without touching.  When water covers the wires current should be able to flow between them, when the water drains out current should stop flowing.  If the waste water overflows the cup it will just run over and down the drain as it usually does.  It takes about 30 seconds for water to drain from overflow until the wires are not conducting, and I was hoping to measure conductivity every minute, so my initial cup holes were close enough.  The waste water runs quickly enough that the cup fills up in about a minute.  This means that polling every minute should produce a graph that closely represents reality.

Cup with two wires hooked up, water running into the top, and water overflowing down the side.  Cup is sitting in a laundry room slop sink.

Next – the Raspberry Pi.  I got Adafruit’s Pi Cobbler along with the Pi, which is a cleverly-named pinout that’s easy to plug into a breadboard.  That plus this handy tutorial from Make made it really easy to write a little voltage tester.  Here’s the code.

#!/usr/bin/env python3

import RPi.GPIO as GPIO
from time import sleep, ctime
import atexit

INPUT_PIN=21
POLL_PERIOD=60
LOG_FILE="/home/username/waterLog.csv"

def resetGPIO():
 GPIO.cleanup()

def setupGPIO():
 GPIO.setmode(GPIO.BCM)
 """ Set INPUT_PIN to pull-up, so the signal will be when it goes low
  That way, we won't potentially source a lot of current to ground with
  a positive voltage, and also just the ground of water might pull it down,
  which would indicate there's water in the cup (and therefore, is what we
  want)
  """
 GPIO.setup(INPUT_PIN, GPIO.IN, pull_up_down = GPIO.PUD_UP)
 
def pollForWater():
 with open(LOG_FILE, "a") as f:
  f.write(",".join((ctime(), str(GPIO.input(INPUT_PIN) == 0)))+"\n")

if __name__ == "__main__":
 atexit.register(resetGPIO)
 setupGPIO()
 while True:
  pollForWater()
  sleep(POLL_PERIOD)

So, now I connect the Pi to a ribbon cable, to a Pi Cobbler, to a breadboard, to two wires on pin 21 and a ground pin respectively.  The other ends of the wires are not touching and are in the cup.  A couple design choices – I could make the pin I’m using for input (pin 21) connect to the Pi via a pull-up or a pull-down resistor.  These options, and the resistors, are built-in to the Pi and selectable in code.

I told pin 21 to use a pull-up resistor, but if instead I told pin 21 to use a pull-down resistor, it would normally rest at 0 V and I would detect a voltage (and thereby detect water) by connecting 3.3 V to the other wire.  There’s a problem with that – I’m putting these wires in water and that will potentially introduce another “ground” connection.  When the wires touch water, the 3.3 V wire would essentially be connected directly to ground, and then the Pi would try to provide a bunch of current, and that could be bad for the Pi.

I told pin 21 to use a pull-up resistor, so that means it normally rests at 3.3 V.  It is connected through a good-sized resistor to 3.3 V, so when nothing is connecting the pin to ground or some other voltage, that resistor “pulls” the voltage on pin 21 up to 3.3 V.  If something connects the pin to ground, the Pi will try to provide current again, just like before.  However, in this case the good-sized resistor is in the way, between 3.3 V and ground, so the Pi won’t have to provide too much current to get everything to equilibrium.  Some folks call this “current limiting” – the Pi is limited to how much current it can provide.  A voltage source simply provides enough current to raise the voltage at its output to its set level.  When that happens, all the currents and voltages balance out and everything reaches equilibrium and stays the same until some other thing happens to the circuit to throw everything out-of-balance.  With pin 21 set as “pull-up”, even if the water introduces another ground, nothing bad should happen to the Pi.

Another design choice – I used Python’s “atexit” to cleanup the Pi’s GPIO port.  The example website I linked to above simply put it after the “while True” polling loop.  The problem with putting the GPIO cleanup after the infinite loop is that if you kill the program by pressing ctrl+c (or by any other means I can think of) the cleanup code never runs.  Python just exits the program immediately.  By registering the cleanup code with “atexit”, Python will run that cleanup code as the last thing it does whenever it possibly can.  There are ways to kill the program where Python will bypass atexit, but all the common methods will let Python exit cleanly and cleanup the port.  Port cleanup isn’t critical in my case – I’ve already got the simple ground protection setup I described above, but it can’t hurt, and if I ever just copy my old code into a new project I’ll be glad I did it correctly.

Raspberry Pi connected via ribbon cable to breadboard.  Breadboard has several circuits on it, and is sitting on a table.  Two wires run from breadboard to slop sink to the right.

Um, that’s pretty much it.  There’s some other stuff on the breadboard but it’s just an old circuit and is irrelevant here.

Waste water hose draining into cup (the cup with the two wires, sitting in the slop sink).

So, that’s what the setup in the sink looks like.  The water is running out of the output here, it’s hard to see in the photo but there’s the shadow.

Photo of a command prompt terminal displaying sample output.  Sample output is date stamp on the left followed by a true or false value, separated by a comma.  The time stamps are a second apart, and true/false values vary through the data.

And here’s a photo of the screen.  Because no screenshots for you.  Just gonna take a photo and pretend like that’s cool.  See how some say true and some say false?  This was a test run, polling every second.  When the wires are less than half-submerged they don’t provide a clean on/off signal to the Pi.  That’s ok, this was a hack.  When I poll only every minute the on/off signal gets much sharper.

Screenshot of terminal data taken once a minute, timestamp comma true/false.  All of the early time stamps are true, then about halfway through they switch to all-false.

Actual data – a screenshot this time because we’re not savages.  I filled up some containers at around 17:20, that caused the filter to start filtering and the waste water to start running, then the water ran until about 18:31, so about an hour.  I would expect that the water doesn’t run again until late tomorrow at the earliest…  We’ll see!

RasPi Flow Meter In A Pinch – Part 1

META: This first part is about the problem that caused me to build the solution.  Part 2 is about the solution.

My new place has an awesome feature that was disabled when I moved in – a reverse osmosis water filter!  It’s not a whole-house hookup, it’s just for the refrigerator and a dedicated tap on the sink.  We definitely wanted to use this thing!  At first, I just turned it on and it seemed to work fine.  However, with a little time, I noticed that the output water from the filter never seemed to stop, and there was a small leak on the “filtered water” side…

A marketing image of a reverse osmosis filter.  There's a storage tank that holds about four gallons on the left, there's a five stage filtering system on the right.  The first three stages are long tubes along the bottom, they filter out sediment and shit.  The fourth stage is the reverse osmosis membrane.  It's the branes of the operation, but it's hidden behind the fifth stage and sitting on a small platform just above those first three cylinders.  Stage four and five are squat horizontal cylinders.  Stage five modifies water flavor.

So – reverse osmosis filtering – it uses water flowing past a membrane to pull impurities out of the water on the other side of the membrane…  It uses water to filter water…  Pretty crazy.  That water that did the pulling, however, has to get dumped down the drain.  The filtering system wastes about 5 times as much water as we drink.  Not great, I know, but maybe I’ll rig the thing up to water the plants later, or something.  It’s not like the waste water got very dirty.

Anyway – that waste water never stopped running.  It was very wasteful.  The parts didn’t really have numbers on them so I couldn’t lookup the system to figure out what was wrong…  I just called some dude who knew.

And he wanted $340 to fix the thing!  Crazy.  I can figure this out.

I decided to start by fixing the small leak.  Start small!  I figured out how the hoses worked, then figured out how to look the system and spare parts up online, then rejiggered the output hose, and the leak stopped.  Score!

The waste water output is controlled by two valves.  One valve prevents backflow – when this is broken it frequently causes the waste water output to never stop.  The other valve is a pressure balance thing, so when the filtered water side pressure is close-enough to the input water pressure the valve closes off and it stops water from flowing through the filter.  Pretty slick!  When the pressure balance is broken it frequently causes the waste water output to never stop.  A little troubleshooting indicated that the pressure-balance valve was the real culprit.  Perhaps it was broken, or dirty, or just out of balance?

It was at about this point in the troubleshooting that I realized the output water was not continuously running anymore – the entire system seemed to be working properly.  I think solving the small output leak caused the pressure on the filtered size to raise enough that it closed the pressure-balance valve.

Problem solved!  Maybe…  I’m never very confident when problems with systems I don’t understand very well seem to solve themselves…  It’s nice, but not ideal.  Plus, it’s hard to tell if the output water is really running a sensible amount.  The system has this tank built in to store up water, so even after we dispense a normal amount, the pressure in the filtered side is still pretty high – it’s still high enough that the system doesn’t need to filter more water right away.  That sets up this very nice natural hysteresis, which is great for the system but not great for troubleshooting.

To be confident everything is working, I need to monitor the waste water output for several days.  I do not want to watch the output valve for several days.  I need a data-recording flow meter.  Time to get nerdy!

Building Your Own OpenVPN

I’ve wanted to have a VPN setup for a while – I’ve never been entirely comfortable when using public wifi, even secured public wifi…  Open wifi?  I feel a little crazy every time I connect.  But I usually console myself that I’m not a target, I can make sure important connections are encrypted, and I can just avoid doing some things while on public wifi.

A VPN though, that could make things much easier!  All communications would be encrypted between the device I’m using and my VPN endpoint.  If I set it up myself, the VPN endpoint would be my home Internet connection.  This essentially makes all my browsing look like it’s coming from home, with solid protection between the coffee shop and home…  I could do any browsing I wanted without worry!  Also, I would essentially be connected to my home network, giving me access to all my devices there.

OpenVPN seems like the popular self-setup VPN, it’s open-source, and there are plenty of tutorials…  OpenVPN, that sounds friendly!

It was not.

If you have tried to set this beast up yourself, you know what I’m talking about.

The purpose of this post is to document what I’ve done.  This will help me when I, inevitably, have to redo the setup in the future.  It may help you if you’re trying to do something similar.  First of all, let’s talk about hardware:

  • Netgear WNDR3400
  • Early 2011 MacBook Pro running OS X El Capitan
  • Samsung Galaxy S5

Here’s the software I ended up using on each of these devices to get OpenVPN working:

“Big” versions of DD-WRT have an OpenVPN server built-in!  I’ve been using DD-WRT for years, previously on a few WRT-54G’s, but now I’ve got this N-Netgear (which is great) which also runs DD-WRT.  Lucky me!

First – get the above software installed.  You’re going to need to do some configuration on each of them, so I’ll describe that next.

Second – generate some keys!  Your VPN is going to use cryptographic certificates to secure the communications between all the parts.

Third – setup the server.  This is the DD-WRT router, in this case.

Fourth – setup the Mac client.  Or whatever client you want…

Fifth – setup the Android client.

How Do These Certificate Things Work?

Here’s how it’s going to work – there’s a “server” end (the router at home – the thing running DD-WRT) and multiple “client” ends (my Mac and my Android).  Every one of these parts will have a unique certificate – in my setup I’ve got three certificates.  Each client needs its own certificate or OpenVPN will barf – don’t cheap out on me!  I learned this from experience.

A certificate sounds like a piece of paper, and you can imagine it that way…  It’s like a piece of paper with a big number written on it, that number is a “public” key.  There’s a companion piece of info called the “private” key.  You can give anyone the public key…  It’s like a physical key, that they can use to lock a secret message in a box.  BUT – the public key won’t open the box back up once the secret message is in there – because math.  The message writer can hand the box to anybody, but no key will open that box again except the private key.

YOU DIDN’T GIVE ANYONE THE PRIVATE KEY, DID YOU?  Don’t.  The private key opens the box and you can get the message.

So, you could write your certificate out on the Internet and then folks can send you secret messages!  That’s how OpenVPN does its thing.  Later on, when this thing starts working, you’ll connect to the server and it’ll send you its certificate (so you can send it your browsing requests secretly) and you’ll send the server your certificate (so it can send you the responses to your requests secretly).  Again – OpenVPN needs a separate certificate for each client because it’s needly like that.

OpenVPN does another cool thing with these certificates – it determines who’s allowed to connect and use the system.  For this purpose you need a fourth certificate called a “certificate authority” (CA) cert.  This one is not special, it is the same as the other ones, but OpenVPN uses it backwards.  You generate the CA public and private key, and then you encrypt other certificates with that CA private key!  Before, remember, we sent secret messages by encrypting (locking the box) with the public key, then only the private key could open the box (decrypt).  By encrypting with the private key, now only the public key can decrypt – and nothing can re-encrypt.

This is cool because anybody can open the box and make sure that someone who holds the CA private key wrote the message inside!  If anybody changes the message inside, everybody else will know that the new message wasn’t the original.  This is called “digitally signing” something.  Nobody can change the document you put the CA’s signature on.

How Do We Make Certificates?

Ok!  So, that’s how it works, but now how do we set it up on a Mac?  Just an aside – this is much easier on a Debian box, and you use the same tools.

Open up a terminal.

mkdir OpenVPNKeys
cp -R /Applications/Tunnelblick.app/Contents/Resources/easy-rsa-tunnelblick/* ./

This makes a place to store everything, and copies over a bunch of tools that will make the job easier.  Specifically, this thing called Easy-RSA.  Now we need setup some configuration for Easy-RSA.  It’s essentially a set of scripts, so we’re going to edit a file with some shell variables in it, then source that file so the variables become part of the environment.  I’ll walk you through it.

Edit the “vars” file that’s now in your directory.  I prefer vi, maybe you like nano, but use whatever text file editor you want.  Leave almost everything as it is, but scroll to the bottom.  Change your country, province/state, city, org[anization], and email to be whatever you want, whatever makes sense.  Something legit maybe?  (maybe?)  You don’t have to change most of these things.

There are now the CN, OU and Name fields.  Don’t put spaces in these things.  Maybe that’s just superstition, but I wouldn’t do it.  These fields don’t seem to matter much unless you’re trying to organize a large set of keys across an organization…  If you’re reading this you probably aren’t, so you can just leave them alone.

. ./vars
./clean-all

That brings all those variables into the environment so the other scripts can use them, and clears out old config.

./build-ca
./build-dh

These setup the certificate authority certificate and some stuff for the Diffie-Hellman key exchange (look it up suckah!).  The first command will ask you a bunch of questions with default answers set to what you put in vars.  You can probably just hit enter right through them.  This next one is going to ask you some questions too, but again, enter will probably be fine.

./build-key-pkcs12 --pass [someUniqueNameForTheKey]

This step is going to build a certificate for your client to use, you’re eventually going to take what the command outputs and put it on your phone, tablet or laptop.  Again, each client needs its own certificate.  Replace “someUniqueNameForTheKey” with something related to the client you’re going to put the certificate on – something without spaces in it.

This step is going to ask you for two passwords.  The first is the “challenge password”.  “Leave it blank”, everyone says!  Fools.  Leave it blank, I say!  Fools run the planet, they seem to know what they’re doing well enough.

No really, leave the first one blank.  The second password is the “Export Password”.  I recommend putting in a password here…  Clients generally ask for this password the first time they use the cert, then don’t need it again.  The export password seems to prevent against someone finding the cert and using it, but don’t slow you down from using it.

Build as many certificates as you need.  Each of them will be stored in the “keys” directory as a “.p12” file.  One cert per client.

How Do We Setup The Server?

Alright, certs are built, now how do we setup our DD-WRT?  Login to your router, go to Services->VPN, and make that page look like the one below.  (Click on it to get a big version…)

DDWRTPage

Ok – that image explained where to get the values you need for the crypto settings, but there are a couple other values you should consider changing from my setup…  Literally, only two!  Easy stuff.

First – you need to change something in the first “Additional Config” line.  You need to make this line reflect your internal LAN.  You can find that info on the “Setup” tab (don’t forget to save your settings before switching over there!).  Take “Local IP Address” and “Subnet Mask” from “Setup”->”Basic Setup”->”Network Setup”->”Router IP” and put it in that first “Additional Config” line in that order.

Next – decide what subnet you want VPN clients to be on.  I recommend picking something weird like “192.168.8.0”.  This should be different from your internal LAN (see the previous step).  If your internal LAN isn’t .8.0, just use the settings I show in the screenshot.  To change your VPN client LAN, change “Network” on the VPN page, and change the third line of “Additional Config”.

What is “Additional Config” doing, anyway?  It’s telling the server to send any clients that connect (to “push” them) some networking information.  Specifically, it’s telling clients how to talk to the internal network and to use the router as the DNS server.

Save the configuration and apply it now.

We’ve got a couple steps left to finish the router configuration, but we’ll need some more information.  Specifically, we need to know what the router calls your “tunneling” network adapter.  This is a software-based network device that all the traffic is going to flow through.  It’s kindof a complicated concept, but it’s like a network connection within a network connection – like it a connection tunneling through your existing connection.

It’s easy to find though.  Go to “Administration”->”Commands” on the router admin page.  Enter “ifconfig” in the “Commands” box and click “Run Commands”.  This will refresh the page slowly and output a bunch of information.  Look for a block of text that starts with something like “tun0” or “tun1” and that has your VPN client subnet info near it.  It could be any number after “tun”.  Mine is “tun0”, so that’s what you’ll see in the rest of this tutorial.  Just replace every “tun0” with your specific “tun” entry!

While you’re here, also note what bridge network your local LAN is using.  This is probably near the top of the ifconfig output and will be called “br0” or something and will have your local LAN info near it.  You just need the basic device, not anything with a colon in it (your router will get colon cancer if you use the colonnaded one (that wordplay was hardcore terrible!)).

So, now we need to fix up the DNS server a little.  Go to “Services”->”Services” on your router config.  Enable DNSMasq, disable Local DNS, enable “No DNS Rebind”, enter “interface=tun0” in the Additional DNSMasq Options.  Remember – use the “tun” you got from the router, don’t just blindly use “tun0”.

Save and apply your configuration.

Now we need to setup some firewall stuff.  Go back to “Administration”->”Commands” and enter the following block of text in the “Commands” box.  We’re going to edit it a little before running it, though.

iptables -I INPUT 1 -p tcp –dport 1194 -j ACCEPT
iptables -I FORWARD 1 –source 192.168.8.0/24 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.8.0/24 -j MASQUERADE

First – change “192.168.8.0” on the second and fifth lines to be whatever you set your VPN client subnet info to.  Why does it have a “/24” afterwards?  This is a short way of specifying the subnet mask 255.255.255.0.  Hopefully you used that subnet mask with the VPN client subnet…  Otherwise you’re on your own suckah!  (If you used a different subnet, you can calculate the right “/” to put in there, it’s called CIDR Notation, and here’s a calculator for you)

Second – change the instances of “br0” and “tun0” on the third and fourth lines to reflect your router’s bridge and tunnel interfaces.

Run commands, save firewall, now the new firewall config should show up right below the “Commands” box.

Ok, so that took a while, but hopefully it was pretty much straightforward.  We’re done with the router!

Setup the Mac Client

Tunnelblick is not tough to use, and neither is the Android client.  Many OpenVPN clients use the configuration filetype “.ovpn”.  We’re going to build a version that will work for both Tunnelblick and Android, and all you’ll have to do is change the certificate file name.

I had to use a bunch of trial-and-error and Internet tutorials to figure this out and make it work, but I think the configuration below will work for most OpenVPN clients.

Make a file with the following contents:

client
dev tun
proto udp
port 1194
remote yourRoutersExternalAddress
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 1
reneg-sec 0
pull

pkcs12 clientKeyFileHere.p12

cipher AES-128-CBC
link-mtu 1570
auth SHA256

Change the line “pkcs12” to be the name of one of your client .p12 certificate/key files.  Change the line “remote” to reflect your router’s external Internet address – the address other folks on the Internet can use to talk to your router.  Save this configuration file with a name like “macbookConfiguration.ovpn”.

Alright – back to the Mac specific part!  Copy the ovpn and p12 files for your Mac to the Mac.  Double click the ovpn file.  Tunnelblick will open up and import the configuration.  Click “connect” in Tunnelblick.  It will ask you for the “export password” you put in when you created this client certificate – enter that.  Tunnelblick should connect to your VPN now .(Probably don’t try this stuff on your local LAN, although that might work just fine.  Probably try it at a nearby coffee shop with wifi, or on your neighbor’s wifi.)

That’s it.  Your Mac is setup and VPN’d to your home Internet connection!  Prove it by going to Google and searching for “what is my IP address”.  Google should give you the same IP address now, when you’re not physically at home but VPN’d there, as it does when you’re at home.

Setup the Android Client

Build an “ovpn” file in the same way we did for the Mac, but using your Android certificate.  Copy the ovpn and p12 files over to your Android.  Open “OpenVPN Connect” on your Android, and click the “…” up in the upper right.  Click “Import”.  Select “Import PKCS #12 from SD card”.  Browse to your p12 file and click it.  Enter the password.  Go back to the OpenVPN Connect home screen and click the “…” again.  Click Import and this time “Import Profile from SD card”.  Select the ovpn file you copied over.

Click “Connect” on the OpenVPN Connect home screen.

That’s it!  Your Android is setup!  Prove it using the google IP address trick we used in the Mac section at the end.

Something to watch out for – if you connect to the VPN while you’re on your cell network, then you move in range of a wifi network and intend to use that network, you must disconnect from the VPN, wait a second, and reconnect.  After reconnecting the VPN it should be running over the wifi network.

Conclusion

So, I hope I gave you enough detail and walkthrough to figure out how to setup your VPN successfully.  It took me a pretty significant amount of research and time to set the damn thing up, so hopefully I’ve saved you some time.  There are a lot of tutorials out there that cover parts of this setup, but this is the first I’ve seen that goes all the way start to finish explaining each step.

What if this doesn’t work for you?  Well, you can email me.  I’ll try to help.  Probably.  If I’m not busy.  Better – try to troubleshoot it.  This VPN is a system of systems, so lots of parts can go wrong.  Let’s walk through a few.

Troubleshooting

I got the server and clients setup, but neither client will connect to the server – Cool, I bet this is a server problem!  First step – remember that the server is your home router.  Is it working and connected to the Internet at home?  Did the router change addresses since you built your OVPN file (dynamic DNS services can help solve this problem, but that’s for a different tutorial)?  Can you ping your router while you’re not at home (you’ll have to disable “Block Anonymous WAN Requests (ping)” under “Security”->”Firewall” to try this, enable it again when pings work from the outside, because enabling this setting is a little more secure)?

Second step – use Tunnelblick’s “Log” tab to help you figure out what is breaking and where.  Some of the output is right there in the tab, some of the output is spit into a separate file that is referenced there on the log tab.  Search for the warnings and errors and Google them.  Here are some of the things this log can help you fix, in the order that you should check/fix them.

2.1 – Can Tunnelblick start talking to your home router, or does the connection break before that even happened?

2.2 – Can Tunnelblick start the exchange of session parameters?  This is where your client tells the server what kind of stuff it will accept, and the server tells the client the same.  Do you see that kind of exchange happening?

2.3 – Are the server and the client telling each other they can use the same session parameters?  In my experience, the client and server had to be specifying the exact same parameters.

2.4 – Is the crypto all working out?  Maybe the certificates are in the wrong place on the server…

The router also has a server log on it, and that can help too.  It will tell you some similar things.

I got the server and clients setup, but one of the clients won’t connect and the other will!

The problem probably lies with the broken client.  Maybe Googling stuff in its log file will help you?

One of the clients connects, but when I connect the second client it boots the first off after a short period!

You probably are trying to use the same certificate/key for both clients.  Don’t do that.

Saturday Ramblings of a Frustrated Cybernerd

This is one of those Saturdays where I’m finding it hard to focus on what I want to focus on.  Ok, so that’s a pretty regular problem for me on Saturday.  I’m trying to focus on programming for this volunteer activity I’m supposed to be leading in September.  I’ve got to build some software for the event, and make some decisions, and wrap it all up at some point.  It’s not too far from being done, and I guess this is the first time I’ve had to just sit and think a bit this week, so maybe that’s why I’m not too concerned about being unproductive, and I’m just letting my mind wander.

I’m sitting at this coffee shop on Broadway in San Antonio that’s beautiful.  It’s not my favorite coffee place, that’s in Dayton Ohio, and it’s dressed like this old timey comfy grandma parlor room.  With funky art.  No, this coffee shop is too modern for any of that.  But, there’s also this falling down burned out building architecture thing going on which makes me feel like a fucking outlaw.  Which reminds me of old times.

And makes me remember how much I like being rebellious.  Which is basically the opposite of what the Air Force has me doing now.  But which I got a taste of on a recent visit to San Francisco.

My thoughts keep turning, over the last weeks, to the thought of kicking this AF thing and starting my own company or something.  I don’t know what it’d do yet, I guess that’s the only thing holding me back, but I’m pretty sure it’s only a matter of time.  Thinking about the problem this much means at some point a piece of my brain will kick over and find the answer – what I should start a business doing.  What’s the thing the World needs now, with computers and shit, that people or businesses would pay for?  It needs to be new.  I want to invent some shit again.

The idea of inviting some of my college and high school buddies to come invent some new shit with me is so attractive.  In my brain it’s days and nights of programming and designing and breaking shit and fixing it.  I know there’s also this hustling piece of starting something like that, the marketing piece.  I don’t have that on lock-down, and don’t have anybody in mind, but I bet I could find a partner to manage that side.

The idea of moving out to the left coast is so attractive.  But I look around San Antonio and see places I could move into, too.  Boston.  The idea of setting up something that could be worked anywhere is probably more valuable to me.  Something with a physical location of wherever we’re at.  I’d become a nomad during the day, or find some maker-shop or incubator to work at.

It’s not that there’s anything wrong with being in the AF, or even doing what I’m doing now.  I have my hand in how AF cyber is developing, which is valuable to me.  However, it feels like it’s this big cruise ship and my hand is out a port-hole dragging in the water alongside the ship, trying to turn it a little.

Maybe the worst thing is that I’m not sure which way I’d want to turn it.  Some of the things that are clear to me that we need to be doing are being worked already, in small ways.  They’re great!  Fundamental things like, let’s thing about our security differently!  AF folks have great ideas and are doing things that are the same as what the really smart security folks are suggesting.  Things like – assume bad guys are in your network, now do security.  In a scenario like that, the naive solution is to kick the bad guys out.  It’s naive because once you succeed at kicking them out you must then think, “ok now it’s time for security again!  What are our assumptions?  We assume bad guys are in our network!”  It doesn’t stop, and it shouldn’t.  The smarter thing is to figure out how to make sure the bad guys in the network don’t cause serious problems.  Sometimes that involves kicking them out at a specific time and place, and only with the expectation that the kicking-out will last for a set amount of time.  The smartest thing is to design and build networks in which the assumption (bad guys are in the network) is true to a much lesser extent.

The Air Force calls that “smarter” thing mission assurance, and many are trying really hard to do it.  It’s a great freaking idea!  It’s probably one of the long term solutions, and we’re mature enough to be getting that.  The problem is it’s a big freaking organization – the entire military really – and we have money but not enough people!  To the military money buys contractors, but no other type of person, and we cannot take care of our contractors like we take care of military and civilian.  Like, by law.  The motivations are all fucked up.  The individuals that contractors bring on are great, but we can’t use them like normal people.

The solutions we come up with, where I sit, are so focused at making things work across the whole AF.  When we get something that works in a small place well and it’s what we need it’s like getting lucky.  The right folks were in the right place with their small organization and could do good stuff at that level.  Then the military says, how do we make this work everywhere?  How do we institutionalize this?  I think the answer is to take all the shit that’s tying peoples’ hands and cut it, and make sure good nerds are in charge of these organizations, but in general that’s the opposite of what happens when institutionalizing something.  Efforts to educate cyber leaders and educate their followers are necessary, but not sufficient.

We aren’t working on that “smartest” solution at my level.  Not in any strategic way, just by slowly improving the shit we’re working with to try to get there.  That’ll work eventually, but it’ll be a while.  That was basically my last job, take what we have and make it better.  Well, we need a strategy for a full revamp.  It’s time.  We need a huge picture of what the military cyber enterprise (people, networks, missions) needs to look like in 10 years based on all the good shit we know now, without compromising due to cost or money already spent or projects we’ll kill.  Without compromising due to people who want their equipment to do unsafe stupid shit.  Then we need to come up with the roadmap to make our current investment and projects fit into that ideal.  Then we need to get some really big General that understands why compromising due to morons is _so_ bad, and to back it.  Most of the stuff we do or are doing will fit into it, because it’s good stuff, just seemingly lacking a vision to fit into.

So, maybe I am in the right place.  Maybe I need to focus this frustration that kinda motivates me back as a call to arms for my fellow frustrated AF smarties.  I’m fucking out there with fun sometimes, and I can brief the shit out of some stuff, maybe I need to take time at work to focus and motivate people.  Maybe I could make the front staff seem less intimidating, and tell people about what’s going on, and tell people what I think we need to do about it all at the same time.

Yup, I could probably do that.  It would probably be fun.  I’ll email some folks and try to set something up.  Maybe it’ll keep me sane.

Engineering the Van Allen Belts

This article proposes a pretty crazy sounding idea – remove the Van Allen Belts.

Simplified Explanatory Summary:
The Van Allen Belts are a natural phenomenon, electrons and protons flying around the Earth at high speed. Electrical current is essentially electrons moving around, so when astronauts or satellites pass through these regions the effect is shocking. Passing through the proton regions is even worse because they’re comparatively mass-ive. Electrons and protons are normally flying around in space, but these ones are trapped by Earth’s magnetic field.

Some scientists figured out a way to pull the electrons down into Earth’s atmosphere by emitting low pitch radio waves, but there are some problems. The low pitch waves get trapped close to Earth by our atmosphere. Actually, they get trapped by the same part of our atmosphere that let’s us hear AM radio when you’re very far from the station. The scientists think they could emit the radio waves from satellites, but it’d be tough.

One scientist chick thinks we can emit different radio waves from satellites to take care of the protons. She’d also pull them down into the atmosphere. It’s all too early to tell if it’d work, and what the effects on earth would be.

What if the belts protect Earth from some solar radiation? What if they protect us from some kind of cosmic radiation? By removing the belts we’d solve problems for satellites and space travel, but we might cause other problems. Scientists think it’s unlikely, but also say that it’s too early to tell for sure.

In any case, it’s cool to think that we might build what is essentially a dam in space, not for water but for invisible particles that cause trouble in modern life.