9603N in Artemis Global Tracker not starting :/

I have been running the examples on the global tracker and today I cannot start the modem.

What can I check? GPS works ok, but when the modem tries to start (I see the red light in the board) I get:

https://content.screencast.com/users/er … ording.png

Hi Erwin,

Have you made any changes to the hardware?

Best wishes,

Paul

None, it has been running a slightly modified example next to a window to see if it was “stable” as a prototype. I ordered another one from Rock7, but I am a bit afraid of putting it on the artemis tracker now :confused:

Hi Erwin,

You can enable debug messages which might give more information. Near the start of each example, below the pin definitions, you will see a line which says #define DIAGNOSTICS false. Change false to true to enable the extra messages. Please post these and we’ll take a look.

Also, there are test points on the bottom of the PCB which let you access the serial transmit and receive between the Artemis and the 9603N. If you are able to, you could probe on those. You should see the “AT” messages from the Artemis, and any replies from the 9603N.

Best wishes,

Paul

OK thanks. I enabled diagnostics and also added some extra ```
Serial.println


<IMG src="https://content.screencast.com/users/erwinried/folders/Capture/media/dd8a0e72-5c14-4c40-ac4a-94c1bd5c98e7/LWR_Recording.png">[https://content.screencast.com/users/er ... ording.png](https://content.screencast.com/users/erwinried/folders/Capture/media/dd8a0e72-5c14-4c40-ac4a-94c1bd5c98e7/LWR_Recording.png)</IMG>

But for what I can see is the modem not answering. I will check the direct serial now. The pads are these right:

<IMG src="https://content.screencast.com/users/erwinried/folders/Capture/media/37c0dc49-d5e0-45b3-8ee4-b64baaea7d62/LWR_Recording.png">[https://content.screencast.com/users/er ... ording.png](https://content.screencast.com/users/erwinried/folders/Capture/media/37c0dc49-d5e0-45b3-8ee4-b64baaea7d62/LWR_Recording.png)</IMG>

I sent my broken iridium modem back to sparkfun and replaced the one in the global tracker for one bought on Rock7 that has been working fine in RockBlock’s own board. It is safe to assume that the SparkX board is safe and it wont kill another 9603N? or do I better wait for the response from SparkFun when they receive my package?

Hi Erwin,

I’m confused… What did you actually return to SparkFun? Just the 9603N modem - or the whole Global Tracker?

The problem you were having seems more likely to be with the Global Tracker circuit board - not the modem. We are offering to test the Global Tracker for you if you return it. We won’t be able to learn much from testing just the modem?

Best wishes,

Paul

ohhh, I returned the modem so you can handle RMA on that unit, I actually needed the other part for building the prototype. We need to decide between some technologies (we also have rockfleet and 2 rockblocks, one which donated the modem)

Can I test myself something on the global tracker, just to be sure?

Hi Eriwn,

Thank you for your understanding.

During the production test, we insert a dummy modem which allows us to test all of the connections on the small 20-way modem connector. You will see that the connector is delicate, and we use epoxy to strengthen it. I think your fault might be a faulty joint on that connector. Your board has been fully tested during production, but maybe a joint has opened up since then? I have been using the 9603N modems for years and I have never seen one fail - even after being flown to 30km on a weather balloon multiple times!

The best thing would be for you to return the AGT board so we can test it for you.

Best wishes,

Paul

I understand, but being in norway makes things a bit more complicated. Shipping it back and forth will cost similar to the price of the item+ weeks of delay. I will try to check if the connector is ok, it looked fine, epoxy is not cracked or anything. Otherwise I think the only option I have would be to use rock7 solutions which include full warranty. I kinda liked to try the artemis though.

PaulZC:
Hi Eriwn,

Thank you for your understanding.

During the production test, we insert a dummy modem which allows us to test all of the connections on the small 20-way modem connector. You will see that the connector is delicate, and we use epoxy to strengthen it. I think your fault might be a faulty joint on that connector. Your board has been fully tested during production, but maybe a joint has opened up since then? I have been using the 9603N modems for years and I have never seen one fail - even after being flown to 30km on a weather balloon multiple times!

The best thing would be for you to return the AGT board so we can test it for you.

Best wishes,

Paul

The only thing I can “visually” see is https://photos.app.goo.gl/LiJBUkDaS9zsrMWb6 some stains of epoxy in the connector (lower part) but besides of that, the epoxy looks intact. Of course one of the pins below might be not connected but I am trying to think why the modem stopped answering after a couple of days running the example :idea:

Hi again Paul, I think you were right and the problem is on the global tracker boards… so I sent you my working iridium modem :? because I just decided to test it again on the tracker with the new 9603N and no AT responses either. So it might just not be getting power

Hi Erwin,

It might be nothing, but please have a close look at this pin:

I don’t think it will explain the problems you are having, but it does not look quite right.

Best wishes,

Paul

9603N_Pin.jpg

good guess, but it is just a lighting effect, it is perfect. I think for now I am gonna use the artemis tracker as a gps only, since that part works. And one day I will try to follow the schematic for the power for the iridium

Hi Erwin,

It has taken some time, but I think I might understand why your Global Tracker was not starting correctly. There was a problem with the deep sleep code - caused by some recent changes to the u-blox GNSS library. The effect was that the 9603N would transmit successfully on the first attempt but would fail on subsequent attempts (after waking from deep sleep). It looked like a hardware issue, but was actually caused by RAM corruption.

I have updated the examples on GitHub. Please give them a try if you have time.

The critical change is this one:

https://github.com/sparkfunX/Artemis_Gl … cd7429R860

Very best wishes,

Paul