Wireless Tracker: GNSS performance

#1

Hi folks,

I am investigating the performance of the UC6580 which by default appears to be a bit lackluster. Yesterday, I had a discussion elsewhere with the user @ksjh. I will replay the first part of the conversation and we can continue below.

“I built a LoRaWAN Mapper using RadioLib and it’s working fine just fine! Woohoo! See <link> to see some datapoints…”
<Insert image of device using Wireless Tracker on a battery with a LoRa antenna>

Hi <bns>, this is a great implementation. I am currently using a similar solution, but with 3000mAh LiPo cells made by MakerFocus. Looking at the map, I see that your setup receives data from 15 GPS satellites most of the time. I am not sure if you are using the standard TinyGPS++ library, but this lib does just rely on GPS, no other constellations. The version the board manufacturer provides has been patched to include the messages $GNGGA and $GNRMC additionally to the GPS versions $GPGGA and $GPRMC . With another GNSS library like MicroNMEA and an external L1/L5 antenna, I am able to receive GNSS data from 20 satellites indoors and get position fixes much faster since it uses all constellations. You might need to send an initialization string $CFGSYS,h35155*68 to enable the additional GNSS systems.

"Duuude you’re coming in clutch here. I’ve been investigating the GPS performance the past couple of days.
The fact that the number of satellites on the map reports at a maximum of 15 is because I only reserved 4 bits for that field, since anything above 15 does not tell that much information; I can receive over 20 without problems.
I did indeed notice that the board outputs much more than the basic NMEA protocol, but have been focused on user experience the past weeks, since I recently got one of my devices out to an experienced tester. Since that’s now mostly fixed, I started looking at this.
Is the integrated antenna capable of receiving these L1/L5 signals, or do you need the extra antenna for that? And can you please recommend me some antennas? I see a wild variety of sizes and prices after a quick search.

I’ve also been trying to activate the GPS backup power, but I can’t really seem to get it working. Have you used that in any way or can you share any thoughts on it?"

Hi <bns>, glad that the info was useful.

  • I think the integrated antenna is not really meant for L5. The usual L1/L5 patch antennas look differently. You might be able to receive really strong L5 signals occasionally.
  • You can try to find the UPrecise application on the web and program the board to output all GNSS data via USB CDC so that you can visualize the GNSS NEMA sentences. Doing so will show signal reception for different constellations and frequencies.
  • I used a cheap external antenna bought at AliExpress, no-name, active, with SMA connector and an U.Fl to SMA pigtail. I can send you the link somehow, but I do not want to spam the discussion here.
  • Did you try to connect something (e.g., a button cell) to test pad T3 (Vbat) and T4 (GND)? Looking at the schematic, a battery connected to the main battery connector of the board should feed the backup supply input of the GNSS chip anyway, even when Vext is disabled. So, unless your main battery is disconnected or completely flat, you would not notice any difference. I did not try an additional button cell.

@ksjh

You can try to find the UPrecise application on the web

I will try this out, sounds useful!

I used a cheap external antenna bought at AliExpress … I can send you the link somehow

Yes please! I’d really like to give this a shot. Question then is: does an external antenna overrule the built-in antenna on the Tracker, or would they combine their reception? Any idea?

I haven’t tried connecting a separate battery to the V_back T3 pad on the back - did you connect anything to the pad (your main battery?), do you keep your device powered continuously (e.g. utilizing deepsleep - does this keep V_back powered?), or do you not care enough about your TTFF?

By the way - you mentioned 20 satellites indoor: is that like at the ground floor in the middle of a house, or is that still near a window on the top floor?

1 Like
#2

Well, the antenna I used is this one:

https://www.aliexpress.com/item/1005005426016725.html

When I look at the schematic, it seems like both antenna inputs are connected in parallel. There is no antenna switch. So, both are active at the same time. Not sure this is the best configuration. Then, the antenna signal seems to be fed into an SW7125DE LNA to amplify the signal by 20dB. This chip is specified to operate in the frequency range from 1550 to 1650 MHz. The L5 band for GPS is at 1176.45 MHz, so it outside of this band, also not optimal. Then, there is an bandpass filter to filter the frequency band and feed the signal of the two bands to individual inputs for L1 and L5.

