Tutorials

The GNSS module is initialized by creating an SpGnss object and calling its begin() method. This powers on the hardware block and prepares it for positioning. Then, for a basic example that uses GPS only, we call the start method without any parameter in the applications setup:

This causes the GNSS module to look for satellites. When a fix is established, positioning information is acquired.

To receive positioning data from the receiver, the application’s loop function waits for some data to be available and then gets it:

The waitUpdate() method blocks the application and waits until some data has arrived. The parameter to the method is a timeout determining for how long it should wait if nothing is received, but when set to “-1” it will wait indefinitely.

The SpNavData structure contains position data (latitude, longitude and altitude) and also information about all found satellites and their status. For a full description, see the API reference.

By default, the GNSS module updates its positioning data once every second. This update rate can be modified during setup so updates are less frequent:

The lowest possible update interval is 1 second. It cannot be set to 0. If no more updates are wanted stop the GNSS module.

Instead of blocking the application loop while waiting for an update, you can let the application poll for updated data whenever it needs it. This gives you full control of your application’s flow, but means you might not always get the latest updated data, depending on your update interval:

The GNSS module uses GPS by default but also supports the GLONASS and QZSS positioning systems with some additional satellite-based augmentation systems. The supported options are shown in the following table:

For example, so that your application also uses GLONASS for positioning, you must add it during setup using the select() method:

There is also a corresponding deselect() method that stops the GNSS module from using the given option. To check if a specific system is currently selected use isSelecting() with the given option.

When the receiver is first started it will take some time until satellites are found and a position can be determined. This delay is called TTFF (Time To First Fix). By selecting a suitable start mode and supplying initial data to the GNSS module, the TTFF can be greatly reduced.

Available start modes in the Arduino IDE are:

Satellite data, such as position, almanac, and ephemeris, are lost when the device enters deep sleep or powers off. To speed up TTFF at next start-up, these data can be saved to flash by calling Gnss.saveEphemeris(). This should only be done when positioning is deactivated, that is, after calling Gnss.stop(). The saved data will then be automatically read and used the next time a HOT_START is triggered.

If no mode is specified when calling start(), the GNSS module will try to use HOT_START. However, if it is not possible to reuse any data it will fall back to COLD_START instead. This could happen if, for example, some time has passed after the data was saved, because data received from the satellite is only valid for a limited time: two hours for ephemeris and 90 days for the almanac.

Current time is not included in the backup data. When the module wakes up from being inactive, for example when the device wakes up from deep sleep, the new GPS time is calculated using the time elapsed in the Spresense Real Time Clock (RTC). At boot however, the RTC is set to 0, so if the application knows the time and date to within 60 seconds, before initiating a hot start, use the setTime() method to supply the time and date.

It might also be a good idea to set an initial position using setPosition() if it is believed to give a better approximation than the saved data. Note that setting time and position should be done when the receiver is in idle mode, i.e. before any positioning is started.

Here are some general things to be aware of when testing your GNSS application:

To equip Spresense with WiFi you need to connect five wires to the WiFi module. In this example, we show how to use an Arduino library with an ESP8266 ESP-01 WiFi module.

Here is the list of components you need for this example:

Do the following:

The list of available AT commands for the ESP8266 can be found here:

https://www.espressif.com/sites/default/files/documentation/4a-esp8266_at_instruction_set_en.pdf

Examples of how to use AT commands can be found here:

https://www.espressif.com/sites/default/files/documentation/4b-esp8266_at_command_examples_en.pdf

The FONA module is available in two versions with different antenna connectors (SMA or uFL), so make sure to get an antenna that matches it. An external battery also needs to be connected to the modem because USB alone won’t be able to drive it during current spikes in its operation.

It is common practise to attach a pull-up resistor to the data pin of a Hall sensor, but in this tutorial we configure the input pin of the Spresense board to use its internal pull-up instead.

Download the Spresense FONA MiniGSM demo sketch from here:

