Movesense sensor hardware variants

There are several different variants of Movesense sensors available for developers. The following table lists the different sensor types and their main features:

Sensor model HWCONFIG Data memory 1-Wire master Remarks
Movesense active SS2 384 kB EEPROM YES "Original Movesense Sensor"
Movesense medical SS2 384 kB EEPROM NO (Certified Medical device accessory)[../medical/medical_sensor.md]
Movesense "big mem" SS2_NAND 128 MB FLASH YES The new big mem variant

NOTE: The default HWCONFIG is "SS2"

Building software to different variants

Each incompatible hardware is recognized by the HWCONFIG-field in the above table. As can be seen both Movesense active and Movesense medical are software compatible (same HWCONFIG), the differences being mostly in the software and hardware certification. The new Movesense "big mem" variant however is not compatible with the binaries built for the other two variants.

To build sensor software that targets the different variants, one must provide the HWCONFIG definition to the cmake when setting up the build directory. To target "big mem" variant, simply call cmake as:

cmake -G Ninja -DMOVESENSE_CORE_LIBRARY=../MovesenseCoreLib/ -DCMAKE_TOOLCHAIN_FILE=../MovesenseCoreLib/toolchain/gcc-nrf52.cmake -DHWCONFIG=SS2_NAND <sample_directory>

Protected DFU updates

Each hardware variant has a bootloader with different cryptographic key and the DFU packet is signed with a corresponding key when creating the DFU packet. That way the sensor is protected from accidental update with and incompatible firmware. Correct bootloader and key are chosen automatically by the build system based on the provided HWCONFIG value.

Practical differences of "big mem" vs "original"

The most striking difference in the new "big mem" variant is obviously the large data memory. The 1Gb (128 MB) flash memory is organized as a file system instead of ring buffer. This has following consequences:

Effects of slow-down when memory gets full

The effect of flash memory operation slow down depends on what else the sensor is doing while recording data. As an example if the sensor is recording raw IMU9 on two different sample rates:

In both cases when the memory is almost full (~ 125 MB used), the operations get so slow that the application thread can no longer empty the accelerometer data from the Whiteboard queue (at default length) resulting ASSERT in Whiteboard.cpp and consequent sensor reset.

Effects of low battery

Flash memory is more sensitive to low voltage situation during write operations than EEPROM in the "original" sensor. As a result the "big mem" variant has been equipped with a fast low voltage detector chip which triggers if the low voltage is detected at any time. In software this can be detected by subscribing to the "BatteryStatus"-state (StateID=1) in /System/States/{StateID} -API. The DataLoggerService subscribes to this API when it is recording data and stops logging automatically if needed.

Note: It is a good idea for the firmware to SUBSCRIBE (or GET) the value to determine if low voltage has been encountered. Typically this happens in situations with high current consumption such as writing to flash memory or heavy BLE transfers.