As a team, we have a historical trend of failing at everything we try. Common sense dictates that we should try to hide that fact. However, we’ve adopted the opposite strategy. Publishing our failures shows others how they should not proceed, and might give them ideas about how they should proceed (see The SMOS project). What’s in it for us? Not much. But it’s not a big effort to spend a few hours documenting things for the benefit of others.
[By Jakke Mäkelä and Niko Porjo]This particular concept was a low-tech lightning detection system. Our former employer let us put some effort into looking at a system that could have used a cell phone’s radio circuits for remote lightning detection. The idea was more or less ridiculed, and it never did become commercial in the original form.
However, we found that the idea is less stupid than it sounds. I eventually did my PhD thesis on the physics of such systems. In brief: the crackle that lightning produces in any radio channel can be used to identify and range lightning, giving some pre-warning time before the thunder can be heard.
This is fairly pointless in Scandinavia, but could be significant in tropical areas with more frequent and violent thunderstorms. Both the hardware and software can be extremely simple — basically, an AM radio costing a few dollars can be used. This is thus a technique that might be feasible in developing countries.
We considered Sri Lanka to be a possible place to test the system. It has high mortality from lightning, and a poor economy and infrastructure. Thus, more expensive lightning detection systems do not sound highly realistic there. We also had connections with Sri Lanka during the project and my PhD studies.
Some other researchers and I wrote a peer-reviewed paper on how such a device could be used to detect lightning (Gulyas et al, JoLR 2012). We also wrote a non-peer-reviewed conference paper on how multiple sensors could be used to create a detection network. It’s one of those things that theoretically works. Making it work commercially is a completely different question.
Having been let go from our previous employers, we looked seriously into making this a commercial project. But we came to the conclusion that we would just starve.
The text below is mostly in the form we left it after deciding to stop. It is in draft form, as we do not feel like wasting our time on prettifying it after making a no-go decision. Technically oriented people will understand what we are saying. For readability, we have split the document into two parts; the technical document here, and a commercial document to be published later.
The various entities mentioned here (University of Uppsala, University of Colombo, and Finnish Meteorological Institute) were approached unofficially, but have not formally commented on the idea.
OVERALL PROPOSAL
A loose consortium between for example the University of Colombo, University of Uppsala, Finnish Meteorological Institute, and the proposers could contain all the competence that is needed to implement the project. As of 2012, a new lightning detection chip AS3935 is available from Austriamicrosystems which could form the detector part in the first generation. Thus, the hardware design would be particularly simple now (http://www.ams.com/eng/Lightning-Sensor/AS3935)
POSSIBLE PARTICIPANTS
- The University of Colombo has experience of the local conditions. Since the target is to transfer all the knowledge to Sri Lanka, Colombo should be the overall lead for the project, with other parties consulting per need.
- The University of Uppsala has in-depth knowledge of lightning physics and a close working collaboration with Colombo.
- The Finnish Meteorological Institute has a unit which is experienced with setting up weather-observation systems in developing countries.
- Mäkelä and Porjo have experience with low-end detector design as well as the network technology.
PURPOSE
•Create an ultra-low-cost lightning detection and warning system for developing countries.
•Pilot project could be run e.g. in Sri Lanka.Technology tests need to be done in a country with accurate lightning location reference data (USA or Europe)
•Technology exists (and multiple technologies possible), missing is a low-cost system to bring the data together and disseminate it to end users. Specifically, low-cost real-time systems are missing.
•Focus is on extreme simplicity, capability to withstand power cuts, quick response times.
•Modular and technology-agnostic (no technology lock-in). Only requirement is that each station be able to provide a distance estimate when a flash is detected.
•Open-source project, with possibility to incorporate better techniques as technology improves.
•Simplest detectors can be built based on public-domain information. Local Sri Lankan R&D can be used to design and build the sensors.
•In the somewhat harsh conditions, it is realistic to assume that some of the measuring sensors will be malfunctioning or offline at any given time. Network algorithm must be made flexible to account for this.
Proposal for demonstrator
•Build network that covers the western coastal region of Sri Lanka.
•Build detection network on principles described in Porjo & Mäkelä 2010. As of 2012, the AS3935 chip from Austriamicrosystems (about 4 USD) is available as a front-end. This information is in the public domain. Simple detectors are also well-known and in the public domain. Some original design work may be needed, but could be done at University of Colombo (academic work). Lowest-cost approach could include a stock Android phone with a Rasberry pi attached to a GPS clock source and a small custom board for the AS3935.
•Sensors by default transmit flash information via mobile phone link (SMS or GPRS). Landlines (Internet access) can be used if available, but they can be expected to be more vulnerable to errors than wireless especially when storms are nearby.
•Flash-by-flash locations are not attempted, only storm risk zones (Gulyas et al 2012). Intra-cloud flashes are difficult to range in any case, and from the viewpoint of security, the most important parameter are the boundaries of the active storm cells.
•Central computer identifies storm risk areas. Sri Lankan Met Institute? Must plan system with high redundancy from the very beginning (at least two computers running separately) because probability of failure is highest exactly when the storms are strongest. The duplicate(s) can also be used to beta test networks whenever stations change.
•Mobile base stations within the risk areas send warning SMS to participating cell phones. GSM standard allows this since a cell broadcast recommendation exists. But this is potentially difficult issue as requires operator cooperation, as well existence of the GSM network which may be unreliable. Negotiation with operators is needed, and in particular operator lock-in must be avoided (in which an operator can define his own price at will). Note that in principle it is NOT necessary to alert 100% of the people in the area, as it can be expected that people will alert each other. However, 100% should be a target.
•Since ranging accuracy drops radically after 20 km, stations cannot be separated by much more than this. For redundancy reasons, stations every 10 km might be better. In case of Sri Lanka, region of main interest is the coastal strip, thus the network could consist of approx three rows of sensors separated by ~20 km, sensors every 10 km or so. To protect 200 km strip of coast, need minimum 3×20=60 sensors.
Data transfer needs
•Data transfer needs to be divided among multiple operators to avoid collapse if one operator’s SMS center crashes. Ideally each sensor would have at least two SIM’s (dual-SIM technology already exists) in case one crashes.
•Data transfer from sensors is to be by SMS or GPRS. Since locations of stations is known, only need per flash time (to 1-sec GPS accuracy) and intensity (8 bits would be sufficient if calibration is OK). Since we want to allow possibility of direction-finding at least in the future, 8 bits allows 1.4% angular resolution. Time can highly compressed if for example nearest hour is assumed to be known, in which case 12 bits is enough to code nearest second. Some kind of reliability value of a few bits would also be useful. → Each flash could be coded in 32 bits.
•SMS spec has 1120 bits per message (160 7-bit characters as in SMS, equivalent to 140 8-bit characters as in Twitter). Thus up to 35 flashes could be coded in a single SMS. Since flash rates are essentially never 30 flashes/minute (in extreme cases ground flashes up to 4-6 flashes/min, cloud flashes theoretically 10 times higher). Sending SMS once per minute would be sufficient even in case of an extreme storm.
Part 2 on business aspects: click here
