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 ID	Data memory	1-Wire master	Remarks
Movesense HR2	SS2	384 kB EEPROM	NO
Movesense HR+	SS2	384 kB EEPROM	YES
Movesense MD	SS2	384 kB EEPROM	NO	Class IIa Medical device (MDR)
Movesense Flash	SS2_NAND	128 MB FLASH	NO	The new flash memory variant

NOTE: The default HWCONFIG, if not specified, 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 HR+/HR2 and Movesense MD are software compatible (same HWCONFIG), the differences being mostly in the software and hardware certification. The new Movesense Flash 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 Flash 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>

NOTE: For version 2.1.x, The only working Build type for Flash variant is the "Debug"-build. Updating the flash sensor with Release build firmware will brick the device and require re-flashing with the programming jig to recover!

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 Movesense Flash vs HR+/HR2/MD

The most striking difference in the new Movesense Flash 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:

• When the filesystem is full, data can no longer be written (vs the EEPROM where it overwrites the old data)
• Minimum size that a single log (=file) takes is 128 kB and the size grows 128 kB at the time. File size is reported as multiples of ~128 kB
• File system slows down if there are a lot of logs created. Significant delay happens when creating logs once every 7 logs. This can cause buffer overflow (on 2.1.x) or dataloss (coming versions >= 2.2). The effect is similar to the one described below, when mem gets full.
• When file system gets more full, some filesystem operations slow down (see more below)
• The filesystem only supports one user at the time (at least for now). As a result simultaneous writing and reading is not possible (GET /Mem/Logbook/Entries can be done while writing)
• The filesystem allocates much more RAM than the EEPROM DataLogger implementation, resulting much less heap RAM available for the rest of the code.
• The flash memory uses more power when in operation as well as when not in use. This raises the power consumption by ~ 15 uA when IDLE and extra ~100 uA when recording fast data such as ECG (more power testing will be done in future).

NOTE: To read more detailed information about the Movesense Flash, please read the document Movesense Flash Application Notes.

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:

• Samplerate 52 Hz: The first accelerometer FIFO overflow (= data loss) happens when 95 MB of memory is used.
• Samplerate 208 Hz: The first accelerometer FIFO overflow happens when 50 MB of memory is used.

When the memory is almost full (~ 123 MB used), the datalogger is stopped automatically (version >= 2.2) before the slowdown is too severe. This condifition can be checked by fetching the state of the /Mem/Logbook/IsFull.

Note: In older framework versions (2.1.x), the sensor will ASSERT and reset as the result of the slowdown and buffer overflow.

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 Movesense Flash 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.