Easy way to set the outputs

[YohanHadji]

I would love an easy way to set the desired outputs of the sensor. Choose which data we want to get and the main update rate.
This can be done using Xsens SetOutputConfiguration message.

Here is my suggestion, this has been tested successfully with an MTi-7

In xsens_constants.h

enum FREQ
{
    HZ1 = 0x0001,
    HZ5 = 0x0005,
    HZ10 = 0x000A,
    HZ20 = 0x0014,
    HZ50 = 0x0032,
    HZ100 = 0x0064,
};

and

// Message Identifiers for Host->MTi
enum XSENS_MESSAGE_ID_OUTBOUND
{
    MT_WAKEUPACK                  = 0x3F,
    MT_GOTOCONFIG                 = 0x30,
    MT_GOTOMEASUREMENT            = 0x10,
    MT_RESET                      = 0x40,
    MT_REQDID                     = 0x00,
    MT_REQPRODUCTCODE             = 0x1C,
    MT_REQHARDWAREVERSION         = 0x1E,
    MT_REQFWREV                   = 0x12,
    MT_RUNSELFTEST                = 0x24,
    MT_REQBAUDRATE                = 0x18,
    MT_SETBAUDRATE                = 0x18,
    MT_REQOPTIONFLAGS             = 0x48,
    MT_SETOPTIONFLAGS             = 0x48,
    MT_REQLOCATIONID              = 0x84,
    MT_SETLOCATIONID              = 0x84,
    MT_RESTOREFACTORYDEF          = 0x0E,
    MT_REQTRANSMITDELAY           = 0xDC,
    MT_SETTRANSMITDELAY           = 0xDC,
    MT_REQCONFIGURATION           = 0x0C,
    MT_REQSTRINGOUTPUTTYPE        = 0x8E,
    MT_SETSTRINGOUTPUTTYPE        = 0x8E,
    MT_REQPERIOD                  = 0x04,
    MT_SETPERIOD                  = 0x04,
    MT_REQOUTPUTSKIPFACTOR        = 0xD4,
    MT_SETOUTPUTSKIPFACTOR        = 0xD4,
    MT_REQALIGNMENTROTATION       = 0xEC,
    MT_SETALIGNMENTROTATION       = 0xEC,
    MT_REQEXTOUTPUTMODE           = 0x86,
    MT_SETEXTOUTPUTMODE           = 0x86,
    MT_REQSETPORTCONFIG           = 0x8C,
    MT_REQSETCANOUTPUTCONFIG      = 0xE8,
    MT_REQSETCANCONFIG            = 0xE6,
    MT_REQDATA                    = 0x34,
    MT_REQLATLONALT               = 0x6E,
    MT_SETLATLONALT               = 0x6E,
    MT_REQAVAILABLEFILTERPROFILES = 0x62,
    MT_REQFILTERPROFILE           = 0x64,
    MT_SETFILTERPROFILE           = 0x64,
    MT_REQGNSSPLATFORM            = 0x76,
    MT_SETGNSSPLATFORM            = 0x76,
    MT_SETGNSSLEVERARM            = 0x68,
    MT_RESETORIENTATION           = 0xA4,
    MT_SETNOROTATION              = 0x22,
    MT_REQUTCTIME                 = 0x60,
    MT_SETUTCTIME                 = 0x60,
    MT_ADJUSTUTCTIME              = 0xA8,
    MT_ICCCOMMAND                 = 0x74,
    MT_SETINITIALHEADING          = 0xD6,
    MT_FORWARDGNSSDATA            = 0xE2,
    MT_SETOUTPUTCONFIG            = 0xC0,
};

(The diff is the last line)

In xsens_mti.h

void xsens_mti_set_output( xsens_interface_t *interface, enum XDA_TYPE_IDENTIFIER outputList[], size_t len, enum FREQ freq );

In xsens_mti.c

void xsens_mti_set_output( xsens_interface_t *interface, enum XDA_TYPE_IDENTIFIER outputList[], size_t len, enum FREQ freq)
{
    xsens_mti_request( interface, MT_GOTOCONFIG );
    xsens_packet_buffer_t packet = { 0 };
    
    packet.message_id = MT_SETOUTPUTCONFIG;
    packet.length = 4*len;

    // Split outputList into 1 byte chunks
    for (int i = 0; i < len; i++) {
        packet.payload[4*i] = (outputList[i] >> 8) & 0xFF;
        packet.payload[4*i+1] = outputList[i] & 0xFF;
        packet.payload[4*i+2] = (freq >> 8) & 0xFF;
        packet.payload[4*i+3] = freq & 0xFF;
    }

    xsens_mti_send( interface, &packet );
    xsens_mti_request( interface, MT_GOTOMEASUREMENT );
}

