I was told the following “NMEA output is disabled on this configuration file, for this reason you don’t see anything when uploading the file. You can just go to your wished message in u-center, “right click”, enable.”
Can anyone help me figure out where in the u-center do I go to enable it? I’ve been trying since the morning and I just can’t seem to figure it out
Thanks
This is normal, messages outputting fix information are disabled on the moving base (simpleRTK2Blite). You can enable any by pressing right click enable message.
Thank you and sorry, this leads me to more questions then.
So if NMEA is disabled on SimpleRTK2lite, is it still sending GPS information via UART 1 about itself to the other SimpleRTK2Budget board?
And also then, do we only need to connect SimpleRTK2Budget to Pixhawk orange cube and will it send both GPS data and GPS yaw information?
I saw some videos on YouTube where both GPS are connected, any benefit or harm there?
>>I saw some videos on YouTube where both GPS are connected, any benefit or harm there?
One is solving for position of Antenna A, the other is computing the spacial geometry of Antenna B vs Antenna A, ie “Attitude Determination”
Whilst depending on the ZED models involved, you can get a position for Antenna B, it is a somewhat “second hand” value, people interested in accuracy and precision, would really typically want the “first hand” position computed against the fixed/known base station.
I’d recommend a review and understanding of the Moving Base concept so you might better understand the mechanics here.
https://www.u-blox.com/en/docs/UBX-19009093
After reading the section on moving base, page 11 (2.2.1) I got confused with the following line. “No other protocols other than RTCM are enabled by default on UART2. No RTCM messages are enabled by default to be output on UART2.”
So only RTCM protocol is enabled by default on UART2. But then no RTCM messages are enabled for output on UART2? What does that really mean? Protocol is enabled (which is needed for information to go out via UART2), but then messages are not enabled (so how does the information generate that can go out via UART 2)?
And if NMEA messages are disabled on the Moving Base. UART1 is still to UBX+NMEA+RTCM3. So if NMEA message are disabled, how does Rover GPS get the position of the moving base to determine the heading?
I apologize if these are very simple or nonsense questions to anyone, but I’m just trying to get a thorough understanding of what’s being communicated between the GPS.
It means the default configuration is to be a ROVER, and be listening for RTCM3 data.
UART2 was originally envisioned as connected to a radio subsystem, where as UART1 was the primary output for position to an MCU/SBC
Now the RTCM3 data can be sent via other methods, but every hop/transition adds to the latency. With a direct/radio connection on UART2 the data goes through the “least hands”
NMEA data isn’t rich with the type of information necessary for the ROVER to use to compute an RTK solution. That needs raw observation, ie carrier phase, pseudo-range, doppler, on a PER satellite basis.
FIXED BASE -> RTCM3 1077,1087,1097,1230,1005 -> MB or SIMPLE ROVER
MB -> RTCM3 1077,1087,1097,1230, 4072.0 -> ROVER
Thank you for your very detailed answer. I’ll admit this one will take a moment to sink in. But I’m still stuck on one more thing.
If NMEA data isn’t enabled in the moving base, how did its location get sent to the rover for heading calculation (UBX-NAV-RELPOSNED)? Moving Base Configuration file is sending data via UART1 (UBX-NMEA-RTCM3) to Rover’s UART 2 (which is only set to receive RTCM3).
So is the RTCM 4072 (Reference station PVT) sending the moving base’s gps location?
You’re not going to let this NMEA thing go. It’s an old maritime protocol, mostly assuming 2D motion on an ocean.
PVT – Position, Velocity and Time
The 4072.0 message provides this and more, likely also acceleration components.
It does provide for an ECEF position computed for the Moving Base unit.
The 1005 message is from a fixed location, again reporting an ECEF position.
The MSM messages ARE actually sufficient to compute a location, and certainly enough to develop a 3D line vector between to points in space. The accurate position allows for one end of the vector to be solidly anchored to a particular point in space. Consider it to be a Geometry problem.
The interfaces can be used in many ways, there’s a lot of possibilities. The Rover(s) don’t want NMEA position messages, Input in this context simply means for commands, like the $PUBX configurations ones.
In my Dual system I’ve used the full sized boards, and UART2, other solutions can do it in different ways. I’m not looking to get into the weeds about how the newer boards with switches, and the Lite form factor boards work. The concept of which RTCM3 messages go from which ZED to the other transcends that. Imagine it as a pipeline / daisy-chain of data and you’ll get less confused.
I’m not using the scripts, I read the instructions from uBlox, they give more clarity about what’s happening and the expectations.
I’ve decomposed what’s in the scripts here https://github.com/cturvey/RandomNinjaChef/tree/main/ArduSimpleScripts
Thank you so very much. I’m new to all this and just started learning a week and this definitely helps a lot. Thanks again.
Please login or Register to submit your answer
replied 1 year ago
uCenter classic, Message View, expand the tree,
Goto UBX-CFG-PRT, make sure NMEA is enabled on UART1 there, I think it is based on the review of the scripts.
Goto UBX-CFG-MSG, go into the combo-box selecting the NMEA message(s) of interest.
You can also expand the NMEA tree view, and then Right-Click on the messages, selecting Enable
Alternatively, look at what the underlying setting are for this mode, and set the NMEA messages you want to 0x01 instead of 0x00
https://github.com/cturvey/RandomNinjaChef/blob/main/ArduSimpleScripts/simpleRTK2B_FW113_HeadingKit_MovingBase_1Hz-00_gen9cfg.txt