Issues with M10 GPS via CAN Bus

I’ve been having flakiness issues with the GPS on a M10-l4-3100 module that I have connected to a LUX H7 board via CAN, sometimes I get 20 Sats other times nothin. I contacted Matek and they recommend I try

which appears to be a small pre-compiled module. My question is how to I load this with 4.3.0?

Thank you!

Update: I found the mechanism for updating the device, very cool but a bit buried, I had completely misunderstood what I was looking at. Sadly it didn’t help, I think my module is a bit dodgy, won’t be dusting off with it anytime soon.

This has been brought up in the Developer meeting
Probably make sure you set GPS_GNSS_MODE to the minimum number of constellations that work reliably for you, no more than two.

Or try Master V4.4.0-dev as a fix has been merged. You may not want to fly on Master but it could give you an indication that it is indeed the problem.

Another Update: I’ve tried the new AP_GPS firmware & 4.4.0, not much has changed except that now I max out at about 9 sats with crappy HDOP. I’ve got a another model sitting right next to it with an M9-5883 (serial), Lux H7 running 4.3.0 that gets HDOP under 1 in 1:40. I believe this is a hardware problem (with this particular unit) that only a new one will solve. Thank you!

It will likely get attention soon as there is a Dev proposal to acquire a couple of these and do some fast auto mission work with them.

Yet another exciting update:

This information was provided by Matek support.

desolder these 2 resistors to disconnect UART connection between M10 module and STM32L431 MCU


then connect RXD TXD G 5V to a USB-TTL adapter. connact M10 module to u-center


After doing this, solder back that 2 resistors, or bridge the resistor pads with a drop of tin.


This is nice information because it allows one to talk to the M10 directly with the ublox center software. I’m pretty sure the unit I have is defective and I’ve replaced it with an M9N-5883 but the M10-L4-3100 is a pretty cool, inexpensive CAN bus solution (3 peripherals with 4 wires) if it worked.

1 Like

Same here. received the Mateksys M10-L4-3100 few days ago. Connected to FC Matek H743 Wing v3 and the FC Matek H743 slim V3 . Both still on the bench and loaded with FW ArduPlane. No GPS -Fix yet with both FC. All other older GPS units connected to a Cube -orange and also a Pixracer are having excellent fix in the same environment. I am pleased I found your explanation here and will follow closely your topic. There is definitely something wrong with the M10-L4-3100 I have here.

Is anybody around who purchased that M10 L4-3100 and has it working fine?

I think Matek are going to send me one

1 Like

Thanks Andy.
BTW - I did comment to you at YouTube yesterday.

Today I had another look at my new Matek M10-L4-3100 CAN-GPS.
I connected it via CAN to an old Pixhawk Cube black out of a TREX Helicopter 600 which is dismantled. Upgraded the FC to copter FW, the latest stable.
The MatekGPS worked as the GPS2, now without a problem. GPS 1 is a very old original 3DR-GPS. Both had 3D-fix at the same time after about 10 minutes. Still on the bench but the Matek GPS M10-L4-3100 seams to be not faulty what I can see. I want to use it in a plastic-Plane which I am going to 3D print. That will take me a long time.

So its working now? Or is something still broken?

It definitely works connected to the Pixhawk Cube Black. Have not tried again with the Matek H743 Slim V3.
I am sure most likely that I have done something wrong with the Matek FC, will find out.

Any news, info or solutions to this thread? I have problems with the same h/w: Matek H743 Wing V3 + Matek M10-L4-3100 and the latest s/w.

I have good news. It is working with my Matek H 743 slim perfectly now. Still on the bench but I have high Sat counts even indoors. I have done only checking the params and loaded the latest FW plane 4.3.
This Matek H743 slim with the GPS M10- via CAN Bus is going in a plane I am in a process to 3D print.
Will take a wile for me to finish.

I just have problem with Qoi-tek CAN-GPS M10.

I need to apply quick fix by:

case STEP_M10: {
        // special handling of M10 config
    if (_hardware_generation == UBLOX_M10) {
        const config_list *list = config_M10;
        const uint8_t list_length = ARRAY_SIZE(config_M10);
        Debug("Sending M10 settings");
        const uint8_t buf[]={0xB5, 0x62, 0x06, 0x8A, 0x23, 0x00,0x01, 0x01, 0x00, 0x00, 0x01, 0x00, 0x21, 0x30, 
        0xC8, 0x00, 0x20, 0x00, 0x31, 0x10, 0x00, 0x22, 0x00, 0x31, 0x10, 0x01, 0x0F, 0x00, 0x31, 0x10, 0x00,
        0x0D, 0x00, 0x31, 0x10, 0x01, 0x21, 0x00, 0x11, 0x20, 0x08, 0x8D, 0xCD};
        if (!_configure_config_set(list, list_length, CONFIG_M10, UBX_VALSET_LAYER_RAM)) {

some how the message UBX_CFG_VALSET never get set. I turn on the debug log it show the error.
return _send_message(CLASS_CFG, MSG_CFG_VALGET, buf, sizeof(buf));
This is the line that return error. I suspect that this is the GET message not the SET message. but even I change it to MSG_CFG_VALGET it still return ACK=0;
So I decide to send the array hex to solve my problem.