Sensing the Storm with Azure Sphere,

AM Radio and IR Thermometer


Storm-sensing device

The goal of this project is to build a device capable of detecting of incoming storms. I used this opportunity to learn about Azure Sphere hardware platform, about writing code for both types of its cores and about interfacing Azure Sphere with the outside world. This project demonstrates Azure Sphere A7 and real time M4 core programming, intercore communication, GPT timer usage, I2C communication and GPIO state manipulation.


Finished device at its most basic version consists of Avnet Azure Sphere Starter Kit and custom AM radio module based on TA7642 integrated circuit. The complete version of the device also utilises OLED display, standalone MLX90614 IR thermometer module and LPS22HH pressure sensor already present on Starter Kit board.



Project description

  • Interferences caused by static electricity discharges (a.k.a. lightning) are detected by AM receiver circuit. Number of interference pulses (lightning strikes) is integrated across time axis. Number of lightning strikes during certain time period allows us to estimate the approximate storm distance.
  • Storm forecast can be further enhanced by measuring cloud cover. For this purpose we can use non-contact infrared thermometer for measuring the sky temperature. Clear skies will generally have lower temperature readings than clouds.
  • It is useful to also keep an eye on atmospheric pressure as a sudden drop of pressure may indicate incoming storm.
  • All those data are displayed on device’s OLED display as a bargraph or numeric value. Predefined warning level thresholds are indicated by RGB LED. Optionally all readings can be periodically uploaded to Azure Cloud.


Project repository:





Required Hardware


Required Software

  • Visual Sudio 2017 or 2019
  • Azure Sphere SDK for Visual Studio


Detecting lightning

Of course the most interesting part of this project is the lightning detector. While nowadays it is possible to use for example AS3935 sensor for this purpose, for the sake of learning about lightning detecting principles of operation I decided to  look at this problem in more depth and do some experiments.
There are various possible approaches to detecting lightning but the most reliable seems to be detecting electromagnetic interferences in AM radio bands. This project was inspired by Blitzwarner device by Burkhard Kainka who designed detector based on AM radio TA7642 integrated circuit. TA7642 is a three-pin low voltage AM radio receiver IC in TO-92 package. It is very cheap and experiment friendly. We will use a modified version of B. Kainka’s detector also in this project.

Basically the main feature of this circuit is that in presence of AM radio band electromagnetic interference the voltage on C3 temporarily decreases. We can detect those voltage dips using Azure Sphere ADC and process this information further.


Lightning detector

TA7642 detector schematics

As you can see from the circuit schematics, this is a simple AM receiver tuned to approx. 500 kHz. TA7642 ICs are very sensitive to operating voltage (see file TA7642_receiver_notes.pdf included in project repository) and it is necessary to control this voltage in some way. In this case we will be generating precise operating voltage using software PWM.


Detector perfboard layout and finished module

Detector schematics and perfboard layout are available as a Fritzing file in project repository.


TA7642 detector breadboard

Parts list:

  • IC1: TA7642
  • D1: 1N4148
  • L1: 220 uH type 07HCP
  • L2: 150 uH type SMCC
  • R1: 100 kOhm
  • R2, R3, R4: 1 kOhm
  • C1: 270 pF
  • C2, C3: 100 nF
  • C4, C5: 100 uF / 16V


TA7642 detector


Detector is connected to following pins on Azure Sphere Starter Kit:


Detector moduleStarter Kit
PWMClick Socket 1 PWM
OUTClick Socket 1 AN
GNDClick Socket 1 GND

(If connected to Click Socket 2 modify TA7642_SOCKET_NUMBER in RTCore app main.c)



This project uses one Azure Sphere Real Time M4 core for controlling AM radio receiver and transferring radio measurement data to main application. RTCore application generates PWM pulses on Click Socket PWM pin and calibrates PWM duty cycle so that TA7642 operating voltage is just slightly below 1.1 Volts. After calibration RTCore app performs continuous measurement of input voltage on Click Socket AN pin. Any input voltage change greater than preset threshold value is considered as electromagnetic impulse (possible lightning strike) detection. Number of impulses per second is integrated into warning level value. Relevant operating values are sent to main A7 core application for further processing or optionally are also displayed on serial debug console.


Loading RTCore application onto Azure Sphere Starter Kit

RTCore application is stored in project repository, subdirectory rtcore_lightning_monitor. Open this project using Visual Studio File -> Open -> CMake and navigate to CMakeLists.txt inside rtcore_lightning_monitor subdirectory.

See Microsoft documentation on how to build and load RTApp here:


RTCore application operation

