Why do I get the feeling that us end users are being used as Emlid’s testing group? I mean these types of issues should have been resolved before the release of any unit for sale. I mean GPS rely on satellite signals. RTK relies on the units talking to each other. Even if base & rover will not be using the same number of satellites to get a fix, the fact is they should report what is the other seeing in the sky. This information helps the user in determining if he should move the base or rover to a better environment because the accuracy of his results depends on how many satellites are being seen by the base/rover.
I mean we can’t have our survey crews update to the next stable firmware every day an issue crops up. Like I mentioned in other posts, our survey crews are not tech savvy to update firmware while in the field. What will happen to our work if a major firmware upgrade is needed and all units are out of the office?
Hope Emlid understands this common survey office scenario.
I think Emlid is doing a great job for the value. Overall its pretty polished.
Usually all other RTK equipment has $10k to $30k more price tag. I am fully willing to Beta anything at that price differential.
There is a thread on here where they put the RS2 up against a total station, RS2 performed extremely well.
Considering the only other low cost option really is F9P, Emlid is in a league of their own at the moment.
I could not agree more!
And to boot, even at the Higher $$$$ big manufacturers do the same thing. I have worked around Trimble Ag products since 2009. They have had software updates that were total crap, didn’t even last a month. Sure more were stable but just the same, the end user was the beta group.
As Potato and most other members would say, at the price difference, I could care less and would volunteer to Beta anything Emlid has to offer.
Hi Juan,
Our team conducts the test for all Reach receivers before any new release. It’s important for us to provide you with the products that will enhance your experience in the field. As I’ve mentioned, the case in this thread is not a software or hardware related issue. It’s just how the algorithms on the receiver work for calculating the RTK solution. You don’t need the exact number of satellites to match between the units in order to obtain Fix as long as the base and rover have at least 4 satellites in common. Of course, the more matching satellites, the more data there is for the rover to calculate the solution.
The app doesn’t specifically show which satellites are not common between the base and rover as this information could be excessive. Reach RS2 provides you with the automatic tool for the solution calculation. The information in the Status Tab is enough to check whether there are at least 4 matching satellite signals on the base and rover. However, we’re always open to the reports and willing to improve. We’ll rethink how this information can be displayed in some other way.
For now, I suggest always make sure the placement requirements for RS2 are met and the receivers are configured as described in our Base and Rover setup guide. This will help you to obtain a Fix solution without the need of checking each of the satellite signals on the units.
Also, I’d like to note that the Status tab on the rover’s ReachView shows the number of satellite signals that are being transmitted from the base to the rover. Not how many satellites the base obtained.
Sorry if I sounded a bit off on my comments. You see I have been reading a lot lately about firmware update issues and common problems when using dev firmware - i.e. problems with HI/RR not properly reducing rover elevations, etc. I was curious to know why release the dev firmware if these issues are not yet resolved? Granted that users should not be using dev firmware for actual work scenarios but some issues appearing in stable releases are said to be resolved in the dev releases so users really have no other recourse but to try the dev release.
I just hope that when you release a stable firmware, it really means it is a usable firmware that we can use in our everyday work and not later realize that there is another bug that will affect x,y,z accuracy.
Most of us actually bought these units for actual work and any errors resulting from hardware/firmware issues may mean penalties from our clients or we may need to re-do the work at our expenses. Any errors that Emlid makes due to hardware/firmware issues are given a “we are looking into this” response.
There is always a potential for bugs, always. Even in medical equipment, where the QA routines are much more rigorous (and the prices likewise).
Agreed, one solution does not always fix thing when there are so many variables in the equation.
If you take as an example the comparison between a paid software suite like ArcGIS Pro and an open source crowd-funded equivalent like QGIS, I would venture to say that QGIS is doing a better job even though there are bugs. The ESRI suite is not even feature complete yet and it’s a paid service.
It’s annoying when you’re using a tool for production and something goes wrong, but the entire market has evolved from extremely robust, tested tools that see almost no updates past release to having a relatively rushed initial release with frequent updates. Emlid is definitely not an outlier in this regard. Of course, some companies will follow the “old” model, but then you have to pay a huge premium for it.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.