Simple Base/Rover with (2) PostCards using ESP-NOW

[rftop]

I assumed this would be a fairly quick exercise => to establish a Base/Rover Combo with ESP-NOW.

I started with making sure both LG290P’s were upgraded to LG290P03AANR02A01S.pkg
I upgraded both postcards to RTK_Everywhere_Firmware_v3_3.bin
I turned both ESP-NOW radios ON in the FW and paired them.
On the Base, I selected the Low Bandwidth RTCM defaults.

I want to use Static Base coordinates, instead of Survey-in, so I cheated with PointPerfect Flex RTCM corrections to establish the position of the Base’s Antenna.
The Point Perfect Lat/Long/HAE was entered in the Base Config as a Static Base Location.

The Base was started and it is successfully sending RTCM over ESP-NOW to the Rover PostCard… just like I would expect. The Rover entered RTK Fixed mode

Note: I set the Antenna Height (Menu: Base) to 0mm and the APC to 0mm, because I wanted to place the Rover’s antenna next to the base to confirm elevations.
The Rover reports ~1.8m Lower than the Base Antenna, when they are side-by-side essentially touching.

A few more Details: The original Base Location was quickly determined in SW Maps with PointPerfect Flex RTCM corrections. I used the “Elevation” Field in SW Maps, as this is the HAE. I connect to the GNSS device with a 0.0m Instrument Height in SW Maps, for this test.
Same situation with the Rover, connect via SW Maps with a 0.0m Instrument Height. I’m interested in the Antennas, not a mark underneath at the ground.

I would expect the Rover to report the same elevation that the Base is referencing for it’s RTCM Observation output, but the Rover elevations are ~1.8m Lower.
Static Base Antenna = 91.8m (entered as Fixed/Static Position in Base Setup)
Rover Antenna = 89.9m

Assuming I did something silly, I moved the Base Location and started over (since this only takes a minute or so) paying close attention, and will note the elevation to the mm for the 2’nd Base Location below.
New Base Elevation = 94.251m
Rover Elevation = 92.414m
ΔZ = 1.837m

Any ideas what I’m doing wrong in my simple exercise ?

Could there be some artifact related to the Torch Rod Height that’s getting scrambled into the mix somehow in RTK Everywhere ? 1.8m feels awfully familiar, and so does 37 mm.

Thanks in Advance !
Ryan

[rftop]

I may have stumbled onto something.

On a different PostCard (virgin), I looked at the defaults :

Even though I changed these to 0’s for my Fixed Base Position, the FSM doesn’t use them.

I asked ChatGPT to take a look at the Repo with this in mind, and he says:

[amlago]

Hi @rftop
In the Postcard settings there is a section to configure the pole height and it defaults to 1.80 m

[amlago]

Ha ha, while I was using my translator you found what I was trying to tell you

I use cane height = 0 in the postcard and enter the cane heights in the data collection program.

[rftop]

@amlago

In the Postcard settings there is a section to configure the pole height

Where ? You might be thinking about the torch?

[rftop]

ChatGPT thinks it found the reason…

Specific suspected issue:

In GNSS_LG290P.ino fixedBaseStart(), if gnssInBaseFixedMode() returns true, the function exits before recomputing totalFixedAltitude and before calling setSurveyFixedMode().

So “already in fixed base mode” may skip reapplying updated fixedAltitude / antennaHeight_mm / antennaPhaseCenter_mm settings.

My measured offset is 1.837 m, which matches 1800 mm + 37.5 mm exactly…which is pretty wild.

[amlago]

The Wi-Fi configuration looks great.

[rftop]

I haven’t used WiFi Config in so long I’ve forgotten about it. Thanks @amlago !

But that’s going to give me the same results as the Serial Menu does, since my 0m Rod Height and 0m APC were indeed saved and remembered in the Serial Base Menu…but the FSM apparently doesn’t use those in Base Mode, Fixed Position, Geodetic System.

Here’s a screenshot where I just Serial connected over a Bluetooth Terminal into the Base while it’s operating outside.

The BASE PostCard remembered the 0mm Antenna Height and 0.0mm APC, it just not using those when it computes the ECEF coordinates for the Base Position (apparently, still a guess).

I know I can get the ECEF coordinates and make this work, but I’m attempting to prove how easy this can be. Not going so well at the moment

My assumption is there might be folks getting bogus elevations and don’t recognize it. That appears easy to do from my quick little experiment.

[rftop]

@amlago, I wanted to check the WiFi config as you suggested.

I realized that I don’t know how to get the PostCard into AP mode to perform the WiFi Config, without a Portability Shield. I don’t think we can ?

So 30 minutes later gathering up all my soldering widgets…I have a portability shield installed on the PostCard Rover.

