GNSS not working

Hello, everyone!
I’m a new programmer and I just bought a Wireless Tracker. I’m using Arduino IDE to build my code to test the GPS, with the examples of the library TinyGPSPlus (simples code to print latitude and longitude). However, it seems that the GPS is not being initialized correctly, since no coordinates are shown on the serial.
I’m using Pins 34 for RX and 33 for TX. I’m not sure if I need to conect anything physically on the board on those pins, the only thing I connected was the antenna on the GNSS pin on the back of the board. Is there anything else I should define on the code? Is there any configuration I should do on the board? Do you have any example code for me to test it? I just need to read the latitude and longitude from the GPS.
I really don’t know what I’m doing wrong!!

CODE:
#include <HardwareSerial.h>

#include <TinyGPS++.h>

HardwareSerial Serialgps(2);

TinyGPSPlus gps;

void setup() {

pinMode(46,OUTPUT);

pinMode(3,OUTPUT);

digitalWrite(3,HIGH);

Serial.begin(115200);

Serialgps.begin(9600, SERIAL_8N1, 33, 34); // Pins 34 (RX) 33 (TX)do GPS

}

void loop() {

if (Serialgps.available()) {

int c = Serialgps.read();

if (gps.encode(c)) {

 

  if (gps.location.isUpdated()) {

    float gpslatitude = gps.location.lat();

    float gpslongitude = gps.location.lng();

   

    Serial.print("Latitude: ");

    Serial.println(gpslatitude, 6);

    Serial.print("Longitude: ");

    Serial.println(gpslongitude, 6);

   

  }

}

}

}


Hope to be helpful to your friend

Which version of the board do you own, V1.1? When this is the case, your GPIO pins and baud rate might not be right. For these boards, I use the following code:
#define GNSS_TX 33
#define GNSS_RX 34
#define GNSS_RST 35
#define GNSS_PPS 36
#define GNSS_BAUD 115200UL
Serial1.begin(GNSS_BAUD, SERIAL_8N1, GNSS_TX, GNSS_RX);

@ksjh I tried using our tips and for sure now the GNSS is probably on, but is still not reading the values correctly! I’m now using the example below, but in the Serial Monitor, when I print the values from the Serial1.read, these are the lines that appear:
$GNRMC,V,N,V37
$GNGGA,0,00,99.99,56
$GNGSA,A,1,99.99,99.99,99.99,1
33
$GNGSA,A,1,99.99,99.99,99.99,2
30
$GNGSA,A,1,99.99,99.99,99.99,436
$GNGSA,A,1,99.99,99.99,99.99,3
31
$GNGSA,A,1,99.99,99.99,99.99,537
$GPGSV,1,1,00,1
64
$GPGSV,1,1,00,86D
$GLGSV,1,1,00,1
78
$GBGS1,0,000002,0000,0000,0000,136.095,0*74
0000-00-00 99:99:99.00
LAT 0.000000
LON 0.000000
ALT 0.000
HDOP 25.5
NMEA invalid.

I went outdoors to try it, and the only thing that appears is the correct date and the wrong time (don’t know the reason that the time is 3 hours ahead), but latitude and longitude still zero!
Any idea of what it can be?

EXAMPLE LINK: https://github.com/ksjh/HTIT-Tracker/blob/main/src/MicroNMEA-serial.cpp

The first time it can take well up to 15 minutes before you get a full GNSS lock, as the device needs to figure out where on the world it is. Next time around (within ~4 hours) it will have a pretty good idea as the satellites haven’t moved too much and take a few tens of seconds, after those ~4 hours it’ll take medium-long to get the location lock (up to a minute or so). After ~4 weeks off it may take up to 15 minutes again.
Those numbers assume a reasonable view of clear sky.

@bns thanks for the help! I was definitely not patient enough kkk Now everything works perfectly!
Also thanks @ksjh and uther for all the support!

1 Like

Hi I am new to the GNSS module too, does it mean it have to wait ~15minutes every time I turn on the GNSS module from deep sleep? What will happen if I the tracker is constantly moving within 20km ranges?

