We have a Reach unit (and latest software updates) with base station mode configured successfully (accuracy reported at 0.016 m). The rover unit is outputting to our computer program via Bluetooth, which we use to effect a trigger (of a camera on a moving platform). The trigger is activating but while the device says the output frequency is 5 Hz, but we suspect it is outputting at a varying speed. We hope the NMEA can be output constantly at >= 10 HZ rate.
We will try changing RTK settings to GPS only (to effect a 14 Hz rate?).
I notice this topic was previously an item āreach bluetooth output huge lag/latencyā (closed Jan 12) but v2.9.3 was said to have fixed the issue raised then. The last question in the string was āAre there plans to allow changes to the NMEA output messages in future updates? i.e select only GPGGA messages only. Iām having bluetooth connection issues and fairly sure it is a buffer issue on the receiver endā but I can not see a response.
Advice appreciated
Have you reviewed this page on camera control?:
https://docs.emlid.com/reach/common/reachview/camera-control/
This method is different and it would be wired instead of Bluetooth, but it would give you superior results with the lowest possible latency.
Thanks for the suggestionā¦ however, we have the Reach+ (rather than the Reach M) which I believe doesnāt have the feature you refer to.
Hi @walshk,
Do you mean RS+?
Yes, with only GPS on, you can use 14Hz frequency.
Unfortunately, at the moment you canāt turn on/off certain NMEA messages.
Thanks Andrew
Yes we have the RS+, one in base mode, one in rover mode.
The following exercises used ReachView (running on a Samsung Tablet).
We switched GLONASS off (with satellites R06, R07, R09, R16, R21, R22 disappearing) and set āRTK rateā (we assume this is related to the NMEA output rate) to 14 Hz. Location accuracy decreases (to lat +/- 0.231 m long +/- 0.131 m). The location accuracy did not converge well over 30 min (achieving Lat: +/- 0.162m long: +/- 0.077 m). Previously (with GLONASS on) it achieved Lat: +/- 0.013m long: +/- 0.007 m.
We are aiming for 0.050 m accuracy
Then we attempted use on a moving platform (5 km/h) The location (long/lat) reading value changed slowly, approx once every few seconds). We expected change as the device is moving.
Advice appreciated!
Screenshot_20181024-120647|375x500
Hi @walshk,
Thereās a float solution on your screenshots so you canāt get cm accuracy as you expect.
Try to get a fix before the test.
Also, youāve a bad satellite visibility according to your bars.
What are your environmental conditions and setup? Can you share a photo?
What do you bean by values changed slowly? Have you tried to post-process your logs after the test?
Thanks Andrew.
Test is done in an open (car park) area. This time Lat longs values updated rapidly (device set to 14 Hz RTK rate) and accuracy was good (+/- 0.018 m), but the solution status still showed āfloatā. What is required for āstaticā status? I am not sure how to āpost-process your logs after the testā.
thanks again
K
Screenshots attached
If the rover is set to operate in either static or kinematic mode, then achieving an AR validation ratio figure greater than 3.0 will cause a switch from float status to fix. AR validation ratio (as seen on the status page of ReachView) will rise faster if both base and rover have a good view of the sky; the number of satellites is high; GNSS signal interference is low; base corrections are arriving at the rover; and the age of differential figure stays low, etc., etc.
If you wish to try to post process your log files, the post-processing documentation can be found here:
If you want a static reading, why use 14 hz?
Usually the higher sampling rate is to give you better resolution over distance, but if you are static, thatās not needed.
Also, using the 1 hz you can enable the most constellations, which gives you higher precision and faster fix-times.
Thanks Bide,
We will get there but are still on our learning curveā¦thanks for the nudge
We are not getting AR validation values over 1.3, with setting set to either static or kinematic, or in 5Hz or 14 Hz (GLONASS off) modes in any combination on base and rover. Age of differential seems poor - around 2 or 3 s. However the spatial accuracy is reporting at 0.02 m (which would suffice for us if valid).
There is a clear view of sky, and 6 satellites are shown with green bars on 14 Hz. At 5 Hz there are an extra 5 R satellites in view, 2 green.
Thanks Christian, Our application is to trigger a camera at set locations from a moving vehicle (at 2 m/s) so I am thinking the optimal settings should be kinematic/ 14 Hz /no post processing.
Suggestions welcome,
base and rover locations - open (if cloudyā¦first rain of the wet season) sky
Your 2 or 3 second age of differential relates to a base RTCM3 messages frequency of 0.5Hz. If that is how it is set, then what you see is OK.
Maybe you should try the āreset to default settingsā button and see if that makes any improvement.
You could also slow right down with base and rover sampling at 1Hz, and just GPS, SBS enabled. If you can get a consistent fix at 1Hz, then start increasing our settings one at a time and try to get up to 10 or 14Hz.
Also, get them to an elevated position (using a pole or a stand). That will improve your SNR and reduce the risk of cycle slips and multipath interference.
Thanks for your helpā¦ we went to 1.5 m poles and that helped. We āreset to default settingsā button and set rover sampling at 1Hz, with just GPS and SBAS enabled. AR validation values over 3 were achieved, with āfloatā switching to āfixā, but not consistently, with AR > 3 coming and going over minutes. Stated spatial accuracy was around 0.07 m
Any suggestions welcomeā¦first to achieve a stable signal. Thenā¦what combination of settings would you recommend for our application? (2 m/s moving vehicle, at least 10 Hz NMEA sampling rate, southern hemisphere .
thanks again
Hi @walshk
Can you try to turn on more GNSS systems?
Please, look through this doc section to choose the best settings for your workflow.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.