System Operation
The System comprises of a number of detectors hosted by individuals and the radio club around the Brisbane area together with and a couple of small servers located in a local data centre.
Some detectors have been built and encased - also mounting a nice LCD touch screen display (Thanks to David VK4ZF), while others are simply bare board, some are display-less, snugly snapped into the same plastic bubble case that the STM32 processor board arrived in from the distributor!
The detectors are hard wired into a local Ethernet router (no WiFi), as the data burst speed from the raw sampled packets when a detection came in was thought to be too fast for many domestic Wifi installations.
A daughter board was designed (the ‘LightningBoard’) using KiCAD. VK4YA couldn’t resist adding a few extra features such as WiFi and a precision pressure monitor - even through the current embedded software may not take full advantage of them.
Each detector uses an Automatic Gain Controlled front end and RF bandpass filter to listen to the signals and noise that arrive down the antenna into the LightningBoard. The processed analogue signal is converted to digital samples at just over 2M samples per second using three interleaved 12 bit Analogue to Digital Converters located on the STM32 board.
The embedded detector software runs a Z-test moving average algorithm looking for signal excursions that are above the floating average noise floor.
When a signal excursion is detected, the detector sends the entire sampled sequence (a packet or packets) to the middleware host which is running at a local data centre.
The middleware server takes all the near real time ‘excursion’ packets from the detectors and looks for a correlation of a transient signal in each received packet. If the correlation makes sense considering the min and max allowable speed of light delay between detectors due to their distance apart, and provided there are at least three detectors agreeing, a position fix and confidence level is computed (if possible).
The middleware also relays the raw packet feed to any other host that may be running correlation code. We have used the technique to run multiple copies of the middleware with slight parameter variations, so as to try and determine the optimum values for the most reliable detections.
If a successful correlation is made, the middleware computes the best position of the detected signal. Implementing an algorithm to compute the position was a bit too difficult for VK4YA so the system cheats and uses an iterative numerical method (which seems it can produce credible results even so).
VK4PLY is working on a Levenberg-Mead multilateration algorithm which we’ll run on another small server to determine the strike position in a more conventional way; it will be interesting to compare the results.
This information is passed to the Discord Bot and to the second server which runs a relational database and the Grafana web server.
