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ā¦
Thanks!
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:
- 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?
- 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 ! 
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?
Hi!
-
Standard RTKCONV and RTKPOST do not support this feature. We are working on the patches ones. In the final stages now.
-
Yep, thatās correct.
Hello,
Thanks!
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!)
Thanks!
New update is here with updated to RTKLIB. Would be nice to see if it helps your case!
Iām closing this thread.