I have setup my Emlid Reach RS2 as Base station using the following RTCM messages: 1004, 1006, 1008, 1012, 1033 and fixed ARP coordinates and I am broadcasting this correction stream to my NTRIP caster, using ReachView. My Rover station is a Leica GS15 receiver. I can successfully connect to the mount point that Reach RS2 broadcasting the RTCM data and get data to feed it in the Leica’s RTK engine. Even in very close distances (bellow 2 meters between base and rover), I couldn’t get I fixed solution, but only DGPS one. Could you please give me further instructions on how to setup the Emlid receiver correctly as a Base station for my Leica GS15? Thanking you in advance!
I am broadcasting the default RTCM messages form ReachView Base menu: 1004, 1006, 1008, 1012, 1033
The broadcasting rate is 1 Hz for 1004, 1008, 1012, 1033 and 0.1 Hz for 1006 message. This messages with this kind of rates is also described in Leica’s manual.
Have you used another NTRIP service in the past? I do not know your experience level with GPS or NTRIP. If you have connected to another service in the past it should be the same with the Emlid products. If not, check and double check all settings.
I have used a lot of NTRIP services in the past. I have also double check many times the settings and the broadcasting RTCM messages. I am using the BKG NTRIP caster. Does anyone have similar experience with third party GNSS Rover receivers from other vendors?
The problem I think it has to do with RTKLIB software. Emlid ReachView is using the RTKLIB str2str software to transform the UBX messages from ZED-F9P GNSS module to RTCM legacy or msm messages. This transformation I think is problematic with some third party receivers. I am using now a M2 base setup with Reach RS2 rover with no issues (I get fix solution in seconds) with exact same setup (same internet connection, same NTRIP caster). I will try to get a fix also with a stand-alone ZED F9P receiver only though transferring the msm RTCM messages from u-center (dedicate software from
Ublox) with no RTKLIB str2str or str2svr (windows ui) software. Any updates from an Emlid representative about this issue? Does have a plan to fix this in a future software update?
Reach RS2 and Reach M2 don’t use RTKLib to calculate a solution. The difficulties you faced are most likely related to something else. Could you please share the Simple system report from your unit so that I could check the settings?
I will sent you the system report as soon as possible. I understand that Reach RS2 and M2 are not calculating the RTK solution based on the RTKLIB engine. My problem has to do with he fact that if i set up the Emlid Reach RS2 as a base station and a third party GNSS receiver like Leica, Trimble, etc as Rover, then the Rover station cannot get a fixed solution (not even float but only single). Emlid is using RTKLIB str2str software in order to transfer the RTCM data from the Reach RS2 to my NTRIP Caster, i definitely know that for the listeners source table (please take a look on my attached image on my previous post that saying RTKLIB 2.4.3 Emlid). Last week I search this issue a little bit more with different receivers and I find that the Reach RS2 is extracting into the RTCM messages only the L2C PRN code on GPS and Glonass constellations. Third party vendors like Leica are solving the ambiguities using the P (Y) code and not with C code, in their RTK engines. That’s why you can’t use an Emlid Reach RS2 or M2 as base with a few of third party vendors as Rover. So my next question is that if you have an option to enable the L2P tracking instead of L2C inside the GNSS chipset (u-blox) that Emlid is using on RS2/M2. And if not, do you have any idea if the firmware of the third party vendors have the option to use the L2C code for RTK solution? Thanking you very much and I believe that if we can solve this problem together then many users with Emlid Products can benefit from it.
That’s a good point! Both Reach RS2 and Reach M2 indeed don’t support P-codes. I understand that it would be a useful feature. Currently, we don’t have plans on expanding the list of supported codes. However, we’ll discuss with the team if there is something we can do in the future.
I’m not very experienced in 3rd-party devices, and your version sounds reasonable. However, just to confirm, do you work on the latest 26.1 firmware version?
I am using the 26.1 firmware version for our tests with the third party Rover GNSS receivers. @James, it is a hardware feature. Emlid Reach RS2 and M2, are using the u-blox ZED F9P GNSS module which is only L2C compatible and not supporting the P code on L2. That’s why you can’t use this receivers as base stations with third party GNSS receivers from Leica, Trimble, CHCNAV, etc. Some newer receivers from Topcon, have the option to extract the RTK solution using only L2C PRN code with the Magnet Field software. As far as Leica is concerned, I have already open a ticket about this issue (why Leica Viva and Captivate field software have not the option to enable L2C on RTK solution, only L2C satellites tracking supported here as an option but the satellites are excluded for RTK). According to Novatel’s OEM board manual (OEM board manufacturer for Leica Geosystems and many other hexagon’s GNSS products) , this feature is originally fully supported. I don’t understand why Leica as well as many other companies cannot enable it from their embedded firmware.
Then other manufacturers should get a head-start supporting L2C because, even though L2P is still broadcast, it is supposed to be deprecated somewhere in the future when most/all GPS satellites can broadcast L2C, from what I read. I’m not an expert on that subject and it probably doesn’t cost much to keep broadcasting the signal for backward compatibility but as time goes on, there will be more and more receivers who skip the L2P signal entirely because it is technically inferior to L2C.
My hemisphere P20-P40 based receiver works fine with L2c signal and fixes with emlid base but it works for some minutes and then some bug on the emlid base side makes rover not work with it and returns to single solution. I will make a video with the problem and the workaround i have found but it is not useful for me.
I have come to this conclusion because the rover never had problems with other bases. Also because I have found a workaround which involves enabling the ntrip corrections on the emlid base.
I usually connect the base to ntrip in order to collect average fixed solution for about 3 minutes.
Then I disconnect the emlid base from ntrip. When the rover stops receiving the corrections I go to the emlid base, reconnect to ntrip, regain fix and immediatelly the rover regains the corrections. I cannot explain why this happens.
P-codes should be supported by the hardware, indeed. However, as Gabriel said, L2P-signals have been heavily used in the past, but now most modern systems can track and transmit L2C signals. So, it’s enough to obtain a Fix solution fast. That’s why we don’t support L2P.
