We’ve just pushed a new dev update - v2.13.0. This update contains huge improvements for our positioning engine, RTKLIB. Starting with this version, Reach can peform GLONASS ambuguity resolution with a non-Reach receiver acting as a base. This will immensely improve both convergence time and fixed solution stability. We’ve also fixed BeiDou AR, which should give a serious boost to our users in Asia and Australia.
Small note: you may notice that we skipped v2.12.x. From now on versions where the second number is odd, will be considered dev. The next non-dev release will be v2.14.0.
Another small note: Reach M+ and RS+ devices will skip this round of dev updates and will be updated to v2.14.0 directly.
Reach will now correct GLONASS inter frequency biases, allowing for GLONASS AR with non-Reach bases, such as NTRIP casters. Please note, that this version has GLONASS AR fixed to be ON.
BeiDou processing significantly improved
Reach will now restart the processing if base position changes during processing. That might happen with smart NTRIP casters which automatically provide the closest source of corrections.
Recommendations for using this version
Perform the first initialization in good conditions. While it’s a general rule for great results, this version in particular will shine once you let it calibrate the inter channel biases. Once you get your first fix, it will endure conditions tougher than ever before.
Try reducing the elevation mask to about 5. This build will work better with more information, even if the quality is lower.
New features are coming to Reach receivers, so stay tuned
v2.13.1 is out! It’s mostly an under the hood release, bringing things in sync with the RS+ and M+ devices. Among these things is the beautiful new Wi-Fi interface:
Unfortunately, due to hardware limitations, the Wi-Fi scan feature is only available on the + series devices.
Oh, and we also fixed a bug with the battery indicator that would sometimes not show the fully charged battery state.
v2.13.2 is out. It’s a huge improvement for our survey tab. The project view has been reworked from the ground up and will act as a foundation for new surveying features. All the screens have been given a facelift, too.
New survey project view. Once you open a project, you will see a completely different screen. It is now based around the map, which has all the points and displays the base and the rover. You can still access the point data as a list and access all the point data, though.
For the first time I feel confident using L1 Beidou in Australia.
And the improvements in Glonass AR are fantastic also.
Always nervous with the Dev updates, but this one appears solid.
When changing from Glonass to Beidou do I need to (still) deselect all but GPS, apply and then select GBPS and Biedou and whatever else?
Getting a solid 30 satellite fixe with a 10 deg mask, GPS, Beidou, Galileo, SBAS and QZSS and 28 satellite fixe with GLONASS rather than beidou. I need the 18K Lora data rate, so we shall see what range this all holds together out to, and look forward to going into the trees to see how robust it is.
Can’t wait to try out BeiDou for a change! Although the data rate is pretty high compared to Glonass… thinking about which RTCM messages to use for LoRa, would it be better to use BeiDou @ 0.5Hz and sacrifice QZSS / GAL or bring BeiDou down to 0.1Hz so we can keep QZSS / GAL on? Has anyone played around with this with any success? Or does it just come down to picking the one with the most satellites over head…
We’ve got some good projects coming up that will test the endurance of the new fix too!
We took our two Reaches out this morning, Beidou working really well on this build! Also seemed to do a great job handling the 5 degree elevation mask. From our crude testing we found the following to work best (i.e most satellites, fastest fix, good AR ratio). GPS @ 1hz; ARP @ 0.1hz and BeiDou @ 0.5Hz running over 9.11 kB/s LoRa. Running Beidou @ 0.1Hz was still quick to get fix but the AR ratio appeared a bit sporadic…
We will try get the rover out in the field to stress test the stability a bit more.
Edit: I should note that this was in the Australia region.
The idea here is rather simple. Multipath problems mostly arise in proximity to buildings and other big objects and in this kind of conditions, measurements of the “high” satellites are often affected too. To avoid that, we’ll need a an extremely high elevation mask, which will cut off most of the sats in our view. So instead, we set the mask really low so we can take advantage of more sats, some of which might not have been affected by the “big wall”.