Rate of rtcm messages (1074,1084,1094,1124 and 1230) does not match what was entered in wifi config.

[amlago]

Facet v3.3 24/04
Rate of rtcm messages (1074,1084,1094,1124 and 1230) does not match what was entered in wifi config.

The real rate of rtcm (messages 1074,1084,1094,1124 and 1230) is half of the one entered in wifi config.
This is reported by rtk2go and a program I have to parse these messages.
Try with default speed and default speed for low speed.
In both cases the rate is reduced to half of what was entered in wifi config.

Message 1005 has the correct rate.

[nseidle]

Thank you for testing!

We made a lot of changes to how base RTCM messages are shown on the Config page. So perhaps something is broken.

I assume you are setting RTCM message rates while in Base mode. These are now separate from Rover. Be sure to set the Base RTCM rates under the Base tab:

Above - I can confirm the Base RTCM rates are getting set on the ZED correctly. Unfortunately, I cannot replicate your issue.

In the above image, RTCM can also be set for the device in Rover mode. This is a rare need.

Are you sure you're setting the RTCM rates under the Base menu? Do you have the same error using the serial based Base RTCM menu?

[nseidle]

Well that's embarrassing! Looking at my own images, I am wrong. Let me look into this.

[nseidle]

Alright, I think it is working. I just had out of date screen captures. Below is the full settings from the Config page to u-center.

Please let me know if things are not working for you.

[amlago]

Hello.
Update to v3.3 on 04/25
With the Facet connected to the PC by cable and using u-center I see the same rate of messages marked on the Facet and in the program.

The strange thing is that both Rtk2go and Android's Ntrip Checker inform me that messages 1074,1084,1094,1124 and 1230 1094 are being sent twice as fast.
If I dial 1074----1
1084----1
For example, in both applications they tell me that these messages are sent faster.
In Ntrip Checker it tells me every 0.5 sec and in the Rtk2go page I see twice as many messages as expected per second.

Instead message 1005 is sent correctly.

                     1005-----1

And in the applications it tells me that it is sent every 1 second.

In previous versions this did not happen to me with the 1074,1084,1094, 1124 and 1230.

[amlago]

Hello.
In previous days, rtk2go was carrying out maintenance tasks on its website and I even think it changed the address of its server.
Is it possible that they have something wrong?
I keep receiving twice as many messages as expected on your page and I confirm it with the Ntrip Checker android app.
According to u-center I am correctly issuing the messages that I configured by wifi config.
I suspect that we don't have anything wrong with our software but that it is a Rtk2go issue on their page and how they are processing messages.

I can't do the same with Emlid because I think that Emlid doesn't have a summary page of the base stations that are transmitting.
This last one would be very good but it escapes us.

[amlago]

I do not know what to think. ufff
I am repeating the signal of a fixed base of the network of my country, in rtk2go and the message rate values are correct.
I still have doubts...

[nseidle]

I never noticed the (#) on RTK2go before. Thank you for educating me!

A few things:

• I cannot replicate this issue. I think everything is working ok. I suspect there was some oddness with RTK2Go for a bit but it's better now.
• Our RTK products are set for 0.1Hz for the RTCM 1230 message but RTK2Go is showing (5) on both of my stations. Looking deeper:
  

We are correctly configuring the module for 10. But the module is indeed outputting 1230 at (5) (one report every 5 seconds) shown below:

No other RTCM message behave this way. This is not a big deal in my view. I believe it's something odd with the ZED-F9P. I have an email in to u-blox to see if they have any feedback.

[amlago]

Hello . Looking at the image that you send me with the messages I see that some intervals that should be 1 second are only a few tenths of a second. In the messages 1074 1084 1094 1124. If you analyze the times with all the decimals it seems to me that the messages are coming out faster than what we configured. For example, 1124 is almost at the end of the list and I give you only the seconds: 58,037 and 57,924. And I think there are more cases. Please take a look and clarify.

[amlago]

In fact, in those 5 seconds that you mark there are approximately 10 messages 1074,1084,1094 and 1124.
In other words, double what we configured, which is what I have detected with other programs.
The only one that remains correct is 1005 as I mentioned above, in other messages. Of the 1005 there are approximately 5 messages as it should be.

[amlago]

It occurs to me that if twice as many messages are being sent per second, it may be a small problem, when we send the data to rtk2go by 3g cellular service in remote areas.
At low connection speeds or in low signal areas it can be a problem.

[amlago]

[amlago]

facet v3.3
I found the culprit.
With the Facet connected to u-center via usb cable, and by issuing ntrip fixes to rtk2go, I was able to find the duplicate fixes.
The facet is sending the same 1074, 1084, 1094, 1124 and 1230 messages to rtk2go in the same second.
That is why rtk2go tells you that it received a message on one side but when counting the total number of messages it tells you that it is double.
I don't know why Facet is sending duplicate messages if it has the default rate configured.
But with the previous image I am calm that they were not my imagination.
We must make the Facet resend the corrections correctly according to the values that one puts in the configuration.
We are using twice as much data via Wi-Fi to send them and if the connection is via 3G and with a poor signal, it becomes a problem for latency.

[amlago]

[nseidle]

Sorry for the delay! Ok, I think we got this fixed.

Below is output using v3.3 firmware. You can see the RTCM 1230 is reporting every 5 seconds (incorrect):

v3.4 May 25 is below with 10s between 1230 messages:

Reason: We recently enabled the NAV2 global feature by default, even if there were no NAV2 messages enabled. (NAV2 messages are receiver output without high-precision corrections applied. This is good for recording raw, uncorrected, data for post analysis). The NAV2 global feature causes the RTCM to be generated twice, effectively causing the RTCM to be generated twice as fast. Now, if no NAV2 messages are enabled, NAV2 is turned off, and RTCM behaves as we expect.

Below is the base transmitting to RTK2Go at the expected 1/1/1/1/10 rates.