Reach + RFD900 radios

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

25 posts were split to a new topic: No fix with corrections over RFD900

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/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

Oh…OK, I really want to apply this configuration, but now I really busy with my job, I would really hope the reasult is better.


There’s lots of chatter in a few threads here which brought me to ask my (other) self the question, “How could we troubleshoot a situation when we are using a radio link and where the grey bars of the base are not showing a continuous, good signal?”

At the office, there is a short radio range and everything can appear good.
In the field, the conditions are often less than ideal, and when things aren’t working, we are more concerned about capturing the particular data set than doing radio troubleshooting.

I suppose that one could do his RTK work while also capturing raw logs for post-processing. If the RTK results are bad and the post-processing is good, that would shift the blame to the radios.

Currently this can be accomplished with 3 Reach devices, or by using my command-line workaround, or by waiting for this feature in Reachview, which, by the way, is on ReachView’s roadmap.

If the blame is then shifted to the radio, then another thing that could be done is to record a set of good quality base and rover logs, then play them back in real time with the RTCM3 portion going over the radio link and see what happens to the quality of the solution data versus the post-processed original. Of course the logs could be compared for quality as well.

Another idea which could be implemented, is to send a file with known contents across the radio link, and compare it on the other end. For example, a copy of this file is on each Reach device. Say the file is in RTCM3 format and it contains 100 RTCM3 messages. The file is is sent over the radio link, at a certain pace, to another Reach. There it is compared to the original file and scored for the number of identical RTCM3 messages received, and for the correct timing of those messages. This whole process could be automated with, let’s say, a “receive RTCM3 test file” button on the rover, and a “send RTCM3 test file” on the base, and a percentage score displayed at the end of the test. Something like this might even be paired with another feature for changing radio settings :wink:


(@Juan_Diaz I wrote this post before I read of your latest tweaks, so I am hoping your tests turn out to be successful!)

Today’s test was quite successful. Although I have experienced previously that one days configuration that works, may not work a different day in similar conditions. I would love to hear extra feedback if anyone tries the same or other configurations. Again, this is what I configured in the radio (I am focusing on that, because I have not had issues with graybars dropout using wifi connection between modules and my cell phone as a hotspot):


First, the results: I tried two different times and was able to obtain fix within less than 1 minute. I still saw some of the gray bars dropout but I think not as often as before, and they recovered quickly. In fact, it did not affect the ability to obtain first float and then fix. It did go from fix to float a couple of times but I am not entirely sure that it is due to the dropouts. In all cases, fix was recovered within 3 seconds.

My setup, as mentioned before was using my cellphone as a hotspot for PC and both reach modules, the Mission Planner obtaining corrections from base using TCP and GPS inject into 3DR 433MHz radios. The base module is on a 1,7m tripod and powered by an external USB battery pack:


The rover module is inside the drone canopy, with the antenna on top of a mast I made with gopro brackets, and at the same level or slightly above the main GPS antenna. (I know the canopy is in bad shape, its the one I use for testing antenna placement and drilling holes :sweat_smile: )

Ground planes are made of Raw PCB boards cut to 10x10cm squares and with the antenna cable straight down through a small hole.

Finally, a screenshot of the SNR levels when fixed.

And the positions in RtkPlot. You can how the solution goes from single to float and the fixed.

And also the spots where the solution went very briefly from fixed to float and then back.

I will try this set-up again next monday and also check the results while flying. Because I am still not 100% confident that this solution is completely reliable every time. Again, I would really appreciate feedback or results from someone else in this or other configuration. I have some very important milestones close by and I need to have the RTK working reliable to ensure the future of our project.
Cheers!

2 Likes

by the way, does anyone know if it could be an issue of GPS injection by mission planner instead of the actual radio link? or did you already test it without mission planner in between? I guess this could be checked easily, although I cannot do it today.

Good afternoon Juan,

I have not been able to get the point that you have get, because I have not been able to adjust settings in the ReachViewApp.

Could you please send us an image about the way you connect your radios and how do you set up the ReachViewApp?

I am at Colombia and I have 3DR radios.

Thanks in advance

as requested by PM, here is a field report with working RFD900 settings:

reach_2:~/serial-radio$ python SiKset0.0.9.py --local --baud=57600 --show-parameters
ATI5
[1] S0: FORMAT=27
[1] S1: SERIAL_SPEED=57
[1] S2: AIR_SPEED=32
[1] S3: NETID=8
[1] S4: TXPOWER=27
[1] S5: ECC=0
[1] S6: MAVLINK=0
[1] S7: OPPRESEND=0
[1] S8: MIN_FREQ=915000
[1] S9: MAX_FREQ=928000
[1] S10: NUM_CHANNELS=50
[1] S11: DUTY_CYCLE=100
[1] S12: LBT_RSSI=0
[1] S13: MANCHESTER=0
[1] S14: RTSCTS=0
[1] S15: NODEID=1
[1] S16: NODEDESTINATION=65535
[1] S17: SYNCANY=0
[1] S18: NODECOUNT=2

reach_2:~/serial-radio$ 

Today, we worked in light rain with a 450m baseline. The radio signal had to push through 100m of forest/underbrush and the remainder was clear. Both Reach were running v0.4.9. The only changes to the “reach_kinematic_default.conf” was GPS_GLONASS_5Hz and increasing the minimum SNR from 35 to 40 and then to 45 to get more stable float values for the rover’s sub-optimal 45% sky view. Initially the radios were set for an air data rate (AIR_SPEED) of 64 (kbps), but there were times when the base’s grey bars were dropping out. The air data rate was decreased to 32(kbps) and the grey bars were rock solid for the duration.

For the day, there were some fixes, but mostly float, and I was not expecting anything more with such a limited sky view.

*a side note. at times when ReachView status was showing as “-”, I would wipe the water droplets off of the rover antenna, and it would immediately switch to “float”. A radome or a conical antenna would fix that problem, I think.

Than you bide, that’s good news and nice share. I would like to try this configuration. Regards…