Issues with HDOP/baudrate/telemetry

NEO-M8P RTK
#1

Hi all,

I am facing some problems setting up a u-blox NEO-M8P RTK system with a separate telemetry connection. It consists of:

  • Tiny RTK GPS (NEO-M8P Base)
  • XL RTK GPS (NEO-M8P Rover)
  • 3DR/SIK 433MHz telemetry

I configured everything following: drotek.com/en/documentation/tiny-rtk-documentation/#integration-dropixpixhawk-2
After some issues described below I upgraded the firmware of both the rover and the base, configured everything again from scratch and verified every configuration step.

The issues:
i) Different(wrong) HDOP report in Mission Planner compared to uCenter
ii) Unclear baurate settings
iii) Telemetry settings and requirements

i) Different(wrong) HDOP report in Mission Planner compared to uCenter
As a first test after configurating the modules I went on the roof and checked the status on the M8P rover connected to an Ardupilot-Pixracer in Mission Planner. I was confused by the high HDOP of 1.88 even after 10 min or so. Then I plugged in a normal Drotek M8N XL GPS. Then the HDOP was down in the normal region of 0.7-0.8. After updating the fimeware and I think with the addition of Beidou the HDOP of the M8P Rover went down to 1.15. Still much higher compared to the M8N. Connecting the M8P Rover to uCenter the HDOP was down to 0.7. The PDOP which is usually about twice as high as the HDOP was at 1.2. So there seems to be something wrong in the communication between the M8P Rover and Mission Planner/Ardupilot. It seems it shows the PDOP and not the HDOP.

	Model		Software	Sat count 	HDOP
Test 1:
	M8P(1.0)	MP		12		1.88
	M8N		MP		18		0.76
Test2:
	M8P(1.3)	MP		18		1.15
	M8P(1.3)	uCenter		18?		0.7 PDOP 1.2

ii) Unclear baurate settings
At https://drotek.com/en/documentation/tiny-rtk-documentation/#integration-dropixpixhawk-2
it is stated that:

There make sure to select your flight controller’s GPS baudrate (38400 for Pixhawk) and click on Send.

and

Make sure your datalink is also configured to work at 38400 baudrate on rover side!

If I set the baudrate to 38400, Ardupilot (3.5rc2) is not detecting the M8P Rover module. But when I set it to 115200 it does.
As far as I remember all M8 GPS are currently running at a baudrate of 115200. If this is a must, then the telemetry should run at 115 as well. Is this correct? If the 115 is not a must in Ardupilot and if there are no sacrifices in reducing it, the question is what is better for an M8P setup - 57600 or 38400?

iii) Telemetry settings and requirements
I have not managed any RTK fix in the setup so far. The telemetries are communiacting with each other, but I am not sure if they commuicate properly with the GPS modules. This might be due to the baurate settings.
My first question here is what is the best way to test if the system works? Do I see it in uCenter or Mission Planner?
Second, what are the requirements for the normal SIK 433MHz telemetry in terms of duty cycle when running a M8P RTK setup?

Thanks a lot in advance,
Thorsten

PS: cross-posted at discuss.ardupilot.org/t/m8p-rtk-setup-issues-with-hdop-baudrate-telemetry

  • edited: it seems only two links are allowed - even in replies…

Since my “account has been temporarily placed on hold as a precautionary measure” (not sure why) I cannot post any further replies. Hence a new edit here.

I just made another test with the exact same results. I switched between MP and uCenter several times to be sure and this is persistent.

uCenter HDOP vs. Mission Planner HDOP:

HDOP_PDOP.JPG1226×526 79.3 KB

Since the numbers are correct when using a M8N instead of the M8P I guess it must be some message/communication issue between the M8P and Ardupilot.

Any suggestion what to test?

Thanks,
Thorsten

Account still on hold… Another edit.

At discuss.ardupilot.org/t/m8p-rtk-setup-issues-with-hdop-baudrate-telemetry/16019/5 Michael Du Breuil relpied that:

Getting a PDOP loaded rather then HDOP is a fallback mechanism if we haven’t yet recieved a UBX-NAV-DOP message. If you had autoconfig enabled then you should have been receiving these messages.

So the strange HDOP value issue seems to be solved/explained. I’ll try it again with NAV-DOP enabled.

However, there is some more discussion about the message settings. Would be great is someone from Drotek could provide a solution.

Thanks!
Thorsten

#2

