Configuration of ZED F9P with u-center(stand alone)


I’m a bit confused about how to configure the ZED F9P using u-center(stand alone operation).

Our HW and SW version are as below :


-version : 00190000


-version : EXT CORE 1.00(61b2dd)


-ROM BASE 0x118B2060

-FWVER = HPG 1.12





  1. Firstly, I tried to set configuration using your drotek github web( and referring to your document web site. And then I setup the system as follow picture.

But this setting is not worked. I think the base system is working well(I already checked the status(TIME) of base module). But the rover module always shows the status is ‘3D’ in u-center.

I don’t understand this situation. So I checked the output(RTCM) of base module using terminal program.

Actually I cannot interpret the binary output, but this protocol/packet is showed in terminal program with constant time interval.

In this situation, I wonder the telemetry setting parameter(baud rate, data type …) and then I tried to change both setting(telemetry and gps modules).But this is not worked.

  1. So I tried changing the configuration as follow picture,

As you can see, I changed the connection between base and rover module from wireless to wired ( UART1, UART2 ).

And then I tried to check the packet status using u-center, I can see the status of RX/TX bytes and message parse/process in Message view-‘UBX’-‘IO’& ‘MSGPP’ tab.

In base module side,

The TX bytes(UART2, RTCM port) is increasing,

In rover module side,

The RX bytes(UART2) is increasing, but this message is just ‘UNKNOWN’ bytes in MSGPP monitor.

I think the rover module receive the packet, but the protocol is not valid.

So I tried changing the HW port(UART1<-> UART2), setting the ‘PORT’…

But this is still not worked.

Any idea or solution how to fix this problem?!

Hello YPDynamics,

Thansk you for the very helpful pictures.
Did you properly set the device baudrate into the “PRT” register of both DP0601 devices ?
These must be the same as the telemetry ones.

In addition you need to use UART1 on the base side and UART2 on the rover.

UART2 is meant to be used as RTCM receiver.

Yes I properly set the device baudrate into the “PRT” register of both DP0701 and telemetry.
But the situation is same.
So, I tried changing the port ( UART1 : base side, UART2 : rover side) before you recommended.
The result is as below :

  1. Rover Side

  2. Base Side

As you can see,
The base side status is ‘TIME’ , and it transmit the packet via UART1.
The rover side status is “3D”, and it receive the data via UART2 but the packet is “UNKNOWN”.

I am going to check the provided config files this morning. I ll get back to you very soon.
Did you revert back to default xonfiguration before uploading the config files ?

I do not know what could be wrong since it should be pretty straightforward in a standalone use.

Hello there,

I would kindly recommend you to revert the base gnss module to default configuration and reconfigure the base. Please use the UART2 port for the base station to send the correction data since the configuration files are set accordingly.
To check whether the radio transmission is working fine, we will first test using the JST-GH 6 pin cable. Once you achieve the TIME mode for the base, you may connect from UART2 base to UART1 rover with the standard JST-GH 6 pin cable.
You can also connect from UART2 base to UART2 rover with interchanged JST-GH 6 pins cable.

With this order; you will get a fixed mode. Good luck.

Hi. Paul.
Are you still in progress?
I already revert back to default configuration.

Thank you for your reply, Anthony.
I already set and use your recommendation. But it is not work.
The base and rover module are connected(wireless or wired).
I think the cable or port configuration is not problem.


“is not” or “is” a problem ?

If you still believe there is an issue with this device, please open a ticket here :

Hi Paul.
Before Anthony recommended the way(reconfiguring the base, using UART2 port), but it doesn’t work.

And, what is “open a ticket”? I don’t understand your statement.

Opening a ticket is like a message you can send to us so that we can plan for a product return related to the device that may not be working properly.

You did say you tried everything to make it work, however the device is still not working properly.
In order for us to check wheither the issue comes from (a bad configuration or a hardware issue) we need them back for troubleshooting purposes.