I can now confirm the Rover doesn’t think it is sitting on a 1.8m Rod.
This was the default, no changes by me on the Rover :

It’s weird that Instrument Setup isn’t available on the Serial Config (that I can find anyway).

I thought I knew a lot about the PostCard, but apparently not. LoL.

[rftop]

OK… this is NUTS.
After doing the above (wifi config) only on the Rover, the ROVER is now giving me the correct elevation at the base antenna (within 2mm).

I haven’t touched the base this evening, he’s been out there doing his thing all day.

Base Elevation = 94.251m
Rover’* Elevation= 94.253m
'* = with Shield & after wifi config but no changes to instrument setup.

You fixed it @amlago, but I can’t explain it.

[rftop]

Now it’s time to reproduce the issue, considering it might be the Rover and not the Base.

I removed the Portability Shield from the Rover PostCard
I reflashed V3.3 RTK Everywhere FW to the Rover PostCard

I rebooted the Rover and it was still paired with the Base’s ESP-NOW radio. Quickly reached RTK Fixed solution with the correct Elevation.

So I reset all settings to defaults in an attempt to reproduce the problem.

Rebooted Rover, and now it’s using HAS corrections instead of the BASE PostCard. Makes sense because the ESP-NOW radios are no longer paired.

Told Base to request Pairing.
Turned Rover’s Radio ON, and requested Pairing.
Quickly Paired the Set.

Rover reports correct elevation to the exact mm.

I can’t reproduce the problem, so I feel like a complete idiot
I guess we can delete this thread…

[PaulZC]

Hi Ryan (@rftop ),

I’m not sure if the following will help, or just pour fuel on the glowing embers of this thread…!?

I ran into the same or a similar issue when I was adding the Base Assist mode (option “A” in the System Menu). This is a feature Doug asked for: switch to Fixed Base mode using whatever the GNSS coordinates (Rover or Temporary Base) are right now.

I had to be careful to ensure the combined pole length was dealt with correctly when switching from Rover to Base. If you want to point AI at the relevant piece of code, it is here. If you are using Geodetic coordinates, the combined antennaHeight_mm + antennaPhaseCenter_mm is subtracted before being written to the settings fixedAltitude. (If you are using ECEF, that doesn’t happen.) Then when Fixed Base starts, the combined pole length is added back on again so that Base uses the antenna coordinates, not the pole tip coordinates. Where that happens depends on the GNSS; for Postcard (LG290P) it happens here.

Yes, correct, if you are already in Fixed Base mode and gnssInBaseFixedMode() is true, setSurveyFixedMode is skipped. It appears we only perform that check on LG290P and UM980, not on mosaic or ZED. I am not completely sure why that check is there. Perhaps those GNSS don’t like to restart Fixed Base when already in Fixed Base? I’m not sure… I would have to dig into the history, perform tests and talk to Nathan to understand why.

Clearing the settings puts the firmware back into Rover mode and ensures that the GNSS is fully (re)configured from scratch. Maybe that explains why the issue appeared, then went away?

Anyway, cutting a long story short, the following should always work: reset the settings; in Rover mode, set the antennaHeight_mm and antennaPhaseCenter_mm to zero; set your fixed coordinates by whatever method you choose; then go into Fixed Base mode.

As always, if you think we’ve missed something or that something isn’t right, please tell us here and/or open an issue on GitHub. We truly value the feedback.

Best wishes,
Paul

[rftop]

Thanks for the reply @PaulZC.

@PaulZC

the following should always work: reset the settings; in Rover mode, set the antennaHeight_mm and antennaPhaseCenter_mm to zero;

How exactly should I do that in the field? It’s my understanding the only place those 2 variables are exposed to the user (Serial) is under the Base Menu, after changing to Fixed and Geodetic.

We really don’t want the FSM to have the ability to insert 1.8375m of vertical error behind the curtains without the user knowing or agreeing. That’s the same problem that is typical with Tilt Mode.

---

Do you think there is any possibility that this combination (PostCard & fixed Geodetic) got “back on track” simply when the MicroSD card was added (portability shield) to the Rover, because that was my experience ?

Once the Rover PostCard had a SD Card to write the settings file (and subsequent read), everything was fine. I don’t think this is caused by the Rover, but IDK what happened since I can’t reproduce it.

The goal is to write a How-To Guide from a user’s perspective. The recent HAS/E6 testing on my PostCards is pointing me towards the ultimate Base/Rover combo when cellular isn’t available for NTRIP, especially with the accuracy from the mini choke ring I’m testing for Nathan. HAS/E6 and ESP-NOW make this fairly simple for beginners. Having a 20-30minute Survey-In w/ HAS/E6 at a few cm’s isn’t a bad backup option. My workflow caught the elevation error between the Base and Rover immediately during this initial exercise, but I’d love to answer how/why it happened.

