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

[rftop]

Some quick testing of HAS/E6 with RTK Everywhere V3.1 on the PostCard :

Initial PPP convergence took about 15 minutes in open sky.
SW Maps reports RTK Float, which is expected since the GGA sentence reports Fix Mode 5 (RTK Float / PPP) when only using HAS PPP corrections. The same for the PVT message, it correctly reports Fix Mode 5 (PPP/HAS).

Using 15-second Averaged positions in SW Maps makes fairly repeatable points, usually less than 1’ horizontal, for today at my particular location.

Performance under light tree canopy was questionable. Repeating Averaged Positions on the same mark could result in 10+ feet of discrepancy, as multipath takes over. This isn’t the fault of the hardware, it’s the nature of HAS/E6 in the US.

At this point, I was still happy with the HAS/E6 performance, as this is something that could be useful in some GIS applications, with a dedicated HAS/E6 workflow.

Then I attempted some real-world testing. Losing satellite signal for a few seconds causes the dreaded cycle-slip. This means another 10-15 minutes for PPP convergence before Fix Mode 5. It doesn’t appear the Quectel V2.01 firmware has “re-acquisition” logic that would shorten re-convergence if the outage is very brief.

“Dumping” the antenna (force the solution to re-converge) simulates coming back to the same place at a different time, and is a standard practice in the Industry. The precision/repeatability of Solutions on previous marks widens when a new PPP convergence is obtained after 10-15 minutes.

My overall thoughts:

• In Open Sky, HAS/E6 can be beneficial if no other correction source is available. The user must ensure continuous satellite “lock” while moving between locations
• Users must be extremely mindful of multi-path conditions, as the Receiver doesn’t know it’s made a bad assumption in the Carrier Phase Integer guess. I think the bogus points I had under the light tree canopy were actually Corrected Code Measurements but the LG290P hadn’t updated it’s Fix Mode yet. That needs more testing to confirm.

I look forward to hearing from others on their recent experiences

---

Setup Used:

• PostCard with external battery, no shield, a proven Quad-Band helical antenna
• RTK_Everywhere_Firmware_ V3.1 on the PostCard
• LG290P03AANR02A01S (V2.01) FW on LG290P
• SW Maps used and a Bluetooth Serial Terminal to make changes to FW

Configure LG290P GNSS Receiver to :
1 Hz, Disable QZSS & NavIC, 15° Elevation Mask, 30 dBHz min signal,
Turn OFF all NMEA except : GGA (makes it easier to look at the serial stream while testing)
Turn ON PQTM PVT message.

[sparky]

Amazing! Thanks @rftop. Funny, I was doing the same thing this morning!

My Setup:

• Postcard with USB power and the standard display shield

• A roof mounted SPK6618H, with 24 hour data collection from 2 days ago. CSRS reported +/-7mm on lat/lon location of the antenna.

• RTK_Everywhere_Firmware_ V3.1 on the PostCard

• LG290P03AANR02A01S (V2.01) FW on LG290P

• pygpsclient for scatterplot with known location

Above, the green dot is known location of the roof antenna. What you don’t see is 15 minutes of bad locations (waiting for PPP convergence). After convergence, we see the LG290P’s reported location meander across 20cm or more. Don’t let the image fool you (the reader); we can slice and dice these images to look really good, or really bad.

To put HAS into perspective, above is the same setup with PointPerfect corrections (~$15/month). The scale has changed by an order of magnitude. The RTK Fix took less than 5 seconds. The 80 readings are in a coupling of 2mm. And they are 4mm away from the ‘known good’. Insanely good.

Overall, I agree with you @rftop - HAS E6 is not pretty, it’s not fast, but it’s free, and it’s global. If you can live with 20cm accuracy (what Galileo claims as its accuracy), you’ve got a clear view of the sky, and you’re not in a rush, it’s a fine backup.

[rftop]

@sparky

After convergence, we see the LG290P’s reported location meander across 20cm or more.

That’s Great results for a static test ! Thanks for sharing @sparky.

Could I beg you into disconnecting the antenna for a few seconds to force a new PPP Convergence, with several sets overlaid ? Naturally, we aren’t interested in the positions during convergence, only Fixed Mode 5.

In the useful context of HAS/E6, the repeatability across convergence means more than long static plots. To use HAS/E6 as a correction source in the field, we need to mimic field behavior and workflow. But your 20cm plot is impressive and promising !

[rftop]

@sparky

with PointPerfect corrections… RTK Fix took less than 5 seconds. The 80 readings are in a coupling of 2mm.

Yeah…we are ridiculously spoiled with PointPerfect RTCM
To me, it’s worth any amount of trouble to establish an internet link to be able to use PP, in real life

But I’m still hopeful for HAS/E6, even though we know the technology comes with limitations, in the US anyway.

[amlago]