Here is a link to the Pull Request that increases the default baudrate to 115200 for all u-blox devices:

#3

Thanks for reactivating the account!

#4

Hello Thorsten,

i) Interesting, this is weird because both M8P and M8N use the same GPS driver/messages at the autopilot level. If there was a bug on the driver we would see it on both ends. Needs further investigation, I’ll try to run some tests to reproduce the issue.

ii) At the moment we wrote documentation, Ardupilot GPS settings used to configure the GPS for a baudrate of 38400. I took a glance at the code and now it has switched to 115200 indeed : https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_GPS/AP_GPS_UBLOX.h#L40
So GPS configuration must have 115200 baudrate indeed. Your radio link must match this baudrate in order to be able to communicate with the module. M8 GPS run by default at a baudrate of 9600, then they are usually configured by autopilots at startup. I suggest to keep it at 115200. It has been measured than 38400 bps is enough to pass all differential data without losing information, so anything equal or greater is fine. I’ll also have a look on PX4 side so we can correct documentation with appropriate numbers.

iii) If you want to make sure your whole setup is working before connecting it to the autopilot, please follow this tutorial : https://drotek.com/en/lessons/comment-utiliser-le-module-rtk-drotek/
The key point is to check that RTCM messages are correctly received by rover. Once it does, everything should be ok. The default configuration for SIK 433 MHz radios for duty cycle is 100%. This is to comply with local regulations on some bands. If you are allowed to transmit on the band 100% of the time, you can leave it there. Please don’t hesitate to ask any question about it.

#5

I think there is an incoming PR regarding not using NAV-DOP, NAV-STATUS, NAV-POSLLH and NAV-VELNED anymore in favor of NAV-PVT (it contains all useful data within the same message). It is likely that the problem disappears with it. Have you also tried activating NAV-DOP message manually?

#6

Sorry, something is misconfigured on the forum!

#7

Hi @Kevin,

thanks for your detailed replies!

Yes activating NAV-DOP seems to works (a value < 1 and 12 sats on a balcony between two houses must be HDOP now…). So adding NAV-DOP to the list seems to solve this one.

I am still not sure about the baudrate.

But this automatic configuration by the autopilot is not possibe with this module (Tiny RTK XL) - right?
So you suggest to set everything to 115200 manually, which includes the telemetry on both sides (base and rover)?

Regarding the SIK 433MHz radios, can you explain it in more details?
It seems that only 10% duty cycle are allowed in Europe with a TXPOWER< 8.

These are the options according to http://www.etsi.org/deliver/etsi_en/300200_300299/30022001/02.04.01_40/en_30022001v020401o.pdf

Since 1mW seems far to low then the channel spacing should be set to <=25kHz to run it at 100% duty cycle. How can this be done?

#8

GPS modules are configured at startup if bridge is soldered on rover (bridge is the link between autopilot’s TX and GPS RX, hence the configuration). The presence of the bridge allows using a separate telemetry for RTK corrections.

With SiK radios, it is not compulsory to have the same baudrate on both ends, the important parameter is Air Rate, otherwise you can have different baudrates.

There is a good explanation of SiK radios there : http://ardupilot.org/copter/docs/common-3dr-radio-advanced-configuration-and-technical-information.html

Specifically, the radio divides up the frequency range between MIN_FREQ+delta and MAX_FREQ-delta into NUM_CHANNELS channels. The ‘delta’ value is a guard range to ensure that we stay well away from the edges of the allowed band. The guard range is set to half a channel width. The channel width is defined as:

channel_width = (MAX_FREQ - MIN_FREQ) / (NUM_CHANNELS+2)

The traffic you will generate will be quite “bursty”, so even the 10% duty cyle setting should work, but with these you can choose between :

  • no restriction on channels nor frequencies and 10% duty cycle
  • 25 kHz channel spacing and 100 % duty cycle
#9

@Kevin,
thanks a lot for the information on the radios!

Regarding the M8P modules it would be great if you post some config files on your product page. Is the configuration of rover and base the same for the GPS injection method via Mission Planner and a dedicated telemetry link?

#10

Ok we will definitely do that. we will figure out differences between PX4/Ardupilot and try to write something explicit. Base configuration is the same, but rover differs in baudrate and type of messages. In addition Ardupilot is moving towards the NAV-PVT message, so things are going to change in a near future.

#11

Hi Kevin,

thanks! Much appreciated!