What caster are you using and have you made sure that all of your other devices are logged out?
Yes I’ve used it with Trimble both via a radio and NTRIP
The NTRIP caster was Emlid’s caster
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?
Wonder if this new update fixed it?
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?
Hi @svetlana.nikolenko, is the ability to support P-codes a hardware or software issue?
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.
Just out of curiosity, how do you know it is a problem of the email base and not the rover being a diva when it comes to input?
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.
Maybe EMLID can? ; )
I have an ongoing discussion with the Emlid team but no fix so far.
I understand that if they don’t have the exact same 3rd party rover it is difficult to troubleshoot.
Yes, I just want to confirm that we’re investigating the issue with @vgo195. It takes us a while since we don’t have much experience working with 3rd-party devices. However, I can say that issue isn’t related to P-codes.
Hmmmm… might be a good idea to invest in a few of these pricey 3rd party devices to know their inner workings… (even if older cheaper used items) especially since EMLID is and has been biting at the heals of these over-priced $$$$$ competitors. Their days are numbered and they know it as technology maxes out. But hey, thanks to high priced construction and government projects, it will be a good while. Most surveyors, engineers, construction companies will NOT use anything but $$$$$$$ Trimble, Leica, Topcon etc.
You could even rent some of these $$$$$ devices if need be.
Same for software, really. I often find myself talking to a wall when it comes to promoting QGIS over ESRI’s offer because being “free”. The former is still mostly as powerful, more flexible, and yes, mostly free (but you can directly fund certain features if you want to contribute, like NRCAN actually did one of two years ago). Inertia is hard to beat.