Tag: lightning

Part 2 of write-up on ultra-low-cost lightning detection network. See Part 1 for background.

[By Jakke Mäkelä and Niko Porjo]

This part summarizes the cost and business case estimates made for the project. The analysis suggests that an extremely low cost might be possible, making the solution suitable for use even in developing countries like Sri Lanka. However, we could not find a way to motivate anyone to fund the R&D part. Thus, we are not pursuing this further for the time being.

BUSINESS ASPECTS

Business case: both hardware cost and data transmission costs are kept so low that building and maintaining network is realistic to perform as a public service. Data transfer can be made over mobile phone network (SMS, GPRS, 3G…) or landline if available. Multiple operators are made to compete to keep data costs down. Hazard indication to end users will need to be wireless to achieve real-time warning.

Benefits

•An exact business case is difficult to determine, as it is for any lightning warning system.

•Situation in Sri Lanka: Tens of deaths reported annually, real number of deaths and injuries unknown. Commercial detection systems too expensive to maintain.

Costs

•Absolute worst-case scenario: If SMS sent less than once per min, reliability of network becomes poor. Thus cannot transfer much less than this. During storms, whole network would need to be transmitting 60*60=3600 SMS/hour. In Finland,  cost of SMS on one operator is ~5 cent, so cost would be 180 EUR/hr for whole network. Assuming 6 hours/ day of storms in active seasons, would mean 30 kEUR/month, which is of course completely unacceptable. But in practice, there are fixed-cost deals available from operators. Multiple operators are absolutely needed in order to maximize price competition and minimize risk of monopoly pricing. But there are SMS-based systems in existence which are affordable (for example Nokia Life Tools http://en.wikipedia.org/wiki/Nokia_Life_Tools) which means that costs could be kept reasonable if there is political push.

•Transfer rate over GPRS, if available, is even in extreme case ~160 B/min or 1kB/hour per station.  For total network, transfer is ~60 kB/hour. Per month, amounts to ~100 MB. On one Finnish operator, GPRS cost can be ~1.5 EUR/MB, so cost would be <200 EUR/month. Clearly GPRS would be the preferable channel where available.

Costs

•Sensors need to be stockpiled to allow them to be replaced quickly if needed, so at least 100 need to be built. Smaller calibration networks can also be developed in parallel and run in a suitable country.

•Main components are radio receiver, GPS clock, GSM/GPRS, processing unit. Battery may be most expensive individual component. ideally will run on AC power, but need to have backup battery/UPS capable of multi-hour operation in case of power failure.  Unit cost of 400EUR should definitely be reachable (cost of full network 40kEUR), though profit margin to manufacturer is then low. This part may need to be subsidized.

•Setting up of network is low-cost since all sensors are autonomous and operate by wireless network. Slow deployment is possible.

•Central unit can be a tabletop PC. Redundancy and power supply needs will increase cost significantly, but main algorithm is simple.

•Operating costs can be minimal if GPRS can be used.

•Cost of transmitting hazard information to users via Cell Broadcast is largest open question.

Funding and implementation

•No funding has been found.

•The organization Geoscientists Without Borders has been funding projects which are similar to the proposal: http://www.seg.org/web/foundation/programs/geoscientists-without-borders

•The target of the pilot is to improve local R&D competence in Sri Lanka, but kicking off the project could require an investment that is difficult to find locally. National foreign aid organizations (Finland or Sweden) might be approached for projects of this type, especially if some of the testing can be done in Europe (enhancing local knowledge also).

Similar projects

•Lots of small semi-official warning systems are known to exist, but limited info in public domain. Data transfer is almost always by fixed-line Internet, which can be unreliable especially in developing countries. Mobile wireless networks have better reliability (though not perfect).

FINAL OUTCOME

We continue to think that the idea would work in principle, but there is no real way to make it successful commercially. We need to feed our families, and cannot do it.

If someone is interested in making this a non-profit open-source project, the crucial documentation is already in the public domain and just needs to be collated together. There are some major engineering issues to be solved, but if profitability is not a requirement, they are likely to be solvable.

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.

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