Un poco de actividad en tu zona…
1 Like
This would explain my problems today.
These things can happen when atmospheric issues aren’t corrected.
The Trimble website reported activity 7 out of 10.
1 Like
Keep in mind you can view the Video from past days at JPL.
The past 24 hours aren’t significantly different than the past 2 days -
2 Likes
My problems these days seem to be atmospheric.
Yesterday, as night fell, I had a good series of data, with average distances to the base point of 10 cm.
Today, during peak tecu hours, the problems and disconnections from the HAS corrections returned.
That is, randomly, I would stop receiving HAS corrections.
Later they would come back, but the accuracy was never good. Always above 35 cm and up to 1 meter, even though it indicated accuracy of less than 10 cm.
PD I forgot to mention that I put a metal plate on the antenna, as suggested.
Hi Ryan (@rftop ),
Humm… We might not have included PQTM when we overhauled the GNSS_CONFIG code. I have opened an issue for this.
Best,
Paul
1 Like
Hi everyone.
First, I should mention that Uruguay is almost always near or within the equatorial anomaly, which seems to complicate PPP corrections.
I investigated the most likely times when the electronic charge (TECU) is very low.
During those time zones, I’ve obtained improvements in the data obtained with Galileo HAS corrections.
About an hour ago, my zone turned a light green, almost blue (TECU ± 40), and I have deviations from the fixed point of less than 20 cm.
Your ideas about atmospheric disturbances seem to be confirmed, and this would be a major problem for the practical use of Galileo HAS corrections in fieldwork.
Even if Galileo HAS had atmospheric corrections, they seem to be only for the European zone.
I will continue to report on the correlation between TECU values and the accuracy of the measurements taken, compared to a fixed point with coordinates from Canada PPP.
Regards, Angel
1 Like
At stage 1, Galileo HAS don’t have atmospheric correct, never ionospheric nor tropospheric. Indeed, double or triple frequencies receivers should cancel themself ionospheric contribution by performing differences between delays of each frequency (from the same sat). But statistics say that one can subtract signals but we always add noise. And also that each signal is associated with a noise i.e. bigger signal means bigger noise.
One may also mention Equatorial plasma bubble although I would not consider Urugay as an equatorial country but seems to be affected by an equatorial wave on your map.
1 Like
Update for the Feb 11 Release Candidate .bin file , release info :
The PQTMPPPNAV message now works great on the PostCard. Thanks Paul !
A generalized summary from my testing:
- 20cm seems to be a realistic number after HAS/E6 Convergence, if no multi-path conditions. I’ve seen as quick as 6 minutes, ~10 min Average, and 15+ minutes generally means a local atmospheric upset.
- 40cm is a realistic number for repeatability of a mark across convergence solutions / different days in the southeast US. I think that’s inherent to HAS/E6, not the hardware.
I think Marco (@bamarcant) made a great point in this thread. HAS/E6 could be useful during the survey-in procedure for a local Base/Rover. The FW could watch for PPP convergence (State 7 in the PPPNAV message), then cook for a few more minutes (user defined) before automatically switching to broadcast (and recording the position). Because…Why not use HAS/E6 during a survey-in procedure?
1 Like
Hello everyone. Your results are very promising. However, I’m curious to know how you configure your chips, as I’m far from achieving your results. I’m in France, using the latest firmware version (02A01), and I maintain an accuracy of over 80cm after 30 minutes of static observation. My parameters are as follows:
$PQTMCFGCNST,W,1,1,1,1,0,02B
$PQTMCFGPPP,W,2,1,180,0.10,0.1561
$PQTMCFGSBAS,W,0000*0E
My measurements of the day (each circle is 20cm apart)
I must be doing something wrong.
What antenna you use?
If you are in an open field or in an urban space also makes a difference…
1 Like
You need a really good GNSS environment for ~ 20 cm horizontal accuracy. It doesn’t take much obstruction to reduce the accuracy.
Also 30 minutes sometimes isn’t enough time to converge in a true accuracy sense. I’ve seen it take multiple hours at times even in good receiving areas. Not often, but it does happen. Note that I’m not talking about the receiver reported convergence which is almost always going to be optimistic.
In short, with the LG290P or Unicore UM980 you can get close to the HAS accuracy specs, but the GNSS environment needs to be really good. Better than what you need for RTK/PPK.
Also are your reference coordinates in the Galileo Reference Frame (current epoch)? Essentially ITRF2020 or WGS84 (current epoch) and not perhaps some version of ETRS89?
I’m using an AT-603 type antenna. I’m in an imperfect environment, but correct open sky, with 19 GPS/Galileo satellites in view, and more than 25 in total. I think Jbp has found the problem. I’ve reread the discussions in the different topics, and I think I’m doing it all wrong in terms of methodology. I’m taking an RTK control point with ntrip, then I’m doing a PPP HAS survey. All of this is done in SWMAPS, whose project is in Lambert93. My ntrip correction antenna should be operating in Lambert93/ETRF2000, and Galileo HAS in ITRF2014, which seems consistent with my 80cm to 1m discrepancy. I’ll do another test tomorrow. Thank you for responding so quickly and so well 
Hey there, just chiming in with my results although I should preface that my LG290P is a generic breakout board from aliexpress with some cheap included patch antenna.
$PQTMCFGPPP,W,2,2,90,0.1,0.15*61
$PQTMCFGMSGRATE,W,PQTMPPPNAV,5,1*43
QGNSS deviation map for PPP (~37m of 10hz fixes)
PS: Thanks for keeping a public repo of LG290P firmware sf!
Also, my receiving environment could be better, I just swung them out the window onto the porch roof 
( I attached a photo but forum rules only allow one image 
)
I think your problem is your cheap patch antenna, as you mentioned. You need at least a decent quality antenna to get good results with Galileo HAS.
Hi everyone. I’ve been on vacation and now I’m back testing Galileo HAS.
During peak hours with high TECU, I’m still having major problems with real-world accuracy relative to my fixed point.
As evening falls, things start to improve, and I get accuracy better than 20 cm.
I’m worried because for most of the day, with the Postcard RTK and a helical antenna, I can’t get any useful data. On the ionospheric map, the equatorial anomaly is above my area for most of the day, even if it’s just on the edge.
I’ve ordered a higher-gain UFO antenna and I’ll see if the results improve.
Your comments are appreciated.
Regards, Angel
[Warning: I’m guessing here]
In this particular circumstance, I wouldn’t expect a better antenna to have much impact on HAS/E6 performance. I know that sounds crazy…but once your receiver sees and decodes the HAS correction, that’s really all it can do with it.
For instance, I have a dinky little patch antenna on HAS testing right now.
It’s seeing (4) Galileo birds with a good E6 signal.
It only needs 1 bird with E6, 2 or more is just redundancy to avoid signal interruption.
Before I get in trouble… a bigger and better antenna is always good. Just not sure it helps in the context of HAS/E6 
Definitely worth exploring and finding out for sure.
2 Likes
Thank you for your kind words. When my larger antenna arrives, I’ll comment on whether there’s a difference in the results.
Analyzing the ionosphere since last year (2025), I see that in my winter, the TECU values over my country are much lower than what I’m seeing these summer days.
I suppose the better results obtained last year were due to lower ionospheric activity.
And that’s why my results are also improving now, in the late afternoon and into the evening.
I’ll share my results with my new antenna later.
Regards, Angel
3 Likes
Hi everyone.
I received an email with a 2.01 debug firmware, but first I’m testing the previous beta version, which I remember working much better.
And indeed, with version LG290P03AANR01A06S_PPP_TEMP1107.pkg I’m getting quite acceptable results, even with high TECU values.
So I dared to suggest to Quectel that they check what the difference is between the previous version and the current 2.01 version.
With this beta version, the corrections are received without significant interruptions, and the results during periods of high TECU values show quite acceptable distance differences to the fixed point, below 30 cm and most of the time below 20 cm.
It seems obvious that there are differences between firmware versions when the atmosphere presents high TECU values.
The previous version handles atmospheric conditions better.
Regards, Angel
PD: circle 0.20 m
It took me a little over 20 minutes to get down to 20 cm.
1 Like
For my understanding, did you get a newer version than what’s in the SparkFun Repo ?
I/we have been testing what was called “V2.01” LG290P03AANR02A01S.zip
Your comparison of results to the previous Beta is very interesting !
Sounds like we need to run both LG Firmware Versions side-by-side on 2 Postcards… ?