Nature is vast, and present a diverse array of interesting phenomena. Lightning is one of them, and in today's post, I'm going to discuss a few ways a lightning locator network could, and how it should not, be implemented.

Somewhere before 2006, when I began researching how to detect and position lightning, I stumbled upon blitzortung.org, which, to my understanding, at the time collected its data mostly from primitive lightning detectors that guessed and approximated a great del.

Portable detectors

These detectors, which were not used in the network, are mostly sold as personal lightning warning devices. They detect nearby lightning strikes, and show an approximate distance. The distance is calculated from the strength of the received noise, compared to a statistically average level. The received noise is stronger if it was produced by a large discharge, and weaker if the discharge was small. That’s one level of uncertainty, and then you have to keep in mind that rain, trees, walls and buildings between you and the detector will affect the strength of the signal. One could compare the approximated distances of several such detectors, and kind of try to triangulate a strike location based on that, but the inherent inaccuracies would make the result pretty worthless. Personal, portable detectors are, at best, toys and party tricks.

"How could the precision be improved?", I thought to myself.

Two ways:

Either triangulation based on time of arrival, or triangulation based on direction.

The first method requires exact position and extremely exact timing, and was expensive.

The second method requires exact position and bearing, but less much exact timing. One major drawback is that resolution decreases considerably with distance.

Lightning is fast. Like really fast, but not nearly as fast as light. Light is really, really fast, and the electromagnetic noise created by lightning travel at the speed of light.

Light travel at a speed of 299,792,458 meters per second, give or take a few decimals. That’s almost three hundred million meters per second, or just over a billion km/h, which translates to about 671 million mph. Not even the ThrustSSC can keep up with that.

Going to the other end of the scale, the speed of light is 299,792.458 meters per millisecond, or 299,792458 meters per microsecond. If you sample the lightning detector one million times per second, you get a resolution of 300 meters, and it would probably make little sense to increase the resolution more than that, bearing the sheer size of lightning bolts in mind.

Synchronizing clocks to a precision of less than one microsecond is not the easiest thing to do. Using the DCF77 signal with low cost parts, you get a precision of about two tenths of a second. That’s the time it takes light to travel 60,000 kilometers. Better hardware could get a precision of 4 to 44 microseconds. That’s better, but a resolution of 1.2 to just above 13 kilometers is not practical.

NTP has a practical precision of "tenths of milliseconds", which in this case mean it’s not nearly enough.

GPS would provide a usable time resolution, but the price of a GPS module in 2006, let alone at least three of them, to form a usable network, was not within my experiment budget.

Hence, I decided not to try a time of arrival approach, but rather directional triangulation.

Direction finding

This is where I’m going to become somewhat theoretical. I did assemble some experimental hardware to evaluate my theories, but that’s as far as I got. Direction finding has a few drawbacks, but also a few advantages. The resolution, how accurately the direction to the lightning strike can be calculated, decrease with the distance to the strike. My initial guess was that I might be able to get eight or nine bits of direction out of a setup that involved two loop antennas at right angles, either the wound wire type or ferrite rod antennas, suitable for about 300 kHz.

When lightning strikes, electromagnetic noise is produced. This noise seem to be strongest around 300 kHz for cloud-to-ground strikes, while more modern detectors monitor a larger span of frequencies in order to increase accuracy and detect cloud-to-cloud strikes.

With two directional antennas at right angles, both antennas receive this noise, but different amounts of it, one receiving the strongest signal while the other receives the weakest, and vice versa. I was going to connect these antennas to simple tuners and amplifiers, and then into the line input of a computer, sampling a stereo signal at 48 kHz. When the static received peaked past a certain threshold, the computer would compare the amplitude of the stereo channels, and compute a direction from that. It is my understanding that this setup should be able to calculate a line through the detector, and give two possible lightning directions, 180 degrees from each other. This is why you need a network of detectors; one detector can not distinguish between the two directions on its own. It could guess, based on polarity and probability, but never be certain. It takes at least three detectors to be able to calculate every possible strike location.

These antennas have to be precisely aligned. My theory, though, was that if you have three stations with exact alignment, new detectors could be added in a setup mode that did not use the new detector’s data for strike location, but rather for figuring out which way the detector is pointing, using the known detectors’ data compared to the new one’s.

Given the low sampling rate of the detectors, and the blinding speed of light (it would travel a tad longer than six thousand meters between each sample), I thought NTP would give enough temporal accuracy. One problem that Blitzortung had with the earlier, direction finding network was that the stations used only had second resolution, but lightning could strike several times per second. My take on that was to use time stamped data, and work out individual strikes from that. With knowledge about where the detectors were located, and that the signal would be displaced one sample every 6245 meters, it should be possible to work some pretty impressive miracles on the data.

One thing I didn’t foresee, but I’ve told would be a problem with directional detection, is reflections. Electromagnetic pulses reflect off things, be it mountains, buildings or different layers in the atmosphere. The principle is the same as when one shine a flashlight onto a wall; what arrives at one’s eyes is the photons emitted by the lamp, but reflected off a distant object, making it seem that they were emitted by that object. This would be a problem regardless of detection method used, and would have to be handled accordingly.

All of this is long since obsolete.

Time of arrival

Time caught up with this darling while I wasn’t looking. The price of GPS modules has dropped to a point where it more or less would be a crime not to go for the time of arrival approach, like Blitzortung did. The resolution is better, and the distance to the strike matters much less. Plus, it’s really cool to have a network of satellites being an integral part of your lightning locating network!

Finishing off

It’s easy to believe that finishing off one’s outstanding experiments prematurely would not take very much time. Just take what there is, and dump it on the public scrap heap. There, done, next!

I could have done that with this experiment, but honestly, who’d want to read 'I once planned to build a lightning detection network, mostly to see which level of accuracy I could achieve. I never did, and the existing networks have shaped up and become much better now, anyway.'? No, I want to explain some of my reasoning and the history of the experiment. That puts my ambition level somewhere between ‘just dump it’ and my friend Christer Weinigel, who use some of his spare time to actually complete what he’s been working on.

In some cases, explaining concepts is easier if you can illustrate your thoughts, but finding tools for creating a quick and dirty lightning detection animation wasn’t all that trivial. My first thought was PIL, but it’s non-trivial to make circles with walls thicker than one pixel there. I wanted to antialias my circles, and antialiasing is another thing PIL isn’t all that good at.

ImageMagick probably would have done the trick, but its command lines tend to become mind-numbingly long.

GD was next on my list of possibilities, but I didn’t want to install PHP on my somewhat cramped computer.

In the end, I went for SVG files, created by a Python script and converted to PNG by rsvg-convert. Pretty easy and straightforward. When I decide to learn to animate SVG, I could re-arrange that script, and get a proper animation out of it, but I have to save some learning for the future.