larus-breeze / sw_sensor Goto Github PK

I have observed that we still have some ferromagnetic material around the sensor.
Magnetizing this material shifts the offset of the sensors by a few percent.
This is an issue, example: An offset change of the sensor channel pointing east of 1%
results in a heading-error of 1.4 degrees in Germany with 65 degrees of mag. inclination !

Even pure soft-magnetic stuff will create some variable parasitic induction.
We shall therefore avoid to put any ferromagnetic material like screws etc. around the sensor.
If possible we shall demagnetize the complete setup after assembly.
The disturbance from interfering magnetic fields from the airplane is another issue.

Our automatic magnetic calibration can reduce hard-iron effects pretty well.
Soft-iron effects impair the orthogonality of the magnetometer channels,
are very hard to detect and can (by now) not be eliminated by the firmware.

measure, compensate and display. Variation/Declination and inclination!

A fixed value for one location might be unsufficient for long flights and or usage of the variometer in a different geografic location.

Can the UBLOX GNSS provide this information?

Reveice RS232 data and mix to bluetooth data for XCSOAR /OPENSOAR.

Provide a configuration option for a unique Bluetooth / Wifi name, baudrates.

Read vom SD Card? Store in Flash memory?

• Bluetooth Name setting

• Calibration parameter for cheap IMU (Identify by using the STM32F4s UUID)

• Mode (1 GPS, 2 GPS, ) , Low-Cost IMU, High-Cost IMU (or just use High-Cost if available)

• Add a configuration file parser: https://github.com/zserge/jsmn https://github.com/DaveGamble/cJSON ...?

• Will there be some system configuration which affects the behaviour of the vario?

• Trigger a reconfiguration of the bluetooth module in case a new name is provided via the SD configuration file.

Make the logger delete the oldest log files if there is not enough space for new recordings.

Es sind 32 statt 16Bit integer Werten.

Presently a virgin sensor MUST have read a meaningful set of
configuration parameters as defined in the standard file sensor_config.txt.

We need to program something that make the sensor not to crash if no such file has been seen.

The Cortex M library handles the lowercase assert() incorrectly by calling __assert_func(...) in the library.
We need to avoid this somehow because it will not report errors similar to our uppercase ASSERT(...)

This configuration:
COMMON uint16_t VirtAddVarTab[NB_OF_VAR];
#define NB_OF_VAR ((uint8_t)0x03)

and not using the VirtAddVarTab causes that all EEPROM parameters will be lost once the system initiates a flash page transfer.
We probably haven't seen this yet as we are not writing a lot via the EEPROM emulation and one page contains 16KByte of data!

Only the EEPROM Parameter with the Virtual Addresses which are defined in the VirtAddVarTab will be copied during a EE_PageTransfer();

EEPROM_PARAMETER_ID needs to be mapped to VirtAddVarTab and NB_OF_VA!

All code written around the AD57 relies on a common schema to denote and display version information : "V major.minor.build".

Inside the sensor code there is a analoguous yet slightly different mechanism implemented with the <git-post-action.sh>-file.
This bash file, when called, creates a sourcefile "git-commit-version.h" using info from a file called <git-commit-tag.h>.

In order to streamline and combine this solution with the versioning in AD57 files, I have suggested an add-on on how to build the required #define in git-commit-version.h.

This proposal works seamlessly with the sw_sensor code as it stands.

All information on behalf that enhancement (bash code, CAN_output.cpp code snippet) has been forwarded to Max and Uwe, in order for them to proof-read and then to integrate these inputs.

I think it would be wise that I not tinker with the holy cow, that I better leave that to the Äkspädden.

MCready, Volume changes shall be communicated bidirectional between AD57 and a via Bluetooth or RS232 connected XCSOAR device.

Requires a Serial <-> CAN bridge.

Logger task writes every 10ms to the sd card.
SD cards sometimes need longer for a write access due to internal page or wear leveling algorithms. This could potentially cause data loss.

