The Detectors

The detectors use a STM Nucleo32 F687Zi development board as the main CPU platform. This 32 bit ARM based CPU runs at 206MHz and has adequate memory to support two banks of Flash ROM. We utilise this to provide on-line software updates without the user having to be involved. The board costs around AU$40.

The onboard peripherals consist of a very rich multitude of devices, including comms, timers, ADC’s and Ethernet, USB etc. Our ‘Lightningboard’, a piggy-back board of our own design simply contains an analogue filter and a programmable gain amplifier along with the various connectors for the GPS etc.

The system is developed using the free STM Workbench program suite which is an Eclipse based IDE. Fortunately, the STM board has built-in JTAG debugging via USB - this is both very convenient and necessary!

The software which is witten in the ‘C’ language, is run under FreeRTOS, which is a open source Real Time Kernel. Low-level Drivers and hardware abstraction API’s, together with 3rd party integration are provided by STM as part of the IDE environment. The Ethernet stack uses the open source LWIP.

The optional 3.5” LCD display uses a Nextion resitive touch type. These are serially driven using asynchronous comms, and they have their own command interpreter and protocol stack. They require little STM 32 CPU overhead, and although a little more pricey than bit-mapped LCD’s, they are good quality and offload a lot of the design and development work that would be otherwise required.

The Middleware

The middleware, running on a low cost Virtual Private Server (VPS) located at a local datacentre in Brisbane, listens for packets being sent by the detectors. These packets consist of two sorts; Status and Samples.

The output from the middleware are predominantly JSON feeds and log files. These are used by the other user-oriented programs and applications to inform.

Obviously, developing software without having access to a local on-demand lighting storm was a bit tricky! To overcome this we use a combination of in-house software simulators and analysis tools. We also found that a good old-fashioned piezo-electric lighter came in quite useful for inducing simulate lightning signals into the Lightningboard antenna!

One of the software tools we use is shown below - this was used to generate the correct Time of Arrival between detectors of a simulated signal waveform.

Time of Difference of Arrival TDoA

The Database and WEB GUI

A SQL database is used as a data capture and source. It is used to feed the End-user applications such as Grafana. This, and Grafana run together on a separate VPS in the same datacenter as the middleware server.

Grafana

The Future

We have collected quite a bit of raw data from several local thunderstorms over the last years and months. The detection system seems to work well enough in the main, but there are still plenty of things that we want to do to improve the system:-

  1. Implement a more classical algorithm to determine strike locations from Time-of_arrival datasets.
  2. Analyze the data to try to figure out how to recognise a ‘strike’ waveform so that we can ultimately implement this at the detector itself. Then we need only send summary data to the middleware rather than whole packets of raw data. Analysis
  3. Upgrade to a newer and faster STM board - using dual processors etc.
  4. Utilise the Lightningboard’s WiFi peripheral / co-processor.
  5. Interface to other ‘Weather Station’ type of peripherals.
  6. Figure out how we can compare the strike location data produced with where the strike actually was.