Has anybody has stable fix with actual beta?

If i use gps only fix is no problem…

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

We have updated RTKLIB in the new beta update. Check it out!

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

same at me…

For rover select:

TCP Client.
in opt: Adress 102.168.43.24 Port: 2000
Format: u-blox
Receiver commands are done by reachview!

In Options/Postitions: Select RTCM Antenna Position when you use your own base station with rtcm.
if you are also get raw data from your base you must switch to settings/positions and lat/long/heigh and enter your base station coordinates.

at reach:

under : /usr/bin/RTKLIB/app/rtkrcv you can find rtk.conf = configuration file of rtk and ubx.cmd = receiver commands.

booth files are under controll of reachview and rewritten every time you change something in reachview.

Andreas

Hey Andreas,

We would love to get some logs on which we can diagnose your issues. Is that possible?

Hi Egor! Here is one older data set. with heavy testing i had brick my mcx cable connector
from tw 3710 to reach.

therefore at the moment i removed my base…

reach.zip (1.9 MB)

it´s in the next post