I have a rover set-up with the following:
• Postcard + Portability Shield + Battery.
• Cell phone to relay RTK Point Perfect correction to SW maps for recording data.
• Postcard set for 10 Hz data collection and Bluetooth as primary for RTK.
I walked the track recording discrete data points (RTK fix was stable) using SW Maps “record feature”.
When the rover follows the track (0-50 mph) it loses the RTK fix (displays float) and the position data loses accuracy using SW Maps “record track”.
Are there other Postcard settings that will enable a more stable RTK correction at speed?
Is there a different hardware set-up that I should consider?
I’m guessing your problem is related to pushing the NMEA messages over Bluetooth at 10Hz.
It’s possible you were dropping RTCM occasionally, but it didn’t really matter at walking speed ?
I’ve never had trouble at 85 MPH using the NTRIP Client in SW Maps to get the Point Perfect RTCM corrections for a PostCard operating at 1 Hz over BLE.
I would turn OFF all NMEA messages that not required for your application. Each one matters.
You could start with GGA and RMC only, at slower rates. Once it’s stable, increase towards 10Hz.
I disabled all NMEA messaging except GGA and RMC and it didn’t seem to make a difference.
The RTK fix becomes float when I move the rover around rapidly (hand movement back/forth will trigger this). SW Maps shows no change in satellites (when all NMEA messaging was active) when the transition occurs. RTK returns to fix when the rover movement stops or is slow.
My use case requires RTK fix during acceleration of the rover.
Still looking for other suggestions.
I’m using a GNSS Multi-Band L1/L2/L5 Helical Antenna (SMA) that is screwed directly onto the Postcard.
The satellites acquired quantity doesn’t change when RTK switches from fix to float.
I’m using Bluetooth to connect my cell phone to the Postcard (and provide RTK corrections via NTRIP) and wondering if the data transfer rate isn’t fast enough to correct for the rapidly changing position of the Postcard.
What’s the baseline length ?
What correction service are you using?
What is the typical “corrections age” that SW Maps is reporting during the drop to Float ?
I’m thinking about Doppler Shift…
“IF” you are operating with a long baseline, the rapid movement could cause a cycle slip (verses a shorter baseline)… which would immediately drop to Float. That’s just a guess.
The PostCard can do it, with a good view of the sky and appropriate correction source.
@Jeff_G , I took a PostCard outside this morning to take a video of it staying in RTK Fixed mode while moving aggressivly. Problem is…it dropped to Float as you described.
Previously, I’ve had no problems using the Postcard in dynamic situations (85 MPH with no issues).
Hi everyone.
I’ve also experienced transitions to Float mode when the Postcard with the helical antenna moves quickly. When it slows down or stops, the Fix mode returns almost instantly if there’s good visibility.
I had the chance to test the LG290P on my car these days… I pushed it up to 170 km/h (105 mph) on the highways (hopefully they won’t revoke my license). I noticed that the HAS correction easily reverted from float to DGPS when I drove under viaducts (worse if I went through tunnels, of course), but the standard RTK wasn’t affected at all… On the way home, however, I noticed that on the stretch I drove at 110 km/h, the HAS correction maintained the float without degenerating. I saved the 10Hz traces, which I’ll analyze in the coming days.
Hey everyone.
I’ve noticed that high speed doesn’t seem to affect RTK if it remains constant.
I lose fix and switch to float with sudden accelerations or very rapid changes in position.
I initially thought it was speed, but change in acceleration (jerk) appears to be the root of the problem.
U-blox replied with: This behaviour is most likely due to a latency in the correction data, especially because of using Bluetooth. As PointPerfect Flex works with both u-blox and third-party receivers, the service itself is not limiting your setup.We recommend reaching out to Sparkfun for any hardware related queries.
Anyone have a way to make the correction data feed more robust to jerk?
