Perhaps it’s just one of those things adults dream up to entertain their children, but were you ever told to count slowly the time between seeing a lightning flash and hearing the rumble of thunder? The idea was that the count would tell you how far away the storm was, but from a grown-up perspective the calibration accuracy of a child saying “one… two…three…” in miles seems highly suspect. It’s a valid technique though, and it can be used to monitor thunderstorms by the radio emissions created through the electrical discharge. It’s an area the SAGE project has been working in, and they’ve posted some details including a fascinating run-down of the software techniques , on how lightning can be detected with an RTL-SDR.
A lightning strike produces a characteristic wideband burst that shows up in the time domain as a maximum point that can easily be detected but could also be confused with radio interference from another source. Thus after identifying maxima they zoom in and perform a Fourier transform to spot the wideband burst. It’s all done in Python, and the pleasant surprise is how straightforward to understand it all is.
SAGE are working on a distributed sensor network, so we hope this work might one day give us real-time open lightning data. The FFT approach should ensure that it won’t be fooled by false positives as a traditional detector might be.
Via RTL-SDR.com.
You will have much better luck spending some dough on an upconverter and listening in around the 100kHz mark.
I know it increases BOM cost, but it’ll result in some MUCH clearer peaks.
Don’t even need an upconverter, that RTL-SDR supports direct sampling.
You would have better luck plugging a long wire into your microphone port and using a spectrum scanning tool that takes microphone input. You will get large spikes across the entire range, pretty hard to miss.
Do you even need the RTL-SDR? I don’t know if it would be as clear of peaks as at 100kHz but doesn’t lightning also produce a lot of RF at frequencies you could pick up with a soundcard?
I’m thinking I wouldn’t want to subject my onboard sound chip to all the static electricity of an antenna connection but I might use one of those $3 ebay usb sound devices. For bonus points crack open the shell and remove any bypass capacitors on the mic input to receive higher frequencies than audio.
A couple of back to back diodes across the input wouldn’t be a bad idea either.
Time-domain manipulation of data is a trick often used in RF land to clean up measurements. Keysight has a good guide on it here: https://www.keysight.com/us/en/assets/7018-03478/application-notes/5991-0420.pdf
To sum it up:
We’re all familiar with the idea of taking a time-domain signal (in this case, say a .wav file), doing a FFT on it to get into the frequency domain, applying some kind of filter (e.g. band-pass) then doing an IFFT to get the back into the time domain. Any EQ you’ve used does something like this.
Now, since integral transforms have the property of duality, anything we do in the time domain, we can also do in the frequency domain. So in RF land, one takes a frequency-domain measurement (your frequency sweep), then does an IFFT to get into the time domain. Your time domain signal really does correspond with the frequency domain data. You can apply a window function (see the PDF) and cut out the unwanted low- and high-frequency components…then do a FFT to get back into the frequency domain and, voila, filtered signal. It works wonders!
The trick will be getting decent time hacks for the RTL-SDR output – the device itself probably has deterministic timing, but USB and the USB stack certainly do not. So you’d really be stuck with a “lightning stroke of apparent energy X at point Y occurred at time Z (with precision of 1/10th second, maybe)”
So you really can’t do stroke location, other than by, perhaps, comparing relative intensities, but then, you have antenna differences to worry about.
OTOH, if you solve the sync problem, then recording around 80 MHz with a moderately dense network of RTL-SDRs would let you actually visualize stroke development. There’s some work done in Huntsville, AL on this, oh, 10-20 years ago (and probably still going on)
Boy I sure would like to get back to Huntsville again… As a civilian this time. Only time I spent outside of Redstone Arsenal was frantic drinking and one of my favorite tattoos.
A gps module can provide an accurate PPS , pulse-per-second , for global time sync, and if the sdr is recieving constantly, it could be as simple as a microcontroller taking the PPS pulse and emitting it as RF that the sdr can see, but that won’t be mistaked as a lightning strike. :-)
Yes – I’ve actually done that – the typical 10 microsecond pulse is easily detectable. The trick is finding the right coupling components, etc.
Even better is if you mix/gate the pulse with an oscillator to get a “tone burst”.
> SAGE are working on a distributed sensor network, so we hope this work might one day give us real-time open lightning data.
I haven’t compared the technical details but I think there already is one:
https://hackaday.com/2014/06/29/a-cloud-of-lightning-detectors/
https://www.lightningmaps.org/about?lang=en
https://www.blitzortung.org/de/cover_your_area.php (German)
You can get real-time lighting strike data mapped (and with sound effects) along with the rest of the weather stuff on windy (dot )com. There’s even an acoustic feature that shows an approximation of where the thunder goes which is pretty accurate to my offhand observations here in the flatlands.
They are using the data from blitzortung.org
-> https://community.windy.com/search?term=blitzortung.org&in=titlesposts
-> https://community.windy.com/topic/6605/real-time-lightning-strikes-on-windy-com
but yes stumbled over windy.com on HaD before and it looks awesome.
Hey! I wrote that :) Yes.. I just bought an upconverter to look at lower freqs.. One amazing thing about the RTL-SDR is it gives you 2Ms/s for $25… That is one thing that makes it attractive as a cheap sensor …
BTW more on Sage here:
http://sagecontinuum.org/
This is probably a good time to mention it’s really about 5 seconds per mile between flash and bang, not one. You’d think people would have gotten this one right more often that not as it gives the kid some math to do.
I’m surprised more people didn’t correct this. With the speed of sound a little over 1000 feet per second and a mile being little over 5000 feet, counting up seconds from the flash to the boom (one one-thousand, two one-thousand, three one-thousand, or Mississippi, or whatever) then dividing by 5 gives a pretty decent estimate of the distance to the lighting.
“but from a grown-up perspective the calibration accuracy of a child saying “one… two…three…” in miles seems highly suspect”
Thats why you tell them to start at 21, so they have to say more, meaning they take longer to count (read: are closer to actual seconds) Also it actually involves basic division, the sound of thunder travels roughly 1km in 3 seconds and 1mile in 5 seconds, its not 1 second equals one mile, how did the article writer not know this?…
You don’t have them count in binary? 1, 1 0, 1 1, 1 0 0, 1 0 1….
If you have two RF inputs one above the other but one is surrounded by a 3D printed cylindrical cage that is metalized and has the holes varying as you travel around the circumference, then the difference in the spectras gives you the direction of the strike.