I’m developing an RTK-based vehicle datalogger based on Waveshare LG290P with an ESP32-S3 microprocessor for motorsports applications (autocross and road racing). I built a matching base station using another Waveshare LG290P as few of our sites have NTRIP casters available. The biggest test I’ve done so far was in the east parking lot of Bristol Motor Speedway, in Bristol, Tennessee, USA, which is a large parking lot in a valley with a large steel stadium to the west and a large wooded hill to the north-east. I had poor performance with the ceramic patch antenna Waveshare shipped with the LG290P, and used their Q36 helical for these tests.
While general RTK-Fixed precision was excellent (average 1.6mm stationary and average 1.9cm @ 20Hz while moving), I experienced a high number of events that caused the rover to drop momentarily to RTK-Float, several of which just went wildly off multiple meters in a random direction for a few seconds, then suddenly snapped back when RTK-Fixed resumed. My logs confirmed my suspicion: Terrain was occluding satellite signals, but the LG290P took several seconds to reject the resultant multipath reflection. I also had a number of events at the bottom and top of a steep portion of the course where the pitch of the car changed. Here is an example video of one of the runs: https://www.youtube.com/watch?v=8PVJdLycLGo
This is an aggregated skyplot of the satellites in view during each of the events where LG290P dropped from RTK Fixed to Float. The blue dots experienced a large sudden dB drop. The green stayed strong. The size of the circle represents the number of times each satellite is in the log.
I was on v1.04 of the firmware for these tests, and have since upgraded to 2.01, but didn’t see anything in the documentation about improvements to dynamic occultation / multipath rejection. I tried adjusting the elevation mask to 30 degrees and C/N0 mask to 30dB, but that resulted in a huge degradation in quality. Is there anything I can do to help improve the LG290P RTK Fixed quality through events like these? Is this something you’re working on improving in the firmware for future releases? Thank you!
Hi @RCX_Engineering,
It would be great if you can provide HDOP value from GGA messages. The cause of the problem cloud be the fast change of direction of antenna and the result of that should be seen in change of HDOP value. The solution for lessening the effect could be placing antenna on the roof of the car.
The latest FW is V2.02 I could provide it to you if you are interested.
Best Regards
Hi Dobrica, we also discussed here this issue; but I remember that with old 04_beta fw the algo was more responsive ( Kalman filter ?)…
in switching from rtk to has_ppp instantly by assigning an age of 1 or 2 to rtk.
Regards
Here’s some additional analysis, this is a map overlay of 10 runs over two days generated from 20Hz GPS logs (Six runs in one direction, four in the other, with some course changes between days) with the events shown and vectors indicating the azimuth direction of the satellite that experienced a large dB drop. Most (but not all) of the vectors are consistent with a line-of-sight blockage.
This car doesn’t have a roof - I do the next best thing, which is placing the antenna on the trunk in the center of the car behind the driver. The roll hoops, windshield, and driver provide some dynamic blockages. This likely contributes to some of the issues as well, and was my first thought for the loss incidents driving up the hill. However, the top of the hill should reduce the blockages, not cause more; I’m at a bit of a loss to explain those. Unless it’s simply a coincidence and the speedway is the actual blockage.
Module can do till 10Hz in rtk, so I do not understand your graph…
However can U do a test with the new fw by setting $PQTMCFGNAVMODE,W,5*62 aka Dynamic mode
or the $PQTMCFGNAVMODE,W,0*67 for driving scenario, istead of the 11 (lawn mover)?
I didn’t record GGA HDOP values so I don’t know precisely what was being used for the solution, but I was able to estimate HDOP from my satellite logs. I’ve plotted them here for pre/post-event.
And yes, I am getting 20Hz (50ms) RTK positioning data at very high precision when I have a clear view of the sky, which I understand is the maximum rate possible for LG290P. Most of my runs converge very closely in the places I would have been driving very precisely (all runs within 20-30cm of the same point) so the average 1.9cm precision in my logs during the majority of the run where I was RTK fixed is not unrealistic as actual on-course precision. That runs taken a day later align so closely is a positive indication as well.
I was using v1.04 firmware during this test, before PQTMCFGNAVMODE was available for LG290P. I updated to v2.01 afterwards, but didn’t know PQTMCFGNAVMODE existed and have not changed it from default. I can’t find any documentation on it aside from that it was added in v1.06. Where can I find more info on it?
Dobrica: I analyzed precision through turns and did not see any statistically significant difference in precision with respect to g-loading in turns. Very similar plot if I analyze by yaw rate.
If this route is drawn just from fixed position, it seems the jumps are related to horizon line change, and it even tracks with the sky view you have sent. Is there something blocking the sky on north-east side. For the next time you are doing testing, such drop in sky geometry should be seen in HDOP value. You can also check if the problem is related to RTK correction injection rate by looking differential age value in GGA, but I doubt that could be the problem.
I am sending you the latest FW to your mail, please check if you have received it.
RTK correction age was good - my base broadcasts at 1Hz and latency through Centipede was low. (Yes, I ran Centipede in the US for that test!) There is a wooded mountain to the north-east. I posted a short video of one of my runs in the OP where you can see the giant speedway to the west and mountain to the northeast. Plus some additional fences and trees in various places.
I have an event tonight at a 1/4mi oval track which will be interesting since it’s ringed with a giant chain metal catch fence that is both a blockage and an RF mirror. I’ve tightened the elevation and C/N0 gates to try to compensate but may be trial/error to get the tradeoff right. My hope is that a future firmware update is able to recognize and adjust faster for these sorts or issues. If not, I’ll probably end up experimenting with my own deviation detection with IMU fallover processing on the ESP32 before I send the (processesed) position data to my data logger.
I receiver your email, thank you! (It had been sent to my spam folder, so thank you for letting me know.) I did not have time to update and test prior to last night’s event so I was still using v2.1 (LG290P03AANR02A01S), but I had implemented elevation and C/N0 gating, and was overall very happy with performance. Quality and reliability were much higher than at Bristol, and blockages/multipath did not cause any large obvious divergences. I’ve attached an analysis here. I was concerned that the tall chain-link catch fence surrounding the track would function as an RF mirror, but it was lossy enough at these wavelengths to only attenuate the signals, not block them. The presence of trees and other structures likely contributed to some of these issues as well.
The biggest issue I had were GSV bursts lasting about 30ms resulting in apparent corruption of speed and heading information. Which caused the datalogger software I stream this GNSS information to rejected those frames entirely. Unfortunately, this impacted 25-30% of every run.. Thus, the raw data saved to my SD card looks fantastic, but the data on my tablet looks ugly.
Hi @sjfehr , the 2.3.64. PQTMCFGNAVMODE works even on the 2.01 fw, so use it for change the default (11)…
$PQTMCFGNAVMODE,W,5*62
$PQTMCFGNAVMODE,W,0*67
let us know…
I was, indeed, in lawnmower mode! It’s fixed now, and I’m in Mode 0, which should be appropriate for an automotive datalogger. Thank you for the tip!
And thank you again for the email, Dobrica, I’m rocking v2.02 now as well! And I have added 20Hz GSA to my logging so I should have better diagnostic data if the previous issues persist.
I also discovered a few other issues in my ESP32 firmware I’m trying to sort out, the biggest of which is that I was losing about 40% of the speed and heading updates, which interfered with the BLE output to my tablet. Possibly a symptom of pushing the envelope at 20Hz with ESP32 processing, as I’m running right up against multiple bottlenecks with very little overehead. It’s working, but it’s tight, especially the epochs with GSV messages (which take 66% of a 50ms epoch to transmit over UART). Consequently, this has forced the rest of the code to be very tight. I’ve already done a lot of balancing to be able to also process IMU & CAN data, log everything to SD, and run an active webserver to interface with the ESP32 & download from the SD card. None of which is an LG290P issue, but still related.
Yea, consider to use a ttl to eth converter…
Regards
I wanted to confirm that my issue has been fixed: The new firmware, switch to automobile mode, and setting tighter elevation and C/N0 gates addressed the vast majority of issues. The sites I’ve been autocrossing at have been more favorable to RTK GNSS, but performance has been great, about 1.5cm mean hacc on-course. I’m definitely pushing the limits of my hardware at 20Hz, though.
Thanks for the help!