developer.sony.com/file/download/spresense-fona-minigsm-demo-sketch

The following parameters need to be configured before you run the application. Load the sketch in the Arduino IDE, and find and update the following defines:

DWEET_THING_NAME
The name used to publish your data on the dweet.io site. Choose a unique name that someone else is unlikely to be using.

FONA_APN
This is the access point name provided by your mobile operator. It is needed to access the internet using GPRS.

FONA_PIN
This string is commented-out by default but should contain the PIN code of your SIM card if it needs to be unlocked by the application. Leave it commented-out if not needed.

If you play around with the code and the FONA ends up in a bad state so it cannot connect anymore, disconnect the battery and the USB cable and reconnect them again to reset.

The online PDM service used in this demo is senseye.io. Senseye is a PDM service provider that specializes in analyzing sensor data from their customers and then using advanced data analysis methods to predict maintenance needs.

You can choose another PDM service, but in that case you must modify the source code to support the REST API of that service. You can find the API strings and associated functions handling in:

examples/pdm_demo/pdm/api_senseye.c

The hardware components used in this demo are:

The sensor will be connected to one of the microphone inputs of the Spresense extension board so that it can be sampled at a high frequency. There are a number of manufacturers producing accelerometers with different forms, outputs and sensitivity levels. Whichever you choose, the sensor output signal needs to be converted to a level within the range the microphone input can handle (0-1.8 V). Also, we have to provide power to the sensor itself.

To satisfy the hardware requirements, we implement the sensor interface as described in Integrated Electronics Piezo-Electric (IEPE). In general terms, this means:

As well as the IEPE specific components mentioned above, we also need to bring the signal voltage down to a level that the Spresense board microphone input can handle, so a small voltage divider circuit is needed. An overview of the setup is shown in the following diagram:

The signal representations marked a., b., and c. at the bottom of the diagram show how the signal changes around the zero voltage baseline at different points in the network. You can find a detailed schematic can be found in the section Set up the hardware below.

The following sections describe the set-up and how to run the software.

The source code is divided into a number of modules with the most important ones shown in the following illustration:

Connectivity handling

The connectivity modules (Senseye API and Net) handle setting up the Wi-Fi hardware, setting up the HTTPS connection to the server and sending and receiving HTTP requests and responses. The API module is web-service-specific and needs to be modified/replaced if another service using another REST API is used.

Signal processing

The signal processing modules (Process and Sigproc) do all signal processing operations on the acquired vibration data. The Process module is the main interface for this and is called whenever a data buffer is available when measuring. The Process module also does some time domain processing itself and interface module, to the DSP where the FFT is run.

Data collection

The Audio module records vibration data from the microphone input as if it was regular audio data. When a full data buffer is acquired, it is sent back to the caller using a callback function. In this demo, recording is done using a single channel with a sample rate of 48 kHz.

Data handling

The DataHandler module is responsible for taking the data processing result received from the DSP, converting it to a JSON string and keeping it in temporary storage (the SD card). When a report is to be generated and sent to the server, this module reads all the previously stored JSON data, generates the complete JSON structure to be sent and then prepares the temporary storage for receiving new data.

Scheduling

To make sure measurements are taken and data is reported in a timely manner at a specific interval, a simple “Scheduler” module is introduced. At application start-up, one or more tasks (callback functions) are registered together with the interval at which they should be run. The application then hands control over to this scheduler, which goes to sleep and only wakes up when any of the registered tasks are required to be run.

In the default setup, the Scheduler component keeps track of two different tasks that are being run at different intervals: one measuring task that does data collection and processing, and one reporting task that sends the aggregated data to the web service. The general flow of the application can be seen in the illustration below. Note that the colors correspond to those of the components in the previous image showing the modular structure of the source code:

