NT Data Logging
The information on this page refers to firmware v2.56e and higher.
A data logger, the NT Logger, can be connected to the NT bus, which allows us to record on a micro SD card a substantial amount of data. The data are recorded for each cycle of the controller loop, i.e., with the maximal possible time resolution. The NT Logger is quite small and can be easily mounted on any vehicle. This way one can get highly accurate and informative data taken during a real flight condition. The same data can also be recorded on the ground, without the need of a NT Logger, using the live-recording feature.
The data logging option allows us to diagnose any in-flight troubles, such as jello or micro vibrations in the video, and find solutions to resolve them. It also suggests many other applications. For instance, one may use it to dynamically balance the motors and propellers.
Comment: The data logger must be a NT Logger; any other logger, such as the widely available OpenLog and its derivatives, cannot be used.
NT Logger Modules
Micro NT Logger Module v1.32
The Micro NT Logger module has the RTC integrated and uses a replaceable battery cell.
NT Logger Module v1.3
This NT Logger module can be extended by connecting a RTC (real time clock) module to its I2C port. Any RTC module which is based on the DS3231 chip can be used. However, the "Raspberry Pi Mini RTC module" is most recommended, because of its low cost and tiny size. In fact, the NT Logger v1.3 PCB is designed specifically for that module.
Comment: The battery on these RTC modules lasts for about 1.5 years, but is not chargeable. That means that after that time the RTC will either not work anymore or needs to be replaced, which is quite a pain to do.
The micro SD card must be formatted with FAT32. The firmware author uses the Windows tool. Using the SD Association formatting tool didn't yielded any noticeable advantage.
The micro SD card should be of very high speed. Unfortunately, not any card works equally well. This experience is available:
|micro SD card||experience||reported by|
|SanDisk Extreme Micro SDHC 32GB Class 10 UHS-I UHS-Class 3 V30 A1-L (SDSQXAF-032G-GN6MA)||excellent, nearly no missing frames||OlliW|
|SanDisk Extreme Micro SDHC 16GB UHS-I Class 10 U3||very good, missing frames of ca. 0.1%||OlliW, GekoCH|
|SanDisk Ultra Micro SDHC 16GB UHS-I Class 10 HC1||very good, missing frames below 0.1%||OlliW|
|Kingston 8GB HC class 4||bad, missing frames of ca. 20%||OlliW|
|Kingston 32GB HC class 4||bad, missing frames of ca. 20%||OlliW|
The NT Logger module can be equipped with a RTC (real time clock) module to its I2C port, and the Micro NT Logger has it already on board. This makes it possible to append the data file names with a precise date&time stamp, which makes identifying the data files on the SD card much simpler. This little feature is in fact so useful, that one wouldn't want to miss it once one has used it once :).
The RTC module must be configured before it can be properly used, i.e., the current date and time must be written to it at least once. This can be conveniently done via the GUI: Go to themenu and call the .
For analyzing the recorded data, the NTLoggerTool is available, providing tools such as FFT, and others. The NTLoggerTool also allows us to record directly the data on the NT bus using a USB-TTL adapter; a feature called live-recording. It enables many work-bench tests and procedures.
The NTLoggerTool is steadily advancing and any manual would be quickly outdated. For a discussion it is best to join the STorM32 NT thread at rcgroups.
The NTLoggerTool is open source (GPL3). Anyone is highly welcome to contribute to it.
The data logger "spies" on the STorM32's NT Tx line, i.e., is capable of recording all data transmitted from the STorM32 to the NT modules. The points in the controller loop at which data are "sampled" are indicated in this sketch:
The actual data which are emitted by the STorM32 controller can be adjusted with the parameter, found in the window. It is a bit mask, and allows combining these options:
|“basic”||SetLogger, CmdAhrs, SetMotorAll, CmdEncoderData, CmdStorm32LinkData|
|“acc + gyro raw”||CmdAccGyroRaw for Imu1 & Imu2|
|“acc + gyro”||CmdAccGyro for Imu1 & Imu2|
It can happen that not all data can be transmitted in one cycle, if the computational load in that cycle is too high to support the full data rate. This typically occurs with both 2nd IMU and full data logging enabled. In that case some data might be simply missing in the log file.
Also the data rate of the micro SD card represents an obvious limitation. If the SD card cannot keep up, frames (the data of one controller cycle) will be lost. Lowering the logging can alleviate that a lot.
For vibration analysis, the experience so far shows that the “acc + gyro raw” and “pid in” data are most useful. It is thus recommended to have these enabled. The “pid” and “acc + gyro” data are comparatively less useful for that purpose.
It is also possible to "spy" on the STorM32's NT Tx line using a USB-TTL adapter, and record the data using the NTLoggerTool. The feature is somewhat analogous to the DataDisplay in the STorM32 GUI, except that it records much more data and moreover at full speed, with maximal time resolution.
The USB-TTL adapter must be capable of handling 2.000.000 bauds. Adapters with FT232RL (FTDI) work out of the box. Adapters with CP2102 may be configured to do so, see How to configure CP2102 USB adapters for high baud rates. The firmware author has much better results with a CP2102-based adapter. His FT232RL adapters appear to have problems with keeping up with the high data rate (it's about 1Mb/s), yielding many data gaps, while with a CP2102 adapter no data are lost.
The USB-TTL adapter is connected to the NT bus as follows:
USB-TTL adapter GND -> STorM32 NT GND USB-TTL adapter Rx -> STorM32 NT Tx USB-TTL adapter Tx -> do not connect
The USB-TTL adapter's Tx line must not be connected to the STorM32's NT Rx line, i.e., should be left floating.
Various metrics measuring the execution time of some parts of the code.
Angles of IMU1, or the camera, respectively, as also visible in the GUI. These are the angles as they are coming out of the IMU1 AHRS and enter the PID and axis coupling calculations.
Angles of the 2nd IMU (IMU2), as also visible in the GUI. These are the angles as they are coming out of the IMU2 AHRS and enter the PID and axis coupling calculations.
Encoder angles, as also visible in the GUI.
PID controller error and setpoint angles.
PID controller output.
Various metrics related to the IMU1 AHRS.
State of the controller, as also visible in the GUI. 0 = StrtMotors, 1 = Settle, 2 = Calibrate, 3 = Level, 4 = MotorDir, 5 = Relevel, 6 = Normal, 7 = FastLevel
Error counts on the NT bus, as also visible in the GUI.
Battery voltage, as also visible in the GUI.
Accelerometer and gyroscope measurements of IMU1. These are the data as they are coming out after the calibration, bias, filter, and orientation corrections, and enter the IMU1 AHRS.
Accelerometer and gyroscope measurements of IMU2. These are the data as they are coming out after the calibration, bias, and orientation corrections, and enter the IMU2 AHRS.
These are the raw accelerometer and gyroscope data, as they are coming out of IMU1, before any other processing. Note that therefore the x,y,z axes refer to the orientation of the IMU1 chip, and not the STorM32's x,y,z axes from which the angles are derived, as the orientation correction has not been passed by these data.
These are the raw accelerometer and gyroscope data, as they are coming out of IMU2, before any other processing. Note that therefore the x,y,z axes refer to the orientation of the IMU2 chip, and not the STorM32's x,y,z axes from which the angles are derived, as the orientation correction has not been passed by these data.
Temperature of IMU1, IMU2
Motor angles as they are send to the motor drivers.
Vmax for each motor axis.