till today I think that the reach module is good but now I think I will give up.
I now use the new SW 0.4.7.
I realize that fix is something i do not get in reality so I tougth that float is good enough for ±1m accuracy.
I have done the following:
get base coords with a NTRIP server, get fix in less than a minute. accuracy looks like 10mmlevel
setup base with 3dr v2 radio with good sat view
setup rover with 3dr v2 radio, get float in seconds. but I never get fix. I put the rover next to the base and get 1m difference. maybe ok…
I now spend 2 hours in getting coordinate of 50 points. then I get back to the first point and get a difference of around 10m!!!
I observed the drift also a few days ago: measure points over 1h,go back to the first point and have 15m drift.
Conclusion:
I do not get fix only float
float is not good enough because there is a drift of around 15m per hour!
I do not say that fault of Emlid that rtk is not getting fix but i think it is not fear of Emlid in suggesting that the setup works.
–> the actual Emlid reach is clearly not working as it should.
I spend 570$ in the kit, another 150€ in customs for importing reach, 100€ for the batters. 30€ for cheap 3dr radios and another 50€ for the 3dr v2s with 500mW and many many hours to get to this point…
My questions are:
is it there a change that is works in near future with sub meter accuracy?
is the problem RTK lib?
is the use of the M8t instead of the m8n the problem?
Someone correct me if I’m wrong but I think part of the issues is only being L1 (clouds etc vs L2). Another, more important, is I can only get GPS constellation, not having GLONASS means I’m at the mercy of the distribution of satellites in the sky. Few have reported getting GPS+GLONASS working, but for the life of me, could not get it to work.
I’m anxiously awaiting the GLONASS update as it will def help the satellite coverage between both constellations. I would like to hear more librtk and GNSS experts chime in and share their knowledge!
I’m not a GNSS or RTKLIB expert, but I’ve been going through quite a learning process with ReachView and RTKLIB, also.
There are a lot of little traps and/or bugs with RTKLIB that can give crazy results. Many are not listed anywhere.
For example, if your base coordinates cause your first base reading to be outside of the base stat limit, you will not get any base corrections and all readings will be singles if I recall correctly.
Another bug is that if the correction time is set too short to determine fix, garbage results in getting good fixes and coordinates.
An example is setting time waiting for fix to be less than base intervals of 15 , 30, or 60 seconds.
I understand your frustration, but appreciate your contributions to this forum and hope you stay with us.
You are maybe correct! It underlines my conclusion that the reach product is not working. The cause is that it uses a technology that is not working (it uses rtklib that is the problem). the module itself is fine (WLAN, Bluetooth, small,…)
But it does not help, the overall product is not working…
I also use other products that are not polished or that are not finished. But with playing around for some time i get it working. This is not the case with reach.
the end product uses a tech that is not working and it is too compley to bring it to a level where fix is established in 80% of the use.
I see the following options:
Option 1:
Emlid is concentrating on this issue with rtklib till the main uses can work with it. This needs experiments and in depth know how of rtklib.
option 2 is: this product will be out of the market in some months.
I have to say that the Emlid team is helpful and clever and good. It is nice to communicate with them but I need something that is roughly working because i paid around 1000€ for the setup. It is not that I paid 100€ and now it is not working. it is 1000€! I would have paid 1500€ if it is working but I will not pay 200€ if it is not working!
Dear @Franz_Helmli, I understand that learning curve with the system is not optimal and we are releasing completely reworked ReachView that will address this (We listen to the community and learn our lessons) soon.
The initial plan to use RTK system in the forest was ambitious, we never advertised this scenario and are telling to all our users that good sky view and signal is required to work on cm level. At the same time you are telling that:
So you are actually getting a fixed solution quickly, but not over radios? Maybe corrections are being corrupted along the way?
You have collected points in float, which means that ambiguities were not resolved. Large difference also suggests that something was wrong with observations quality.
It does work with cm accuracy and M8T is the proper option with officially supported raw data. I understand that telling you that it works does not really help, but we are always here to help you look for the cause of the issues.
GPS+Glonass works, but the ambiguities could not be resolved when using different receiver types e.g. with NTRIP. When working with a different receiver Glonass AR should be set to off.
@RickJ We are fixing things in RTKLIB and ReachView, so if you report issues that is always appreciated!
Could you please elaborate on this? If base position is set incorrectly, there will be no RTK solution. New ReachView is going to have survey-in of the base position in order to help avoid mistakes here.
What do you mean by correction time? There is no such setting in ReachView.
Gah, then it must be something I have setup in the config. Before I attempt again with GPS+GLONASS going to wait for the new ReachView. Thanks again for being so responsive and open to feedback!!!
I have heard from 2 other reach users that fix with gps and glonas will not work in practice: each sat system must have at lest 4 green sats to get fix! If I use gps only i have 3 to 4 green sats (sometimes 5)
I have written that I got fix with NTRIP but this was 10seconds from 10minutes. I tried again today and did not get fix again.
So this is not repeatable enough.
When is the new reachview available?
When are the other important bug solved? averaging of base coordinates? rover does not boot if base is active?
I’m in the same problem @Franz_Helmli , i’m work with this about 3 week so my learning curve with this system is coming to the limit. Because i have many hours of testing in the field and office learning about the system. I can be fixed only after the last update of reachview 0.4.7. Just get fix about 5 seconds than 15minutes. I don know. I don’t know what to do more.I 'm thinking of storing the equipment and hope that a new version of reachview!
Reach is an excellent product considering what it can do for the price. Other systems could be $2000 or more just for one unit. I think Emlid are doing a fantastic job. I have a lot of faith in this little gem and although I know nothing about coding, but cosidering what they are managing todo with just a little Edison I think is remarkable. Documentation could be better but all in all @emlid are doing a great job.
Fix with GPS and Glonass does work and in our testing it is more robust than with GPS only, just don’t forget to disable Glonass AR when working with a different type receiver, Glonass still can be enabled.
Should be a few weeks. We are pushing it really hard, but there are lot’s of things requiring a rework. New wi-fi settings, new logging and new image are yet to be finished.
Completely rewritten backend and frontend, new looks, removed most advanced settings by setting them to an optimal value, only needed settings left and made user-proof. Several layers of protection to make it impossible to kill the ap with wrong settings. New update and packaging mechanism to ensure safe and consistent delivery of updates. Built-in maps and dashboard with detailed status of RTK. Dropped the buggy Intel wi-fi setup script and integrated network settings in the app. Stream statuses (very important for NTRIP to see if connection succeeded). Merged rover and base modes, now possible simultaneous operation in rover and base modes on one device. Different options for base coordinates: average single on boot for t minutes or average fixed position from NTRIP for t minutes and start corrections after that or manual value. This is not a full list of changes, there are many more.
Regarding the rover not booting with active base we were not able to reproduce the issue on the image v1.2. If you know how, please let us know.
@antonio.arns1 Antonio, overall fix time will depend on the surroundings and satellite geometry. Average time in our testing is at 3-5 minutes in GPS+GLO, but it can be longer in less favourable conditions. If you are still seeing problems, please reply to my message in your topic: https://community.emlid.com/t/no-fix-no-float-using-3dr/3579/7?u=ivereninov
@Andreas_Ortner I have answered to you in your thread. @Multirotorcraft Let’s get to the bottom of the issues in a separate thread.
@igor.vereninov:
I don’t have problems getting a fix, but i’m interested in the Glonass-Setting with two different receivers you mentioned. What does “more robust” mean? Does it really make sense to enable Glonass (with 5Hz only) if it couldn’t be used for AR?
thank you for the update. It sound promising!
It sounds that this will improve the use of the system. We will all see if it also improves the fix mode…
Just a note about using NTRIP corrections, baseline lengths are usually longer than they should be so your corrections are no longer as accurate. We use NTRIP, VRS and local base stations and by far the best setup is one of our own base stations always within a mile. Anything longer than 5 miles and its time for static GNSS sessions.
The introduction of an RTK product to a consumer market was always going to be interesting …
Most of the users are expecting a black box solution when in practice achieving RTK results requires a good understanding of the gps and differential gps principles.
I hope that the support load I’d not going to overwhelm EMLID …
Your spot on. When I first got my Reach I knew very little about GNSS aside that RTK used local corrections from a base. I was indeed hoping for a black box solutions, but quickly learned a whole bunch of things about GNSS, who knew they could be so complicated
On the flip side every time I mention high precision GNSS I am given a lecture on how GPS (not GNSS) works.
when I tell people that A-GPS is faster because we can download the almanac from the internet instead of waiting for the 12.5 minutes for the whole NAV message to be received, they say A-GPS is actually based on cell towers that can triangulate your position better than GPS. Don’t even get me started on GNSS. facepalm