In main.c

enum XDA_TYPE_IDENTIFIER outputList[]= {XDI_LAT_LON, XDI_QUATERNION, XDI_TEMPERATURE, XDI_UTC_TIME, XDI_ALTITUDE_ELLIPSOID, XDI_BARO_PRESSURE,XDI_VELOCITY_XYZ,XDI_STATUS_WORD};

When needed :

size_t outputListSize = sizeof(outputList)/sizeof(enum XDA_TYPE_IDENTIFIER);

// Setting for the sensor: fill the outputList with desired data, the last parameter is the rate:
// Available rate, HZA = A Hz rate. 1, 5, 10, 20, 50, 100Hz are available. Defined in xsens_constant.h

xsens_mti_set_output( &imu_interface, outputList, outputListSize, HZ1);

Let me know if I can help getting this cleanly integrated.

[Scottapotamas]

Sure. The general design goal for this library is compatibility across the range of hardware - the specific implementation might look a bit different from your example snippets so I can't promise you the API surface will look the same...

Are you able to produce some packet captures for your MTi-7 for when you configure this, it'll help me write/check test coverage beyond the model I've got on hand.

• Something like a Saleae Logic/Sigrok capture file, pcap, or text dump of (ideally hex formatted) bytes sniffed would be great.
• If you need help, I can write a Arduino sketch to dump traffic over another serial port.

I'll look at integrating 'general configuration' functionality over the next few days if that's OK? It's a little bit of work to get my spare mti-300 on the bench, add other kinds of configuration fields, etc...

[YohanHadji]

Cool, Yes I can do packet capture, actually I had do very basic packet capture to create the example provided above.
The way I've been doing it is by adding some code in the callback functions to print or save what goes through the interface in both directions.

I can also add another arduino/teensy between the sensor and the host to capture the packets without having to modify the code on the host to capture packets. Saving it on a text file with the HEX format is well at my level. I'm unsure about the two other formats.

My exemple code doesn't include any check on the ack sent back by the MTi sensor. I guess the most important thing to check is that the sensor didn't respond with an error code. An error code that would respond to an invalid configuration request.

At this point after a few days of thinking about it I'm unsure how we should handle this in the configuration. The main challenge is that not all settings are available for all sensor models. So a clean implementation would require a library of all available settings for each sensor model, and the user would have to set the sensor model at some point.

This is adding a lot of complexity on what was initially just a driver/parser for the multi-platorm low level communication protocol from Xsens.

Maybe this configuration tool should be on another (higher) layer level than your current library. Let me know what you think about it.

[Scottapotamas]

I don't see the implementation and approach for this kind of behaviour as an issue, but a chunk of it will be handled by the end-user of the library.

This is less about what configurations are valid for a specific model - adding compile-time compatibility tables can solve it reasonably cleanly (but adds some long-term maintenance overhead as new models are added), but because I aim to keep the library free of internal queues and automatic response catch behaviours for portability reasons.

I should have time to get a first-pass implementation ready this weekend, and I'll see how much scope creep comes out of that...

---

On a higher-level note: does your system design need dynamic configuration or is this a nice-to-have during development? On my platforms it's been a one-time configuration with MTManager and then I've not had to touch the sensor/interaction code since.

[YohanHadji]

On a higher-level note: does your system design need dynamic configuration or is this a nice-to-have during development? On my platforms it's been a one-time configuration with MTManager and then I've not had to touch the sensor/interaction code since.

I see a few different points:

• MTi 1 series dont have a USB interface by default to connect to MTManager. (Hardware DK do provide one tho)
• MTManager is only available on Windows and Linux, that's the main reason I had to find a way to configure my sensor the hard way.
• I guess it's also a nice thing to have during development to test different configurations with your code without having to hook your sensor to a PC.
• I would also prefer not have to go through configuring 100 units one by one with the MTManager app if one day I have to.
• Even if the configuration is saved onboard, I'm feeling better with checking the configuration of the sensor at every reboot (by rewriting the configuration).

[Scottapotamas]

@YohanHadji if you've got a spare minute I'd appreciate your thoughts on https://github.com/Scottapotamas/xsens-mti/tree/config.

The Arduino example write_config describes how to use it (the sketch is untested, but the underlying implementation is unit and hardware tested).

[YohanHadji]

@Scottapotamas Thanks a lot for the implementation, I have been busy working on other hardware last week and will also be next week but I'll try to take a look at the code and test it.