Default Operation

This page describes the default operation of the Movesense sensor firmware. However most of the functionality can be controlled by the Movesense API (either from firmware or over the BLE connection). Many of the details are also hardware dependent and the operation may be different in the future in different Movesense sensor hardware.

Boot-up

When the Movesense sensor is powered on, the following happens:

Bootloader

Application bootup

In the beginning of the application start, the hardware is initialized and LED lit. If there is a contact in the HR-studs, the firmware waits to see if the "DFU recovery mode" sequence happens (contact for three seconds, start blinking the led and disconnect studs during one second). If it does, set sensor to DFU mode via reset.

After DFU mode detection is over, the rest of the Movesense framework is initialized, BLE enabled and threads created. After all that the "whiteboard::LaunchableModule"s are created as follows:

Default BLE operation

After the sensor is running, it stays by default in as low power consumption as possible. The BLE Advertising is enabled so that the BLE connection can be made to the sensor.

The advertising after bootup is sequenced to: - First 60s the sensor advertises with 100 ms interval ("Fast advertising") - After that the interval is changed to 500 ms to save energy

If connection is made to sensor, the advertising is disabled. After BLE disconnect the sequence is:

Default advertising packet content

The default advertising and scan packet contents in the current firmware are:

Advertise packet

Scan Response packet

NOTE: If the name in the Scan Response packet is changed by the firmware, you must set the new name also to the BLE stack so that it reflects in the "Device Name" -characteristics of the "Generic Access" -service. Otherwise the Mobile phone can show the old name when the connection is made.

UTC Time

The Movesense sensor keeps track of the UTC time set via the PUT /Time -API. Since the current sensor does not have a separate hardware RTC chip, the UTC time is lost when the device goes in to FullPowerOff system mode. Almost same power savings can be achieved by unsubscribing all sensor data and disabling BLE advertising (Low power IDLE mode) which will keep the device UTC time.

If a sensor experiences a software reset (error condition or commanded reset), the UTC time stays set but there is about +- 500ms loss of accuracy (if the sensor goes thru the full DFU recovery detection the time loss can be bigger).

Error cases and RESET

When the sensor experiences an error condition (HW fault, ASSERT or BLE stack error), the reset reason is written to RAM that is not initialized in next reset. This "Reset reason" string can be read with the following code after the bootup:

    char buf[40];
    if (faultcom_GetLastFaultStr(false, buf, sizeof(buf))) {
        // Deal with error here
    }

The format of the fault strings are:

ResetTypes can get following values:

It is a good idea to read these reset reasons and log them, so that the sensor failure cases can be followed in the field. You can either embed the information in your own service or use the /System/ResetReason API in DebugService.

Common Framework ASSERTs

The following list contains the typical framework ASSERTs and the reasons for them (Line numbers are from release 2.1):