here is an actuall screenshoot of running reach vs last version of rtknavi(by rtkexplorer). data is taken from port 2000 from reach…
with reach no fix with rtknavi stable fix after 5-7 minutes…
if i use data from reach and postprocess if have sucess but not with realtime rtk…
Andreas,
We are working on delivering an updated RTKLib with b26+explorer+emlid features. It should be available in ReachView 2 next week.
Our outdoor tests actually showed quite solid performance even with current version.
I am happy to see it…
2.4.3 b26 from tomojitakasu works also very good. here a run b26 vs b26 rtkexplorer…
the precision is enorm - both have the same solution…
.update:
at the moment i have very less satelittes and weather is very foggy…
only demo5b26 was able to hold fix…
I had fix within a couple of minutes and has been stable for probably .5 hour now.
Here are my rover settings. I basically used the “trial and error” method to make selections that work.
Weather conditions and setup as follows.
Andreas, what correction input type are you using?
My last post with gps only was with ntrip server ~ 25 km away
The first posts were my reach base and rover with tw3710 ~ 45 m between
With no luck
We actually had perfect results with our last field test. Nothing special in the settings. As far as I can remember, we had no GLONASS corrections for some reason.
We are currently testing a demo5 merge with our code, might be something good.
I have had reasonably good results with demo5 post processing with poor sky view environment with a large amount of slips from receivers.
Looking at visibility analysis, using RTKPLOT (Hit the round button near the Rover and Base Rinex file entries), you can click on L1 to see signal strengths of each satellite along with the slips. Not too surprising is that signal SNRs above 40 have very few slips. I have found that in RTKPOST and Reach that this improves results considerably.
Although listing all satellites with many slips to be rejected is also useful in post processing, It is difficult to know in real time. Therefore, using the signal strength to reject satellites appears better.
I have not able to get a FIX with Reach beta as yet.
I was able to get FIXs in the last upgrade or two before Reach beta was released.
I know it is a difficult trade-off to keep setup simple for clear sky drone use and also give the “surveyor l1 grade user” the flexibility to adapt to their specific needs.
I would like to see you add a provision for the operator to edit a custom Reach configuration file as others have suggested.
In my “worst-case” environment, I am getting post processing resolutions of less than 1 CM using two Reach units and demo5 latest bin files. Baseline =21 m.
Appreciate Emlid listening to feedback. Keep it up. Making progress.
By the way,
The new update feature works great for me. Maps are great feature. Working good.
Hey Brent
You could have kept that minus 22 out there instead of sending to us. I think they are saying -23 for tomorrow.
Jim
Same as before …
Reach fails to get fix
When I use rtknavi at port 2000 (rover) and rtcm (base) it is able to get and hold fix status!!!?
We will do more testing this week and keep you updated.
I have found that increasing ARFilter ? from 004 to .05 has given me good FIX in post processing (Demo5) of poor skyview RTKPOST. GPS GLASNOS SBAS.Maybe add more options control?
Update: Did some checking with old Reach UBX files using Demo5 Post Processing. With AR Filter =ON ( Page2 of Configs), Max Pos Var for AR =.004 gives all FLOAT for Kinematic. Changing to =05 gives good FIX for poor Sky View. I suspect this may need to be set for user’s environment. Unfortunately, I do not see anywhere to change it on ReachView as yet.
Demo5 appears to give much more consistent results for me.
Even in FLOAT mode, Reach is showing much better tracking and consistency than earliest versions.
Hi,
Appreciate your feedback to Emlid Community. I am trying connect RTKNAVI to Reach without success. I also have never been able to SSH into Reach beyond getting into edison. I don’t seem to be able to get a typical linux directory.
I know this is off topic, but maybe you could start a new topic or direct to step by step procedures. I’m somewhat LINUX familiar, but not here.
Ssh: user = root password= emlidreach
Ip adress of reach Port 22
For navi:
You can get raw data (ublox) at Port 2000 of rover.
I can SSH OK. Thanks. All I seem to get is BASH commands and /logs directory with my Reach logs. How do I get a look at config files? I don’t see typical LINUX directories. There are a few specific commands that edison responds to, but very few.What am I missing? Thanks for your kind help.
I’ve been able to TCP my solution to the RTKPLOT program, but get communication error onRTKNAVI. If my rover is 102,168.43.24 , what do I enter in the “I” button of RTKNavi? Do I have to enter additional Ublox Receiver commands?
Was doing some testing with the beta yesterday (so maybe with the slightly older beta release). Using my own NTRIP server, base unit connected to wifi network and rover tethered to cell phone wifi hotspot. Corrections are coming through perfectly, with correction age usually under one second Working within about 500m of base receiver. What I’m finding though is that I get a fix after a few minutes, and the GPS AR value gets very high (like over 400), then it seems to start to fall and eventually I get float solution again. This process seems to repeat. I’ve been unable to hold fix for more than a minute or so when stationary, and if I start moving the rover this seems to cause the AR value to fall too.
I’ll try the newest release tomorrow if I can.
If anyone needs access to an NTRIP server for testing let me know I’ll set you up an account.
Simon