Hi everyone.
We’re all in the same boat.

I have a Postcard RTK antenna with a portability shield.

Here are some images from the Landstar 8 where the Postcard performed quite well in static mode.

These are two measurements taken at different times, around an hour and a half apart.
Convergence in Uruguay took me about 15 minutes, just like it did for you.
Most of the measurements are below 20 cm, and the reported accuracy is absurdly good, around 4 cm or less.
This accuracy isn’t believable, but I obtained a lot of data with accuracy below 10 cm.

I tried moving the antenna a couple of times without losing convergence and was able to re-establish the point with an accuracy of 10 cm or slightly less.

The loss of convergence is the bottleneck, as it takes the infamous 15 minutes to return. I’d like to try surveying a plot in an open field using another GNSS RTK system and the Postcard radar with Galileo HA.
My intention is to use the Postcard radar in rural work where a depth of less than 20 cm is acceptable.

Regards, Angel

Pd:The large circle is 20 cm and the small circle is 10 cm

The Landstar 8 in the image reports zero precision because the captures were made without a connection to the equipment.

[amlago]

[amlago]

My question is about the epoch for which the coordinates are obtained using Galileo HAS.
We already know they are in ITRF20, which at the centimeter level is practically WGS84, but it’s not clear to me whether it’s the current epoch or 2020.0.

[rftop]

Galileo HAS is current epoch since it provides coordinates in the same frame as the satellite orbits. Because the satellite orbits are calculated based on their positions today , the resulting user position is in the Current Epoch.

“GTRF is the independent realization of the International Terrestrial Reference System (ITRS) for the Galileo system… The alignment between GTRF and the latest ITRF is maintained to be better than 3 cm (2-sigma).”

So take @sparky’s HAS/E6 static plot for example. He compared HAS/E6 against a known PPP position provided by CSRS-PPP from only 2 days ago (the correct procedure). Realistically we all realize the possible ~3cm misalignment between GTRF and ITRF isn’t huge when looking at a 20cm System.

But the Frame and Epoch REALLY matters in his PointPerfect Plot, as we are now looking at accuracy in the mm range, and not just precisions across the measurements. His PointPerfect RTK grouping is 4mm away from the CSRS-PPP solution. There is actually a conflict with the Epoch in this particular scenario, but that’s still pretty dang slick for $400 in equipment (Postcard & Antenna) !
I apologize for getting off topic

[bamarcant]

Howdy

@rftop

Galileo HAS is current epoch…

It must be this way by force of circumstances; I had asked GSC for clarification but I realize that if the system is based on ground references, the latter are updated in real time really with ITRF2020-u2024.
e.g.

From the tests I have done, I can tell that even with the previous firmware the values ​​were stable even over a long period; as for the difference, obviously one must compare it to a reference system and apply the necessary conversions (from ITRF current epoch) to.The only practical advantage is when you are in a place without a network,( with a base and rover), instead of waiting for a PPP from a third party you can do it in 20 minutes and place the base with the coordinates transformed into the reference system U use.
I note that the new PQTMPPPNAV spits out the coordinates and standard deviation values…it only takes a few minutes…to converge.

Quectel_LG290P(03)&LGx80P(03)_PPP_Application_Note_V1.0.0_Draft_20251212.pdf (452.3 KB)

Regards

[rftop]

It would be nice to see the NAV or EPE message in the RTK Everywhere firmware. I turned EPE on, but never saw EPE in the NMEA stream

Does anyone have any hints on how to get NAV or EPE working on the PostCard V3.1 ?

[bamarcant]

$PQTMCFGMSGRATE,W,PQTMPPPNAV,1,1*47 enable on current port
$PQTMCFGMSGRATE,W,PQTMPPPNAV,0,1*46 disable
PQTMPPPNAV differ by PQTMNAV
pardon, errata corrige!
$PQTMCFGMSGRATE,W,1,3,PQTMEPE,1,2*1F enable on uart3
$PQTMCFGMSGRATE,W,PQTMEPE,1,2*1D on current port
ask if done $PQTMCFGMSGRATE,R,PQTMEPE,2*05
reply $PQTMCFGMSGRATE,OK,PQTMEPE,1,2*4E

[rftop]

Today, I’m seeing up to 1.5 meter deltas between HAS/E6 converged solutions (while reporting 3cm residuals).

My guess is the PPP engine can’t identify and properly handle any sort of multipath.
I might try testing some external ground planes to confirm that theory one day. But HAS/E6 appears to be much more susceptible to multipath than what I experience with RTK.

[rftop]

@bamarcant

The only practical advantage is when you are in a place without a network,( with a base and rover), instead of waiting for a PPP from a third party you can do it in 20 minutes and place the base with the coordinates transformed into the reference system U use.

Marco, that is a great point…and something I haven’t considered until you said it. That’s quicker than PPP and easier than a (freeware) PPK workflow.
Thanks !

