I just hooked up the RFD900 radios to Reach as per the documentation here and here and here.
When using the cable supplied with Reach, one thing to note is the wire colours are a little different at the RFD900 end:
- Black to pin 2
- Red to pin 4
- Blue to pin 7
- White to pin 9
It “Just Worked” out of the box which was nice.
Has anybody tried this setup? How is it working for you?
I noticed that if I started and stopped the rover, then it would not start again unless I booted with the radio unplugged. I wonder if the radio is drawing too much power for Reach?
I will have to do some more testing.
What is your image version(available in the “Settings tab” on the recent versions of ReachView)?
My image version is v1.2 (and ReachView is v0.2.2)
Do you mean starting and stopping by pushing the button in ReachView, or by rebooting?
I mean after clicking the stop button in ReachView, then I can not start it again without reboot.
Let me do some more troubleshooting on my end. I will swap radios and also try powering RFD900 from an external source, etc.
Weird issue. Let us know how the troubleshooting goes. Curious if it is power issue or software.
What does happen when you press start button? Nothing or app is no longer accessible?
I believe app is no longer accessible. That is another thing I can do: run server.py over SSH and watch what happens. Is there a better way to watch the messages from server.py?
I will have to ask @egor.fedorov to provide further guidance with debug here, cause ReachView details are out of my scope
Could you please tell me more about your setup?
Is Reach connected to a Wi-Fi router? What is the LED status?
My radios are working now, so thank you for your concern Igor and Egor, and I’m sorry I don’t know what the real solution was in the end, but here are some related (and unrelated) things I did or noticed while troubleshooting:
upgrade to latest RFD900 firmware
moved the serial cable to the wrong DFU connector for a time (oops, should be beside the usb connector, not on opposite side of board)
on one computer, Reach’s USB to ethernet is now being recognized as enx220555fb0af7 instead of usb0
one Reach was crashing server.py with solid red LED, it turned out to be an empty /lib/systemd/system/bluetooth.service file. Weird. So I copied the file contents from the other Reach. edit: I think it was a bug, fixed here.
used the program screen in Reach to connect the console to the serial port like so: screen /dev/ttyMFD2 57600 and with that, I was able to:
type characters on one Reach, and watch them appear on the other Reach, and
send modem (AT) commands to the local and the remote RFD900 modem
Next, it would be nice to have an easy way of changing the transmit power level (dBm) and air data rate of the RFD900 modem while in the field.
Good to know you have resolved the issue.
You’ve read the commit correctly, it seems that for some reason the
bluetooth.service file got corrupted from time to time. That should not be an issue from now on.
Has anybody experienced drop-outs with the RFD900 radios?
In Reachview, I see the base satellites disappear for a few seconds and then come back and this repeating over and over.
I believe these drop-outs are what is preventing me from getting a fix, so I plan to do some testing. What I’ve tried so far is:
- reducing the air data rate from 64kbps to 32kbps and,
- within ReachView, reducing the u-blox config from GPS&Glonass 5Hz to GPS&Glonass 1Hz.
This could be a packetization issue. Could you try using radio settings from this guide?http://docs.emlid.com/reach/apm-integration/
As per the guide, I have disabled Mavlink. That has fixed the signal drop-outs - thanks @igor.vereninov.
To disable Mavlink over SSH:
- consult your RFD900 Data Sheet first, then
- ssh firstname.lastname@example.org
- screen /dev/ttyMFD2 57600
(modem will reply “OK” to indicate that you are in command mode)
- CNTRL-a CNTRL-\ y
to also disable EEC, add in these commands above:
I’m still working on acquiring a good fix with the RFD900 radios. I have not disabled EEC yet, so I will try that next.
On another note, I was having trouble connecting to one Reach today (solid Green LED), so I power cycled it and I noticed it stuck with the solid Red LED. I ssh into the Reach and saw the bluetooth.service file was mysteriously wiped out again. So I copied bluetooth.service from another Reach unit, and all is well now.
Hi! What is your app version?
I did not realize I was so far behind the times. My app version is 0.2.2
Upgrading to 0.3.2 now…
edit: I had upgraded two Reach units to 0.3.1 before, but I guess I missed the third, so that explains it why the bluetooth.service problem was still there.
Hi, is there any news on that?
I also had trouble getting fixes with the RDF900+
Also the range is quite limited, essentially line-of-sight is needed.
(Using 2 half wavelength dipole antennas per radio, baud rate 57600, 5Hz GPS+GLONASS, Mavlink and ECC turned off. Power through reach 1A USB powerbank)
I will experiment a bit with the settings.
Does anyone have experience with different settings / antennas / power supply / radios for ground to ground links?
Last night I got a solid fix with the RFD900+ radios at a distance of 700m.
My Mavlink is off, ECC is still on, and the air data rate is down to 32. I had line of sight over terrain with a little bit of foilage between antennas. The radio link was up for most of the time, but it did suffer from a few signal drop-outs.
@bide @Johannes_Eberenz You can lower the required bandwidth by setting base to 1Hz.
I was wondering about the bandwidth before and did a test. I think I got about 8kb/s with GPS/Glonass5Hz. That would have been indoors though and I suppose more satellites = more bandwidth. I wonder what the maximum bandwidth would be? Maybe 16kb/s?
BTW: I was happy to get radio reception last night at 1600m.