Putting the RAK12500 to sleep and waking it up again

Looking through the SparkFun u-blox GNSS Arduino Library examples, number 22 is for PowerOff.

The header text contains the following:

By driving a voltage from LOW to HIGH or HIGH to LOW on the chosen module pin you wake the device back up.

However, the RAK12500 datasheet says that

Only the UART and I2C related pin, 1PPS pin, RESET pin, VDD, and GND are connected to this module

Has anybody successfully awoken this chip? If so, how? I have to ask because the example sketch also mentions that

While powered off, you should not query the device for data or it might wake up. This can be used to wake the device but is not recommended.

Hello Bill,

If you follow our Quick Start Guide you should be able to use the RAK12500.

There are two ways to reduce the power consumption of the RAK12500.

  1. The power supply of the whole module can be controlled using WB_IO2 GPIO.
pinMode(WB_IO2, OUTPUT);
digitalWrite(WB_IO2, LOW); // Power off the whole module
digitalWrite(WB_IO2, HIGH); // Power on the whole module
  1. Using the low power mode of the uBlox chip.
pinMode(WB_IO2, OUTPUT);
digitalWrite(WB_IO2, HIGH); // Power on the whole module
... // Initialize I2C and setup the uBlox chip
my_gnss.powerSaveMode(true); // Put uBlox chip into low power mode

I have tested both methods and 1) is better in power saving (obviously because you cut the power supply). 2) only works if the uBlox chip has already obtained a location fix. Otherwise it seems the chip (or the Sparkfun library, I don’t know) seems to ignore the command. But if the uBlox goes into power save mode, the consumption is reduced, but not as much as I expected. Sorry, I do not have the measurements anymore.

the negative thing with solution 1) is that after each power up the uBlox has to search again for satellites, which can take up to 1 minute, depending on how fast the chip can find satellites.

You really are the man @beegee!!

Thanks again my friend … though I am curious, since I’ve got a couple of LEDs wired to the RAK50005 board and they are using WB_IO1 and WB_IO2 … I am signalling the LED on WB_IO2 and yet the GPS board is not affected by this

Hi @billr

Sorry, but WB_IO2 is a bad selection for your LED. It is used to control the power supply of the modules. See Power Supply Diagram of RAK5005-O

It might work if you switch on the LED while you use the RAK12500, because it will as well enable the power supply.

Unfortunately IO1 and IO2 are the only ones exposed on the RAK5005-O headers. So you need to find another solution for your LED’s.

If you do not need the AIN1 on J11, you can use it as generic GPIO as well.

pinMode(WB_A1, OUTPUT);
digitalWrite(WB_A1, HIGH); // Switch external LED on
digitalWrite(WB_A1, LOW); // Switch external LED off

WB_A1 is the solar panel input pin

What I’ve discovered today is that by having RAK12500 in slot A on the RAK5005-0 board, one cannot rely on the headers of J11.

A further observation has been that with the RAK12500 connected to slot A, reset button must be pressed after applying power, whether this is via USB or battery.

This can be demonstrated simply with the following sketch.

#include <Arduino.h>


