Trouble getting clean Raw Data when using Holybro radios.

Hi, good afternoon:

Yesterday i had some issues logging Raw Data. Normally, what i do is to put the base at my roof, at know coordinates and use my rover via NTRIP. But recently, i was in a place with no cellular coverage and i had to take with me both base and rover. I set up the Base, let it Survey in, i while i was using both units At RTK mode, the base was logging raw data, but the quality of the data was awful, lots of cycle slips in Satellites with good SNR. Like i mention, o normally use the base but Via wifi, and the RAW Data it collects is good, and i can process with OPUS and with TBC.

Does anybody else have had this issue before? I want to clarify that RTK worked great, but the data that i got to correct the base could not be post processed.

Just to clarify that the Raw data that doesn’t work is the one that i collected while working with the holybro Radios. The one that i collect while i work Via NTRIP normally is with good Quality.

Hi Ingedgar ,

Can you please explain more about how you had the Holybro radios connected? Were you sending correction data from the Base to the Rover via the radios, while also logging RAWX data at the Base?

It sounds as if the Base was struggling with the GNSS signal. Did the Base antenna have a clear view of the sky? Which RTK product(s) are you using?

Thank you,

Paul

Hi Paul,

Yes, that base is a Express Unit, and is in a strategic position with a clear view of the sky. Actually today I put the base at my roof, where I normally use it, but in this case I use it radios instead of WiFi and the data was again bad, lots of cycle slips , and is the same location I always use. This doesn’t happens when is sending corrections via wifi.

The radios was connected at both units , RTK express and facet, in the corresponding slot. The settings was default. I use it with velcros as suggested in the manual.

OK - thanks!

I must admit I haven’t used the Holybro radios before. Have you checked that you have the baud rate set correctly? The Data Port and Holybro baud rates need to be the same.

I will ask Sparky if he can give you some more suggestions.

Best,

Paul

What version of firmware is on the RTK Express and RTK Facet?

The radios should be configured for 57600bps, as should the data ports on both Express and Facet: https://docs.sparkfun.com/SparkFun_RTK_ … ial-radios

As a test, you can connect both radios to your computer to confirm that serial data can pass back and forth.

Hi, sorry for the late response:

Both units are at the latest 3.6 rc, and the Zed is on the 1.32.

Ye both units are configured as suggested, like i said, RTK works well, but while the base is emitting corrrections via radios the Raw data logged in the base to post process is a lot more noisy than when is emiting correctionsvia Wifi. Take a look at the attached screenshots. i Really don’t know why when the radios are connected the raw data doesn’t return a solution when i post pocess it.

by the way, both loggins are from the same location.

Hi Ingedgar,

The Holybro could be interfering (causing interference) in the GNSS signal. The frequency band is completely different, but if the Holybro is putting out some out-of-band signal and you have the antenna close to the GNSS antenna, maybe it is enough to cause problems.

Can you try moving the Holybro further away - as far as the wires will allow - and orient the antenna away from the Facet?

You could also use a SMA RP (Reverse Polarity) cable to move the Holybro antenna much further away:

https://www.sparkfun.com/products/22037

https://www.sparkfun.com/products/22036

I hope this helps,

Paul

Hi Paul , good morning,

Thank you for your suggestions. I’m gonna try that way. Even though I mostly use it via WiFi it is useful to have it working with the radios when need it. I know I can log the same point with the unit as a Rover( before or later) , but it’s more time consuming.

Anyway let me try it , hopefully we can get it to work.

Thanks.

I’ve tried to do this (log raw data at the base and rover while RTKing with Holybros) also for about a year (May 2022-May 2023) but eventually just stopped trying. I was hoping to be able to post-process and get rover fixed solutions for short time periods when I was out of range of the Holybros, but never had any luck. I also hoped to post-process to confirm the RTK fixes. For me, the post-processing results were always very disappointing.

I never thought that the Holybros were causing interference to the GNSS signals because (a) this is the tested, documented, and supported configuration from SparkFun, and (b) the RTK fixes were very good. SparkFun sold me the Holybros and instructed me how to mount and connect them to the Facets–I certainly hope they aren’t interfering with the GNSS signal!!

I don’t understand how, if the Holybros were causing interference, the GNSS signals were good enough for the base-rover RTK to work very very well but the GNSS signal was corrupted so that the data in the log was bad. Wouldn’t interference with the GNSS signals also disrupt the RTK? I’m open to learning something here. I’ve always just assumed there was some logging bug in the RTK firmware that caused the issues I was having, given the history of logging bugs.

Many many logging improvements were implemented over that time period (thank you SparkFun!!), and the logging and data communication between the various components of the RTK products has been vastly improved in the past 15+ months. I have not had the time to try logging at the base and rover while RTKing using the newest firmware; I’ve simply found other solutions. [Because of the logging issues with the RTK products, I used multiple non-SparkFun GNSS receivers to capture raw data for baseline post-processing and OPUS solutions; and then I built least-squares-adjusted control networks with closely-spaced control points within range of my radios. As the SparkFun raw logging improved, I began to use the Facets to log raw data for baseline post-processing and OPUS solutions.]

And I’d love to be able to log raw data at the base and rover to post-process the kinematic (stop-and-go) data from a base-rover RTK session using the Holybros.