TFUNIPAYLOAD01

TFUNIPAYLOAD01 - universal interface for sensor payload

Reference design of PX4 interface for generic TF-ATMON compatible payload. The purpose of this design is to connect a sensor to the TF-ATMON system, despite that the sensor does not have any driver in the flight stack (autopilot firmware), but at the same time, it is required for atmospheric measurement.

The sensor is connected to the TFUNIPAYLOAD board using a UART, I2C, GPIO, ADC, or SPI interface. ATmega in TFUNIPAYLOAD01 runs the Arduino firmware, which prepares MAVLink messages to be logged and transported to GCS running TF-ATMON infrastructure described in the block schematics.

Example of use

FMU firmware (PX4 or Ardupilot, for example) is capable of logging MAVLink data from the UART (Telemetry Port). Therefore, the “UART Peripheral” connector on TFUNIPAYLOAD01 is intended for connecting a UART-based FMU using the Pixhawk DS-009 telemetry pinout. Typical devices include flight controllers (autopilot) or companion computers.

Pixhawk standard connector pinout is as follows:

For data to be received by the PX4 autopilot, it must have a specific form. Explicitly, it needs to use a serial link with MAVLink v2 packets. In that case, the Tunnel (#385) packets will be stored in the autopilot's log file and forwarded to the GCS. The TFUSBSERIAL01 hardware could be used to easily check for correct wiring.

The following library c_library_v2, which is automatically generated from message definition files, could be used.

Firmware examples

There are multiple Arduino-based firmware examples for different use cases.

TFUNIPAYLOAD

TFUNIPAYLOAD.ino contains a basic example, which listens to MAVLink messages from the autopilot and sends tunnel packets with random data to the autopilot.

TFUNIPAYLOAD_MINIMAL

Since message parsing requires a lot of memory, we have prepared an example where only HEARTBEAT and TUNNEL messages are sent. This example does not require a connected TX (from autopilot), and it is, therefore, suitable for MCUs with less memory.

Source code: TFUNIPAYLOAD_MINIMAL.ino

Tunnel packet sending function

Tunnel packet sending function mav.SendTunnelData(data, sizeof(data), 0, 1, 0); is the main function that enables sending tunnel data to the autopilot. It takes the following as its arguments:

• data in uint8_t [127] format
• data length
• data type (every type of logged data will have its ID - it serves for easy differentiation of different sensors
• target sysid
• target compid

If the data only needs to be logged, the target sysid and compid must match the autopilot’s address, which is usually sysid: 1, compid: 1. If the data has to be logged and sent to GCS, broadcast must be set: sysid: 1, compid: 0 or better sysid: 0, compid: 0.

The autopilot only has a limited amount of storage memory (SD card), and it is therefore necessary to ensure, on the payload’s side, that it does not fill up during the flight. Alternatively, a maximum bandwidth on the MAVLink interface can be set in the autopilot. It is not tested what happens when the level set is exceeded[2021/09].

Autopilot configuration

In the autopilot’s PX4 firmware, it is necessary to correctly set the following parameters (MAV_1_FORWARD and others will be visible only after setting the parameter MAV_1_CONFIG and rebooting the PX4):

How to set the parameters in PX4 is described in manual.

How to check that the autopilot correctly receives MAVLink messages?

There are several options to find out whether the message sending is working correctly.

Using the QGC

The message can be easily viewed live in QGC. For this procedure to function, two conditions must be fulfilled.

1. The message must be broadcast, meaning the message must have set its target sysid and compid to 0, 0.
2. The computer must be connected via a MAVLink instance that supports message forwarding (e.g., via TELEM1 port using modem or UART-USB converter); autopilot's USB does not support it.

Warning: this procedure will not work if the autopilot is connected via a USB cable to the Pixhawk's USB port.

After opening QGC, connect the autopilot to the computer (via RF modem or an external USB converter connected to the serial port). Once the autopilot is connected, live data (such as autopilot attitude) will become visible. A subsequent click on the QGC logo in the top left corner will open a menu where you select Analyze tools and then open MAVLink inspector in order to see a list of all messages.

The list of messages, when functioning correctly, should contain TUNNEL messages.

Using the MAVLink PX4 console

An advantage of connecting via PX4 console lies in its independence from broadcasting settings and the possibility of checking whether the message is received and parsed by the autopilot. If the message is visible here (and the logging is enabled), it is at the same time already logged. With this procedure, a USB cable connection to the autopilot can be used.

Autopilot console can be entered using the following Python script or using QGC.

• In the case of using a Python script, it is enough to run the python3 script with a parameter of the chosen serial link to which the autopilot/modem is connected.
• In the case of using QGC, the QGC must be opened in the autopilot console by clicking on the QGC logo (on the top), choosing Analyze tools, and choosing a console.

The received message can then be retrieved using the following command:

listener mavlink_tunnel

The command displays the current tunnel message. Adding the -n 100` parameter will cause a listing of 100 messages (and the new message will display by itself).

If the communication is working properly, the output should look like this:

From a uLog file

The tunnel message can be logged into autopilot in a standard uLog format. However, because tools like Flight review are unable to display such data format, it is necessary to overcome this problem using a suitable tool. One option is using the PlotJuggler. Another possibility for opening the log is the Jupiter notebook.

Known limitations

• Avoiding overloading the autopilot's memory with messages must be ensured on the payload side
• A maximum of 2 devices + modem or 3 devices without a modem can be connected in this way. The limitation is caused by the MAVLink driver, which is only able to connect a maximum of 3 instances of MAVLink devices, and also due to the limited number of UART interfaces of the autopilot.
• It is not possible for the input of payload messages and output to sik modem to have the same type of MAVLink messages (stream) that would differ only in the number of messages per second. This means that it is not possible to simply select a data stream to be transmitted to the ground from the data stream intended for logging. If it is necessary to log more detailed data (with higher frequency) another MAVLink message must be logged.