Error Setting Power Mode on MAX-M10S #125

TryingToGITthis · 2023-08-19T12:50:35Z

Getting position updates just fine but when I try to set the power mode, I'm getting a -1025 error returned.
Am I missing something in setup or is the M10 not supported in this way?

errorcode = uDeviceOpen(&gDeviceCfg, &gnssHandle);
errorcode = uNetworkInterfaceUp(gnssHandle, U_NETWORK_TYPE_GNSS, &gnetworkcfg);
gOriginalMode = uGnssPwrGetMode(gnssHandle);
uGnssSetRetries(gnssHandle, 4);
errorcode = uGnssPwrSetMode(gnssHandle, U_GNSS_PWR_SAVING_MODE_ON_OFF );
if (errorcode != 0)
   printk("Error setting power saving: %d\n", errorcode);
errorcode = uGnssPwrSetMode(gnssHandle, U_GNSS_PWR_FLAG_EXTINT_INACTIVITY_ENABLE );
if (errorcode != 0)
   printk("Error setting power saving: %d\n", errorcode);

The text was updated successfully, but these errors were encountered:

RobMeades · 2023-08-20T16:58:29Z

Hi there: which one is returning U_GNSS_ERROR_NACK (-1025): uGnssPwrSetMode(gnssHandle, U_GNSS_PWR_SAVING_MODE_ON_OFF ) or uGnssPwrSetMode(gnssHandle, U_GNSS_PWR_FLAG_EXTINT_INACTIVITY_ENABLE )?

I can't see why the first one would return an error but, for the second one, what you're passing into uGnssPwrSetMode() is not a member of the uGnssPwrSavingMode_t enum: you're passing in a member of the uGnssPwrFlag_t enum instead.

For that one what you probably meant was:

uGnssPwrSetFlag(gnssHandle, 1UL << U_GNSS_PWR_FLAG_EXTINT_INACTIVITY_ENABLE)

The compiler should have issued an error, or at least a warning, about using the wrong enum; you might want to increase your error levels.

TryingToGITthis · 2023-08-20T21:22:01Z

uGnssPwrSetMode(gnssHandle, U_GNSS_PWR_SAVING_MODE_ON_OFF ) is returning the -1025.

Thanks for flag setting issue, I'll fix that.

RobMeades · 2023-08-20T21:41:16Z

Hmmm, not sure I can explain that. Exactly which M10 device is this?

Here is a segment of log output from our test system running through setting the power saving modes in test gnssPwrSaving() on test instance 10.0 (which is a MAX-M10S, FW version 5.10, protocol version 34.10), where U_GNSS_PWR_SAVING_MODE_ON_OFF is mode 1:

2023-08-18 00:51:39,022 u_monitor_10.0 INFO    - progress update - item gnssPwrSaving() started on 00:51:39.022444.
2023-08-18 00:51:39,033 u_monitor_10.0 INFO    - U_GNSS_PWR_TEST: testing on transport I2C...
2023-08-18 00:51:39,043 u_monitor_10.0 INFO    - U_GNSS_TEST_PRIVATE: test preamble start.
2023-08-18 00:51:39,054 u_monitor_10.0 INFO    - U_GNSS_TEST_PRIVATE: opening GNSS I2C 0...
2023-08-18 00:51:39,065 u_monitor_10.0 INFO    - U_GNSS_TEST_PRIVATE: adding a GNSS instance...
2023-08-18 00:51:39,077 u_monitor_10.0 INFO    - U_GNSS: initialising with ENABLE_POWER pin not connected, transport type I2C.
2023-08-18 00:51:41,163 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 01 00 d0 20 8a 55.
2023-08-18 00:51:41,183 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 01 00 d0 20 00 [body 9 byte(s)].
2023-08-18 00:51:41,195 u_monitor_10.0 INFO    - U_GNSS_PWR_TEST: power-saving mode was 0.
2023-08-18 00:51:41,206 u_monitor_10.0 INFO    - U_GNSS_PWR_TEST: setting power-saving mode 2...
2023-08-18 00:51:41,282 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 d0 20 02 8e f1.
2023-08-18 00:51:41,293 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
2023-08-18 00:51:41,392 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 01 00 d0 20 8a 55.
2023-08-18 00:51:41,413 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 01 00 d0 20 02 [body 9 byte(s)].
2023-08-18 00:51:41,425 u_monitor_10.0 INFO    - U_GNSS_PWR_TEST: setting power-saving mode 1...
2023-08-18 00:51:41,524 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 d0 20 01 8d f0.
2023-08-18 00:51:41,536 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
2023-08-18 00:51:41,632 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 01 00 d0 20 8a 55.
2023-08-18 00:51:41,653 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 01 00 d0 20 01 [body 9 byte(s)].
2023-08-18 00:51:41,665 u_monitor_10.0 INFO    - U_GNSS_PWR_TEST: setting power-saving mode 0...
2023-08-18 00:51:41,762 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 d0 20 00 8c ef.
2023-08-18 00:51:41,774 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].
2023-08-18 00:51:41,872 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 01 00 d0 20 8a 55.
2023-08-18 00:51:41,893 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 01 00 d0 20 00 [body 9 byte(s)].
2023-08-18 00:51:42,002 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 d0 20 00 8c ef.
2023-08-18 00:51:42,014 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].

You might want to set uGnssSetUbxMessagePrint(gnssHandle, true) and capture the trace output to see if there is anything obvious in the UBX message exchange with the device.

TryingToGITthis · 2023-08-20T21:58:34Z

Here is the output:

U_GNSS: initialising with ENABLE_POWER pin not connected, transport type I2C. U_GNSS: sent command b5 62 0a 06 00 00 10 3a. U_GNSS: decoded UBX response 0x0a 0x06: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 120 byte(s)]. U_GNSS: sent command b5 62 06 04 04 00 00 00 09 00 17 76. U_GNSS: sent command b5 62 0a 06 00 00 10 3a. U_GNSS: decoded UBX response 0x0a 0x06: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [body 120 byte(s)]. U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 01 00 d0 20 8a 55. U_GNSS: decoded UU_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 d0 20 01 8d f0. U_GNSS: decoded UBX response 0x05 0x00: 06 8a [body 2 byte(s)]. Error setting power saving: -1025 Error setting power saving: -1025 U_GNSS: sent command b5 62 06 8b 18 00 00 00 00 00 02 00 d0 40 03 00 d0 40 05 00 d0 30 07 00 d0 20 06 00 d0 20 c0 35. U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 02 00 d0 40 0a 00 00 00 03 00 d0 40 0a 00 00 00 05 00 d0 30 00 00 07 00 d0 20 00 06 00 d0 20 00 [body 36 byte(s)].

RobMeades · 2023-08-20T22:08:38Z

Well, that is pretty clearly a NACK:

U_GNSS: sent command b5 62 06 8a 09 00 01 01 00 00 01 00 d0 20 01 8d f0.
U_GNSS: decoded UBX response 0x05 0x00: 06 8a [body 2 byte(s)]

You could maybe add a call to uGnssInfoGetFirmwareVersionStr() with, say, a 256 byte buffer and print the [multi-string] buffer that comes back, just so that we could get the exact device version details? Or if you don't want to fiddle about with printing a multi-string buffer you could call uGnssGetVersions() instead and print the values in the structure that it populates.

Is it possible that you have one of the flavours of GNSS device that doesn't support power saving?

TryingToGITthis · 2023-08-20T22:22:51Z

MAX-M10S
Firmware Version: 537075204

RobMeades · 2023-08-20T22:28:38Z

I don't understand that FW version but the MAX-M10S should be fine since it is exactly the same device as we test with in the output I pasted-in above (GNSS device FW version 5.10).

I have very occasionally seen GNSS devices return a NACK if they are hit with many power-saving related requests in succession: maybe it is a timing thing and somehow the device is not ready to accept the power saving mode change? For debug purposes, maybe try adding a delay before sending the power saving mode to see if that makes a difference?

TryingToGITthis · 2023-08-20T22:37:14Z

Sorry, did a %d instead of %s.
Firmware Version: ROM SPG 5.10 (7b202e)
Five second delay before the power saving mode change didn't help.

