Wireless Tracker: GNSS performance

I will upload something to github to provide more info, but I need to do some cleanups first. I will not touch the Arduino IDE, though. Does it help you, @bns, if I upload an Arduino-based PlatformIO project with an esp32-s3-devkitc-1 board definition without any Heltec stuff?

The GxGSV messages are describing the satellites in view, where the x encodes the constellation. Messages that start with GP are for GPS, GB for BeiDou, GA for Galileo, GL for Glonass, GI for IRNSS and GQ for QZSS. Most libraries take their position from GxGGA or GxRMC messages. Again, the start of the message encodes the constellation. For these, there is an additional prefix GN which is used for positions calculated from multiple constellations. The reason I used MicroNMEA was that it also decodes GNGGA by default, whereas some versions of TinyGPSPlus just relied on GPGGA messages. I just now took another look at the TinyGPSPlus source and found that the current version on github does also support GNGGA messages. Not sure which version I used previously. Therefore, it now makes little difference if you use TinyGPSPlus or MicroNMEA.
Do you have the unicore-firebirdii-protocol-specification-en-r1-01.pdf and/or ufirebird-standard-positioning-products-protocol-specification-en-r4-8.pdf documents? To access documentation from the GNSS chip manufacurer, you need to register, but it is no big deal to do so.

Sounds about identical to my config, so very welcome :slight_smile:

Ahh… explains why I wasn’t getting any different results wrt number of satellites! Glad to hear the TinyGPSPlus works just as well.

I have the Firebird II protocol specification, hardware reference design and datasheet - I don’t have the standard protocol specification.

You can find my example programs on github.

I did a few short experiments with my GNSS-transparent implementation and uSTAR 3.0 from the Unicore support section.

This is a Heltec Wireless Tracker just using the integrated antenna outdoors. It performs not so bad, it is able to track some L5 satellites. I did not expect this.

The reception became a little bit better with the L1-L5 antenna from AliExpress (the external one with the long cable). But the difference is not that dramatic. But now it was able to track Glonass satellites.

Then, I used a cheap professional GNSS surveying antenna (L1-L2-L5), the bigger antenna things you might know from construction sites. This shows that the UC6580 is really a quite sophisticated receiver. It tracks lots of satellites of different constellations and both L1 and L5 frequencies. Nice.

Unfortunately, at the time and place of the test, there were not many Galileo satellites present.

I was wondering if it would make sense to try some other firmware for the GNSS receiver to improve the TTF. One could ask at the manufacturer forum.
Another thing would be to save the last know position in flash memory and try a simple assisted GNSS (i.e., AGPS) solution. This might also speed up the TTF, assuming the receiver was not moved too far while it was switched off.

For comparison: This is what it would look like with a surveying-grade L1-L2-L5 receiver (UM982) that can track up to 1408 channels simultaneously, in the same place with the same surveying antenna.


Not so much difference in the number of tracked satellites, except that this receiver also supports the L2 frequencies.

And back indoors, with my L1-L5 external antenna. If you have had good reception once, the receiver happily continues tracking indoors.

Ahhh this is what I’m looking for - amazing work and detail, thank you!!!
Do you happen to have a link to the uStar software? I can’t find it from Google; or is it behind the Unicore login?
I hope to have some time soon to check this all out and run some comparisons, at least there’s now valid data to compare to :smiley:

And I already did a quick search on Unicore and AGPS but found nothing - do you have an idea how that would go? And what is “not too far while switched off” in your idea?

uSTAR is behind the Unicore login. If you have trouble registering, I will find a way to send it to you.
A simple form of assisted GNSS would be to provide a rough estimate of the current time and position to the GNSS receiver. The protocol specification mentions $AIDTIME and $AIDPOS. So, before you switch VEXT off, you could save the last position and also try to keep tracking the UTC time (RTC). Then, when activating the receiver again, you could try if sending the last position and the current time to the reciver helps. This should (hopefully) speed up the TTF. But when you move the reciver while it is off to a far away position, you are more misleading the receiver than aiding.

That’s all super useful, thank you. I will have a look at the Unicore login in a bit.

If I’m right, you said that you also have (something similar to) the GNSS receiver I linked & bought. Any chance you could give that a shot as well in uStar to compare against the other cheap antenna with the 2m cable? Curious to see the influence of nearby antennas. If I hold mine close (couple centimeter), they don’t work at all, so wondering if the u.FL cable length is enough to still get decent results compared to larger distance between the two.

Glad that this helps. I will see when I find the time to test the other L1-L5 U.Fl antenna and when the rainy weather is over here. I have no idea if the distance between the antennas really makes so much difference. But since they are connected simply in parallel, there might be unwanted influence, not sure.

Outside on my roof, Tracker with integrated antenna after two minutes or so:

Now with the AliExpress antenna connected:

After removing the external antenna, the integrated module is able to keep more sats alive:

So, the external antenna does seem to add value (at maximum u.FL distance). Thanks for referring the uSTAR tool, makes it much more scientific! :wink:
I mostly end up with 25 sats instead of 18 after doing a bit more testing, with more sats across all four systems.

Great :+1:, thanks for the feedback. Since I was using GPS for time synchronization in the research for my PhD thesis many years ago: Using the receiver with Lady Heather would make it really look scientific :wink:. It uses NMEA, after all, so it could essentially work. But it would bring exactly zero benefit in this use case.

1 Like

The external antenna also helps with TTFF, two sets of 10 tests - one stock Tracker, one with the extra antenna:SAVE_20240211_145937 SAVE_20240211_145946

1 Like

Creating something of a journal here while I experiment away…:
Word of caution on the orientation of the u.FL cable + antenna. I couldn’t reliably reproduce a certain configuration, but it appears to be of quite great importance how the cable and antenna are oriented relative to the integrated antenna. Sometimes I am able to put them completely next to each other with fine reception, but moving/rotating the cable or moving the antenna could result in a certain ‘dead spot’ where it lost all reception and received 0 sats.
Apparently there can be strong interference or ground-plane effects due to the large grounded blocks which can cause a loss of all reception.
Thankfully the uSTAR software is a great visualization tool to test this with :smiley: but generally word of caution for anyone that’s designing a product or expecting certain results.

A-GNSS doesn’t appear to help in any meaningful way. Here, I input the ‘exact’ location 2 seconds after issuing $RESET, and below the results. The A stands for an assisted fix, otherwise no assistance, followed by the number of seconds.

image

Interesting. Just the position, or also the UTC time? I assume that you left the power supply to the board connected all the time. Therefore, I think the backup power supply to the GNSS receiver was always powered on and the RTC of the receiver kept running. I would assume that the results might be different if you save the position to flash memory, remove power to the board completely (also no battery connected) and then try it again. But then you would need something like a Dallas RTC chip to get the current time.

Do you have pin headers soldered to the tracker? I can imagine that the shield of the U.Fl GNSS antenna connector (GND) could touch a GPIO pin. I have not checked if this is physically possible, since I have no pins soldered to my tracker boards.

I tried just position as well as position + time, but if it helped, it didn’t help much. Especially AIDTIME didn’t appear to do anything; AIDPOS does appear to shave a second or three off on average, but probably not worth the trouble. Plus not really reliable - sometimes it is still quite random (e.g. suddenly jumping to 40s instead of 28s).

The cable did not in any way short with a pin - I have accidentally ‘shorted’ the antenna backplane to a pin at some point and that just shorted the board with resulting loss of connection (USB removal / insertion sound played as well), but that is not the case for these ‘dead spots’. It must be ground-plane effects from the antennae / cable.

Good results - keeping the board powered and putting to / waking from deepsleep results in hot/warm starts! Deepsleeping for 20 seconds (with VExt disabled), the device has a fix in three seconds after waking. Don’t think I will have to pry the UC6580 casing open :wink:

Great, thanks for the info. Today, at work, I was testing an old u-blox NEO-6M receiver with integrated antenna indoors at the window sill. A colleague plans to install a 5G base stations to be used by our students in exercise classes. For this, he needs a GPSDO, and it would be complicated to position the antenna outdoors. Since the receiver was off for a long time and did not have a current almanac and current ephemerides, and the reception was bad, I was waiting for hours and still could not get a fix. So, all in all, the UC6580 is not that bad. Even for modern u-blox receivers (e.g., NEO-M8N) TTFF times from cold start are specified to take around 30 seconds. And, by the way, I was glad many years ago when we could get the u-blox NEO-6M, since reception with the Motorola ONCORE M12 we used before was much worse still.

1 Like

Hi,
I am new to this, but I have been search the web for hours trying to find the command protocol description so that I know how to set things like RESET and CNFG. I cannot find it anywhere.
This is the only post I can find anywhere that discusses these commands, si I was wondering if you could share how you know what these commands are. I have looked at the Umicore manuals and other documents and find them very lightweight with nothing like what I would expect in a manual. No description of power modes interfaces etc. Thanks for any help you can give.
Regards Chris