Wireless Tracker: GNSS performance

https://drive.google.com/drive/folders/1ym6L23z9e-D_7hsI7EO5h1_3bTL2wYJH?usp=sharing

1 Like

The documentation is really lacking a bit. The main source is the documentation for the UC6580 GNSS chip. Most of these documents require a registration for the support section of the website of the chip manufacturer. But, thankfully, @bns has already provided a google drive link to the relevant PDFs. Additional documentation for the standard NMEA 0183 messages can be found on the web, e.g., here. Most manufacturers implement proprietary extensions to the standard NMEA sentences, like the ones described in the mentioned PDF files.

bns, ksjh, thank you both. This is what I was looking for.
Excellent Job

1 Like

(Months laterā€¦)

I noticed that the uStar R3.0.0 app has been replaced with UPrecise.

Was there any benefit to uStar?

Also, if it wasnā€™t clear in the prior posts, for those who just want to test the Unicore UC6580 directly and leave the Wireless Tracker V1.1 unpowered, you can use a USB<>TTL (3.3V) cable and connect:

  1. VCC (3.3V) from the cable to the boardā€™s VEXT (GPIO3/PIN7)
  2. GND to the boardā€™s GND (PIN8)
  3. RX to the boardā€™s GNSS_TX pin (PIN33)
  4. TX to the boardā€™s GNSS_RX pin (PIN34)

The Heltec doesnā€™t power up but the UC6580 GPS module starts spraying NMEA at 115200/8N1.

I ran UPrecise and verified everything was working.

Interesting, thanks for the heads-up on UPrecise. I will give it a go soon and see if thereā€™s any notable difference in terms of features.

Regarding powering the UC6580: definitely works indeed, but if you want to benefit from being able to un-power the receiver while keeping its backup-power running, then powering it through the board itself is the way to go :slight_smile: because that keeps the Vback running as far as Iā€™m aware.

1 Like

The old UStar R3 interface looks better than new UPrecise!

I used Unicomā€™s UPrecise tool and went through each ā€œ$ā€ Unicom command. It looks like its defaults are fine ā€“ there is nothing that isnā€™t already enabled so thatā€™s reassuring.

I never got signal from an SBAS satellite though but they were listed (almanac?) as being in range. Iā€™m too far from QZSS sats so I donā€™t know about that.

The new $CFGSYS bitmask setting docs appear to disagree with the old docs. The QZSS and SBAS bits conflict between the two docs and an error will be returned if you try to enable those constellations.

As you all noted, the built-in antenna is only OK indoors but probably solid outdoors. It received some L5 sats for a little while but Iā€™m not convinced itā€™s an L5-capable antenna.

A cheap external L1 antenna (ā€œBingfuā€) is quite a bit better but only grabbed a couple L5 sats for a short while (not a surprise).

Iā€™ll try it later with an L1/L5 antenna.

Do you have any recommendations for an L1/L2/L5 helical antenna (cheap?)ā€¦

Thanks!

Edit ā€“ this is the output upon $RESET:

UC6580I G1B1L1E1 COM1
PN 2400615000268
SN 20230727114033005
HWVer 00
FWVer R6.0.0.0Build3700
Copyright (c), Unicore Communications Inc.
All rights reserved.

I did a little more testingā€¦

An inexpensive external Waveshare L1/L5 patch antenna takes a while to cold start but it demonstrated that the UC6580I receiver is quite capable and even from indoors Iā€™m seeing 70 sats and using 25 (L1+L5).

By comparison, the patch antenna really struggles from a cold start but seems like it can hang on to 14 L1 sats.

I guess the counterargument is that the use case for these devices is to keep them powered on indefinitely.

Hi everyone,

has anyone here tried calibrating the UC6580 chip themselves using NMEA codes to improve GNSS performance? If so, how did you do it? :slight_smile:

For example, when I send a message to the chip to stop it from sending the GNTXT message, it doesnā€™t seem to work.

Has anyone had experience with this or found a solution?

Thanks!

The meshtastic firmware folks silence everything but GGA and RMC messages.

These two NMEA compact ā€œsentencesā€ provide a satellite count and position.