RobMeades · 2023-08-20T22:44:25Z

So, we have the same GNSS device, same FW version.

In our test we happen to set the power saving modes in the order 2, 1, 0: for debug purposes, maybe try setting mode 2 (U_GNSS_PWR_SAVING_MODE_CYCLIC_TRACKING) instead, or perhaps try setting the mode that the device is already in, just to see if those succeed?

TryingToGITthis · 2023-08-20T22:49:53Z

Same error. Any other thoughts? The device never enters sleep mode either.

This is all the code up to changing the mode:
`
uPortLogOff();
// initiate ubxlib
uPortInit();
uPortI2cInit(); // you only need this if an i2c interface is used
uDeviceInit();

int32_t errorcode;
uDeviceHandle_t gnssHandle;
printk("\ninitiating the module...\n");
errorcode = uDeviceOpen(&gDeviceCfg, &gnssHandle);
if (errorcode == 0) {
  // bring up the gnss
  errorcode = uNetworkInterfaceUp(gnssHandle, U_NETWORK_TYPE_GNSS, &gnetworkcfg);
  if (errorcode == 0) {
     char str[256];
     uGnssInfoGetFirmwareVersionStr(gnssHandle, str, 256);
     printk("Firmware Version: %s\n", str);
     int32_t gOriginalMode = uGnssPwrGetMode(gnssHandle);
     printk("Original power mode: %d\n", gOriginalMode);
     uGnssSetRetries(gnssHandle, 4);
  k_sleep(K_SECONDS(5));
     errorcode = uGnssPwrSetMode(gnssHandle, U_GNSS_PWR_SAVING_MODE_CYCLIC_TRACKING);

`

TryingToGITthis · 2023-08-20T22:54:45Z

This is on a custom board if it matters.

RobMeades · 2023-08-20T22:54:47Z

Maybe, for some reason, the various timers that the GNSS device uses to govern the durations of the different power saving phases have somehow gone screwy, so it is unable to power save? Not that I can see how that would happen, but maybe call uGnssPwrGetTiming(), print out all of the values to see if they make sense, and maybe write these back again to be completely sure, correcting any that don't look sensible, with uGnssPwrSetTiming()?

TryingToGITthis · 2023-08-20T22:56:37Z

Here are the values:
Acq Period Secs: 10 Acq Retry Period Secs: 10 On Time Secs: 0 Max Acq Time Secs: 0 Min Acq Time Secs: 0

RobMeades · 2023-08-20T22:57:46Z

Those look OK to me.

I'm not an expert in the GNSS device and/or HW, but I wonder if V_BKUP needs to be connected to VCC? When the device enters power saving it enters back-up mode, which might rely on the supply from that pin?

RobMeades · 2023-08-20T23:30:48Z

Another possibility: checking the integration manual, it says that RAM is erased during on/off power saving, restored from BBRAM on wake-up, with BBRAM maintained from VIO.

The code in uGnssPwr only sets the configuration in the RAM layer; maybe, somehow, in your case with V_BKUP not connected (I suspect it is connected to a button cell on the board we are testing with), the device is NACKing the request because it knows that it doesn't make sense, it will just be lost when power saving is entered/left? This is just a guess of course but, thinking about it, only setting the power saving settings in the RAM layer doesn't make sense for on/off power saving.

To debug if that has an impact, search u_gnss_pwr.c for all occurrences of uGnssCfgPrivateValSetList and replace U_GNSS_CFG_VAL_LAYER_RAM with U_GNSS_CFG_VAL_LAYER_RAM | U_GNSS_CFG_VAL_LAYER_BBRAM.

TryingToGITthis · 2023-08-20T23:47:25Z

V_BKUP was never connected because main power is never removed. Unless the internal circuitry disconnects
VCC and V_IO.

By changing those occurrences, my uGnssPwrSetTiming() settings are now being saved between code updates:
Acq Period Secs: 3600
Acq Retry Period Secs: 120
On Time Secs: 10
Max Acq Time Secs: 240
Min Acq Time Secs: 12

No change to the error code though.