Currently, I am using the device just as a mapper, therefore, I switch it on for mapping and then off after I am done with mapping. This means that the first TTF takes longer, but afterwards, my GNSS receiver stays on all the time. Normally, GNSS receivers have three different boot states, cold, warm and hot. I did not find this information in the datasheet for the UC6580. Cold boot means that the almanac (rough position of the satellites) is unknown. Acquiring the almanac takes a long time. I hope that at least the almanac is stored in some NV memory, even when switching VEXT off. But the schematic shows that a battery connected to the main battery connector should power the V_BACK pin of the GNSS chip (via an LDO and a diode), independent from anything connected to the T3/T4 pads. The UC6580 datasheet just specifies that V_BACK is used to power the RTC section and Retention RAM. Not sure what is retained in this RAM.

With the antenna mentioned above, I was able to receive 20 and more satellites indoors. This was in a position where there was just drywall plates, thermal insulation, some wood and a slate roof above the antenna (so, top floor of the building). But the slate roof was wet, it was raining at that time. I also tested it outdoors without any cover briefly and recieved more than 32 satellites, but the weather did not allow for longer outdoor testing at that time.

2 Likes
#3

Awesome, thank you very much for sharing the information! I’ll try to get my hands on one of those antennas and see if it improves my situation. You’ve given me a lot of tools to do more research, thanks!!
Hopefully I can acquire one of these antennas relatively fast & will update once I have useful findings or more questions.

#4

Yes, it is really sad that the antenna and the LNA are not optimized for L5 reception. The GNSS receiver ist really a quite sophisticated one, especially at this price point. I would almost buy the boards just for the GNSS receiver alone, even when not using any other features like LoRaWAN, the display or anything the ESP32-S3 has to offer.

1 Like
#5

Then it sounds worth it to try and squeeze the performance out of it :smiley:
One more question: do you know if it is possible to put the receiver into some sort of sleep mode? I have scrolled through the available commands and have successfully configured e.g. PPS settings, but I couldn’t find anything about some sort of sleep mode.
The GNSS receiver is coupled to display power which is a bit unfortunate since the receiver does consume quite a lot of power. Pulling GNSS_RST to ground lowers the power consumption by about 20 mA, but then there’s still 15~20mA power consumption…

#6

This is another unfortunate design decision by the manufacturer to only use one VEXT pin to enable the LoRaWAN transceiver, the display and the GNSS chip all at once. Since I am currently using the device for mapping, not tracking, I had the opposite idea: I would prefer to power down the display completely, not just switching the backlight off and not updating. But the only thing that looks like remotely useful for disabling the GNSS chip seems to be the command $RESET,3,h0. I have not tried what it does, but the protocol specification says for the parameter ‘3’ in this command : Receiver stops working. No idea if it self-destructs or whatever :bomb::crazy_face:. Perhaps worth a try?

I was also wondering if a Heltec CubeCell GPS-6502 (HTCC-AB02S) might be a better choice for a tracker. The GNSS system used in this model (AIR530Z) promises a much lower power consumption, but also provides less features (no L5 reception). Btw.: The processor in this model an ARM M0+ core, not the one from the Commodore VIC20 :laughing:, despite the name. One should also be able to get it running with PlatformIO, Arduino and your LoRaWAN implementation. But, at first glance, again just one VEXT for everything.

#7

The Tracker v1.0 had two separate power pins for display and GNSS… wonder why they coupled them into one indeed!
Fortunately, the SX1262 is not coupled to Vext - it works on 3V3 only

I’ve literally been wondering the same! I do have a somewhat damaged Tracker which I might at some point sacrifice to test this… it would be really nuclear if it self-destructs!

While the AIR indeed consumes much less power, the Cubecell series uses an outdated firmware and a really poor flash & RAM size… it’s nothing compared to the shiny ESP32-S3.
For me, that is definitely an easy choice, but it of course depends on one’s requirements.

