This page describes how my aurora application works. The application’s page isn’t really self-explanatory, it is more about getting as much relevant data to me in a space that will fit conveniently on my iPod Touch’s display.
First of all, it is fairly specific to my area; it takes into account the local NOAA weather data, including visibility, cloud decks, humidity, and temperature. This data is retrieved from NOAA at five minute intervals, which is sufficient to catch weather updates in a timely manner. Usually, they update once an hour, but from time to time there are intermediate bulit-ins that the application catches.
I’m considering making the cloud data non-blocking, because the instrumentation that NOAA uses to determine cloud coverage does a very poor job of it. The instrument only has about a 30º field of view straight above the weather station, so it only takes a small cloud bank in some circumstances to get data from NOAA that the cloud coverage is 100%. I’ll play that one by ear for a while. At the moment, only 100% coverage blocks notification (notification is explained below.)
In addition to the weather, I track the altitude of the sun and moon, and also the phase of the moon as these are critical to determining visibility of any aurora. These are also updated at five minute intervals, though not at the same time the weather data is fetched;
Finally, I track the data output of both the primary and secondary GOES geostationary satellites that report 1-minute interval geomagnetic field data in nT (nanoTesla.) When the earth’s magnetic field is disturbed, auroras are most likely to manifest. I do this every five minutes as well.
So at one, two and three minutes, I fetch GOES, NOAA data and generate ephemeral lunar and solar data. At four minutes, I build a new graph from the GOES data, and at five minutes, I run the notification process. All of this is entirely independent of the web page, driven by the Linux crontab. Loading or refreshing the web page doesn’t force any any data retrieval, it just looks at the most recent collection and reports it. This way the page is low demand for me, and cannot abuse the data sources should it be loaded and/or refreshed more than once every five minutes.
The application itself will send a text to my cellphone if all conditions are favorable (I bet you were wondering why I had it watching the sun… now you know. I don’t want to be notified of an aurora during lunch when I can’t see it… that’s just frustrating.) So I can watch it, or not, and it’ll still let me know if things look really good.
If you click on the link entitled “Notification State” at the bottom of the page, you’ll be shown the state of the various components of the texting/notification code. A (+) means that the parameter is favorable for auroral viewing; a (-) means that the parameter is blocking viewing, or highly unfavorable, and a (o) means that the parameter is considered irrelevant for some reason. Examples of this would be if the moon is half full, which would be too bright for almost any auroral viewing, but it is below the horizon — so the phase is irrelevant at the moment; another is if one satellite reports large geomagnetic shifts, then the other reporting a small shift will not block notification.
Each parameter indicates the threshold at which it switches from blocking to favorable. As the page is fairly new (I wrote it in early 2010), I don’t have a lot of experience with the Δ nT thresholds yet; 45 is a number I picked after going out at 40 and seeing the aurora only as a vague glow on the northern horizon. The Δ parameter is the distance between the minimum and maximum nT readings in the last two hours, basically it reports the maximum steepness and amplitude.
I may notch it up yet; and I’m also considering using the closing distance between the maximum and minimum as a multiplier, as it would also indicate steeper waveforms. I’ll have to see what kind of graph corresponds to what kind of aurora first, though.
Sometimes the satellite data is unavailable; in that case, the graph line for that satellite will turn green and hold the previously measured level, if any. If there is no data for two full hours, the line will fall to zero and stay there until a valid measurement is retrieved.
The application is written in Python, and uses two libraries. The first is EPHEM, which is a pretty fabulous astronomical library; the other is PIL, the Python Imaging Library, which gives me a convenient and easy way to create the graph.