RobMeades · 2023-08-20T23:51:56Z

OK, so I will make the change to add the BBRAM layer to the CFG-VAL save operations, that makes sense, but still getting a NACK back for the request to enter on/off power saving I can't explain.

I will see if I can find someone who knows more about this than I to give me some hint tomorrow.

TryingToGITthis · 2023-08-20T23:54:18Z

Thanks for all your help. Tomorrow will try supplying power to V_BKUP and see if it makes a difference.

RobMeades · 2023-08-21T12:52:11Z

Writing to BBRAM also is now pushed to master here: 7446b97. I've not found anyone who can explain the NACK yet though.

RobMeades · 2023-08-29T09:21:39Z

Hi again: did you get any further with the "NACK" issue? I have not found anyone here who is able to come up with a reason why you should get a NACK; I have shown them your schematic but that didn't raise any eyebrows.

TryingToGITthis · 2023-08-29T14:53:06Z

We have made a modification to the board to enable V_BKUP. Should have that tested by the end of the week to see if it makes a difference.

RobMeades · 2024-01-04T12:15:43Z

I'm going to close this as I guess you have resolved your issues, or maybe this is not relevant any more, etc. Please re-open if there is more to discuss on this topic.

nautalert · 2024-03-20T13:15:04Z

We were able to connect V_BKUP to V_CC. However, the problem still remains:

U_GNSS: sent command b5 62 06 8a 09 00 01 03 00 00 01 00 d0 20 02 90 01.
U_GNSS: decoded UBX response 0x05 0x00: 06 8a [body 2 byte(s)].
Error setting power saving: -1025
U_GNSS: sent command b5 62 06 8b 08 00 00 00 00 00 01 00 d0 20 8a 55.
U_GNSS: decoded UBX response 0x06 0x8b: 01 00 00 00 01 00 d0 20 00 [body 9 byte(s)].
Updated power mode: 0

RobMeades · 2024-03-20T14:34:26Z

@nautalert: apologies, just wanted to confirm that this is the same issue as it has been a little while now. Let me restate (and re-open) the issue, please let me know if any of my assumptions are incorrect.

you are using a MAX-M10S-00B GNSS chip, ROM SPG 5.10 (7b202e),
whatever you do with it, the response to the UBX command b5 62 06 8a 09 00 01 03 00 00 01 00 d0 20 02 90 01 is 0x05 0x00, which is a NACK (0x05 0x01 would be an ACK).

FYI, breaking down the UBX command:

    b5 62 06 8a 09 00 01 03 00 00 01 00 d0 20 02 90 01
    ^^^^^| UBX header|  |  |  |  |           |  |     |
          ^^^^^| Message class/ID: UBX_CFG_VALSET (see interface manual section 3.10.5.2)
                ^^^^^| Message body length: 9 bytes   |
                      ^^| Version: 1         |  |     | 
                         ^^| Layers: RAM (bit 0) & BB RAM (bit 1)
                            ^^| Transaction: 0 (transactionless)
                               ^^| Reserved (hence 0) |
                                  ^^^^^^^^^^^| Key ID: 0x20d00001 CFG-PM-OPERATEMODE (see interface manual section 4.9.1)
                                              ^^| Value for this key ID: 2, which is PSM cyclic tracking operation (see interface manual section 4.9.1, table 34)
                                                 ^^^^^| FCS 0x9001 (see working example below for comparison)

...and we send the same message to a MAX-M10S chip in our test system, where the exchange looks like this:

2024-03-17 11:18:29,385 u_monitor_10.0 INFO    - U_GNSS: sent command b5 62 06 8a 09 00 01 03 00 00 01 00 d0 20 02 90 01.
2024-03-17 11:18:29,403 u_monitor_10.0 INFO    - U_GNSS: decoded UBX response 0x05 0x01: 06 8a [body 2 byte(s)].

...where the MAX-M10S chip reports the following version structure:

ROM SPG 5.10 (7b202e)
000A0000
FWVER=SPG 5.10
PROTVER=34.10
MOD=MAX-M10S
GPS;GLO;GAL;BDS
SBAS;QZSS

Hmph.

