Our measurement shows 2458 b/s (bits per second) with GPS+Glonass 1Hz and full sky view.
1 Like
RFD900+ theoretical Air Data Rate minimums for each ReachView u-blox configuration file:
- GPS_1Hz, 1758b/s --> ADR = 4
- GPS_5Hz, 7899b/s --> ADR = 8
- GPS_10Hz, 14744b/2 --> ADR = 16
- GPS_14Hz, 20430b/s --> ADR = 32
- GPS_GLONASS_1Hz, 2458b/s --> ADR = 4
- GPS_GLONASS_5Hz 11584b/s --> ADR = 16
- GPS_BEIDOU_1Hz not tested
- GPS_BEIDOU_5Hz not tested
- reach_raw, 15270b/s --> ADR = 16
This is based on my testing with a partially blocked sky view, but I have adjusted my numbers by a factor of 1.29 to match your full sky view figure of 2458b/s for GPS+Glonass 1Hz.
In practical testing today, I have had to increase 1 or 2 speeds over the theoretical speeds above, otherwise there tends to be signal drop-outs. In reality, I think this is because of delayed transmission. What you see is the grey bars coming and going, or the grey bars just disappear after a short time and they donāt come back.
7 Likes
Youāre right! I removed the ākā to bring it back to realistic speeds.
I just wanted to report I had my fastest time from startup to RTK fix with the radios.
Immediate float, and around 2 minutes to fix. Iām pretty sure all that I had changed was the GPS/Glonass update frequency from 5Hz to 1Hz.
- static mode
- used positioning systems: GPS, GLO, SBS, and QZS
- baseline was a few hundred meters
- minor amount of vegetation obstructing the line of sight
- ReachView 4.0
- I think everything else default, with Glonass ambiguity resolution ON, SNR mask 35, and elev mask 15
- post-processing gave me 600 fixed coordinates with a 10 minute occupation and it all fit in a 0.5cm box.
So, I had previously assumed that faster update frequency = faster fix.
Maybe not?
5 Likes
0.5cm box wow impressive! Leica may have to drop there prices lolā¦just curious on why u use radios for communication between base and rover? No internet?
1 Like
Yes, I was very impressed too, and now Iām anxious to find out if these results are repeatable.
You are correct, there is no internet where I am working.
1 Like
Hiā¦
comming back to this nowā¦
do you power the RDF through the reach, and whats your powe source there?
I still coudnāt get high ranges with obstructions with our RDF
My RFD900 are powered through Reach. Reach is powered by L-ion battery capable of 2 Amp output.
I have had RFD900 work well with minor vegetation obstruction. It also does work beyond the line of sight, but not very well for the purpose of getting an RTK fix.
We would have a better link with a lower transmission speed, but Iāve also read that increasing the speed and repeating packets can also improve a serial link (in general). The trouble is that packetizing increases latency, which is not helpful for RTK.
I suppose a software tool could be written to run through an exercise with various settings and pick the best one for the current conditions.
Thank you! That sounds somewhat encouraging. I will try to do some more tests as soon as I have time. For the moment we will focus on a post-processing solutionā¦
I do have same condition,i stop the reachview, then start again, it couldnāt be startedā¦ maybe this problem can be solve in next updateā¦ I hope.
Hi bide, I have a question, where to choose or configure 11584b/s for GPS_GLONASS_5Hz
1 Like
Well, the official tool for setting the RFD900 radios is shown here:
http://rfdesign.com.au/documentation/rfd900-config-tools/
While we are on the topic, I will give a shameless plug for SikSet.py, a new tool for changing RFD900 settings from Reachās command line. One day, I hope ReachView will also be able to control the radio settings by utilizing this tool.
But this tool is something you would have to copy to your Reach and then run from the reach on the command line. It may just be easier for you to run the official Windows config tool with the radio plugged into your computer with the USB cable.
Back to the question: You want to run with GPS_Glonass_5Hz and the theoretical speed is 11584b/s. The next closest, but higher Air Data Rate (ADR) setting is 16 (or 16000b/s). You could try that, but I would recommend going at least one step higher to 32 (or 32000b/s).
1 Like
I have disappear and appear again repeatedly, Even though 2 days ago with same setting i didnāt get this problemā¦
This is the video show up the signal
https://drive.google.com/file/d/0B4NFPYGvPmMvc1NKTTFSaHBsNEU/view?usp=drivesdk
https://drive.google.com/file/d/0B4NFPYGvPmMvNXRHcVFXb01TRzg/view?usp=drivesdk
And one more the strangest, my rfd900 868MHz changed to 900MHz, I donāt know how and why iy can be?
I was able to watch the first video. This could be any of:
- a bandwidth problem
- a signal strength problem
- a latency problem
- interference
It would be hard to determine which one it is, so trial and error is your best bet, and I know you have already been doing that. Good luck!
I am experiencing the same issue, some days it works perfectly and other days the gray bars appear and dissappear constantly (without changing configuration).
@bide, I was thinking about those kind of issues, but not sure how to solve them or isolate them. Any ideas?
Trial and error,i think that is good idea.
Hey @dicky, @bide. I just did some testing (it was indoors because I was only looking at the performance of the radio link (the gray bars stayng solid vs continuous dropouts).
It might be an issue of latency, because I had some success with the following configuration of the Radios:
As you can see, I configured to Low Latency instead of Raw Data and MaxWindow of 33. As I understand, this lowers latency but also bandwidth. Since the performance is better (no gray bar dropouts in initial testing), I am assuming for the moment that it is a matter of latency.
I will try to do some field testing ASAP to confirm the results. Meanwhile, I would appreciate any feedback that you have or results from your trial and error. In any case, I think it is hard to isolate the problem, because magically sometimes it works great without changing configurationsā¦
1 Like