ReachView 2 beta v2.1.3(and new image)

Chromium worked well. I downloaded portable binaries for Windows here: Chromium binaries.

I’m not sure wether the configuration of reach is permanent or whether it is lost every now and then. Got the impression that sometimes onfigurations like stop logging when full or position output change their configuration magically.

It would be nice to have profiles. And automatic logging start after 2 minutes.

I managed to connect via a 433 MHz UART radio. First had problems because correction output as well as position output was via UART. Would be nice if a message would be displayed so that everytime one of them is enabled the other one is disabled.

Got float and fix under weard circumstances behind a window… , Baseline was 40 m eventhough the antennas where 10 cm apart. Precision was 6 cm. So total nonsense data. What is the problem here and how can I trust other results?

Thank you,

1 Like


Thanks for the report!

I can confirm that adding an open network is broken. Will be fixed in the next release.

Hello Hugo,

What you see here makes perfect sense. On the first screenshots you can see Reach has an IP address on the wlan0 interface, so it’s connected to your network and can ping the router.

When you start hostapd Reach creates its own network, so it can’t ping your router.

It’s base mode output

which rinex version new reachview use?

its for postprocessing

Unfortunately, we don’t have RINEX in the beta yet. You can use RTKCONV to convert raw logs to RINEX.

Sorry! My question was not clear enough!

I use rtkconv to convert. Could you post a screenshot of settings to use with current Ubx.?

If I selected different rinex versions in rtkconv I got other results…


I noticed that the solution logging now is in NMEA. The file extension however is still is .ERB

Also I had problems putting out solution via BT… however I only tried with one device… and BT often makes trouble

Ah ha - I was about to report that solution logging was stuck in ERB, but had not thought to check the actual format of the file! Thanks!

My question tonight is probably not strictly about the Beta, although other people report that the newer versions of ReachView do appear to have an effect on the ability to deliver a solution: I’m constantly surprised how often my base station (with a pretty clear view of the sky, not perfect, but >7 “green” sats) does not give a solution - enough to make doing a 10 mins average for the base mode impossible. (My rover, also with plenty of green bars, remains in float with very occasional fixes. But maybe this is due to the base regularly declining to give a solution)

I will try the set up on top of the nearest mountain, but given the location, I’m finding Reach to be somewhat shy of giving me solutions. I know it is not fair to compare with other less accurate devices, but all my simpler units (eg GlobalSat BU-353) give me an output even with a very restricted view of the sky. Is it necessary for the Reach to be so shy at giving an output?

I’ve got a couple of questions on time marks:

  1. The “missing time marks” issue that is mentioned in post #1 - does that mean that 2.1.3 is not recording time marks in the logs, or that RTKCONV and/or RTKPOST don’t correctly find them? Is there an ETA for the fix or a workaround in the short term?
  2. Since reach has a pull up and current limiting resistor, all we need to do is connect the time mark pin to ground to trigger the event, correct?

Installed new 2.1.3. Much nicer interface !
I did some trials with a Leica GNSS base and I got 90% “fix” solution on my trajectory, so I am quite please.
I struggled a bit with how to log everything. The option tends to disappear easily after de-connection.
Same question as above : what happened with the time mark ? I got empty event pos file.
On previous firmware, there was a good QC check on the raw file before downloading : display of data summary i.e. GPS & Glonass observations number, camera trig number…
You should put it back.

Edit : sorry I read too fast post 1. I have Firefox and saw for the time mark. So waiting for update…
Edit 2 : Please quickly update for time mark ! :pray: Urgent need here and do not want to flash again with old FW

We are currently working on a RTKLIB version based on the latest beta and rtklibexplorer’s changes. It’s currently being tested. The new RTKCONV/RTKPOST will be posted soon with a small tutorial.

I’ll check that. By the way, the solution log is supposed to mirror the format of position output and automatically restart, if it was changed.

Could you please elaborate?

Do you mean single solution? As if one of your Reaches in base mode isn’t able to get a single solution and therefore not able to start averaging? Or does it lose the single solution in the process and starts over?


  1. Standard RTKCONV and RTKPOST do not support this feature. We are working on the patches ones. In the final stages now.

  2. Yep, that’s correct.



Do you mean a power down? I think we can confirm this, currently checking the ways to make power cycles more safe.

See my answers above.

It was a part of RINEX conversion. But we don’t do it at the moment, so no info as well.

Yes - the Reach config’ed as base (latest beta), sitting on a pole on my driveway (not horizon to horizon perfect view, but pretty good (and many green bars), antenna on alu 12cm disk. Will often drop out of single during a 5 or 10 min acquisition period.

Then the rover, attached to a raspberry pi on my bike (with a GlobalSat BU-353 also connected) drops out of single also on the driveway (which unfortunately causes gpsd/gpxlogger to stop logging). I need to achieve a reliable logging setup to begin to assess the RTK solution for tracking carts on a short fixed track. Yesterday I at least was able to create a gpx for the test ride from the reach’s nmea log: clearly in non-kinematic mode the trace is far from good compared with the GlobalSat, Garmin and iPhone recordings over the same path. Something which surprised me, given the much better antenna. Maybe there are settings I can make that will improve this? Slower rate? Turn of GLONASS? Different AR modes?

(I am aware that my needs are different from those people looking for highly accurate measurements doing survey work… I am willing to sacrifice a bit of resolution for a more dynamic… inertial measurement unit would be a huge bonus for us, but aware this is something for the future. In the meantime, what can we do to maximise the availability of a solution - fixed, floating or single!)


New update is here with updated to RTKLIB. Would be nice to see if it helps your case!

I’m closing this thread.