nautalert · 2024-03-20T15:28:57Z

Pretty much all other commands work but uGnssPwrSetMode(). uGnssPwrSetFlag() and uGnssPwrSetTiming() work fine.

Initializing GPS...
Firmware Version: ROM SPG 5.10 (7b202e)
Original power mode: 0
Acq Period Secs: 3600
Acq Retry Period Secs: 240
On Time Secs: 10
Max Acq Time Secs: 240
Min Acq Time Secs: 20
Acq Period Secs: 3600
Acq Retry Period Secs: 240
On Time Secs: 10
Max Acq Time Secs: 240
Min Acq Time Secs: 20
Error setting power saving: -1025
Updated power mode: 0
GPS is ready

RobMeades · 2024-03-20T16:57:05Z

Purely as an experiment, could you try compiling ubxlib with -DU_GNSS_CFG_LAYERS_SET=U_GNSS_CFG_VAL_LAYER_RAM (that or hand-modify gnss/src/u_gnss_private.h to make the change), just to see if that makes a darned bit of difference?

EDIT: hmmm, actually, I think it was like that when [your colleague, I guess] originally raised this problem back in August 2023, we changed it to be both RAM and BBRAM after that. So that can't be it.

RobMeades · 2024-03-20T22:59:00Z

FYI, find attached a complete log of our standard regression test of GNSS power saving, run to the MAX-M10S device over I2C, where you can see the command sent at line 11 is identical to what you are sending.

power_saving_test_m10.txt

I have already asked our positioning AE team why this might not be accepted by a GNSS device and everyone looked at me blankly (via Teams, but you get what I mean); we must be missing something here, some fact that is probably staring us collectively in the face. I will ask again...

nautalert · 2024-03-25T00:43:36Z

Making the change in u_gnss_private.h didn't help.

RobMeades · 2024-03-25T09:12:43Z

No, didn't think it would. I am trying to find someone internally who has any idea how the problem you are seeing could ever occur. Out of interest, does this happen on more than one device, just in case it is something really crazy going wrong with one particular chip?

nautalert · 2024-03-25T11:18:44Z

It's happening on all chips.

nautalert · 2024-04-03T13:37:25Z

Any update on why this might be happening?

RobMeades · 2024-04-03T13:39:38Z

Apologies, I will prod the experts again...

RobMeades · 2024-04-10T12:17:15Z

The gentleman who knows what he's talking about has got back to me and there is a slim possibility: might you have enabled system BeuDou B1C (this is specifically B1C, not B1l) in the GNSS chip? He says that "PSM does not support BeiDou B1C"; BeiDou B1C seems to be in the default set for SAM-M10Q but it is not for MAX-M10S, you would have to have enabled it specifically.

EDIT: FYI, this is buried in the integration manual, section 3.6.2, along with a potentially useful note about SBAS:

nautalert · 2024-04-10T12:45:47Z

What is the correct way to enable or disable these?

RobMeades · 2024-04-10T13:14:53Z

Examples of how to do configuration using the CFG_VAL mechanism (that you must use for M10 and later GNSS modules), which I guess you've found, are in cfg_val_main.c.

For the system types, you want the configuration key IDs with _SIGNAL in the name, see here. So to read all of them at once, you could use uGnssCfgValGetListAlloc(), something like:

    uint32_t keyId;
    uGnssCfgVal_t *pCfgValList = NULL;
    int32_t numValues;

    keyId = U_GNSS_CFG_VAL_KEY(U_GNSS_CFG_VAL_KEY_GROUP_ID_SIGNAL, U_GNSS_CFG_VAL_KEY_ITEM_ID_ALL, 0);
    numValues = uGnssCfgValGetAlloc(devHandle, keyId, &pCfgValList, U_GNSS_CFG_VAL_LAYER_RAM);
    for (size_t x = 0; x < numValues ; x++) {
        printf("%d keyId 0x%08x = ", x + 1, pCfgValList->keyId);
        if (pCfgVal->value) {
            printf("true");
        } else {
            printf("false");
        }
        printf("\n");
        pCfgValList++;
    }
    uPortFree(pCfgValList);

