SUCCESS_LED = LED_BLUE
FAIL_LED = LED_GREEN
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.
This happened by accident today after the board had stopped recognising the module (I had to take everything out of the enclosure we have built) and it certainly has only happened to that one board and that one GPS module
Hi Bill,
Accidents can happen, just wanted to make sure.
RAK engineers have tested RAK12500 in both slot A and C and I have tested it as well in both slots without problems.
Can you try to make a good picture of the connectors on the RAK5005-O and RAK12500. I want to make sure there is no damage on the connectors itself.
Like these:
These images are the best that I could manage Iām afraid @beegee.
So this morning, we put the GPS chip into another board. This board worked as expected with the module connected to slot A, however when we placed the module into slot C the call to gnss.begin() fails as on the other boards.
Also, today the board that I was having trouble with yesterday, now the module works in slot C and not in slot A!! I had my colleague watch me as I performed the steps (you know get someone elseās eyes on the matter just to make sureIām not doing anything stupid), and he was left as baffled as I.
Itās the inconsistency of it that I simply do not understand. It can be the case that with the USB attached, the board powers up and the program runs correctly, and then after pressing the reset button, the board cannot then locate the GPS module but that is not consistent behaviour either.
Hello Bill,
The images are good enough. I just wanted to see the connectors, because I personally damaged several of them (thick fingers and impatient when connecting).
I am kind of lost with your problem, I am playing with WisBlock modules everyday, as I have access to the first prototypes of new modules. But I never experienced anything like your problem.
Did you try to run the very simple Example Code on the base board / RAK12500 that shows these strange behaviour?
#include <Arduino.h>
#include <SparkFun_u-blox_GNSS_Arduino_Library.h>
bool Initialise();
SFE_UBLOX_GNSS _gnss;
void setup()
{
Wire.begin();
vTaskDelay(10);
while(!_gnss.begin())
{
digitalToggle(LED_BLUE);
digitalToggle(LED_GREEN);
vTaskDelay(1000);
}
}
void loop() {
}
This to me, is even more simple than the example you pointed to, and this works āsometimesā and doesnāt work other times ā¦ what baffles me the most is that BOTH of the boards I am working with were working perfectly fine on Saturday, and then yesterday when I got back to them (because it was a bank holiday here on Monday), they just stopped working.
BatteryWatchdog_t BatteryWatchdog;
FlashChoreographer_t* startup_light;
TickType_t _lastRun;
void setup()
{
time_t timeout = millis();
Serial.begin(115200);
startup_light = new FlashChoreographer_t();
startup_light->CreateTask(FAIL_LED);
while (!Serial && ((millis() - timeout) < 5000))
{
startup_light->Flash(1);
vTaskDelay(250);
}
lora_rak4630_init();
Wire.begin();
while(!gpsUnit.Initialize())
{
#ifdef CONNECTED_FOR_DEBUG
Serial.println(F("u-blox GNSS not detected at default I2C address."));
#endif // CONNECTED_FOR_DEBUG
digitalToggle(SUCCESS_LED);
digitalToggle(FAIL_LED);
vTaskDelay(500);
}
digitalWrite(SUCCESS_LED, LOW);
digitalWrite(FAIL_LED, LOW);
BatteryWatchdog.CreateTask();
gpsTaskMaster.Initialize(BatteryWatchdog.GetMailBox());
RadioTransmitter.Initialize(SUCCESS_LED, FAIL_LED);
gpsTaskMaster.CreateTrackerTask(&gpsUnit);
gpsTaskMaster.CreateReporterTask(&RadioTransmitter);
}
void loop() { vTaskDelay(pdMS_TO_TICKS(50)); }
BatteryWatchdog_t is a task whose responsibility is to check the battery voltage and then overwite the message in a Mailbox (queue with only one entry which is never removed, but is overwitten with new values as they change). gpsTaskMaster is a class which wraps two OS Task instances, one task (TrackerTask) is responsible for collecting data from the GPS module and placing that data onto a queue, which the other (ReporterTask) removes, formats and passes over to the RadioTransmitter
This is the code which was working as expected when I finished up on Saturday. Yesterday morning we had a brief discussion here and decided that we would now like to make sure that the program does not attempt to start up the radio or the GPS module if the battery charge is below a specified level. The following is the change I made to achieve that.
#include "BatteryReader.h" in main.cpp
lora_rak4630_init(); in the setup function shown above I added if(BatteryReader_t::ReadVoltage() <= LOWEST_ALLOWED_BATTERY_VOLTAGE) { return; }
which would stop all board initialisation -this would leave the board powered on, but with a program with would simply run the loop function, so that we can charge the battery without it being dsicharged further.
This is the BatteryReader.h file (just for clarification of what it is doing)
typedef class ClsBatteryReader
{
private:
static const uint32_t vbat_pin = PIN_VBAT;
public:
static float ReadVoltage(void)
{
float raw;
raw = analogRead(vbat_pin); // Get the raw 12-bit, 0..3000mV ADC value
return raw * REAL_VBAT_MV_PER_LSB;
}
} BatteryReader_t;
When I uploaded that change to the board (which was connected via USB) I noticed that the board was not transmitting any data (we flash the onboard blue LED when a transmission is completed and it was not flashing). I opened comms on the connected port and there was no information coming through, which then led me to believe that the BatteryReader test had failed and we were now in the empty loop().
So I made a further change:
void loop()
{
Serial.printf("Voltage : %04.f", BatteryReader_t::ReadVoltage());
vTaskDelay(pdMS_TO_TICKS(500));
}
Then, when I ran the program and opened up the COM port, I viewed readings like the following
Voltage : 0809
Voltage : 0854
Voltage : 0906
Voltage : 0862
So it was only registering as 0.8V. Something which I found to be incredibly odd, since the board was currently being powered by the connected USB.
I then swapped the USB cable out thinking that maybe there was a fault on that, but no, I got hte same readings. I had decided that there must be something wrong with the code and that I must have introduced some other change that had resulted in these strange readings, so I reverted all of my changes, uploaded the program to the board and that is when the GPS unit started failing consistently in an inconsistent manner (if that makes sense)
This image shows one of the boards and the voltage reading I get whilst it is plugged in to the USB ā¦ this should be in the region of 4000 as per the following image
@beegee Iāve been thinking that it is power related, and this latest screen grab, kind of points in that direction.
The code running there is this:
while(!gpsUnit.Initialize())
{
#ifdef CONNECTED_FOR_DEBUG
Serial.println(F("u-blox GNSS not detected at default I2C address."));
#endif // CONNECTED_FOR_DEBUG
digitalToggle(SUCCESS_LED);
digitalToggle(FAIL_LED);
voltage = BatteryReader_t::ReadVoltage();
Serial.printf("Voltage @ %04.f\n", voltage);
vTaskDelay(500);
}
BatteryWatchdog.CreateTask();
gpsTaskMaster.Initialize(BatteryWatchdog.GetMailBox());
RadioTransmitter.Initialize(SUCCESS_LED, FAIL_LED);
gpsTaskMaster.CreateTrackerTask(&gpsUnit);
gpsTaskMaster.CreateReporterTask(&RadioTransmitter);
The board was connected via USB so that I could access the Serial data. As you can see, the board continued trying to start the GPS module, whilst reporting that the applied voltage was around 1V.
The line (fromt he screen grab) that reports Creating WatchdogTask comes after the GPS module has been initialised.
The line that reads $OWGPS,1,1,4290,,0 is the data that this board is going to send via LoRa P2P, and the significant datum therein is the number 4290 which is the voltage that the BatteryWatchdog_t is reporting.
@beegee I just donāt know what to say, but I think we can all agree that there was something I had missed.
This issue came to light when I started messing around with power: Iād got the board to power down the GPS module when the battery has discharged to a specified level, and then to power up the GPS module again when the battery has been sufficiently charged (i.e. to another specified level).
Well, thatās an interesting question as it turns out (or not so interesting at all really), completely at a loss I resigned myself to load the Example you pointed to onto my board. I fired it up and everything worked. I then took the GPS module out of slot A and put it into slot C, fired up the board and it worked as expected. I repeated these same steps with my second board, and guess what? ā¦ Thatās right, it worked as expected.
pinMode(WB_IO2, OUTPUT);
digitalWrite(WB_IO2, 0);
delay(1000);
digitalWrite(WB_IO2, 1);
delay(1000);
This code was the difference between the startup() function in the example code and in my code. Of course!! Iāve not made sure that power is being supplied to the GPS module! and more to the point, when the board is running, I have been (programmatically) manipulating the state of the power pin! Why, oh why did it not occur to me that I need to make sure the GPS module is supplied with power?
Yeah, that would be the stuff about the battery voltage readings ā¦ that turned out to be me trying to calculate a voltage reading without having set the analogReference and analogReadResolution
I am soooo glad that Iāve not toasted these boards!
I didnāt want to be insulting and tell you āitās your softwareā 
Thatās why I proposed to test with our default example.
Glad you figured it out. If your project is going into mass production, we can advertise it on our website. We love to show how our products help to build solutions.
It wonāt be mass production, but it will certainly be production ā¦