The AS3935 “Franklin” from ams/ScioSense is a single-chip RF lightning detector, and it is the only sensor on a typical build whose output has no home in the APRS weather format at all. It is also the one most likely to mislead you, so it gets its own page.
How it works
A loop antenna tuned to 500 kHz feeds an analog front end. A watchdog monitors that front end, and when activity crosses the configured threshold it wakes the lightning algorithm block, which validates the signal pattern, calculates an energy value, rejects man-made disturbers, and produces a distance estimate.
Range is out to roughly 40 km, and it sees both cloud-to-ground and intra-cloud flashes.
Register configuration
| Register | Field | What it does |
|---|---|---|
REG0x00[5:1] |
AFE_GB | Gain. Use the outdoor preset (0x0E); indoor is 0x12 |
REG0x01[3:0] |
WDTH | Watchdog threshold. Raising it rejects disturbers, at the cost of distant lightning |
REG0x01[6:4] |
NF_LEV | Noise floor. Auto-adjust: raise on repeated noise interrupts, lower after ~15 s of quiet |
REG0x02[3:0] |
SREJ | Spike rejection. Higher is more robust; default 0x02 |
REG0x02[5:4] |
MIN_NUM_LIGH | Require 1, 5, 9 or 16 strikes before interrupting |
| n/a | MASK_DIST | Mask disturber interrupts |
REG0x08[3:0] |
TUN_CAP | Antenna tuning capacitor, 0–120 pF in 8 pF steps |
LCO calibration is mandatory
The antenna has to resonate at 500 kHz ±3.5% or nothing downstream works.
Set the IRQ pin to output LCO divided by 16, measure the frequency, and step
TUN_CAP until you read 500 kHz / 16, about 31.25 kHz. Then calibrate the RCOs
with CALIB_RCO.
A multimeter’s frequency mode is nowhere near accurate enough for this, so use a scope or a frequency counter. A bad LCO tune cascades straight into RCO calibration failure, and the symptoms look like a broken sensor rather than a tuning problem.
Interfacing
Prefer SPI. The I²C interface has known errata, and most experienced builders end up on SPI for exactly that reason.
The IRQ pin asserts for one of three reasons: noise floor too high,
disturber, or actual lightning. Wait about 2 ms, then read REG0x03[3:0] to
find out which, and if it was lightning, read the distance from REG0x07 and
the energy from REG0x04 through REG0x06.
Known failure modes
- False triggers from fluorescent and LED lighting, motors, chargers and nearby electronics. Disturber rejection is good, not perfect.
- Distance jumps as the algorithm revises its estimate of the storm front.
- Energy is relative, and comparing it between sensors is meaningless.
- “Storm out of range” and single-strike readings mislead badly in isolation.
What it is, against real networks
| What it gives you | |
|---|---|
| AS3935 | Presence, approach and rough distance, from one point |
| GOES GLM | Satellite optical, continuous CONUS coverage, ~8 km resolution |
| NLDN / ENTLN | Professional ground networks, sub-km location, high detection efficiency |
| Blitzortung.org | Crowd-sourced time-of-arrival network, located strikes |
An AS3935 is a single-point, hobby-grade approach detector. It is genuinely useful and it is not a located strike. Say so wherever you publish its output.
Using it responsibly
The honest case for a local AS3935 is that it is low-latency and connectivity-independent. It can confirm nearby activity from the ground, it can trip a few seconds before satellite or network data arrives, and it keeps working when the internet is degraded, which is precisely when severe weather has knocked it out. That is the on-site sensor model that commercial systems like Perry Weather are built around, driving the familiar 30-minute all-clear countdown.
The NWS 30-30 rule is the reference behaviour: take shelter when flash-to-bang is 30 seconds or less, roughly 10 miles or 16 km, and wait 30 minutes after the last thunder or strike, resetting the clock every time there is a new one.
Getting the data off the station
APRS has no lightning field. Your options, worst to best:
APRS telemetry packets (T#seq,a1,a2,…) could carry strike count and
nearest distance in analog channels. It is low resolution and a stretch of what
telemetry is for.
MQTT is the clean path. Publish to a topic of your own and keep the schema explicit:
{
"ts": "2026-09-01T20:14:03Z",
"site": "DW9876",
"event": "strike",
"distance_km": 12,
"energy": 184501,
"strike_count_15min": 7,
"noise_floor": 2,
"sensor": "AS3935",
"confidence": "low"
}HTTP POST to an ingest endpoint, with the same shape.
Whichever you choose: keep energy an opaque integer, always tag the sensor
and a confidence, and timestamp in UTC.
Alternatives
Boltek StormTracker and LD-250 are prosumer E-field detectors, and the LD-250 does direction finding. A Blitzortung.org receiver kit joins you to the crowd-sourced network and gives you access to located strikes, which is a categorically better dataset than one AS3935 can produce. An E-field mill measures the static field and can warn before the first strike, the Thor Guard approach, at considerably more complexity and cost.
Where to go next
- MQTT lightning feed: WxAlerts’ GLM feed, for the other half of the blend.
- Building one from scratch: the rest of the sensor stack.
- Install and commissioning: grounding matters more than usual on a lightning-reporting site.