Is it a massive downgrade to use RTCM3 from LG290p rover for rtklib?

I’m at a stage that I can use either the hardware or the rtklib software for it. However rtklib would basically need both rover and base modules to be on some kind on base mode and send only RTCM3 messages every 1 second; unless I miss something and it’s possible to go above 1Hz; the reason I consider rtklib is that it’s a fully software solution and I have already setup tools for it from an old module pair I was using and it’s also convenient to have RTCM3 for post processing (unless I should just make the Rover record RTCM3 messages in a log).

Forgive me if I misunderstand, but why would a Rover need to send RTCM3 messages? My understanding, and how I use it is that the Base station (typically fixed), sends RTCM3 correction messages TO the Rover, which then uses the correction data to get centimeter level accuracy on it’s position.

The way I use MY setup for surveying is my Rover is connected to the SW Maps app and allows me to mark and measure points, etc. It gets it’s RTK correction via the Internet, either from a public CORS base station, or from my own personal RTK Base station (running RTKBase), both via NTRIP protocol. RTKBase uses rtklib for it’s base station function, but I’m not familiar with rtklib to know if it has similar tools and functions to the SW Map app for mapping, measuring, etc.

That idea there was for using rtklib for doing rtk (the module only sending satellite data and not doing rtk).

A problem with the hardware solution is that it’s hard to do post-processing because QNSS is limited.

I consider using the rover for hardware rtk AND saving and rtcm log if possible.

Hi Epigramx,

Did you set LG290P to output NMEA and RTCM at the same time?
If you want to separate NEMA and RTCM message, you need to operate on your end(maybe on your MCU). You can separate the protocol according data stream.
For example, NMEA starts with 0x24 and ends with “Carriage Return” and “Line Feed”. RTCM starts with 0xD3 0x00.

Best regards.

1 Like

Thanks; yeah I figured it’s slightly complex; because RTCMs don’t have an end but only a beginning and the NMEAs are often spliced together one after the other. For the time being I’ve made solution that detects them sort-of one-by-one and it seems to work; I wonder if there’s a complete solution that does it efficiently or at least a schematic for an algorithm because it’s unclear if there are certain conventions followed by the hardware that make it easier; I noticed there are a few general libraries around for the purpose but none that seem straightforward for the purpose but at least I have it working already for the purpose (albeit unclear if it’s bug free).

I think a useful way to use the hardware is to have it do rtk “live” but at the same time save the RTCMs; I hope it’s not congested at output; but those 460800 bps sound a lot so I doubt it would be congested at the interface level.