QGNSS V1.10 does not seem to apply RTK data to LC29HEA fixes

Wait for a re-flash but also consider that the ntrips in US (but also in EU) broadcast rtcm in L1 and L2 that could distract the Kalman filter on the internal algorithm to calculate fixing of phase & ambiguities on a chip with L1 & L5 receiver.

OK, I am getting my free ntrip from Florida Department of Transport. I will investigate

@Oli has the full board for this purpose; hope that for Oli “che gli fischiano le orecchie” for the mentions…so we are not alone in this adventure.

I am still wading thru the threads you sent, thanks for pointing directly to relevant posts…

This may sound bad, but I guess I have to hope his ears are ringing with the same issue I have here (where I am not getting RTK fixes) :wink:

1 Like

Hi Marco,

Re: US ntrips:

I am an ntrip newbie and I do not know if I am even selecting the best ntrip port form the Florida Department of Transport listing. Here is their list and what I chose for my use:

Also, here is the basic data that is being received from the FLWD mount point:

Do you think I am using the correct Port that would talk to the LC29HEA?

You can see that basic data seems to mention L5Q signals…

Thanks,
Dale

Yes, inputs are correct, module accepts RTCM3.x and MSM4 & MSM7 in list: :arrow_down::arrow_down::arrow_down:

1 Like

Hello. I also can’t get the RTK FIX on the module.

1 Like

Hello Anatolii, I see that many have problems (99.99%) using a public RTK base station (ntrip) also if in table of mount points are compatible msm messages…
Marco

Hi bamarcant. I tried different mount points. Only manage to get float rtk. Now I want to update the firmware, maybe this will solve the problem somehow, but I get an error when updating.I posted the screenshot with the problem in a new topic.

Hi Anatolii, U posted this LC29HBANR11A01S_CSA4,2023/01/16,18:20:07*07
it is for a LC29H-BA model; now what is your $PQTMVERNO*58 output on the model u try to update…
Я ничего не понимаю
however if you have a mozihao evb, you have to put the boot in download mode with a reset to the request of the message: Handshake (Press The Module Reset Button!) in this way described here :slight_smile:

Unfortunately, after grounding pin 8, the program does not respond and the flashing process does not occur.
The module now has a firmware
Без імені1

Now I don’t seem to be able to get a response to ANY query I make to my EVB inside QGNSS V1.10:

Finally, taking heed of some remarks that QGNSS V1.10 has a very touchy (to say the least) Command Console, which sends and receives data to/from my LC29HEA, I tried a few of my old favorite serial port terminal programs. My version of Putty does not have the ability to send pre-defined strings of characters out.

BUT, YAT seems to handle even an unlimited number of predefined commands and it is able to reorder, cut/copy/paste, export/import and even link predefined commands and pages. All of these are available from a scrollable view of command buttons.

Here is a view of my current YAT terminal connection to my LC29HEA:

BE CAREFULL THOUGH - With ANY terminal program I have tested, it seems that if there are any spaces after the checksum of your command, the LC29H’s do not recognize the command and you will NOT get an OK response for it.

In the meantime, even though I am now able to communicate commands to my LC29HEA reliably, I am still unable to obtain any RTK fixes :frowning:

One step closer though :wink:

EDIT - I also tried all the steps to achieve my RTK fixes here… Configuring the Quectel LC29HEA receiver for real-time RTK solutions – rtklibexplorer

Dale

Well I was answering you…(in_box)
yes I also noticed the spaces after checksum…
I will use the Yat program instead of those 中 文, thanks.

1 Like

Marco,

Here is that YAT file you can open to use as a start for you command buttons…

LC29HEA_YAT_config.zip (4.8 KB)

Dale

1 Like

Hello Dale, problem is here:


caster use NAD83 instead of WGS84…
if I found the string to convert into chip will send, otherwise U must set your own Base.
immagine

$PAIR076,<Datum>*CS<CR><LF>
$PAIR077*CS<CR><LF>
$PAIR076,144*26
$PAIR077*3A

Datum

Marco

1 Like

Marco,

I can’t find the the QUECTEL protocol description for $PAIR076 and $PAIR077 but I think I am using them correctly here:

But still no RTK fixes in QGNSS V1.10 (I still need to try out in a clearer sky area yet but I have little hope that will help):

Let me know if I tested this concept correctly.

Thanks,
Dale

Hello. need to put the proprer datum, also see what gives rtcm1005 for base data , if not exposed must set manually ntrip base coordinate in given datum NAD83 into qgnss.
Manual for AIROHA here.

I am starting to question the need to put in my datum manually as WGS84 coordinates versus NAD83 coordinates.

The error between the two coordinate systems, even if you use the wrong system, seems to be only about 0.1 mm :

Here is the conversion calculator I used (NAD83 to WGS84 - online and free):

There are no big differences but You have to find the string 1005 of the position of the station that transmits the corrections…if you do not find it you have to get its position and enter it manually in the program.
The strsvr window is just the one with serial since your LC29H module is connected in serial to the com port of the pc…
While in satrack you have to choose a com_port connection to monitor the LC29H module ; but being connected to com_port you can also use qgnns. Note that the input of rtcm data is transmitted via the rtklib service with the strsvr app which is set to receive from the ntrip caster and transmit to the chosen serial port (com8), then the module receives “directly” the correction and processes it with an internal algorithm , then fixes the points and spits them according to the GGA & RMC date at the chosen fix_rate.To read the results you have to use a program that can be QGNNS, Mission Planner , Satrack etc , as the protocols used are universal ( hopefully ).

I have not been able to see what the actual ntrip data being received from FLWD, so how can I find string 1005?