Building a Spresense Powered Smart Security Device Part 1: Introduction

This series of posts demonstrates how the advanced capabilities of the Sony Spresense can be put to use in creating a low power security device for asset monitoring and tracking.

The Sony CXD5602 at the heart of the Spresense provides a unique combination of flexible sensor interfacing which benefits from low power digital signal processing, plus integrated GNSS and a powerful 6-core processor. As such it is the perfect candidate for battery powered location-aware IoT applications which need to pack an awful lot into a small space.

In this series of posts we will document the prototyping of a solution based on the Spresense board, all the way from specifying requirements and selecting the additional components required, through to testing individual subsystems, assembling a prototype and publishing the source code.

So let’s start by taking a look at our application.

Use case

ZVA40 vector network analyzer from Rhode & Schwarz, CC BY 3.0.

It is very common for high value machinery and equipment to be made available on a rental basis, given that outright purchase may not be possible or indeed appropriate for many users. Obvious examples include hire cars, commercial vehicles and plant equipment. With others including costly test equipment, such as vector network analysers and high bandwidth oscilloscopes.

A particular challenge of providing such services is proving who is at fault when damage occurs; it could be that equipment was mishandled just prior to being booked out — else possible that failure occurred during the hire period, but not due to misuse or any fault of the hiring party.

What information might help ascertain where responsibility for damage lies? A good start would be:

• Event has occurred

  • Time of event

  • Location of event

The sort of events we might be interested in will depend upon the equipment or machinery in question, but a common one is going to be a certain class of movement. E.g. a sharp shock from being jarred or dropped, or maybe being tilted beyond a certain angle.

In terms of additional requirements it would prove beneficial for the solution to be:

• Compact so that it can easily be affixed to equipment/machinery

• Self-contained and not requiring multiple modules and cabling etc.

• Low power and capable of running on batteries for long periods of time

Our prototype will be constructed from more than one board and we won’t fully optimise power consumption, but it will be clear how it could be reduced to a much smaller single board solution and in closing we will briefly explore how further energy efficiency gains may be made.

High level architecture

Above we can see the CXD5602 block diagram and next we’ll take a look at the key capabilities that we’ll be making use of, starting with sensor interfacing and initial processing.

The Sensor Control Unit (SCU) can be used to receive data from peripheral devices connected by SPI and I2C. It is designed to reduce processor load and power consumption, achieving this by carrying out decimation — “downsampling” to reduce the sample rate — filtering and event detection, via dedicated low power hardware with configurable operating parameters.

The integrated GNSS receiver works with both the GPS and GLONASS constellations. When an event happens this will allow us to ascertain when and where this took place.

Finally we have the Storage/Connectivity capability of the microcontroller, which will allow us to interface with flash storage in order to log event details.

Next steps

In the next post we will set up the tools, run our first example explore the SDK structure.

— Andrew Back