The observed offset and gain differences are around 2%.
Therefore it will improve the system performance slightly
if we would individually calibrate the accelerometers.

If we would calibrate the magnetometers at the same time
before installation in the aircraft we could get an idea
about the magnetic environment based on the
intensity of the magnetic induction after installation.

With a simple 6 state calibration-procedure this can be done
in one process semi-automatically using a manually triggered
calibration program within the sensor firmware.

The sensor software shall not know anything about a certain airplane. There shall be one generic software for all configurations. Airplane configuration shall be done via the SD card configuration parameters.

Also remove "// sensor orientation SteFly" configuration from system_configuration.h

The current git hash shall be compiled into the software so that we can track the currently flashed version.

• start flight data logging only when e.g. vtas > 60kmh (test via simulated pitot pressure)
• stop flight logging when vGround & vTas < 40kmh for at least 1 minutes to also capture the landing and to be robust for high wind wave or acrobatic flight conditions.
• After landing: close the flight data recording file, write latest sensor calibration values to the eeprom and dump to sd card.
• Shall there be a feature to enable continuous logging via a sd-card configuration file?

CAN paket reports "1" (== GPS_OK), when at the same time GPS status is better (GPS_2D or GPS_3D ...)

At least, pressure-dependent density has to be used.
Better: Use density from pressure vs. GNSS-altitude observations.

Design and implement the firmware for the ESP32 communication module.

• Decide for Wifi or Bluetooth as the used wireless communication interface

• Provide a configuration option for a unique Bluetooth / Wifi name, baudrates.

• All data received on U1 (from the STM32) shall be transmitted parallel via Wifi and U2 (RS232 converter)

• Idea: There could be a bridge between the RJ45(RS232) and the Wifi/BT interface. E.g. to bridge data from a Flarm to a connected smartphone.

• Later and ambitious: The STM32 could be flashed from the ESP32 via UART.

• https://github.com/larus-breeze/hw_sensor/blob/master/design/uart_bluetooth_rs232_wiring_concept.png

• https://github.com/larus-breeze/hw_sensor/blob/master/media/v2.0_schematic.pdf

• Which NMEA data is therefore used from OpenVario / XCSOAR.
• Output via Bluetooth / USB.
• Which device drivers are parsed as Generic from XCSOAR and which do require a specific driver setting?

Events shall be logged to the SD card.

