Im getting a 3D dgps fix on both GPS units, but no RTK fix. In CAN inspector i see moving baseline messages being sent from one of the GPS units.
Went through both gps units in U-center also, but cant find anything wrong according to other posts iāve found. RTCMv3 messages are being sent but somehow ignored by the second gps?
Pretty sure the problem is some parameter if anyone would care to take a look. Ship.param (14.8 KB)
I wonder if youāre sure the GPS_POS1_Y and GPS_POS2_Y are correct for each GPS. Thereās no chance that theyāre swapped? Itās possible to check by just disconnecting one and make sure that on the HUD the expected GPS changes to āNo Dataā.
Also thereās no chance that youāve updated the firmware on the Here4? The Here4 ships with a custom firmware and if itās overwritten with the normal UBlox firmware the GPS-for-yaw wonāt work I think.
We see this all too often - folks think that just because they have some degree of reception indoors that they should be able to test advanced/precision features. That is simply not true.
Your parameters look correct, and even a reversal of the GPS_POS*_Y params would only cause an orientation error, not a complete failure of heading computation.
yes the GPS_POS1 and 2 are correct, even tried swapping them with no difference in results. ALso the GPS_MB1_OFS_Y is set to have distance between the master and slave units correct.
Firmware from factory was 1.3.something. Updated both modules manually (.bin file) to:
Also tried the latest 1.13. with the same bad results.
Firmwares from: Releases Ā· CubePilot/GNSSPeriph-release Ā· GitHub
Maybe the firmwares are not right? But in changelog it is written that 1.12 adds support for moving baseline.
@Yuri_Rage tested in the middle of a field with no high mountains around. Left outside for 1h+ with both modules getting ā3D dgpsā fixes with 25+ sats each.
Should anything be changed in U-center or should it work right out of the box?
Moving baseline is still a work in progress for the Here 4 receiver (and really all DroneCAN GNSS receivers). It requires a firmware update to the u-blox chipset that must be completed by a CubePilot reseller and it this PR to be merged into ArduPilot.
That explains a lot. I recently got quite mistakenly frustrated attempting to get moving baseline working on Here3+ (not a supported feature of the M8 module). However, this userās frustration would be well placed!
Was Here4 maybe a bit early to market? Moving baseline seems a basic feature for it to be missingā¦
Not early. The Here 4 was never intended to have moving baseline as a feature. MB was not supported in the version of the F9 chipset that was selected when the Here4 was designed. It is only a recent firmware update from u-blox that has made it possible.
I would like to point out here that the firmware update from ublox website will not help. The latest public firmware from ublox for Neo F9P does not support Moving Baseline. The ublox firmware with moving baseline has been specifically developed for use with Here4, and not publicly available. Only recently shipped Here4 units will come with Moving Baseline support, please contact your reseller to confirm the units have Moving Baseline support or not. Updating your units that support Moving baseline with publicly available firmware, the moving baseline support will not be available.
To check if your unit supports Moving baseline or not one can simply verify the Ublox Firmware version hash. It should look something like this: u-blox 1 HW: 00190000 SW: EXT CORE 1.00 (49f616) 49f616 is the firmware hash that supports Moving Baseline.
This is printed by Here4 units few seconds after boot, so you may need to reboot the unit from DroneCAN/UAVCAN panel in Mission Planner or if using DroneCAN GUI Tool enable the Log message view and then reboot the Here4 module.
As @CraigElder correctly mentioned, Here4 was never intended to have this feature to begin with. This is something that we are offering as an add-on with newer units. Also it does require some modifications to ardupilot code to work and firmware higher than 1.13 Releases Ā· CubePilot/GNSSPeriph-release Ā· GitHub
Understood and thank you for clarifying all. I think many of us may have mistakenly expected moving baseline as a core feature of any unit using an F9 module. I also understand that the first two letters of a uBlox product number arenāt the whole story regarding the supported feature set.
That explains a lot. Thank you so much for clarifying @CraigElder. I was under the impression that moving baseline is working as the here 4 manual has the reference layout on the bottom of the page.
Also on GPS/Compass (landing page) ā Plane documentation the Here4 is under āmoving baselineā gpsās.
Any ETA of when the supporting firmware and ardupilot code changes will be made available?
@Yuri_Rage any reccomendations on confirmed working Moving baseline units? @bugobliterator are there any ardupilot builds available to test this with 1.13 firmwares (you mentioned some code changes needed)? @CraigElder why is the firmware file that comes on the Here4 originally not available to the public?
I have to add a sad fact to this. If somebody updates the Ublox firmware
(letās say he had a couple of Here4s from the first batch and got the instructions from HEX to do it, and later, nobody notified him to donāt do it with new purchases)
It not only loses the Moving Baseline function but renders the module useless since the 1.13 fw tries to configure PPS and fails.
Update: It is worst, even units with HEX firmware show this error. 4 from a batch of 10+ā¦
Anything using Zed-F9P or UM982 modules should work.
A word of caution if you land on ArduSimpleās website: donāt bother with the kit labeled ā+heading.ā Just get two SimpleRTK2B boards instead.
Both Holybro and CUAV make products that are more polished than simple breakout boards if thatās your desire.
Gotta say Iām a bit disappointed in the Here4. Between the firmware oddities and its use of the lesser Neo chip, it just doesnāt live up to the hype as far as Iām concerned. I understand that it met its design intent and likely nailed a price point target, but Iād have gladly paid a few more pennies for a Zed-F9P module with all the bells and whistles offered by the onboard periph firmware, and I suspect this wonāt be the last thread where someone expresses frustration over an expectation for moving baseline that may not be met.
Thanks, @Yuri_Rage, iāve returned the here4s and got the C-RTK2 HP, and am happy to confirm it works out of the box. When it gets gps fix, the yaw jumps straight to the correct heading.
But now am having problems with using the C-RTK2 HP as a rover base station for a Quadplane. The quadplane (with Here3+) isnāt getting an RTK fix. Any way to see the RTCMv3 packets and where they stop? (Maybe i should make another topic to not hijack this one)