After rtcore_lightning_monitor application is loaded and also after every restart it starts to calibrate output voltage. PWM signal with increasing duty cycle is generated and at the same time TA7642 operating voltage is monitored. As soon as TA7642 voltage reaches 1.1 V the calibration process is stopped, PWM duty cycle value is recomputed (in effect slightly lowered) and subsequently used in detector operation. The video below shows voltage waveforms on PWM and OUT pins during calibration.



During calibration process Starter Kit yellow APP LED is blinking periodically. If TA7642 output voltage never reaches 1.1V, the calibration fails and the APP LED stays on to indicate calibration problem. The calibration is then retried with the APP LED staying on.

After calibration succeeds, APP LED is switched off and RTCore app enters main monitoring loop. When the impulse is detected, APP LED blinks momentarily to indicate impulse detection.

If one hour passes without any detection whatsoever, the detector is recalibrated.


For more details see commented RTCore app source in main.c file.


Fine-tuning detector parameters

Since every detector module operates with unique components and under unique conditions, it might be necessary to change certain parameters to get an optimal detecting performance. For the best experience this process requires USB-to-serial adapter connected to RTCore UART, as decribed here: Microsoft Azure Sphere Docs. But it is also possible to use debug data shown on OLED display for this purpose.

We will be modifying parameters in main.c of rtcore_lightning_monitor, read comments in source code for detailed information:


  1. If you have trouble calibrating detector output (e.g. it never seems to calibrate, TA7642 output voltage never reaches 1.1V), you may want to modify TA7642_ADC_MAX value. After successful calibration follow with the next step.
  2. Depending on the surrounding AM band noise and interference you may want to tweak detector sensitivity by changing TA7642_NOISE_THRSHLD. If the detector is too sensitive, it might be necessary to increase this value and vice versa.
  3. Usually it is not necessary to touch PWM_DUTY_MAX and PWM_TUNE_UP, but feel free to experiment with them.


RTCore UART debug messages example:

RTCore UART debug messages


Debug screens - TA7642 running normally and calibrating:

TA7642 debug screen - calibratingTA7642 debug screen - running


Lightning warning indication

Current warning level is indicated on OLED display as a bar-graph or numeric value. It is also indicated on RBG LED as green, yellow and finally red alert. It is possible to set your own warning level values for those alerts.


Warning level - green alert:

Lightning warning - green alertWarning level - green alert, numeric




Detecting clouds

Cloud detection is based on measuring sky temperature using non-contact infrared thermometer module with MLX90614 sensor. For this purpose I ported MLX90614 I2C driver to Azure Sphere, you can find my MLX90614 support library on GitHub here: The main application periodically polls thermometer sensor for its own (ambient) temperature and also remote measured temperature. Based on the difference between those two temperatures we can infer cloud presence. Zero or very small temperature difference means clear sky, larger differences indicate clouds.

For best cloudiness bargraph resolution you may tweak CLOUD_DELTA_T_MAX value.


MLX90614 debug screen:

MLX90614 debug screen


Measuring atmosperic pressure

For this purpose we will use Starter Kit onboard sensor LPS22HH. I prepared a simple Azure Sphere wrapper library for system independent LPS22HH drivers from STM, you can find this support library here: . Again we just periodically poll the sensor for current data and display the result as a bargraph or numeric value. Usually sudden drop of atmospheric pressure may indicate incoming storm.


LPS22HH info screen:

Atmospheric pressure data


Sensor placement

For best measurement and forecast results it is necessary to pay attention to selecting the best location for every sensor and detector used.

LPS22HH: this sensor is not really location sensitive. LPS22HH is mounted onboard on Avnet Azure Sphere Starter Kit and it will work fine anywhere the Starter Kit would work. Just bear in mind that due to some (probably hardware) glitch, LPS22HH sometimes stops working. In this case the atmospheric pressure gauge on display would stay on its minimum and the would be no changes in measured value. Usually just powercycling the board helps to resolve this problem.

MLX90614: this sensor needs unobstructed view of the sky, also you should not to cover the sensor with glass or anything since this would distort measured values. This sensor is available in a few different versions with varying field of view angle. For best results get the sensor version with largest field of view.

Lightning detector: since this is basically a very sensitive AM radio receiver, it is recommended to keep it as far as possible from any possible RF interference sources. Sometimes such a source might be non obvious. During my experiments I found out that for example some LCD monitors pollute AM band with quite heavy noise. Your best bet would be getting some old AM radio, tune it to some MW (medium waves) frequency and place it to planned detector location. If there is no noise coming from the radio speaker, the location will be probably OK.



Connecting to Azure Cloud

The project contains all code necessary for connecting to Azure Cloud IoT Hub and uploading measured values. Azure Cloud functions are enabled by editing appropriate options in build_options.h and connection_strings.h. For more details regarding Azure setup see Brian Wiless' excellent detailed guide here. It is possible to set measurement data upload time period by modifying AZURE_UPLOAD_PERIOD constant in init.c source file.