Hi, I have an RS2 as rover, M2 as base with v2.22.5 on both units. I have 15deg. mask and 35s/n filter on the RTK. 5hz sample rate and using all gnss systems.
I am continuing to experience a problem reported previously, but apparently never resolved. I am reporting this again because I am now using an M2 I recently acquired for the stationary base instead of an ntrip source. I had hopes that this would resolve my previous issues.
During field survey I am getting fixes at at least 2 different coordinates for a single physical point. These fixes are about 4ft distance from each other in 3d. This is obviously not useful.
It seems I have a defective unit that needs replacement. No one else has seen this problem? I am ready to send mine back.
Thanks!
I can, they total about 250Mb for the last session though and I am using fieldgenius for data collection. I might be able to extract a time period around the abberent observations if that is more useful.
What would you be looking for in the logs? It seems that this behavior should not be possible if the device was working properly.
It’d be really helpful if you could share the raw data from both receivers with us as well as the Simple reports from both of them. You can do that by uploading the files to any of the file exchangers like WeTransfer and sharing the link with us.
This will help us see the observational quality for both receivers. Also, we need to understand how the connection between the base and the rover was established. This is essential to understand what might have caused differences in the results.
May I ask you to elaborate on your setup in more detail? How is your base placed?
@polina.buriak
I have posted the files HERE.
The connection to base was via tcp over cell phone wifi hotspot.
The base is using a harxon gps1000 antenna about 2 ft above the roof peak mounted to the side of a building.
Thanks!
I did a post processing of the data and my results showed much less fixes than what I experienced with RTK. It seems that I am getting a lot of false fix and with low PDOP indicated. I am not sure how to distinguish between a false fix and a true fix in the field.
I am in a treed area, which I can understand will cause some issues, but surely I shouldn’t require full horizon of clear sky for this to function.
I see this problem all the time… the Emlid receivers and others at this cost level don’t have the multi-path mitigation such as other high $$ receivers, aka Trimble, JAVAD. Users think that just because you have multiple GNSS systems available at the receiver, they are good to go. Wrong. Users either don’t spend enough time on station or try to get a position in a high multi-path area.
New users expect the equipment to go anywhere and also don’t verify positions by either multiple occupations or PP against a short baseline. Short length baselines are your friend. At such a low-cost of the M2, there’s really no excuse for verification of the point by PP, even with RTK.
We have probably the best GNSS equipment in the world for surveyors (JAVAD) and even using RTN, I check my data with 2 M2’s via PP with the JAVAD rover. I’ve taken the JAVAD rover in places you would never expect to get a position, but I also have the M2’s onsite <1 km from the rover to PP just in case. Using the M2’s as a baseline approx 300m apart and PP with the rover, I’ve checked and verified within 2cm H and V of the rovers RTN position.
No verification of data= no confidence in your position. I don’t care if the receiver does say it’s “fixed”. You don’t know for sure without verification.
Thanks Bryan, I am beginning to understand what you are saying. I had anticipated that a solid RTK fix would give more confidence than what I am experiencing. I was hoping RTK would be useful for stake-out but it seems that might be an iterative process. Hopefully some improvements can be made to the receivers capabilities, but i understand there is a cost associated with more advanced processing.
Sbm, RTK is a great tool if you know your equipment limitations. Short baselines are the key to confidence in any system. Using RTK with a 10-30 km baseline for staking out is asking for trouble unless you have a name brand receiver and good pdop (sat geometry) and most importantly clear viewing skys, i.e. no obstructions above 20-30° elevation. It’s mostly trial and error to feel confident in the system you have and knowing it’s limitations. I’ve used the EMLID M2’s now for approx 4 months and they are good receivers in open sky environments. They don’t like multi-path. It’s as simple as that. Using my 2 M2’s as baselines, it’s amazing the accuracy you can obtain from them in open skys with no multi-path. That’s why they are so good in UAV use, there’s basically no obstructions flying in the sky.
I’m hoping to buy the LoRa radios in the future to experiment with Emlid RTK. David Hess’s posts on the forum using the M2’S show they are viable RTK machines. Open and clear skys are the key in any RTK methodology, unless you have the JAVAD system like we do. It can basically go anywhere including the jungles in SC.
Just wanted to add that we’ve just released a new dev firmware update v2.23.8. Would it be possible for you to test it? We have improved the RTK solution calculation, especially in somewhat challenging conditions. We believe this should help you achieve better results both in RTK and PPK.
Please note that dev releases provide early access to the new features and are not intended for the real-filed use. You can find the full list of improvements in this community forum thread.
Thank you @polina.buriak, I have been testing this update which it seems applies the latest firmware update from ublox which includes rtk improvements and so far it seems that it is very much improved. I have been working in the same adverse conditions and have yet to acquire a false fix during rtk. I will still keep a close eye on things, but my confidence is growing. This is the type of performance that I would expect to see and I hope you release the firmware update in the stable channel soon. I also appreciate the SBAS support and hope that it stays, but with perhaps an option to enable/disable. I will report back with any new findings, but for now at least this seems to be the right fix.
Thanks for the report! This fix from the dev version will be merged into the stable branch eventually. It’ll be extremely helpful to hear the results of your further tests.
Regarding the SBAS support, currently, there are no plans for adding it for the real-time survey. Thanks for the request anyway!
