LC29HEA Moving Base: Never reaches RTK Fixed — incorrect baseline and heading with 27cm antenna separation

Hello,

Setup

  • 2× LC29HEA, firmware LC29HEANA11A04S_RSA
  • 2× YFGA225E3AM active patch antennas (L1+L5), identical orientation
  • Baseline: 27.4 cm center-to-center (within documented 0.2–5 m range)
  • Wiring: Per Application Note — Base UART2 ↔ Rover UART1
  • Output rate: 10 Hz, PQTMTAR enabled
  • Application: Compact marine GNSS satellite compass

Problem

After a 9+ minute cold-start log (5420 PQTMTAR messages, open sky, excellent signals):

1) Never reaches RTK Fixed:

  • Quality 4 (RTK Fixed): 0 messages (0%)
  • Quality 5 (RTK Float): 4945 messages (91%)

2) Reported baseline is completely wrong:

  • Physical baseline: 0.274 m
  • Reported baseline: 0.94–8.84 m (average 2.47 m)
  • Even best-accuracy readings report ~1.1 m — never close to 0.274 m
  • This indicates the ambiguity resolution is converging on incorrect integer solutions

3) Heading is wrong:

  • Expected: ~320°
  • Reported: 74°–149° (average ~93°) — ~135° error, not a simple 180° swap

4) Signal quality is NOT the issue:

  • 21–23 satellites, SNR 30–47 dB-Hz, HDOP ~1.05, DGPS fix on GGA
  • 85% of float solutions have heading accuracy < 10°

Sample PQTMTAR (best accuracy period)

$PQTMTAR,1,191524.300,5,,1.187,-6.264394,,95.868037,4.529717,,4.529717,23*7E

Quality=5 (float), baseline=1.187m (should be 0.274m), heading=95.8° (should be ~320°)

Questions

  1. Can the LC29HEA moving base engine reliably resolve ambiguities at baselines ≤ 30 cm? The App Note states 0.2 m minimum and shows drones/robots with short baselines. Commercial marine GNSS compasses (u-blox F9P/F9H based) work at these distances routinely.
  2. Is there a baseline length constraint parameter to help the solver? (Similar to u-blox pos2-baselen)
  3. Would reducing output rate to 1–5 Hz help? Other users report better RTK Fix at 5 Hz.
  4. Is there a newer firmware that improves short-baseline moving base performance?
  5. The baseline is reported 4–30× too large — this is a clear sign the float solver is locking onto wrong ambiguities. Is this a known limitation?

Everything has been verified: wiring per App Note, identical antennas/ground planes, UART2↔UART1 communication working (Float is achieved), excellent signal environment.

Thank you for any guidance.

Congratulations on being able to read pqtmtar…
Only LG580P have
immagine
but in the manual of LG69 say ant dist. >30cm…immagine

of course U are the first to publish successfully a moving base setup for the lc29hea.
Try injecting rtcm corrections onto the base uart 1 while (moving) is in rtk float.
Regards

1 Like

immagine
Although GGA 2 (in dgps)
Values are too variable if they indicate a fixed position…
ps anyway try with >30 cm, in the open sky (and not under the trees).

Finally after some tuning I get the the heading ( green line) with precision about 4°