The measurement data is processed by the software to extract a number of different condition indicators, which are eventually sent to the web API. Calculations that depend on frequency analysis using Fast Fourier Transforms (FFT) are done on one of the sub-cores, which acts as a dedicated DSP. Implementations of FFT and other signal processing algorithms are provided by the CMSIS DSP library which is included in the Spresense SDK. The following indicators are calculated and reported to the web service in this demo:

1xRPM, 2xRPM and 3xRPM

These are the frequency components at one, two- and three-times running speed. So, if the motor runs at 1500 RPM, which equals 25 Hz, then 1xRPM will show the waveform energy around that frequency. 2xRPM and 3xRPM do the same thing but show the energy at two and three times the frequency respectively. An increase in these values could indicate that the shaft is misaligned or bent.

Bearing BPFO, BPFI, FTF and BSF

BPFO (Ball Pass Frequency Outer race), BPFI (Ball Pass Frequency Inner race), FTF (Fundamental Train Frequency) and BSF (Ball Spin Frequency) are characteristic frequencies that show different aspects of a bearing. As with 1xRPM etc. mentioned above, they show the energy at those specific frequencies and indicate faults in different parts of the bearing itself. These frequencies are specific to the model of the bearing being used and should be provided by the bearing vendor.

RMS

RMS (Root Mean Square) is a mean measure of the overall energy in the waveform. An increase here does not pinpoint a specific problem but is a general indication that there might be an issue, such as shaft misalignment, a faulty bearing or something else.

Crest Factor

The crest factor is the ratio of the peak signal value to the RMS. Like RMS, this is also not a very specific indicator and an increase of this value could imply a number of different issues.

Peak to Peak

This value indicates the maximum difference between the lowest and the highest signal value, that is, the spread, in the waveform. This does not pinpoint any specific error, but if this increases it means that there is a general increase in vibrations, which could be a warning signal that something is wrong.

Prepare the adapter

Prepare the adapter circuit board according to the schematic below. You might have to adjust the values of the components depending on sensor type and other factors.

Note the following:

Connect the sensor

Prepare the Spresense board

Get the source code

The code for this demo is located in the following Github repository: https://github.com/sonydevworld/spresense-tutorials.git

This repo only contains Spresense demo applications and the corresponding configuration files. To build it you must first download and set up the SDK according to the one of the Spresense SDK Getting started guides in the documentation.

Once you have the SDK in place, download the Spresense tutorials source code repo by running:

git clone https://github.com/sonydevworld/spresense-tutorials.git

cd spresense-tutorials

From this downloaded repo, copy the whole directory of the example application (pdm_demo) into the examples directory of your Spresense SDK.

Copy the folder containing the corresponding configuration (in this case configurations/pdm_demo) into the sdk/configs/examples directory of your SDK.

When all the source code is in place, change working directory to the sdk folder of your SDK repo and proceed with building it.

Build and flash the software

Building the software is done as with any other Spresense SDK application.

Configure the software

The software is configured by providing a configuration file that must be placed on the SD Card. The reason for this setup is to enable reconfiguration without having to rebuild the software and flash the board. It also avoids having to keep login credentials and other sensitive data in the source code.

