We live in a world of sensors. They’re in robots in factories, in our cars, on our wrists, even in our refrigerators making sure our food stays fresh. These sensors generate signals.

In this video we’ll use Simulink to process a signal from a sensor. We’ll perform spectral analysis to explore the signal. Based on that, we’ll design and build digital filters as part of a signal processing algorithm. We’ll assess the performance of our algorithm and, once it’s ready, convert our model into C code that can be embedded into real-time hardware. So let’s get started…

At the bat365 headquarters in Natick, Massachusetts, there are solar panels that generate electrical power. We’ll use measurements of the power produced by the array every 15 minutes. This is our signal.

Of course, the power depends on the amount of sunshine, which depends on the time of day... and the weather.

Predicting and managing the variable production and demand is an important part of renewable energy generation.  To smooth out the generated power, on sunny days we can store some of the power in a battery. Then on cloudy days, we use it to supplement the lower power generation.

Let’s design a system that can predict if it’s going to be sunny or cloudy using signal processing techniques in Simulink.

You start Simulink by clicking the Simulink button on the MATLAB toolstrip. This opens the Start Page where you can create new models, find examples, and even find basic training.

We’re starting our model from scratch, so we’ll choose Blank Model and save it as sunnyvscloudy.

Simulink models are built up from blocks and signal lines. Open the Library Browser to see all of the blocks available. 

We’ll start by visualizing two power signals – one from a sunny day and one from a cloudy day.

To view our signals, let’s drag two input ports, or Inports for short, into our model. Then add a Scope block. 

Let’s label the two Inport blocks “Sunny Day” and “Cloudy Day” and the Scope block “Time Domain”.

We can connect the blocks together with signal lines by clicking and dragging.  To label a signal line, double-click and type the name.

Now we need the data. In MATLAB we have two vectors, sunnyDay and cloudyDay, representing the power measurements for two particular days in June. The corresponding timestamps are in tday.

We also have the sample frequency, in samples per day, in the variable Fs. Sampling every 15 minutes means we get 96 samples per day.

We have to set the Sample Time of the two Inports, so double-click on each Inport to adjust its block parameters. Under the Signal Attributes tab, set the Sample Time to the reciprocal of the sampling frequency.

To bring the data into Simulink, we can go to the Model Settings window, then the Data Import/Export pane, and add the time and two power signals as inputs. We should also set the total simulation time to 1 day.

We can now run our model by clicking on the Run button in the toolstrip.

Let’s double-click on the Scope block to see the signals.

And lets  connect our data points using lines.

The smooth yellow line is the sunny day. The blue line shows that the cloudy day produces less power, as you’d expect, and also has many short-term variations as the clouds pass over the solar array.

So how can we use these features to decide if we have a sunny day or a cloudy day?

Well let’s also look at these signals in the frequency domain.  We’ll use spectral analysis, which helps us measure the frequency content of each of the signals.  We first add a Spectrum Analyzer block from the DSP System Toolbox and then connect the two signals to it.

To branch a signal line, you can right-click as you drag the signal line to a block.

We have short signals, so we’ll need to change a few settings in the Spectrum Analyzer block so we can see them properly.

This time we can run our model from within the Spectrum Analyzer by pressing the green button at the top.  And let’s turn on the legend to see which day is which.

So, what are we looking at?  

The x-axis is the frequency value. The y-axis shows us how much power is in our signal at a given frequency. Although the default time unit is seconds, we’re actually measuring time in days. So the x-axis is cycles per day, not cycles per second (or Hz).  

We see that the low frequency content is about the same for both days, but the cloudy one has way more high frequency content. Remember those short-time variations? Well that’s how they look in the frequency domain. 

So maybe we can tell sunny from cloudy by comparing the power in the higher frequencies to some threshold.

However, the panels produce more power in the summer and less in the winter, which means the threshold would have to change throughout the year.

Well, we’d like to have a constant threshold for all seasons of the year.  If we normalize the high-frequency power by the power in the lower frequencies, we can use a fixed threshold.  So, let’s try computing the ratio of the total power in the top 75% of frequencies to the total power in the bottom 25% of frequencies.

So, how do we separate the low and high frequencies?  By building digital filters. We need a low pass filter for the low frequency content and a high pass filter for the high frequency content.

To build these two filters, we first strip our model back to a single Inport and Scope Block.... And drag in a Filter Realization Wizard block from the DSP System Toolbox.

Double-click the block to open the Filter Designer App. If you’ve designed filters in MATLAB, you may have used this app before. Let’s click on the “Design filter” icon to start designing the lowpass filter.