For reference, I have two trackers on the arm rest of my sofa, with a tiled roof two meters above them. They wake up once every hour to find their position. One tracker does so within 60s without any problems ever (usually faster), the other (30cm apart) is seen to take a minute or three in some cases, although it does have faster fixes too.
But if I were to flip one upside down (satellites 180 degrees opposite compared to what it remembers) I’d be lucky to have it get a fix in three minutes. If I take it outside into the yard, it’ll have a fix in 30 seconds no problems. If I mount it on the bicycle and have it wake every minute, it’ll have a fix in 5 seconds.

Really, the takeaway is that GNSS just isn’t a sensor in the terms of ‘30s startup time, then stable’. It so much depends on environment and use. I’d say it is almost mandatory to combine GNSS with an accelerometer so it knows when it moves - only turn on when necessary. You should design for the GNSS receiver to be on for at least 5 minutes, and if it’s faster, yay, party. Once it has a fix and you keep the GNSS receiver on, you’re always golden. The UC6580 racks up a lot of satellites if left on, you can go indoor pretty well if you’ve been outside for a few minutes.

So… you don’t need to wait 15 minutes every time if you’re outside. But it depends on the wake interval, orientation, view of sky, … Really, the GNSS chip in this thing is great, I wouldn’t trade it for any other - they’re very likely to do much worse. But do not blindly trust for it to work the same everywhere everytime, then you’re doomed to fail.

Super very hard to say as you don’t say how long the board will be asleep for, just that it will be in deep sleep!

TL;DR: If the module runs for a minute or so every few minutes, the most up to date positional data will be good and, with a clear view of the sky, be quite quick - seconds. Turned off for a few hours it may be a couple of minutes. A few days, may be 10 minutes …

I bought a few pieces of the wireless tracker, but they haven’t arrived yet, so I can’t try them out. Just to clear some doubts, let me explain my scenario:

In my case, the device will be used in the jungle. Hikers will carry the wireless tracker while hiking. The device needs to wake up from deep sleep every 5 minutes, get the location and time, and send it via LoRa. A 3.7V LiPo battery will be attached to the provided battery port.

I have3 questions:

  1. Since the battery is always attached, will the GNSS module always perform a hot start, even when the controller is in deep sleep?

  2. Do I need to expose the GNSS antenna (the square one provided), or can I cover it with a plastic enclosure?

  3. The GNSS module has memory to store the last known location, right? So even if I disconnect the battery for a few hours (while still being in an open area), will it still perform a warm start when powered back on?

Yes/no: with the battery always attached, it will remember its ephemeris data, which means that it has a pretty good clue of where the satellites should be - this means it can do a hot start, but the longer the GNSS chip is not in use, the worse it gets. 5 minutes off should be in the region of a hot start ~ warm start if stuff didn’t change too much.

Covering it with some plastic is perfectly fine.

It’s not about location, it’s all about almanac & ephemeris. As far as I’m aware, the almanac (long term satellite trajectory) is stored in non-volatile memory, so it survives a battery disconnect. Ephemeris (short term satellite trajectory) is stored in volatile memory and is lost when there is no power on V_back, and V_back is powered by the battery. So a battery disconnect will result in a cold start, meaning at least 30 seconds but that’s best case.

I have tried pretty seriously to use AIDPOS and AIDTIME to improve the TTF but haven’t found any meaningful improvement.

You should check the schematic for this and the data sheet for the UC6580 to see if it stores the data in NVM - there is no external coin cell.

Spoiler alert!

The datasheet says it doesn’t. You have to keep Vext_Ctrl high when sleeping - this also powers the display. @bns will advise on the details as he is a Wireless Tracker Ninja.

In a forest? Won’t make things any worse than the canopy cover of trees which are ruinous for GNSS! That said, @bns uses his in coal mines so YMMV!

So you’d best monitor the number of sats that are being used to provide the position along with the hdop, so you don’t grab a fix that’s out by a few km. You can also compare with the last fix so if the tracker has moved a lot, you double check.

Quick catch that this is not required for the chip to do do a hot start - the most important stuff is retained without powering the GNSS chip fully. Most importantly keep the battery connected. (@Nick: Mappy doesn’t keep GNSS powered either.)

Ah, horizontal power wires for the win - I can see that V_BACK is connected all the time.

Wonder what the effect is on it when it’s reset on power up via Vext?

I’ve wondered the same, but it does hot starts so I chose to not care further.