I was hoping someone would be able to take a look at this issue I am having.
I recently purchased the Reach M+ UAV RTK kit and have set it up as follows:
Connected the LoRa Radio to the Reach M+ RTK GNSS Module (S2 Port) using the provided 7 pin connector
Connected the Reach M+ RTK GNSS Module (S1 Port) to a Cube Orange controller (GPS2/Serial4 Port) as follows:
a. Pin 1 on M+ to Pin 6 on Cube (Ground - Ground)
b. Pin 4 on M+ to Pin 3 on Cube (TX - RX)
c. Pin 5 on M+ to Pin 2 on Cube (RX - TX)
The M+ Module is powered from an external, power source through the USB input.
GNSS Antennae is connected to the M+ Module and is placed on a 75mm x 90mm steel plate, roughly 250mm above the top surface fo the drone.
Reach RS+ Module Setup:
GNSS Settings:
a. Positioning Mode: Kinematic
b. GPS AR mode: Fix-and-Hold
c. GLONASS AR Mode: On
d. GNSS Selected: GPS, GLONASS,GALILEO, SBAS, QZSS
e. Update Rate: 5Hz
Correction Input: LoRa
a. Frequency: 902.5 MHz
b. Output Power: 20dBm
c. Air Data Rate: 9.11 kb/s
Correction Output: Off
Position Streaming
a. Output 1: UART, 38400 Baud, NMEA
NMEA Settings:
Talker ID: GN
Message type: All set to 1 Hz
b. Output 2: Off
Base Mode:
a. Base Coordinates: Average Single, 5 min accumulation time
b. RTCM3 messages:
1002 - 1 Hz
1010 - 0.5 Hz
1097 - 0.5 Hz
1107 - 0.5 Hz
1117 - 1 Hz
1127 - 0.5 Hz
1006 - 0.1 Hz
Reach M+ RTK GNSS Module Setup:
GNSS Settings:
a. Positioning Mode: Static
b. GPS AR mode: Fix-and-Hold
c. GLONASS AR Mode: On
d. GNSS Selected: GPS, GLONASS,GALILEO, SBAS, QZSS
e. Update Rate: 5Hz
Correction Input: Off
Correction Output: LoRa
a. Frequency: 902.5 MHz
b. Output Power: 20dBm
c. Air Data Rate: 9.11 kb/s
Position Streaming
a. Output 1: Off
b. Output 2: Off
Base Mode:
a. Base Coordinates: Average Single, 5 min accumulation time
b. RTCM3 messages:
1002 - 1 Hz
1010 - 0.5 Hz
1097 - 0.5 Hz
1107 - 0.5 Hz
1117 - 1 Hz
1127 - 0.5 Hz
1006 - 0.1 Hz
ArduPilot Setup:
GPS_TYPE2 = 5 (NMEA)
GPS_AUTO_SWITCH = 1
GPS_INJECT_TO = 1
SERIAL4_PROTOCOL = 5 (GPS)
SERIAL4_BAUD = 38
The system seems to be working, the M+ Module receives corrections and is able to get down to a FIX status.
The issue that I am running into is that I cannot arm the drone when on Position Hold and I constantly get either a High HDOP error or GPS Unhealthy error which does not allow me to arm. I Have triple checked all of my wiring and settings and I cannot figure out what the issue is.
Please let me know if anyone has any ideas or needs any additional information.
In most cases, such errors are shown if the receiver tracks an insufficient number of satellites for the precise position calculation. However, you’ve noted that your Reach M+ got Fix. Could you please clarify whether the Fix solution is stable and how big is HDOP? You can also record the following logs on the base and rover for 10-15 minutes so that I can take a closer look at the satellite signals reception:
raw data, base correction, and position logs on the rover
raw data log on the base
As I see, the Position streaming is enabled on Reach RS+, while the Correction output is turned off. So, it looks as if the settings for Reach M+ and Reach RS+ are swapped. Could you please check it?
In regards to the settings for the RS+ and M+, I think I accidentally switched the titles when I was typing up my original post. The M+ is the one with Position Streaming enabled and the RS+ is the one with the Correction Output set to the LoRa Radio.
Attached are the log files for both the RS+ and the M+ Modules. We started up both modules and let them start recording information and about 10 or so minutes in we turned the drone on. We were still getting the same issue with the GPS unhealthy error. Let me know if there is any other information that I can provide. Logs.zip (7.0 MB)
As I see in the Reach M+ LLH log, the rover’s position was in Single or Float most of the time. That’s why you could get the Unhealthy GPS signal error:
Most likely, the rover couldn’t calculate Fix because of these gaps. So, I’d suggest trying to disable GLONASS in the GNSS Settings tab and check if the receiver can calculate Fix in RTK after that.
The gaps in GLONASS signals seem rather unusual to me, so it would be great to investigate this issue further. As I know, some of our users got worse GLONASS signals with single-band receivers if there were big metal constructions or power lines nearby. So, it would be of help if you can share some photos of your environmental conditions. Also, please check if your receivers work on the latest 26.2 firmware version. If not, please update the receivers and tell me if the issue persists.
I went out again today and gave it another shot after updating both units to the latest 26.2 firmware and disabling GLONASS on both. I still ran into the same issues.
Here is a link to download today’s log files as well as some images of the field that I am working in.
As I see in the rover raw data log, the quality of all satellite signals become worse at 16:57, and many cycle slips appeared at 16:59. It looks like at that time, the signals became affected by RF noise from other electronics or something obstructed the sky view:
If there is a chance some other electronics were switched on at that moment, it might affect the antenna performance. To reduce the RF noise influence, I’d suggest considering placing the antenna on a higher pole and check that you provide proper shielding with a ground plane.
I noticed strange gaps in the base corrections log collected on the rover. The raw data log on the base for the same period looks fine:
It looks like there are some issues with the LoRa radio connection between the units. Could you please share some close-up photos of Reach M+ and Reach RS+ hardware setup so that I can check what might be wrong?
Also, please share Full System reports from both devices. The reports contain detailed information about the units’ performance that might be of great help for further investigation. Please note that the reports may contain sensitive information, so I’d suggest sharing them in PM or via support@emlid.com.
To check if the issue is connected to the LoRa radio performance, please try to transmit base corrections with our free Emlid NTRIP Caster. You can do it as follows:
Provide both units with an Internet connection. You can connect them to a Wi-Fi network or a mobile hotspot with the Internet access
Log in on the Emlid NTRIP Caster page and enter the base credentials on your Reach RS+. The Caster should show that the base is Online
Enter the rover credentials on your Reach M+
If the rover doesn’t get Fix fine via NTRIP, please record 10-15 minutes logs on the base and rover and share the data with me.
So I tried two different things, first I tried to reorganize all the electronics and wires on my drone in order to help prevent any wireless or magnetic interference. After doing this I was able to get the following to work:
When the M+ is in single mode, giving the drone a 3d GPS fix, I am able to arm the drone and no unhealthy GPS error is given. As soon as the system gets an RTK FLOAT or RTK FIX then the unhealthy GPS error comes back and I cannot arm the drone.
Secondly, I removed the LoRa Antenna and used the NTRIP service instead and received the same error as mentioned above where as soon as the system gets a RTK FLOAT or FIX, the gps unhealthy error returns.
I will send you a set of logs and full system reports for both of the tests that I ran above.
I had same issue with ardupilot integration and still not sucess with emlid modules.
I was very upset with emlid M2 module in RTK.the exact issue what your facing that I wa s faced tried so many things to do work but keep getting bad gps signal health.
Thank you for conducting the test with the Emlid NTRIP Caster. The behavior you face is quite unusual, and we’d like to investigate it further. I’ll be waiting for the logs and reports since these data will help us to see the full picture.
However, the nature of the gaps seems to be different. In the LoRa radio test, the RTCM3 messages were transmitted with an unstable update rate. In the NTRIP test, the update rate was stable, but the signal disappeared for a rather long period of time. I’ll discuss it with the team to check what might be wrong here.
We have an assumption that it may help if you disable some RTCM3 messages in the Base mode tab on Reach RS+. Please note that the minimal subset required for RTK to function is the 1002 message for 1Hz and the 1006 message for 0.1Hz.
Also, please share the Serial numbers of the devices with me. They are printed on the bottom of the units under the bar codes.
I’d suggest conducting a test with the LoRa radio and check if there are still small gaps in the base correction log when you disable some RTCM3 messages.