• Measurement values of all Sensors
• Unexpected events. (I2C_Errors, GNSS Reception Gaps,
• Is it possible to log a hard fault, mem fault, bus fault to the sd card? May use a Watchdog and some Noinit RAM?

Status shall be reported via the LEDs:

LED1: SD-Card

• 1/s when writing to card.
• Off if card not available / missing.
• 5/s sd card problem. (Not possible to open a file or card full)

LED2: System State

• 5/s: Waiting for GNSS Fix and initialization. Error if state persists for more than a minute. GNSS might be unconfigured.
• On system active and landed. (e.g. Airspeed below <50kmh)
• 1/s system active and airborne. (e.g. Airspeed above >= 50kmh

LED3 To be defined.

Blink all 3 leds quickliy if not all required hardware components work as expected.

• MS5611 static pressure
• Differential pressure
• GNSS data
• SD-Card logging
• xSense MTi1

Write to the SD-Card which components failed.

In has been observed that the accelerometers of the Mti1 are not precisely calibrated.
Offset and gain vary by some 1-2%. At least for the channel(s) that are used
for the aircraft's down axis a calibration will give some improvement for the
AHRS and the variometer.

The calibration can probably only be done manually on the ground.

We shall add a possibility to calibrate the accelerometers similar to the magnetic calibration.

Here: https://github.com/larus-breeze/sw_sensor/blob/master/configuration/README.md
With these configurations files: uBlox_M9N_75ms.txt
Ardusimple_Heading_Huckepack_100ms.txt
Ardusimple_Heading_Baseboard_100ms.txt
Using the software https://www.u-blox.com/en/product/u-center

This sentence is obsolete.
XCSoar is constructed to use the wind vector (its own or extern), geo coordinates and IAS -- to derive heading.

If the sentence $HCHDM is in the data stream, XCSoar ALWAYS uses this as heading, no matter what the the choice on wind is, no matter how wrong that data is.

XCSoar is better off without that sentence.

URGENT !!!

• all uarts as isr configured by default.
• test RS232 via Loopback
• GPS might be DMA for RX.

Checked in CAN_Data_Receiver with
ASESRT ( TurnRate >= 0.0 );
The ASSERT never fired.

Change configuration here: https://github.com/larus-breeze/sw_sensor/blob/master/.gitmodules
As cloning via ssh requires a personal configured ssh key in Github which represents an unnecessary entry barrier.

Some hardware will have a single GNSS receiver, some will provide a precise heading by a differential second GNSS receiver.
The sensor shall use the best system available. differential GNSS heading if available, otherwise magnetic heading.

Proof that it works via acceleration cross-product between INS-ACC and GNSS-ACC during circling and that it is robust against magnetic variation and not precisely mounted device.

AD57 part for communication is built and tested with emulation with audio board. The Sensor side part needs to be implemented. CAN packet IDs are defined in Generic_CAN_Ids.h in AD57 SW.

Issuing a reset by pressing the mechanical reset button on the pcb causes a MemManage_Handler fault in some situations.

Root cause unclear. Could cause a potential stability problem if resets are happening during power on due to a instable power supply.

Observed with commit: ee8bd2c

Design and implement a new folder structure for the sources.

Idea:

• Application (For all active objects which create a FreeRTOS task)
• Custom / Algorithms(math, matrix, buffer, vector, ascii, ...), Core(System / Board FreeRTOS configuration), Drivers(interface and device drivers), Navigation(AHRS, INS, VARIO classes)
• Middlewares (All generic libaries and included sources which are mainly untouched)

While the Single-GNSS on the master sensor board has no GPS-fix (yet), the sensor SW sends a "0" status for the Single-GNSS. That is semantically incorrect, as the GNSS devoce is up and works correctly. So the status should be send as "1". The fact that the Single-GNSS has no fix yet should be properly reported in the CAN packet
c_CID_KSB_GPS_Sats = 0x10a, //!< uint8_t No of Sats
//!> uint8_t Fix-Type NO=0 2D=1 3D=2 RTK=3

EASA has published the protocol for ADS-L on 868 Mhz in this document:
https://www.easa.europa.eu/en/downloads/137503/en

We can easily add the capability to receive and even transmit ADS-L packets
using a SRD chipset wired to our SPI port.

This means that Larus can also provide air-safety information including
sending and receiving data compatible to FLARM.

CDC_Transmit sends a string of bytes via USB. The functions does not check if the previous transfer has finished. A propper FreeRTOS Queue is required feed the USB driver with new print outs.

are written when they changed significantly or if accuracy improved.
TODO: check this frequency of writes or better couple with #45 and always write after landing

• Add GPL3 headers with our project name to own source files.
• Provide a short markdown manual for how to configure a sensor via the sd-card parameter file:
  • What is important when mounting the sensor into the airplane
  • Mount orientation
  • GNSS variant
  • Magnetic Variation / Declination. The manual shall explain if the pilot must reconfigure the variation values in case the airplane travels e.g. to south africa, australia , ..

Port and Integrate driver.

Das Problem ist das in der aktuellen Version der include nicht sauber abgeschalten wird:

Core/Inc/FreeRTOSConfig.h

//#define configUSE_TRACE_FACILITY 1
...
#if configUSE_TRACE_FACILITY
#include "trcRecorder.h"
#endif

Man muss entweder das if in ein ifdef ändern oder darf den vorderen Teil nicht auskommentieren.

Vorschlag
c_CID_KSB_MagMem_Quality = 0x118, //!< int16_t as float [???] * 10

Anekdotisch : Beim Butterfly war das ein Integer in der Range [0-9], mit 9 als bestem Wert

über XCI oder über geeignetes Protokoll