I am using the sparkfun quadband lg290p module.
My intended setup involves a moving base station installed on a vessel, with multiple rover units positioned on the deck. The goal is to obtain precise relative positions of the rovers with respect to the base station, enabling accurate localization of each unit onboard the vessel. The vessel’s orientation is known through other sensors.
I configured the system to operate in relative mode, but I am unable to obtain relative position outputs from the rovers. They continue to output only standard NMEA GGA messages, which provide absolute geodetic positions.
Could you please clarify the following:
Is relative mode intended to support this kind of moving-base setup?
If so, is there a way to obtain the relative position (e.g., X/Y/Z offsets) of each rover with respect to the base station?
If not, what is the purpose of relative mode in the firmware?
Are there recommended steps or additional tools required to implement such functionality using those devices?
You ask great questions but I haven’t used the LG290P in a moving base setup. I recommend asking on the Quectel forum, and then, if you have the time, please let us know what you learned so we can educate others.
The typical Moving Base setup involves a Dual Antenna Receiver, such as the LG580P.
An ad-hoc Moving Base System with multiple receivers could be created where a single receiver is established as the Base sending observations/corrections to the rovers.
A least-squares adjustment could be applied (by the User) to the Physical Network and then calculate the vehicle’s orientation using the known geometry. That wouldn’t be a simple task on a dynamic platform, but not impossible.
Normally, the heading is the main focus for a typical Dual Antenna Moving Base.
Note: I’ve always wondered why a Dual Antenna Moving Base setup didn’t involve the known baseline length in the calculations. Seems like a great opportunity to reduce the size of each epoch’s “sphere of uncertainty” on both ends, by inserting a known baseline length in the Matrix.
For what little I know quectel has implemented the moving base on a pair of LC29HEA or LG69TAM & LG69TAP with restricted Yaw function…and function supports little baseline lengths.
As Ryan mention for the LG580P, the PQTMTAR Message has the possibility to read the relative baseline but I don’t think it can be implemented on a complex situation like yours,module has heading algorithm solution but none mention of a moving base setup.
Ask for “Quectel_LG580P(03)_Dual-Antenna_Heading_Application_Note”
Would certainly agree, knowing the anticipated baseline length would be helpful, many are rigidly fixed. Things like plane wings can deform in flight, port and starboard on a ship above the bridge, probably less so.
I’ve read the post a few more times and have some thoughts, questions, and assumptions.
The first assumption is you won’t have access to any correction source for the Base.
So the Base never has any assumed coordinates for it’s RTCM output to Rovers.
MSM basically tells a Rover that the Base (with X,Y,Z coordinates) observed these signals from those satellites at that time… and the Rover uses that to “compare notes”, so to speak.
Let’s pretend you installed a Fixed Network of GNSS Receivers on the vessel, one at all 4 corners and one right in the center, operating at 1Hz for discussion purposes (these are not Rovers). We will have pre-determined the location of these 5 Fixed receivers on the Ship and the real-time Pitch/Roll/Yaw are known from other sensors as the post mentions.
Having 5 Autonomous GNSS positions (consider these accurate to 1-2 meters) each second and knowing the three fundamental rotational motions from the ship’s sensors, we can perform a least squares adjustment of the survey network (5 Fixed Receivers). The “network adjusted” position of the Fixed receiver in the center of the ship is now provided to it each second and is used as the “known” position for the Central Base Station, each epoch. Now you have a Base with updated/known coordinates to benefit an unlimited number of Rovers.
I “think” a good bit of environmental errors would be canceled due to each device experiencing similar conditions, but we are introducing a timing issue since the updated base position isn’t known when the RTCM observations would normally be delivered to the Rovers. That’s a @clive1 question for sure
Maybe that’s the same/similar as latency and the rover’s handle it with the MSM timestamps ?
From what I understand, the LG290P does not support this functionality. However, this raises a question: what exactly is the purpose of the “relative mode”? Relative to what, if not the base station? And if it is relative to the base, why am I still receiving geodetic coordinates? That doesn’t quite make sense.
In any case, we’ve decided to move forward with the ZED-F9P module, which does support a moving baseline mode and has a well-documented setup process.
In any case, we’ve decided to move forward with the ZED-F9P module, which does support a moving baseline mode and has a well-documented setup process.
I think the industry term “Moving Base” is much less sophisticated than your expectations.
[I was disappointed when I first started researching the technique for actual field use]
One typical use-case is dual antennas on a fixed wing UAV to provide heading info that’s more accurate than an electronic compass or the vector from the previous epoch. The Base receives external RTCM over MavLINK, etc, and it provides observations (RTCM) to the Rover for an accurate Heading, relative to the 2 antennas. This works extremely well.
It is my guess that if your Base is not able to receive an external correction source, so it will operate autonomously, and it’s rovers can’t enter Fixed Mode. My assumption is this vessel will be in the middle of the ocean with no available correction source. Without receiving corrections, the base has a standard 3D Fix position accuracy (even the F9P). That’s the reason I mentioned the network adjustment for the Ship’s (5) Control Points, providing a real-time position for it’s 1 Base.
I don’t think you will see much improvement in the Rover’s positioning verses having them operate as stand alone units in this scenario. I hope I’m wrong and I’m looking forward to learning about your final solution. It’s a very interesting application.