The exact key for Beidou B1C is missing in our list of key IDs (I will fix that) but, no matter, you can just write-in the key ID yourself as follows (this assuming you are just setting the key value in RAM):

if (uGnssCfgValSet(devHandle, 0x1031000f, 0, U_GNSS_CFG_VAL_TRANSACTION_NONE, U_GNSS_CFG_VAL_LAYER_RAM) == 0) {
    printf("Set 0x1031000f (AKA CFG-SIGNAL-BDS_B1C_ENA) to true.\n");
} else {
    printf("Unable to set 0x1031000f!\n");
}

...value taken from the interface manual, section 4.9.21:

RobMeades · 2024-04-10T13:18:24Z

Update: you should probably replace U_GNSS_CFG_VAL_LAYER_RAM in my example code above with U_GNSS_CFG_VAL_LAYER_RAM | U_GNSS_CFG_VAL_LAYER_BBRAM since a change to the signal settings will reset the GNSS chip.

RobMeades · 2024-04-10T13:20:49Z

D'oh, and of course you want a 0 in there to disable, so:

if (uGnssCfgValSet(devHandle, 0x1031000f, 0, U_GNSS_CFG_VAL_TRANSACTION_NONE, U_GNSS_CFG_VAL_LAYER_RAM | U_GNSS_CFG_VAL_LAYER_BBRAM) == 0) {
...

nautalert · 2024-04-11T02:09:21Z

You were correct that BeuDou B1C was set. Power mode is now able to be set correctly. Thank you for your help with this.

RobMeades · 2024-04-11T07:48:57Z

Phew, my apologies that it took so long. I will add a note to the code somewhere about this in the hope that I remember this corner-case the next time someone asks. Will close this issue [again :-)] now: feel free to re-open it, or open a new one, if there is more to discuss.

RobMeades closed this as completed Jan 4, 2024

RobMeades reopened this Mar 20, 2024

RobMeades mentioned this issue Apr 9, 2024

SAM-M10Q Current Draw Issue 3.3V, ~1mA instead of ~10mA #226

Closed

RobMeades closed this as completed Apr 11, 2024

Error Setting Power Mode on MAX-M10S #125

Error Setting Power Mode on MAX-M10S #125

Comments

TryingToGITthis commented Aug 19, 2023

RobMeades commented Aug 20, 2023 • edited

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023 • edited

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023 • edited

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023 • edited

TryingToGITthis commented Aug 20, 2023

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023

RobMeades commented Aug 20, 2023 • edited

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 20, 2023

TryingToGITthis commented Aug 20, 2023

RobMeades commented Aug 21, 2023

RobMeades commented Aug 29, 2023

TryingToGITthis commented Aug 29, 2023

RobMeades commented Jan 4, 2024

nautalert commented Mar 20, 2024

RobMeades commented Mar 20, 2024 • edited

nautalert commented Mar 20, 2024

RobMeades commented Mar 20, 2024 • edited

RobMeades commented Mar 20, 2024 • edited

nautalert commented Mar 25, 2024

RobMeades commented Mar 25, 2024

nautalert commented Mar 25, 2024

nautalert commented Apr 3, 2024

RobMeades commented Apr 3, 2024

RobMeades commented Apr 10, 2024 • edited

nautalert commented Apr 10, 2024

RobMeades commented Apr 10, 2024 • edited

RobMeades commented Apr 10, 2024

RobMeades commented Apr 10, 2024 • edited

nautalert commented Apr 11, 2024

RobMeades commented Apr 11, 2024

RobMeades commented Aug 20, 2023 •

edited

RobMeades commented Aug 20, 2023 •

edited

RobMeades commented Aug 20, 2023 •

edited

RobMeades commented Aug 20, 2023 •

edited

RobMeades commented Aug 20, 2023 •

edited

RobMeades commented Mar 20, 2024 •

edited

RobMeades commented Mar 20, 2024 •

edited

RobMeades commented Mar 20, 2024 •

edited

RobMeades commented Apr 10, 2024 •

edited

RobMeades commented Apr 10, 2024 •

edited

RobMeades commented Apr 10, 2024 •

edited