I may be tempted enough to give the reset command a try… will let you know if I did!

#8

Indeed, thanks. I just took a look at the schematic again.

Yes, as a general purpose board, it is clear that the Wireless Tracker is much more versatile. No doubt.
But for specific low power sensor nodes, I would perhaps have given the Cubecells a try. But since you mentioned the outdated firmware and I am not sure if it is possible at all to ignore all the pre-programmed code and just flash your own firmware without any Heltec stuff (I read that SWD does not work with these boards, so I have doubts), they might not really worthwhile experimenting with. I could tolerate the limited amount of flash and RAM for some purposes, but not limited ability to program the system. Thank you for saving me the time and money :+1:.

#9

Took out my kamikaze Tracker. And look! (A dot . is printed for every received NMEA line, the rest is printed normally).

12:39:54.943 > $RESET,3,h0
12:39:54.947 > ......................................$OK*04
(--reset GPS module here through pin 35--)
12:40:14.604 > 
12:40:14.606 > UM600 G1B1L1E1 COM1
12:40:14.606 > PN N/A
12:40:14.607 > SN N/A
12:40:14.607 > HWVer 2.0
12:40:14.609 > FWVer R6.0.0.0Build2810
12:40:14.611 > Copyright (c), Unicore Communications Inc.
12:40:14.614 > All rights reserved.
12:40:15.616 > ....................................

Can happily get a fix still!

#10

Great, thanks for trying. Did you already notice a reduction in power consumption after the “kill-switch” command? Glad that the GNSS works like normal after a hardware reset. Does is affect the TTF after the reset much in your case?

#11

Unfortunately, the power consumption only drops by about 10 mA out of the 35~40mA total :frowning: so it’s not doing much within that regard…
There may be a ‘normal’ way to wake up the receiver after a reset, but a software+hardware reset (effective five seconds or so) does seem to increase the TTF roughly three times or more compared to just a quick hardware reset only. But my methods are not exactly scientific LOL, just a bit ‘feels like’

1 Like
#12

Hi Gents,
can you please share with me a piece of code sample which makes the GPS to work. I had tried various samples (from Examples in Arduino IDE) but I am not receiving any signal.

Many thanks in advance !

#13

I could try to extract some of my code for you, but since I am not using any Heltec stuff, not even the board definition, and doing the coding in PlatformIO using VSCode, it might not be that useful for you. One thing: Did you switch VEXT on (set GPIO3 to HIGH)? Did you configure your serial port accordingly? You could try this setup (for the Wireless Tracker V1.1):

pinMode(3, OUTPUT);
digitalWrite(3, HIGH);
Serial1.begin(115200UL, SERIAL_8N1, 33, 34);

Another thing that you might do afterwards is to activate all supported GNSS systems and frequencies:

Serial1.println("$CFGSYS,h35155*68");

Please note that the standard TinyGPS++ library does only support GPS, no other systems. It might make sense to either use the version patched by Heltec or a completely different library like MicroNMEA.

But for me, even the Heltec supplied factory test implementation worked. Not sure what could have gone wrong in your case.

#14

A few days ago these receivers have arrived. I haven’t had the time for a full investigation yet, but from my first tests paired with MicroNMEA, I seem to get less rather than more satellites! Must say that with the shorter cable the two receivers are of course quite close to each other as I’m not planning on keeping them two meters separated like the one you mentioned.
I also am somewhat puzzled by the initialization in the examples for MicroNMEA - did you remove everything and just add the cgfsys one? Could you maybe provide your setup() function for me to double check? I hope to dive in a bit more next week.

#15

Which type on the Ali page did you order? The difference is the gain of the LNA. The external one I have has 28 dBi, just like type A in your listing. I think I have ordered this antenna as well (type A), but have not tested it so far.

I use MicroNMEA similar to TinyGPSPlus. I just read serial data (byte by byte, could also read larger chunks) and pass it on to nmea.process(). I do not do any init except for enabling the constellations. So:

char nmeaBuffer[128];
MicroNMEA nmea(nmeaBuffer, sizeof(nmeaBuffer));

void setup_gnss() {
  pinMode(VGNSS_CTRL, OUTPUT);
  digitalWrite(VGNSS_CTRL, HIGH);
  Serial1.begin(GNSS_BAUD, SERIAL_8N1, GNSS_TX, GNSS_RX);
}

void init_gnss() {
  char gnss_cmd[40];
  char gnss_chk[3];
  //                              33222222222211111111110000000000
  //                              10987654321098765432109876543210
  const uint32_t gnss_sysmask = 0b00000000000000110101000101010101;
  sprintf(gnss_cmd, "$CFGSYS,h%x*", gnss_sysmask);
  nmea.generateChecksum(gnss_cmd, gnss_chk);
  // $CFGSYS,h35155*68
  Serial1.printf("%s%s\r\n", gnss_cmd, gnss_chk);
}

void setup() {
  // [..]
  setup_gnss();
  init_gnss();
  // [..]
}

void loop() {
  while(Serial1.available() > 0) {
    gnss_ch = Serial1.read();
    nmea.process(gnss_ch);
  }
  if(nmea.isValid()) {
  // [..]

I have not modified the standard configuration of the GNSS module, but you could also make some modifications and write the config to non-volatile memory, so that you do not need any config at all.

#16

I ordered the type A with 28dB gain! So that should match to your setup. I’ll give your code a shot likely on Monday, thank you! Will be happy to hear if you get similar results with a short-wire version.

#17

I will look into MicroNMEA now, but am already puzzled by something else:
From the datasheet, it appears that the V_back of the receiver is tied to 3V3. This leads me to assume that even during deepsleep, V_back would remain powered. From the UC6580 datasheet, this would consume about 5 μA:

Backup Mode: 5μA @ 3V

However, the Tracker has a deepsleep power consumption of 18.5 uA, while the Wireless Stick Lite V3 and the Wireless Paper consume (at least for the 2 boards that I have tested) 20 to 24 μA. And they don’t appear to have any additional circuitry like the GNSS receiver.

If someone could shed some light, I’d be happy. I do not know of a ‘scientific’ way to confirm that backup power is retained, I can’t very reliably get a certain TTF or so.

#18

I think we need to assume that the schematics provided by Heltec are accurate. Then, you are completely right, on the Tracker, V_BACK is tied to VDD_3V3. When you compare this to the schematic of the WiFi Lora 32 (V3.1) and the Wireless Stick Lite (V2.1), you will find that the difference here is that the Tracker has two separate LDOs (CE6260B33M), whereas the others use just one of them. Switching V_EXT on or off is done on the Tracker by switching one of the LDOs on or off (EN pin), while the WiFi LoRa 32 or Wireless Lite Stick use a P-channel MOSFET to switch V_EXT on or off. This could lead to different standby currents.

Scientific way to show that V_BACK is present: “Thou shall measure voltages!” The metal can over the UC6580 on my tracker can be removed. You could probe the pins of the chip. But they are tiny. You might need a microscope to attach probes. But, at least, using a microscope sound very scientific :grinning: to me. The cathodes of diodes D5 or D6 might be more accessable points to probe (again assuming the schematic is correct, but then you would not need to measure).

#19

That sounds a bit destructive… but I seem to recall I have a somewhat damaged Tracker anyway :wink: I will see if I can pry it open to check the size of those diodes…
Your suggestion on the standby current does sound plausible - also makes you wonder why they wouldn’t do the same for the other boards…? :man_shrugging:

#20

Still stuck on MicroNMEA / GNSS antenna. Using this tool which appears to recognize quite a lot of messages, judging by ‘parsing log’.

Device is outside on the roof at about 30 degree angle, rainy weather. Output by receiver:

16:18:25.881 > $GNRMC,151826.00,A,5201.89003,N,00534.31521,E,0.046,,080224,,,A,V*11
16:18:25.883 > $GNGGA,151826.00,5201.89003,N,00534.31521,E,1,21,1.39,56.2,M,,M,,*6E
16:18:25.885 > $GNGSA,A,3,18,27,28,26,31,16,04,,,,,,1.91,1.39,1.31,1*03
16:18:25.888 > $GNGSA,A,3,79,81,,,,,,,,,,,1.91,1.39,1.31,2*04
16:18:25.889 > $GNGSA,A,3,43,25,28,23,37,,,,,,,,1.91,1.39,1.31,4*0A
16:18:25.891 > $GNGSA,A,3,07,30,34,40,53,02,36,,,,,,1.91,1.39,1.31,3*04
16:18:25.893 > $GT,01,01,01,0,500482,0000,80A0,80A0,185.823,0*70

This is ‘normal’ output if I’m correct, also parsed by TinyGPS

However, every 10 or 20 seconds or so, there are some additional sets:

16:19:47.110 > $GPGSV,3,2,12,18,51,165,38,20,14,035,,25,20,124,,26,59,289,46,8*61
16:19:47.112 > $GPGSV,3,3,12,27,04,254,29,28,33,205,44,29,55,067,,31,47,235,,8*65
16:19:47.114 > $GLGSV,3,1,11,70,03,318,,71,12,004,,72,05,048,,78,52,152,,1*77
16:19:47.117 > $GLGSV,3,2,11,79,68,307,33,80,14,321,,81,53,215,28,82,06,217,,1*7B
16:19:47.119 > $GLGSV,3,3,11,87,12,039,,88,66,047,,38,27,206,,1*47
16:19:47.121 > $GBGSV,4,1,13,05,13,120,46,8*61
16:19:47.122 > $GPGSV,3,3,12,27,04,254,29,28,33,205,44,29,55,067,,31,47,235,,8*65

16:19:48.127 > $GLGSV,3,2,11,79,68,307,32,80,14,321,,81,53,215,28,82,06,217,,1*7A
16:19:48.130 > $GLGSV,3,3,11,87,12,039,,88,66,047,,38,27,206,,1*47
16:19:48.131 > $GBGSV,4,1,13,05,13,120,,08,35,053,,11,71,073,,12,17,054,,1*7B
16:19:48.133 > $GBGSV,4,2,13,13,38,071,,22,06,030,,23,66,219,45,25,28,161,40,1*7D
16:19:48.136 > $GBGSV,4,3,13,28,18,228,40,34,46,062,24,37,35,304,41,38,26,040,,1*70
16:19:48.138 > $GBGSV,4,4,13,42,06,217,,1*7B
16:19:48.139 > $GLGSV,3,3,11,87,12,039,,88,66,047,,38,27,206,,1*47
16:19:48.141 > $GBGSV,4,1,13,05,13,120,,08,35,053,,11,71,073,,12,1

16:19:49.144 > $GBGSV,4,2,13,13,38,071,,22,06,030,,23,66,219,45,25,28,161,39,1*73
16:19:49.145 > $GBGSV,4,3,13,28,18,228,40,34,46,062,23,37,35,304,41,38,26,040,,1*77
16:19:49.149 > $GBGSV,4,4,13,43,77,193,42,1*4E
16:19:49.150 > $GBGSV,4,1,13,05,13,120,,08,35,053,,11,71,073,,12,17,054,,5*7F
16:19:49.152 > $GBGSV,4,2,13,13,38,071,,22,06,030,,23,66,219,45,25,28,161,38,5*76
16:19:49.154 > $GBGSV,4,3,13,28,18,228,38,34,46,062,,37,35,,1*7D
16:19:49.156 > $GBGSV,4,3,13,28,18,228,40,34,46,062,23,37,35,304,41,38,26,040,,1*77
16:19:49.159 > $GBGSV,4,4,13,43,77,193,42,1*4E

These are not parsed by the decoder, and also my MicroNMEA appears to malfunction because everything is kept at zeroes even though I call nmea.process(c).

@ksjh I would be grateful if you can share a more complete script, as apparently I am missing bits; plus do you know if those latter sets contain actual GNSS info, even though the online parser doesn’t show anything?