Because we only get samples every 15 minutes, we need a filter that can work with just a few samples. We’ll use a Chebyshev Type 1 IIR filter, and we’ll set the filter order to 4.  

We then have to specify a cutoff frequency.  Remember, we wanted to let through the lower 25% of the frequencies. So we’ll select Normalized Frequency and set wpass to 0.25.  And we’ll keep the passband ripple to less than 0.05 dB.

Finally, push the Design Filter button at the bottom.  We see that the new response is what we want.

We can examine the delay introduced by our filter by clicking the Group Delay Response button.  For frequencies less than 0.25, the delay is about 3 samples. Let’s remember that for later.

Now that we’re done designing the filter, let’s add it to our Simulink model by clicking the Realize Model icon. We’ll call the block “Lowpass Filter” and select the option “Build model using basic elements”. That way we can see the basic Simulink blocks used to make the filter, like delay, multiply, and add blocks.

When we click the “Realize Model” button...

   ...a new subsystem is created in our model. Let’s double click this to look inside. 

Sure enough, the filter is just unit delays, gains, and add blocks, which modern DSP chips and FPGAs are optimized to implement.

Now for the high frequency content. We can repeat the same process to design and realize the high pass filter.  In this case, the high pass filter delays the input signal by 1 sample. 

Ok, let’s test our new filters on the power signal.

We add three parallel paths: one for the original power signal, one for the lowpass-filtered version, and one for the highpass-filtered version.  We want to compare them.

But remember that the lowpass filter introduces a delay of 3 samples, and the highpass filter introduces a delay of 1.  So we need to add some delay blocks to make sure the three signals are aligned. Double-click on the model and type “delay” to quickly add a delay block to the original signal of 3 samples and another delay block to the high pass signal of 2 samples.

And we’ll modify the model to work with a much longer 2 ½-year dataset we have, which is stored in the variable power with timestamps in t.

On the Scope let’s zoom in on six days.  

The yellow line is the original power signal.  The blue line is the lowpass signal, which represents the general smoothed trend. And the red line is the highpass signal, which captures the variations due to the cloud cover.  During cloudy periods, these variations can be large.

Now that we’ve separated out the low and high frequency signals, we’re ready to build our Sunny Test.

We need to aggregate over enough time for our filters to give sensible results, but we don’t want to wait too long to get an answer. So we’ll use a 3-hour window, which is just 12 measurements!

To store the filter outputs over a time window, we’ll use Buffer blocks from the DSP System Toolbox.

Double-clicking the buffer, we can set the buffer size to 12 to handle a three-hour window. And we need a buffer on each filter path.

Now we’ll use some basic math operation blocks to compute our sunny test, like the absolute value, sum of elements, and divide blocks.

Let’s add a block to compare the ratio with a threshold. With Simulink, you can experiment easily to find a good value for this threshold.   22 works well, but feel free to play with this value and see how it changes the results. 

The output of the comparison is 0 for not sunny and 1 for sunny. Let’s scale it to match the maximum power, just so it shows up nicely on the plot.

And we should remove the extra input port on the Scope block.

Before we run, note that those buffers added some more delay to the signals. So to stay aligned with the original signal, we’ll need to increase that delay by 12.

Ok let’s run and see how well our algorithm works. If we zoom in on the same days as before, it looks like it’s working pretty well.

But if we look at different set of six days, we find a problem with our method. Sometimes it says it’s sunny in the middle of the night!

To solve this problem, let’s modify our sunny test by adding in a Daylight detector. We’ll simply compare the low-frequency power to another threshold, which lets us know if the sun is actually up. We can combine the two conditions with an AND block.

Re-run the model and check those days... and we see that we’ve solved the false detection problem.

Now that we have a working algorithm, we want to deploy it to an embedded system. With Embedded Coder, we can deploy to Arduino, Raspberry Pi, Zynq, and many others.

Let’s deploy our model to an Arduino Uno board. 

We’ll open the Model Settings window and select the hardware board. Then, we replace the Scope block used for testing with an output port. 

Now let’s generate code. This takes our Simulink model and generates all the C files that we need to compile the model for deployment. You can also generate generic C code for other embedded systems. 

Or… VHDL or Verilog code to deploy to an FPGA.

Once we have our generated code, we port it to the embedded hardware on our solar array.

Look at what we have done using Simulink!  We now have a steady source of renewable energy.

You’ve seen how to go from a blank canvas to a signal processing application running on an embedded system. And you can try this too. The files are available for you to download. 

Now that you have a feel for what working with Simulink is like, it’s time to learn it. The best way to learn Simulink is to work with it. So start up Simulink OnRamp, which will teach you the basics. It’s free and takes just a couple of hours.

Welcome to Simulink!