1. according to the mtlt datasheet, mtlt pin4 (blue wire) is rx and pin5 (white wire) is tx;
2. Is the following connector a female one? If yes, mtlt pin4 (blue wire) rx should be connected with pin3 (rx) of the female db9, and mtlt pin5 (white wire) tx should be connected with pin2 (tx) of the female db9. For the female db9 and the male db9 of the rs232-usb connector, it is rx to tx and tx to rx.
   
3. The RS232 communication is silent by default. After connection established, there may still be no data. But the red in the following fig will turn green. And then you can use nav-view-->configuration to set an ODR to the output data.
   

If this still cannot solve your problem, please make sure the rs232-usb works. And I can get an application engineer to help you.

The latest version of Nav-View can be downloaded from https://navview.blob.core.windows.net/web-resources/NAVVIEWV356.zip.
MS .NET Framework 4.0 is also included in the .zip file.

For RS232 connection, one possibility may be:

1. The USB-RS232 connector has a male DB9;
2. The MTLT unit RS232 port is connected to a cable, and the cable has a female DB9;
3. The cable is connected to the USB-RS232 connector.
   Then, you need connect RX of MTLT to RX, and TX to TX of the cable.

If this is not the case, please provide more details about your connection. A picture will help.

@huhujiajia , from your picture, I found you already have the INS algorithm. You can find the fusion algorithm here in the following picture. Yours might be slightly different from mine becasue I am on a dev branch.

This is already in our plan for next release.
Thank you for your feedback.

You are welcome.

1. Please first confirm the GPS receiver is correctly connected to the EVK.
   .

2. In TaskGps() in TaskGps.c, please track if it can run into GPSHandler()-->_handleGpsMessages(), and the data is decoded as desired, which is NMEA in you case.

switch(GPSData->GPSProtocol){
            case NMEA_TEXT: 
                parseNMEAMessage(tmp, gpsMsg, GPSData);
                break; 
            case NOVATEL_BINARY:
                parseNovotelBinaryMessage(tmp, gpsMsg, GPSData);
                break;
            case UBLOX_BINARY:
                parseUbloBinaryMessage(tmp, gpsMsg, GPSData);
                break;
            default:
                break;
                }
        }

3. Please notice, NMEA is not recommended because it lacks some required info.

OpenIMU open-source code has built-in support for the following GPS protocols:

• NOVATEL_BINARY
• NMEA_TEXT
• SIRF_BINARY
  However, NMEA is not recommened since it lacks some infomation required by the fusion algorithm.

A framework to support other GPS protocols is provided. Users can refer to driverGPS.c for details.

Generally a GPS receiver should provide information to fill the members of the following struct:

typedef struct  {
    int                  gpsValid;   // 1 if data is valid
    uint8_t              updateFlag;    // 1 if contains new data
    
    double               latitude;   // latitude ,  degrees 
    double               longitude;  // longitude,  degrees 
    double               vNed[3];    // velocities,  m/s  NED (North East Down) x, y, z
    double               trueCourse; // [deg]
    double               rawGroundSpeed;    // NMEA kph, SiRf m/s - change to m/s
    double               altitude;          // above ellipsoid [m]
    double               GPSSecondFraction; 
    float                altEllipsoid; // [km] altitude above ellipsoid for WMM

    uint32_t             itow;         // gps Time Of Week, miliseconds
 
    uint8_t              GPSmonth;     // mm
    uint8_t              GPSday;       // dd
    uint8_t              GPSyear;      // yy last two digits of year
    char                 GPSHour;      // hh
    char                 GPSMinute;    // mm
    char                 GPSSecond;    // ss

    float                GPSHorizAcc, GPSVertAcc;
    float                HDOP;
} gpsDataStruct_t;

I never use _GenerateDebugMessage for debug message. Usually, I write my own code for debug message output.
What I mean by ODR is the ODR of user serial port. You can use our web GUI to set the ODR, or you can prepare your own code to do that.
For web GUI, you can refer to:
https://openimu.readthedocs.io/en/latest/tools/ans.html
https://developers.aceinna.com/connect.

Do you directly download the firmware bin or source code? If the source code, you can change the GPS protocal in UserConfiguration.c. The following picture shows the one I am using for development.

const UserConfigurationStruct gDefaultUserConfig = {
    .dataCRC             =  0,
    .dataSize            =  sizeof(UserConfigurationStruct),
    .userUartBaudRate    =  230400,
    .userPacketType      =  "e2",
    .userPacketRate      =  100,
    .lpfAccelFilterFreq  =  25,
    .lpfRateFilterFreq   =  25,
    .orientation         =  "-Y+X+Z",   // the EVB connector pointing forward
    .gpsBaudRate         =  115200,
    .gpsProtocol         =  UBLOX_BINARY,
    // add default parameter values here, if desired
    .hardIron_X          = 0.0,
    .hardIron_Y          = 0.0,
    .softIron_Ratio      = 1.0,
    .softIron_Angle      = 0.0
};

If the bin file, I need to ask for firmware engineers' help to see if there is commands to change the settings online.

I think there are a few things to do.
First, make sure the timer is correctly increased at each step. If the ODR is 20Hz, timer increment should be 50ms. From the picture, the timer increment seems to be 50ms. But there are repeated timer in the output of each channel. This is not right.
Second, make sure the ODR is really 20Hz and fix the issue of repeated timer. That means each port can output timer you desire （+50ms each time）even if they are not synced.
Third, a sync mechanism should be added if sending data via two ports is implemented in two tasks, or you can do this in one task.
Finally, just a reminder: make sure you are outputing the same timer.