RAK12501 TTF Claims and Standby

I received my RAK19007 base board, RAK4631 core, and RAK12501 GPS module to start a personal project of mine. Initial testing has gone great and I’m parsing the NMEA messages fine to write over serial and I decided some benchmarking was in order. Interested in testing the cold/warm/hot start claims from the product page, I tried understanding the schematics to see how to put it into standby. That’s when I realized, it does not appear we’re capable of doing so.

If I understand the schematics correctly, standby is paired with the reset so when I pull P1_02 I’m completely killing the power to the module, no? A critical reason I chose this module was to be capable of putting it into standby with decent cold and warm start times (my aim is to hold it in standby for a while and only bring it back to keep the almanac or ephemeris valid, depending on how frequent I want it to wake). My assumption appears correct in benchmarking, where my TTF averages 20 seconds with best cases being barely under the claimed <15 cold start and worst cases being well into the 30s. The chip manufacturer being used only claims <30 cold start, so why does RAK advertise better?

Welcome to the forum @trackarr

Can you please show where you found the 15 seconds?

in the documentation it states differently

RAK12501 Overview => Product Features
image

[RAK12501 Datasheet](WisBlock Product Line: Modular IoT Boards & Sensors
rak12501/datasheet/#features)

In the store: RAK12501 GNSS Module – Compact Location Tracker UART

Thanks,
We will correct the store pages.

Thanks. To confirm, is there any way to put it into standby other than removing R28 from the module to disable the reset?

R28 is not assembled, check the schematics, it says “NC”

The module can be put in low power mode by switching of 3V3_S (through WB_IO2). The last location will still be available on next power up because the V_BCKP is always powered through 3V3.

My testing when pulling that low is that it appears to lose its RAM and takes just as long to get a fix no matter what. I will attempt to get a voltage off of V_BCKP in the process to see.

Also, in that same schematic it shows R31 as NC, so that would mean it would do nothing at all…?

I run a test, and with this sequence it does a warm-start:

  • Initialize Serial1
  • Start acquisition
    • Power up RAK12501 through IO2
    • Read and parse NMEA strings from the module
    • After location acquisition or after a time out (90 seconds or half of uplink send interval) ==> power down RAK12501 through IO2
  • Wait 300 seconds
  • Restart acquisition

Sample code is in my repo LPWAN-Tracker-V2. This is more sophisticated than above sequence, it is a working LoRaWAN based tracker like our RAK10700.

Screenshot (my test device has OLED) shows an acquisition time of 13.8 seconds after an initial location fix was achieved.

I believe you got a fast cold start. Neither your docs or manufacturer specifications document a warm start, and within 300 seconds you should have gotten a <2 second hot start (I don’t see how you would’ve had an invalid ephemeris that fast unless you were unlucky), which seems to prove what I believe is the case? I’ve also had sub-15 second cold starts every now and then.