void setup() {
  digitalWrite(OUTPUT_PIN, LOW);
  digitalWrite(LED_BLUE, LOW);

  uint8_t counter = 20;

  while(counter-- > 0)


void loop() {
  uint8_t counter = 6;

  while(counter-- > 0)


Attach an LED (and a resistor, I used a 1K) to IO1 (J11) and ground it to GND (J12) fire up the power either with a USB cable or with a 3.7V batttery, and you will see the onboard blue LED flash, after which, the attached LED will perform it’s cycle indefinitely.

Now disconnect the power and attach RAK12500 to slot A and again power up the board.

Try powering with both USB and the 3.7V battery: you will need to press the reset button to start the program running, and then you will only see the onboard blue LED flash, the attached LED will not work

Further observation is that by moving the RAK12500 to the underside of the board and into slot C, the external LED can now be used as expected, however, we can no longer get a GPS fix!!!

Hello @billr
Trying to respond to all your posts one by one :grin:

  1. Vbat is measured with WB_A0, not with WB_A1

  2. reset button must be pressed ==> Did you upgrade the bootloader of your RAK4631? This is an old problem that was fixed in April 2021. See here: Updated Bootloader for RAK4631

  3. Using the RAK12500 in Slot C has no effect on finding a location as long as you make sure the GPS antenna is point to the sky in the correct orientation


Btw, above pictures are taken from my private project to build a small GPS tracker. The Base board used here is not yet available, but will come within this year into our store.


It turns out that the bootloader is dated Jun 16 2020 … so I can think that I can safely say we do not have the updated bootloader.

I do find this curious though, since we have only purchased these boards recently (as in last month): I will have to check all of the boards we have to make sure they are all up to date in this respect.

I’m going to update at least one of them today and let you know how that goes.

With regards to VBAT:

#define PIN_VBAT WB_A0
#define PIN_SOLAR WB_A1

These are the pins we have defined (actually taken from one of the example sketches), however, I have found that AIN1 (from J11) is actually connected to WB_A0

I can assure you my friend that all of my observations reported are exactly the case.

If I place RAK12500 in slot A, I cannot use WB_IO1, however this is not the case at all if the RAK12500 is plugged in to slot C. Also, with RAK12500 connected in slot A, the GPS functionality works exactly as expected (SIV = 6,7,8 and 10), however with the connection instead to slot C, I have had the code running for over 12 hours and the GPS unit does not connect to more than 3 satellites, whilst most of the time SIV = 0

@beegee As expected, the bootloader has fixed the start-up issue.

It’s probably safe to say then that my hardware was manufactured earlier than the updated bootloader was published.

About J11, I apologize, I only looked on the Base board, not into the schematics. And the print on my base board is quite bad. You are right, on J11 it is AIN0.

WB_IO1 of Slot A is connected to the 1PPS pin of the uBlox. I forgot about that (It was a long week). That’s why you can’t use it.

My code is not reading the SIV, I am only looking into the fix type and I get a 3D fix whatever slot I use. As the GPS antenna is away from the module, I do not know what could cause the problem in your case. I will try to add SIV to my code and see what results I get

We are producing in batches of at least 5000 pcs, so it will take some time before the modules with the new bootloader will be send out. The bootloader is flashed during the production, and it would be a big effort and quality risk if we reprogram all modules that are still in stock. Sorry for the inconvenience.

1 Like

It is really weird.
I changed my code a little bit to get the SIV value and I have no problems to get 9 satellites with the RAK12500 in Slot C.
As the slot connectors are identical (only the IO’s connected are different), that is the expected behavior.

Do you have several RAK5005-O Base boards to test with? Just to eliminate that it is caused by the Base board.

Here my log and my setup:

@beegee, so having discovered that the wiring that we “require” -i.e. using the GNSS chip and connecting a couple of LEDs- is not possible when using just the base board, we’ve decided to go with onboard LEDs until we can take delivery of some IO modules.

With regards to connection sockets… on one of the boards at least, when connecting the GPS to socket C, it cannot be found on the IIC bus, on another board we can get no higher than SIV=3. very peculiar.

Right now however, this is no longer an issue for us since we have decided to take the LEDs out of the equation (for the time being).


If you have time to test, on the RAK5005-O with the problem that RAK12500 cannot be found on I2C bus in slot C, can you test another module (any module with I2C bus) if it is detected?

For the other module, where you cannot get more than SIV=3, can you test the voltage on the RAK12500. The 3.3V for the module can be measured on C66 or C67:

If there is a problem with the boards, we need to check and find the cause.

Thank you.

I will look into that later and get back to you @beegee,

thank you

Here’s something very peculiar @beegee: I made the following code change

From this:

    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Freezing."));
    while(1) { Serial.print("FAIL ");}

to this:

    Serial.println(F("u-blox GNSS not detected at default I2C address. Please check wiring. Freezing."));

No other change was made and nothing was touched on the hardware. The program was uploaded to the board; and I am unable to find the GPS unit on the default I2C address … bear in mind that, I’ve not actually run a scan to see if I can find any I2C addresses, I am simply going on the fact that the call to gpsUnit.Initialize() is failing.

I swapped the GPS unit over for another one … same deal, cannot find GPS unit. I then (simply out of curiosity) unplugged from slot A and plugged into slot C, powered up the board and everything works … this is the very board that (on saturday) could not locate the GPS unit when plugged in to slot C.

I then swapped the GPS unit back to port A, and still unable to initialize the unit.


I recognise that gpsUnit.Initialize() doesn’t mean much to you, but it’s a wrapper function defined as follows

bool GpsUnit_t::Initialise()
    if (_gnss.begin() == false) //Connect to the u-blox module using Wire port
      return false;

    _gnss.setI2COutput(COM_TYPE_UBX);            //Set the I2C port to output UBX only (turn off NMEA noise)
    _gnss.setMeasurementRate(GNSS_DATA_RATE);    //Produce a measurement every second
    _gnss.setNavigationRate(1);                  //Produce a navigation solution every measurement

    _gnss.setAutoPVTrate(1);                     //Tell the GNSS to send the PVT solution every measurement
    return true;

@beegee, I really do not know what is going on with the two boards I have here …

both of them are pretty random in deciding whether or not the GPS unit can be initialised.

One of them will not initialise at all now using slot A, and in slot C, sometimes it initialises, sometimes it does not.

The other board I can get to initialise when using slot A, but here’s the crazy routine I need to follow in order to get it to work:

  1. Connect to USB
  2. Unplug GPS unit from slot A
  3. Plug GPS unit back in to slot A
  4. Press the reset button

If Ishould unplug the USB cable and then re-insert it, again the GPS unit cannot be initialised!!

I’ve stripped my code down to the bare minimum

#include <Arduino.h>
#include <SparkFun_u-blox_GNSS_Arduino_Library.h>


void setup() {

void loop() {

Just to make sure it’s not anything to do with the code, and I get the same deal: there really is no rhym or reason to it at all, sometimes it will work, sometimes it will not, however there is one consistency in that if the GPS unit is initialised and I subsequently disconnect the USB and then re-connect, it will cease to work!

Hi Bill,

The other board I can get to initialise when using slot A, but here’s the crazy routine I need to follow in order to get it to work:

Connect to USB
Unplug GPS unit from slot A
Plug GPS unit back in to slot A
Press the reset button

If Ishould unplug the USB cable and then re-insert it, again the GPS unit cannot be initialised!!


That said, if you plugged-in or plugged-out a module under power before, I cannot say if the WisBlock Base board or the GNSS module is damaged.


What are the GPIO numbers of SUCCESS_LED and FAIL_LED ?
Are you securing the modules with the screws after you plugged them in?