Artemis Global Tracker transmists, but later shows error and will not transmit again

Development Boards Artemis
1

Hi,

I am transmitting using the Iridium modem and have an issue.

My code is based on the A Better Tracker example by Paul Clark, see https://github.com/sparkfun/SparkFun_Ar … balTracker

The modem will transmit and after some transmits, it will send the error

Transmission failed with error code 3

and also

modem.clearBuffers failed with error 3

When it tries to transmit anytime after these errors it will give

modem.begin failed with error 5

Any clue as to why this could be happening?

Thanks

2

Do the example codes behave the same? (do they throw the same error after x messages?) Test it using the default sketches and circle back

3

Hi,

I tested the example15_BetterTracker (https://github.com/sparkfun/SparkFun_Ar … terTracker)

The only change was on line 82:

#define DEF_TXINT 5// DEFault TX INTerval (Minutes)

Instead of 5 I used 130

The same issue: Sending messages, then:

Transmission failed with error code 3

Clearing the MO buffer.

*** modem.clearBuffers failed with error 3 ***

Putting the 9603N to sleep.

And after this all messages show:

Starting modem…

*** modem.begin failed with error 5 ***

Getting ready to put the Apollo3 into deep sleep…

4

TS-Russell:
Do the example codes behave the same? (do they throw the same error after x messages?) Test it using the default sketches and circle back

Yes they do. The only change was the transmission delay (I was using 140 minutes). Same errors: first error code 3 and then error code 5. I tried resetting the rx before waking the modem, and still had the same issue. It is also not deterministic: sometimes it takes a while (more than 10 send attempts (either successful or unsuccessful)) to get to error 3, while other times it happens in the third attempt.

5

Maybe try clearing the buffers more often? Can you send smaller messages more often?

Are you using the additional supercapacitors? https://learn.sparkfun.com/tutorials/ar … e-assembly

6

TS-Russell:
Maybe try clearing the buffers more often? Can you send smaller messages more often?

Are you using the additional supercapacitors? https://learn.sparkfun.com/tutorials/ar … e-assembly

I tried clearing the and re defining the modem class, clearing the rx multiple times. I was using supercapacitors and had the same problem, removed them and the problem persists. If send more often I have not had the issue, but have not tested extensively (because it could be expensive). When I reset the controller everything works fine again, so maybe it is not a hardware problem… my current workaround is to perform a software reset and catch it during init so it will not repeat unwanted instructions… but it is not ideal.

7

Has this ever been addressed?
We encountered the same issue. We run the example 16 code.
I uncommented #define noTX and #define skipGNSS and just let it run, while monitoring the communication on the serial line. This should work indefinitely. However, most of the time (but not always) it stops working after 10s of minutes to hours.

I did a lot of digging, and narrowed down where and why this happens:
Sometimes the reply from the Iridium 9603 lacks the [LF] (and sometimes even [CR][LF]) at the end of the message. waitForATResponse() in IridiumSBD.cpp then times out because it does not see the terminator it is looking for. That then causes an ISBD_PROTOCOL_ERROR (3) and afterwards an ISBD_NO_MODEM_DETECTED (5) error.
Is this a known issue of the Iridium 9603N? If so, what exactly is the issue and is there a fix?

8

It sounds like the modem might be having trouble recovering after a failed transmission, possibly due to signal issues or internal state not resetting properly. You might want to try a full power cycle or check for any buffer handling problems.

9

I don’t believe so; I don’t see an open or closed issue for that GitHub · Where software is built - feel free to file one with those same details

10

Ok; I opened an issue on GitHub.

11

Hi Adrian (@adrian_uos ),

I have used the 9603N a lot over the years, and I don’t think I’ve ever seen the [LF] or [CF][LF] being truncated. My vague guess is that the modem is being powered off while it is outputting its reply? Maybe because the code thinks the battery voltage is low? Did you have a LiPo battery attached during your tests? Maybe try reducing DEF_LOWBATT just to be sure?

Please make sure you are using version 2.1.0 of the SparkFun Apollo3 core / board package, and have selected the RedBoard Artemis ATP. I have seen some UART badness with 2.2.1.

I hope this helps,
Paul

12

Thank you for raising the issue on GitHub. Let’s continue the discussion there:

Best,
Paul