HAS/E6 results on PostCard FW V3.1 with LG290P FW V2.01 [Feb 2026]

[amlago]

Hi @Rftop
I’ve been posting my problems on the Quectel forum.
This support guy, @yonghuang, took an interest in the issue. He asked me a few days ago for a log with the NMEA file showing the problematic times.
Today he emailed me version 2.01 with the debug add-on. It seems larger, and I thought about installing it for a while.
But before installing it, I decided to try the latest beta, which I thought would give me better results.

And it did.
I’ve been getting good results all day, even with high TECU values.
The solution converges in about 15 or 20 minutes and remains quite stable. And what worried me a lot, which was the loss of HAS corrections with version 2.01, hasn’t happened with the beta version.

PD:An hour later, it’s still working perfectly.

[rftop]

Thanks for the details and explanation

I watch the Quectel forum, but I don’t post. I’m not a fan of the “beg for FW to be emailed” procedure over there.

[sparky]

@amlago - Can you email me a copy of the beta firmware you received? I’ll get it posted and give it a try as well. I too am frustrated with the v2.1 (LG290P03AANR02A01S) performance today.

[amlago]

Hi @sparky
I’m not sure if that was clear. Remember my translator.
They sent me the same 2.01 with debug options, which I didn’t install.
The one working much better for me is the previous beta we already had: .LG290P03AANR01A06S_PPP_TEMP1107.pkg

It really works much better, giving me good results most of the day, and when the results are off, it’s only for a short time and no more than 50 or 60 cm.
With version 2.01, I was losing corrections and getting differences of several meters.

But I’m sending you the firmware they sent me, and you can try it.

Regards, Angel

[amlago]

@sparky
I emailed you the firmware and a screenshot of what he told me.

Regards

[sparky]

Ah! My mistake. I will run some additional tests with LG290P03AANR01A06S_PPP_TEMP1107.

[bamarcant]

From the experience I had and I talk since the version
06S_PPP_TEMP0829 , I remember the algorithm hold the position even suddenly switching from rtk to ppp and vice versa (in the presence of rtcm corrections), with the latest version (really since NR01A06S) this is no longer possible, in fact if convergence is lost even for a moment it requires another twenty minutes for the full re-acquisition.
Seem the _beta’s have a sort of ppp_hold algorithm that the final do not have.
Regards

[rftop]

I’m about to be travelling with no way to test, but can someone try :

$PQTMCFGPPP,W,1,1,120,1.0,1.0*5D

We were previously initializing the PPP engine with 120s holdover (which should have worked), but V2.01 drops the fix after missing 1-2 seconds of E6 data. The culprit might have been the previous 0.10m H & V thresholds we were using. It may be worth changing the thresholds to 1m and fine tune if that helps.

This is a long-shot, as the PPP engine shouldn’t drop the entire convergence when the uncertainty drifts above the threshold.

OR, the V2 FW doesn’t obey the Holdover parameter. Either would be an easy fix for Quectel.

$PQTMCFGPPP,W,<ServiceType>,<Enable>,<Holdover>,<H_Threshold>,<V_Threshold>*<Checksum>

Parameter Breakdown

Parameter	Type	Description
W	String	Operation mode: W for Write, R for Read.
<ServiceType>	Integer	01: Galileo HAS (High Accuracy Service); 02: BDS PPP-B2b.
<Enable>	Integer	0: Disable PPP engine; 1: Enable PPP engine.
<Holdover>	Integer	The Max Age of corrections in seconds (e.g., 120). If E6 is lost longer than this, it drops the fix.
<H_Threshold>	Float	Horizontal Accuracy Limit in meters (e.g., 0.10). If uncertainty exceeds this, it drops the fix.
<V_Threshold>	Float	Vertical Accuracy Limit in meters (e.g., 0.15). If uncertainty exceeds this, it drops the fix.

[bamarcant]

Yea tried
W , 2 for HAS ,2 for GTRF (hope)

$PQTMCFGPPP,W,2,2,180,1.00,1.00*64
$PQTMCFGPPP,OK*22
$PQTMCFGPPP,OK,02,2,180,1.00,1.00*07

• sbas disabled
• sat_elev & signal both to zero
• $PQTMCFGRTK,W,1,1,15*44 for send noise in rtcm to divert PPP convergence
  First I used an helical antenna like 6E
  result, the convergence occurred fast but differential age goes to 180 and loose ppp
  
  
  
  
  
  
  so changed with “default” helical antenna the one like Q50
  and voilà, the differential age goes lower
  
  then reverted to my defaults $PQTMCFGPPP,W,2,2,90,0.01,0.01*54
  and now, not quickly, but after 15min ppp converged in a stable situation and the differential age is 2.1 to 12
  
  
  
  then noised with rtcm injection for few seconds since E4 occurs and
  
  
  
  
  
  
  so leaved rtcm inj. and
  
  rtk hold respect the 15 age imposed
  re-converge after 15 min
  
  now the matter is when I change to $PQTMCFGRTK,W,1,1,1*71 the module do not hold
  ppp neither rtk and seat in a unstable situation
  
  
  
  not an issue, but the older firmware revert istantanely to a ppp or rtk solution.
  so after leave noise (i.e. close rtcm inj.), the module takes other 15min to ppp.
  P.s I’m trying out some radios Cdebyte sent me “E62-433T30D” …

[amlago]

Hi everyone. The LG290P03AANR01A06S_PPP_TEMP1107 firmware definitely works much better in my area (Uruguay) than the latest v2.01.

This afternoon, with a heavy drizzle, convergence occurred between 15 and 20 minutes, and I obtained many values ​​below 20 cm and several between 20 and 30 cm, which at this stage of the investigation seem quite acceptable to me.
Something was different in v2.01.
Regards

PD: circle 0.20 m

[amlago]

Hi everyone.

Has anyone been able to verify that the beta version LG290P03AANR01A06S_PPP_TEMP1107 works better than the latest version 2.01?
I’m very interested in your conclusions.
Regards, Angel

[rftop]

@2M2C , once HAS has converged, disconnect then reconnect to the comm port. That way you can start a new Map/Window with only the converged solutions.