You can see how they do it here.

FWIW, there appears to be a bug where the $CFGMSG settings are lost when the module is powered off. The settings should be reapplied when the module is powered back up.

1 Like

Hi again,

I wanted to let you know that I tried calibrating it myself. I also used commands like CFGNAV to increase the output frequency to 10 Hz (didnā€™t work -> FAIL, 0*1E was the response :frowning: ). Do i have to activate a special boot moder or smth? This should allow me to update the refresh rate for GGA and RMC messages, enabling me to receive more frequent messages. Iā€™m hoping this will lead to an improved performance.

How so? The GNSS will process signals at itā€™s own pace, all increasing the output frequency, as long as the baud rate can keep up, is tell you the same info faster.

Any use of the word ā€œcalibrateā€ with regard to GNSS involves tens of thousands of $$$$ of equipment - look at the Sparkfun website for RTK setups that will work down to about 1cm if done properly.

The rest us generally accept the cost / performance ratio of next to no money at all, like $10 for a GNSS module and get told inside 10 minutes where on the planet we are to about 2m accuracy. Seems like a good deal to to me!

If you need better, tell us what you need and perhaps we can help.

2 Likes

Edit: the patch antenna on the Wireless Tracker is pretty good outside!

33 sats quickly fixed.

Yes, I understand that as well :blush: and I am completely satisfied with the board. However, my goal is to minimize the initialization time while sending the AIDPOS of my approximate location. Iā€™m not sure why some commands, like CFGNAV, are not working with the UC6580, even after increasing the baud rate.

It sounds like you would like to use AGNSS?

That would require using Unicoreā€™s AGNSS server (and an internet connection).

I suspect AIDTIME and AIDPOS have limited value unless you also have ephemeris and almanac data.

The datasheet for the UC6580 says that time, ephemeris, and almanac data are retained as long as the module has V_BACK connected.

So the most practical way to achieve a warm or hot start on the Wireless Tracker is to ensure the the module has V_BACK power.

There is rarely a link between baud rate and a command working. And as I said above, you donā€™t increase performance of a GNSS by getting it to tell you where it is more often.

There is something rather meta about telling a GNSS where you think it is unless you can also feed it the almanac & ephemeris it needs to make use of the location which is what Assisted GNSS does.

If the module has a valid ephemeris and the new position you give it is in the area that it covers, it wonā€™t really make any difference as it will still need to do a hot fix to give you an updated location from your hint.

A fresh ephemeris is only valid for up to four hours, so after that, any position you give it will then use the almanac to compute which satellites it may be able to see and then search for them. As it would be reasonable to assume that the time is still valid, as long as you havenā€™t moved much more than 100km, you should get a fairly fast warm fix.

If the GNSS is off for an extended period, typically >90 days, it wonā€™t have an almanac so it will just have to listen for any satellites until its received the ephemeris & almanac. You feeding it a rough position wonā€™t help at all.

AIDINFO will give you some feedback on the status of the various constellations ephemeri so that you can choose to leave the module on to update itself. Chunks of the almanac come down at the same time so that will be incrementally updated.

So the best strategy is to keep a rough track of how long the module has been off so you can power it up to allow it to update itself.

Just to be clear, after a couple of hours, without providing the sat data the GNSS wonā€™t be able to use the approximate location to find the satellites it needs to give a more accurate fix any quicker than if you just let it alone.

2 Likes

I have experimented with AIDTIME and AIDPOS just the same, but figured out that it doesnā€™t make a darn difference. It may be that it gave back the GPS time just a touch faster, but not that much that I could give it a real number, and it didnā€™t help a single bit for TTF.

The most important thing is to keep the board powered such that the module retains its memory through V_back, but thatā€™s about the most useful thing you can do.
The UC6580 appears to come in two editions: the bare one on the Tracker and a fully integrated one for automotive (including 6-axis IMU etc), and I guess that these functions are somewhat locked/unused on the bare module.

2 Likes

@nmcc, @bns and @allanmac thank you for the help, i try to do some research now with keeping the data while letting the module turned on. :slight_smile: