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
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
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…
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.
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
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.
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?
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.
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
Ok; I opened an issue on GitHub.
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
Thank you for raising the issue on GitHub. Let’s continue the discussion there:
Best,
Paul
@a.ord.19 and all those that were brought here by google,
Very likely you are using a version of Apollo3 core v2.1.1 or higher. In version v2.1.1 a bug was apparently introduced that causes issues with the UART (serial) communication. As of Apollo3 core version v2.2.1 this error is still there.
The bug sometimes causes not all charcters received on the serial to be passed on. When this happens, the IridiumSBD library used in Example16_GlobalTracker.ino (and others), which interprets the incoming charcters on the serial line, times out while waiting for a response from the Iridium modem, as it does not get the last character it is waiting for, which would signal the end of the message.
As a result of that the IridiumSBD library issues an error 3 (ISBD_PROTOCOL_ERROR) followed by error 5 (ISBD_NO_MODEM_DETECTED), which is what you are seeing.
The occurrence of this is very unpredictable, sometimes the program runs fine for hours or even weeks before it crashes, sometimes it crashes within minutes.
Apollo3 core version v2.1.0 does not have this bug, so the recommendation is to used v2.1.0 for now.
However, I noticed that with Apollo3 core version v2.1.0 example 16 freezes when restarting the code while the Iridium momdem is on (red LED on). As establishing the connection on the serial line causes the program to start from the beginning, this can cause issues if you monitor the serial line, but don’t have precies control when the serial connection is established.