Preparing Movesense Sensor Firmware for Production
The Movesense sensor is a sensor platform that allows OEM customer to implement their own solutions quickly and easily and to cut the time to market. However, since the Movesense sensor gives companies the power to implement their own customer sensor firmware, they also need to have knowledge on things that their firmware affects outside their own customers. For customers that opt to use “productable” Movesense sample apps instead (such as our “Default firmware”) the requirements are less strict, it is still good idea to know the rest of the details. In short, this document tries to explain and list the basic requirements that the OEM customers need to fulfill when making volume orders of Movesense sensors.
From factory to customers
When the Movesense sensor is manufactured “in bulk” there are many steps and details that may not be obvious. They however pose a set of requirements that must be fulfilled for the process to be successful.
In the factory production line, the Movesense sensor hardware is first programmed with our internal production firmware. This firmware allows the production line equipment to interact with the sensor, testing all the hardware and programming necessary data to it such as product information.
When the sensor has passed all the test steps the firmware chosen by the customer is programmed on it. To program the firmware, a “hex” file format is used. Depending on the base Movesense framework version used (1.9.x or 2.x series) the file used is different. For 1.9.x the firmware is typically provided as three separate hex-files (bootloader.hex, s132_nrf52_4.0.5_softdevice.hex and Movesense_with_settings.hex). For newer 2.x series firmwares the build system combines all the necessary data into Movesense_combined.hex-file which is produced by the firmware build process.
After the firmware is programmed, the sensor is set to “power off mode with stud contact wakeup”. This internal power-off state is a one-time power-off state to guarantee that the sensor is in power off when leaving the product line. However, it is possible that further activity such as packaging or quality control steps wake up the sensor from this power off state.
After the power off, the sensors are packaged in the packaging chosen by the customer and prepared for the shipping.
The sensors are shipped first to our intermediate quality control and forwarded from there to their final destination around the world using the agreed-on shipping methods. Since most shipping methods include air cargo, the IATA rules for air freight also apply. The most important of those is the requirement to not to use radio transmitters during the flight. To comply with the requirement, it is necessary to implement a “shipping mode” in the custom firmware unless the firmware is such that it automatically goes to “non-transmitting” mode like Movesense Default firmware.
Shipping mode in firmware
If the sensor firmware is meant to stay powered on even without Bluetooth connection, the easiest way to implement the shipping mode is:
When the user is first time taking sensor into use (real mobile connection from your own app), write information in the EEPROM memory.
In the bootup, check the EEPROM memory setting to see if sensor was taken into use. If it was not, advertise for a while (e.g. 2 minutes or something) from the last WB-connection. If the sensor is not taken into use (see “1”), set wakeup to stud contact using /Component/MAX30004 -API and shutdown the sensor. For an example, see hr_wakeup_app in movesense-device-lib/samples.
Firmware update (DFU) on the field
When the sensor is in its final use, it may need to be updated to a new firmware. The firmware update should be integrated as a part of your own mobile software so that the process is as easy as possible for the final user. It is very important to test the DFU functionality of each custom firmware version before it is sent to customers for updating existing sensors or sent to be programmed on the production line to the new sensors.
The minimum list of tests that need to be performed for each new firmware:
- Test that the old firmware can be updated to the new one using your mobile application
- Test that the new firmware can be updated to another firmware (or the same) using the mobile application (this makes sure that when next new version comes the DFU should work)
- Test the current consumption of the sensor right after the DFU update and during and after possible power off.
Information for Movesense
The following information must be provided when making a bulk OEM order of Movesense sensors:
|Firmware file(s)||Either Movesense_with_settings.hex (Movesense 1.9.x) or Movesense_combined.hex file. Preferably named: CompanyAppName_FW_AppVersion_Date.hex (“SuperTzap_FW_1.2.3_2022-10-11.hex”)|
|Product Name||Name of the product that is returned by /Info -service. This string is used as a basis of BLE advertising device name (first 9 characters). Example: “SuperTzap”.|
|App Name||Exactly as written in the App.cpp|
|App Company||Exactly as written in the App.cpp|
|App Version||Exactly as written in the App.cpp|
|Confirmation of shipping mode||“Yes, shipping mode has been implemented” / “Shipping mode is not needed (goes to sleep in normal operation)”|
|Movesense framework version||As reported by the /Info -service. (e.g. “2.1.1”)|