A template file is available at examples/pdm_demo/config/pdm.config. The configuration is specified using the format :, and lines starting with a hash (#) are comments and will be ignored.

The settings include Wi-Fi and web API login credentials, sensor and bearing specifications, and motor speed. Fill in the missing values to match your setup and copy the file to the root of the SD card.

The demo is prepared so that it can either be manually started (the default configuration) or run automatically at startup.

To manually start the application:

To make the application start automatically when the USB cable is connected, modify the SDK according to these steps:

The startup sequence of the application is shown in the following flow diagram:

Once the demo is up and running, you should see in the log when application sleeps, wakes up to do a measurement or sends a report to the server.

You will need the following components:

Do the following:

In many applications it is not needed to have the Spresense active at all times. If, for example, it is used as a goods tracking device then maybe it is enough to record its current GPS location etc a few times per hour. When it is not doing any active work it is good to shut it down as much as possible to preserve the battery, and Spresense supports two different sleep modes that it can enter to do this:

To enter these modes from the Arduino library call the coldSleep() and deepSleep() functions in the LowPower Class Reference class. For more information about power modes please see the SDK Power Management documentation.

It is not only how often the application runs that matters, but also how quickly it performs its tasks. The clock frequency determines the speed of operation of the CPU and can be dynamically changed between 156, 32 or 8 MHz.

Note that there are some limitations when limiting the clock frequency. For example:

High-quality audio playback requires 156 MHz but if playback sample rate can be reduced to 44.1 MHz you can probably get away with using a clock frequency of 32 MHz. * Camera requires 32 MHz or 156 MHz * GNSS requires at least 32 MHz. Trying to run it at 8 MHz will only cause it to automatically switch to a higher speed.

However, since the frequency can be set dynamically, you can increase it temporarily only when needed and run at a lower speed the rest of the time. This is especially useful if your app is just idling while waiting for some external event, such as receiving updated positioning data from GNSS.

Setting the clock frequency from the Arduino library is done by calling the clockMode() function in the LowPower class. For more details about clock frequency control see the SDK Power Saving Control documentation.

Accessing data storage affects power consumption, especially if it is frequently accessed for reading or writing.

EEPROM is a memory type that is traditionally used for small amounts of non-volatile data. In Spresense there is an API for accessing EEPROM, but this implementation is just an emulation that actually uses flash storage, so from a power consumption point of view there is no difference.

Having the extension board connected will cause a slight increase in power consumption of approximately 700 μA. Also, having UART RX and TX on the expansion board, for example, for debugging Spresense without USB connected, will cause it to draw approximately 3.5 mA extra. This is good to know when doing any power measurements.

Any kind of peripherals connected to the board and the type of battery selected will of course also affect the power consumption and battery life of an application, but the vast number of possible combinations makes this discussion out of scope for this short tutorial.

This simple demo shows how GNSS updates might be handled, for example, in a goods tracking use case where low-frequency position updates are enough. A more realistic application would process the collected data and then transmit it to a host. But to keep this demo simple and to avoid having to use external modules, it just prints the data on the UART. For an introduction to the GNSS-related concepts, see the tutorial: How to read GPS information using the Arduino IDE. For this tutorial, we use a standard LiPo 3.7 V battery.

Application outline

A basic outline of the demo application is given here: (download the Arduino sketch):

This is what the main loop looks like in the demo Arduino sketch:

Sample measurements

One wake cycle (wake up → read GNSS → write SD card → sleep) consumes approximately 7 mA, while during sleep it uses about 300 μA. The application tries to update GNSS data a number of times until it gets a valid update (that is, not cached data), and assuming it takes on average five attempts to achieve this the board will be awake for approximately 10 seconds. Using this we can calculate an approximate value for how much current the board draws per hour for different wake-up frequencies:

There are 3600 seconds in an hour, so hourly consumption is calculated as:

Cawake × (Tawake / 3600) + Csleep × ((3600-Tawake) / 3600)

So in theory, if we wake up and check the position every 10th minute, that is, run for 60 s per hour, it will last for 4858 hours or about 200 days on a 2000 mAh battery. In reality however, the battery life will also depend quite a lot on battery discharge characteristic and environmental factors such as temperature.

The following images show examples of graphs of measurements calculating the numbers from the above table:

As a side note, it’s worth mentioning that by selecting the clock frequency to 32 MHZ instead of 156 MHz the board only consumes about half the power, especially while waiting for GNSS to respond. This is illustrated in the following graph, where the purple line shows power consumption when running at 32 MHz and the blue line when running at 156 MHz. The averages (AVG) are calculated for the GNSS wait period, that is, the shaded area between the white lines in the graph.

Spresense Arduino LowPowerClass

Spresense SDK Power Management documentation