Software defined lighning detector?
I was recently looking at how lighning detectors work. Mainly they compare S-meter spikes to a threshold level in a small band around 500KHz. This works but with problems due to local RFI which can confuse things. It occurred to me that I can tell very easily looking at a waterfall when lighning makes a brief hit to the noise floor which spans more than a decade of frequency. That means that software looking at signal levels on several frequency diverse filters and detecting via a time correlation between events across the filters placed in different parts of the lower HF spectrum would probably be a more reliable and robust way of detecting. If one of the filters happens to fall on a strong local RFI source then the time correlated detection subtractis it out so to speak. Software can also be smart and make use of known quantities such as variations in D-layer adsorbiton in day/night. Software knows time of day and GPS informed software knows sunset/sunrise so all of this data can probably get a much more informed idea of how close lightning stikes are. Could a KiwiSDR extension be a good platform for such a technique? Comments invitied.
Joe
Comments
The main problem with the KiWi for this purpose is the very wideband nature of the receiver, and under conditions of nearby lightning, the coherent nature of the energy pulse often tends to drive the KiWi into ADC overload.
This is less problematic with more distant storms, but even some of those can be quite strong at times.
It would be interesting to see if the TDoA function could locate spasmodic lightning pulse though.
Regards,
Martin
Hi Martin
I'm suggesting that the wideband response is a feature which can be leveraged in this case. A typical lightning detector is a narroband affair with a simple level threshold detection which is prone to many things that can cause a false positive so to speak. Local noise RFI or a strong local in band transmitter etc. On the other hand an SDR with software which looks for a time correlated jump of the floor across several filter windows running in different parts of the spectrum offers immunity from things which might affect a single narrow detector. Software can also look for an overload on the ADC as a feature of the detection perhaps to indicate a distance threshold. That would be subject to antenna efficiency obviously but could be an available option for configuring the detector.
Best regards...Joe
Edit: The other part I was suggesting is that due to D-layer adsorption an ADC overload during daytime is probably a much closer strike than one which happens at night due to better propagation during night time. I think an SDR offers a lot of possibilities to improve lighning detection.
Hello Martin and Joe,
I found this discussion while googling to see if the KIWI sdr might be programmed to be used in this way. I have been looking at the Blitzortung lightning detection network https://www.blitzortung.org/en/live_lightning_maps.php?map=10 and on looking into the hardware, found it very expensive for what it is.
The KIWI sdr probably has all the hardware to do the same job as the specialised Blitzortung system which I think simply detects pulses from lightning of the right characteristics, and sends a message to a central server with an accurate timestamp and details of the lightning signal. This allows the server to accurately pinpoint the lightning strikes by using the time of arrival data for each strike from many stations.
I was wondering if a suitably programed extension might do the same job and be added to an update for the KIWI SDR. Very cheeky, I know.
I am quite certain of three things:
I do know however when running my KIWI sdr at 178khz AM, which is empty around here for about 10 KHZ, I detect lightning strikes here in the north of the UK, that very few nearby stations on the Blitzortung world wide network pick up. This thing is incredibly sensitive on my forty meter low level loop, now that I have matched it better with a transformer at the KIWI antenna input. My loop terminates with about 15 turns on a ferrite ring and is a true loop with both ends of the loop joined together electrically. This probably gets rid of a lot of local electrical noise such as adsl and vdsl which used to plague my system. The other side of the ferrite ring has a five turn coil which terminates both sides on the antenna input of the KIWI.
Tonight, I am picking up lightning strikes from the Middle East about 4000 miles away that other UK dedicated lightning detectors are not seeing. I hear the rasp on the KIWI and then about three seconds later see the detections on the lightning network from detectors in central Europe and the Balkans. I can also hear the crashes from strikes in the Americas - though they are quieter.
Regards
Tony G0BZB
The amazing vlfrx-tools from Paul Nicholson probably come closest for this application. He has already used it to set up a lightning detection network. It uses GPS timestamps and the sound card as a vlf receiver for TDoA/TOGA.
http://abelian.org/vlfrx-tools/notes.html#Lightning%20location
Wow - thanks for the link HB9TMC. That is a process of serious complication.
Hello everyone,
I now came across this thread while researching for my dissertation and felt compelled to chime in, as I find this idea of a software-defined lightning detector very promising.
Introduction
The concept of upgrading the current lightning detection systems to align with today's technology levels is both timely and required. Compared to the limitations of existing systems like Blitzortung (or many other commercial networks), the innovation potential with the use of SDR is immense.
The current approach taken by most lightning networks focuses on processing individual impulses. However, I believe the future lies in processing signal fragments. The minimum length of these signal fragments should be 500ms or more, with a bandwidth of at least a few hundred kHz. This approach offers a more physically and scientifically relevant description of lightning. I tried to explain that necessarily in my article: https://amt.copernicus.org/articles/16/547/2023/
Implementation
From my perspective, the challenge of localizing lightning strikes is not very hard. I've prepared a relatively simple notebook that demonstrates how to localize lightning strikes from signal fragments: https://github.com/ODZ-UJF-AV-CR/CRREAT_cars/blob/master/VLF_lightning/VLF_location.ipynb The real challenge lies in how to present the results in a relevant manner on the map and to implement a scalable solution.
Given today's computational power, it's sensible to design the calculations for GPU processing, as this problem is highly parallelizable. With up to 1,000,000 signals per day, data compression becomes crucial to reduce data flow and improve response times, as the bottleneck is likely to be data transfer speed, not computational power in the case of worldwide deployment.
Conclusion
Based on my research from a few past years, I fully support this idea of a software-defined lightning detector. The focus should be on processing signal fragments with an appropriate length corresponding to lightning duration and bandwidth and leveraging GPU processing for scalability.
The next step is to check the possibility of extracting the signal fragments from KiwiSDR receiver stations. The fragments need to be generated at the station side from the circle buffer, based on a trigger (e.g. energy of signal - pulse width and length). That is needed because the required signal fragment bandwidth is very likely to be wider than the usual data transfer speed from the receiver.
Christoph has done work with piecing together (relatively) wideband output from the Kiwi to measure ionogram chirps: https://hcab14.blogspot.com
Finally a use case for my 10 Gb/s internet access 😁