Use sensor transfer matrix for internal and external magnetic induction sensor

[realtimepeople]

I have observed that using a 4*3 matrix for the induction sensor data acquisition solves many problems together:

• Coordinate transformation sensor -> airframe body system
• Calibration of offset and gain
• Hard- and Soft-Iron-Calibration
• Nonorthogonality compensation matrix
• Support for arbitrary orientation of the external induction sensor (if installed)

The matrix elements can be automatically evaluated when the aircraft is circling.

Integrate this method for both induction sensors and use the external magnetometer if it provides data.

[MaxBaex]

This sounds good! Is it planned to run both the internal and the external (if available) in parallel so that an individual 4*3 matrix for each magnetic sensor is maintained? The sensor could observe the magnetic disturbance of each sensor and use the better one automatically.

Is it planned to extend the *.f37 data recording file format or does the external magnetic sensor values replace the internal ones in the recorded data? The bit EXTERNAL_MAGNETOMETER_AVAILABLE in the system status bitfield shall indicate if the external magnetometer is used. I believe we need to include this status bit field in our recorded raw data?
https://github.com/larus-breeze/doc_larus/blob/master/documentation/can_details/object_directory/sensorbox.md#id-0x12a-system-state-and-git-tag

think the device shall use the arbitration process on the CAN-Bus specification and use recommended addresses below the recommended Larus Sensor IDs ( 0x120-0x12F). Streaming of Magnetic Data with ~100Hz shall not be interrupted by other (lower priority) CAN messages.

[realtimepeople]

Yes: If existing, both magnetometer readings will be used for calculation and calibration.
Presently the external magnetometer is prioritized over the internal one.

The *.f37 becomes a *.f40 to report the external induction readings.

Presently the external magnetometer reports 3 * 16bits on ID 0x160 fixed.
As we will probably never have two external magnetometers this is probably acceptable.

For the moment I did not implement the idea to switch over depending on magnetic disturbance.

[realtimepeople]

Somewhat important decision here:
Shall we output a *.f37 if no external magnetometer is recognized ?
Or always *.f40 ?

[MaxBaex]

I think we additionally need the system status bit field in the raw data format in order to know if the external magnetometer provided data and was available. This bit shall be set according to the magnetic sensor hearthbeat CAN message. The new format would thus require 41 * 32 bit = 164 Byte (peer record step)

The (*.f37 + EEPROM) Format has been stable for about 3 years now. The analysis tools Larus_to_df require *.f37 for all currently existing sw_algorithm_lib sensor_data_anylzer binaries. I would prefer to define a new "standard" format. The file extension shall not change on a update. We shall be able to identify the used format automatically and to add new formats easily.

I think it is time to discuss this issue again: larus-breeze/sw_sensor#157
I suggest to rename *.f37 to *.larusbin or *.larusdat and identify the format within the filecontent with one single 128-bit magic number (randomly created for each new format) at the very beginning of a *.larusdat file.

With that the sensor could easily switch between the different formats with and without an external magnetic sensor.

The sensor data analyzer shall be updated to understand the new format and the old format without configuration changes.

A simple python script could be used to convert the new formats to the old *.f37 in order to use the old libraries for regression tests.