From what I’m reading, this issue wouldn’t happen with a Survey-In using HAS anyway. I was starting my testing using PP Flex as a shortcut since I knew I could trust the initial base position. It appears Base Assist Mode would have been a better choice when starting with a PP base position. It’s hard to keep up with the new features added to the RTK Everywhere FW (great work BTW)

One more quick question…is there a way to reflash a PostCard to get it back to a completely virgin state? It seems that flashing the RTK Everywhere bin file doesn’t completely do that. I can’t swear that this particular PostCard Rover hadn’t been previously abused during other testing with QGNSS, etc. This is going to bug me if I can’t reproduce the issue.

Thanks again Paul,
Ryan

[PaulZC]

Just a very quick reply on the virgin state:

A shield-less Postcard stores the settings in its internal flash memory. It should be as reliable as SD but: SD takes preference (if available), and we have seen occasional flash corruptions the cause of which aren’t clear. Lee is busy adding extra code to detect this and only load the settings if the whole file is valid.

The RTK_Firmware_Uploader has an “Extras” option to completely erase the flash memory, ensuring all the settings and profiles are erased. There is also an option in the firmware Debug Hardware menu “h” to Erase LittleFS (“e”). “e” followed by a “r” is the nuke from orbit option.

[rftop]

@PaulZC

Debug Hardware menu “h” to Erase LittleFS (“e”). “e” followed by a “r” is the nuke from orbit option.

Perfect… I have not noticed that before. Thanks !

[amlago]

Hi @rftop and everyone else

I use the Postcard a lot in base mode, and based on my experience since the Facet era, I have a procedure I follow before switching to base mode.

1. I put the device in Rover mode. I wait for it to acquire a signal from all satellites.

2. Only when all possible satellites have been recognized do I switch to Base mode.

3. I set the pole height to 0.

4. Then I configure the pole height settings in the data controller.

I do this because I’ve had problems several times when starting in Base mode. Messages don’t start transmitting correctly, or I have problems with the Wi-Fi connection. If I follow these steps, everything always works fine.

Regards, Angel

[sparky]

@rftop- I get the feeling you are hunting down an important bug. Please continue and let us know if you find a way to reproduce. We’ll try to replicate as well.

The ‘nuke the file system’ option is fine, but I prefer the Factory Reset: 's’ystem->'r’eset->'y’es. This will erase the local settings, and any currently running profile settings on the SD card (if present), and return the unit to defaults. It will reset the GNSS to its factory defaults as well (‘nuke the file system’ won’t).

If an SD card is detected with a settings file that matches the system, the SD card wins and will overwrite the unit’s settings in NVM. I’ve had a few instances where I jammed a random SD card into a unit, the unit started acting oddly, only to realize the SD card had a pre-existing settings file from ages ago. The ‘golden SD card to program a fleet of units’ is a helpful feature, but be aware of what’s on the SD card before you use it. (But I don’t think that was your issue)

I’ve learned that chatbots speak with a voice of authority that is often misplaced. “Here is your problem” reports are helpful, but are often too convincing and often lead down the wrong bunny trail. I suspect there is a bug, but I’m not convinced we (or it) have found it.

[rftop]

For the Base, I did everything to get it back in a virgin state to reproduce the elevation issue.

I performed:
Factory Reset
Nuked the LittleFS
RTK FW Uploader => Erased Flash.
RTK FW Uploader => Flashed V3.3.bin
Power Cycled the PostCard.

After reading through this thread again, I suspect I had the Base Postcard in BASE mode when I first started the experiment (to enter my Fixed Coordinates)…since I was playing with a Base afterall.

As @amlago said, I probably should have started with the Postcard in Rover Mode to do that, which could have caused the problem.

So, with the Fresh PostCard, I confirmed it was in Rover mode before making the changes with Serial Config.

I got everything like I wanted it, paired the ESP-Now Radios, then switched to Base Mode afterwards. This worked flawlessly, no issues with Elevations. Anytime I power up the Base, it just starts working and the Rover is in RTK fixed mode quickly

I repeated the Factory Reset and performed the same setup procedure but started out with the virgin PostCard in Base Mode (expecting this to cause problems). I still cant reproduce the Elevation errors.

I’m working this poor little PostCard to death (see this post), and it’s doing an amazing job !

I think a Mod should delete this Thread to not scare away any potential Base/Rover ESP-NOW users. It works great, and I have no idea how I fouled-it-up on my first ever attempt.

I’ll start a clean thread later, without all this nonsense I created somehow

[TS-Russell]

Just FYI I unlisted it instead of deleting (it might be helpful internally to keep it searchable, maybe not) - let me know if you do in fact prefer it to be deleted and I can