[bamarcant]

I tried with breakout…
-reset system $PQTMRESTOREPAR*13
-set base mode $PQTMCFGRCVRMODE,W,2*29

$PQTMSAVEPAR*5A
$PQTMSRR*4B

-I disabled sbas and set to zero elev & signal

$PQTMCFGSBAS,W,0000*0E
$PQTMCFGELETHD,W,0*29
$PQTMCFGCNRTHD,W,0.0*24

-left all the sat but must enable PPP
$PQTMCFGPPP,W,2,2,90,0.01,0.01*54
-enabled GGA and PQTM messages

$PQTMCFGMSGRATE,W,GGA,1*0A
$PQTMCFGMSGRATE,W,PQTMEPE,1,2*1D
$PQTMCFGMSGRATE,W,PQTMNAV,1,1*17
$PQTMCFGMSGRATE,W,PQTMPVT,1,1*1C
$PQTMCFGMSGRATE,W,PQTMDOP,1,1*15
$PQTMCFGMSGRATE,W,PQTMPPPNAV,1,1*47

-launched PQTMSVINSTATUS without setting PQTMCFGSVIN
$PQTMCFGMSGRATE,W,PQTMSVINSTATUS,1,1*58

when LG290P(03) get convergence with acceptable mean acc values, just copy the ecef value in the sentence:
$PQTMSVINSTATUS,1,556640000,0,05,1,0,Xx04515.3349,Yy98179.6729,Zz93146.8771,0.0347*1B
and set the base in fix mode in ecef:
$PQTMCFGSVIN,W,2,0,0,Xx04515.3349,Yy98179.6729,Zz93146.8771*checksum
of course it can be shortened,after setting the base_mode
just enable PPP
and launch the PQTMSVINSTATUS
once get a good PQTMSVINSTATUS sentence, set manually the base in fix mode with
$PQTMCFGSVIN,W,2,0,0,X,Y,Z*checksum
P.s. forgot to tell, now it spits also RTCM1230
$PQTMCFGMSGRATE,W,RTCM3-1230,1*5D

Regards

[amlago]

Hi everyone.
Today, February 7th, I have bad news regarding this issue.
Postcard with portability shield.
Elevation mask 10 degrees.
All 4 constellations enabled.
Since last night, I haven’t been able to get good results.
Most of the time, it’s between 35 cm and 60 cm, and sometimes more.
The differential age was sometimes over 15 seconds, and sometimes I ran out of corrections and started again with the infamous 15 minutes or more.
Now I’ve been taking data for 2 hours, and it never even got close to 20 cm. It’s been 35 cm above and sometimes close to 1 meter.

What happened?
What changed between 2 days ago and today?
Is something wrong with Galileo?

Regards, Angel

PD What’s confusing is that the reported accuracy is less than 10 cm, sometimes only 2 or 3 cm.

Hmmmmmmmmmm. ?

[rftop]

@amlago

What happened?
What changed between 2 days ago and today?
Is something wrong with Galileo?

The Global Ionospheric Map history looks good over the past day, for the US and Uruguay.
My guess is the SSR model made some bad predictions/estimates for Uruguay, because I’m assuming your test location is constant ?

[bamarcant]

Sí, a veces hay días malos…
Pero recuerda todas las buenas prácticas del posicionamiento.
Por ejemplo, un

con orificio perforado entre el conector SMA y la antena es suficiente para eliminar la mayoría de los multipath.

[amlago]

I honestly don’t know what’s going on today.
There are random disconnections, meaning the Galileo Hass corrections are being lost.
The point is on the roof of my house, where the visibility is excellent.

In other words, the view of the sky is very good.

Today there have already been four loss of corrections. Two days ago, the differential age didn’t exceed 12 seconds and everything was working fine. Today, as I mentioned, it’s around 15 seconds, and suddenly the corrections stop being received, and we have to start all over again.
Of course, the point is an iron mount screwed to the wall, as you can see in a previous photo; it’s very secure.
I use it as a base when I go out to work.

[bamarcant]

…sí pero no te cuesta nada poner un refractor agujereado, en cuanto a la línea de alta tensión,podría afectar no poco, pero repito hay días no aunque el cielo esté despejado…
Por qué (ya que la posición es fija), no usar el módulo como base para un lanzador ntrip?

[amlago]

Hi Marcos.
Everything you’re saying is helpful.

But today the results are very bad.

Even with the high-voltage line, I was getting acceptable results with HAS every day. The data I’ve mentioned and shown in this post and others…
That point is my base point, and that’s where I place my equipment to send corrections via ntrip. It’s correct. The location works very well for me.
Regarding the disk, I didn’t think I’d need it, and I’m going to try to get one for testing.
We’ll see what happens throughout the day.
I’ll keep you posted.