Raspberry Pi + LG290P + NTRIP in Northern Californnia question

GPS/GNSS
1

Hi - new to the community! I’m building a rover based on the following components:

  • Raspberry Pi
  • pHat + LG290P + IM19
  • Helical antenna

The Northern California environment is hilly with typical Sierra Foothills trees, but not dense forest. I’m trying to determine whether I can get an NTRIP correction feed for my area from GEODNET or Caltrans RTN.

On the software front, I’d like to run Ubuntu or Raspberry Pi OS, and I have the following questions:

  1. Which Linux OS has the best support for this hardware
  2. Can I get PPS interrupts for Linux PTP time keeping through the pHAT?
  3. The IM19 is quite an expensive option - is it “worth” it?
  4. Does the GNSS NMEA string just appear on a /dev/tty device?
  5. Any other correction providers I should look at for rural Nevada County?
  6. If I have to set up my own base station, can I use the same HW/SW with a UFO antenna?

Thanks in advance,

Jim

2

Welcome to the community Jim (@jyl087).

I believe CalTrans is restricted to Gov/Offical Use, and not available to the general public.

CTRN now requires a $100 donation. It also appears to be a single base solution with individual MountPoints (no “Auto”), so that can be frustrating.

I have not used GEODNET, but I do like how they claim to PPP verify each station prior to activating it on the network.

Take a look at the PointPerfect Flex Service offered by SparkFun. It’s the “Easy Button” for $15/month.

I have much more time with the PostCard verses a LG290P + Rpi, so I’ll let others answer those specific Linux questions :nerd_face:

Again, welcome aboard.

Ryan

3

Thanks Ryan - I missed the little note that CTRN is for official use :wink:
I guess PointPerfect is 6cm accuracy vs 2? I’ll check it out.
Best,
Jim

4

I see much tighter precisions with PointPerfect, and accuracy.

Below is a summary from a post made by @sparky that I love:
The Green Dot is the Sparkfun Base Station solution from a 24 hour mission submitted to CSRS-PPP. The orange dots are RTK solutions from PointPerfect.

image
image690×438 46.4 KB

That’s 2 independent systems and tech showing agreement in the mm’s, which is impressive.

5

Wow, good to know! Thanks for sharing!

6

Flattery will get you everywhere, including more dot plots on a Friday!

image
image789×858 30.2 KB

Above, the LG290P with a PPP/HAS converged solution. Green dot is our antenna location as reported by CSRS after a 24 hour survey exactly 30 days ago (so pretty fresh). Better than 10cm is not terrible for free/slow corrections via Galileo.

image
image785×855 25.1 KB

(Above) But as soon as I turn on PointPerfect, the accuracy gets crazy.

image
image788×853 27.4 KB

Above, zoomed in a bit. This is a stock LG290P Postcard but we are using a fancy choke ring antenna. You can expect to see close to similar results with a UFO antenna, and a little less accuracy with a helical (in my experience).

7

That’s so cool sparky. I’ll give PointPerfect a try!

8

And just to share, this is what a cycle slip looks like using HAS/E6:

image
image788×842 25.4 KB

The engine has converged on a solution, but it’s a wavelength away (~0.8m) from reality. AFAIK, there’s no mathematical way to detect when this occurs, hence, HAS/E6 should be used as a backup for terrestrial services that can prevent this.

9

That’s really practical advice!

10

A big reason why these 2 tech’s align is they are comparing “nearly” the same Reference Frame.

I say “nearly” because this is a great example of how 1 month matters in plate motion. Colorado moves about 1.5 - 2cm per year to the SouthWest, so let’s say a little less than 0.2cm per Month.

And looking at the plot, the “30-day old” PPP solution from CSRS-PPP has drifted away to the SouthWest :slight_smile:

image
image788×853 27.4 KB

In terms of accuracy, both versions can be correct but they each define a position in Time just as much as 3D space.

Gotta love Reference Frames :nerd_face: As the plot shows, they are one of the most important aspects when we start talking about true accuracy in scientific terms.

This post also shows the main benefit to a fixed-plate reference frame, because the ground is moving.

A huge metal building like the Sparkfun headquarters isn’t the best place to evaluate local plate motion (large antenna deviations with temperature changes in a metal framed structure), but the plot does agree with the regional motion. Sorry to Geek out, but I love plots/graphs :smiling_face_with_sunglasses:

11

rftop, that’s super interesting. so if you mapped an area, say with underground pipes or features you would have to re-calibrate to visible control points if you returned years in the future!

12

Jim, there are lots of ways to accomplish recovery in the future.

The simple form is to locate a few known positions in the future and look at the delta,
IE: in a few years if you stakeout a control point and your GNSS lands you 5 cm to the SouthWest, then you know how to find the remaining points.

Or you can perform a Site Calibration, where you basically tell your data collector to shift the group of points based on today’s position after you find a few control points.

You can also convert your previous points (coordinate transformation) to a different TIME, so they follow the plate motion.

Or in the future - you can simply set your reference frame in your data collector to match the frame that the RTK points were collected in.

Or sometimes its better to use a plate-fixed reference frame. In the US, that’s typically been NAD83(2010). However, NATRF(2022) is the modern replacement for NAD83 and is built around ITRF (similar to PointPerfect). By switching to ITRF, the US is finally aligning with the rest of the world. The new NATRF(2022) system has plate motion “built-in” somewhat - with a planned 5 year update schedule. It is a far superior system to NAD83.

I use all of these methods, depending on the application.

As long as you record how the RTK Points were collected (Date, Correction Source, Ref Frame, etc), they will always be useful in the future. All RTK points inherit the reference frame from the base station.

Point Perfect (PP) updates the reference frame every quarter (3 months). That’s one of the reasons why I said it’s the Easy Button. If you know when a point was collected with PP, you automatically know the reference frame. For General Users: PP is much safer than using community-driven correction sources since you never know who or how a base station was commissioned. Also - it’s easy to create your own base station these days. For professional work, a Statewide CORS network ties your RTK points to the entire network and it’s proven statistics.

There really isn’t a wrong path, as long as you are aware of the Reference Frame used at the time of data collection.

13

Thanks for that rftop. Is there a good reference website you can suggest I read to understand this better?

14

Yes, there is :
https://docs.sparkpnt.com/ebook-gnss_fundamentals/

15

Thanks again for all your help Ryan (rftop)! Do you work for Sparkfun?
If so, do you know how I can get answers to my RPi specific questions? Or does anyone else know?

Thanks, Jim

16

No Sir, I don’t work for SparkFun.

I’m fairly sure one of the Linux guru’s will be by this thread soon.

17

  1. The hardware will be fairly indifferent to the version of Linux running…the Raspbian OS works fine, ubuntu works fine…it’s pretty open. I will say the default Raspberry OS might be a bit simpler, as the pHAT is designed to make use of the Pi’s default UART and such. If you’re using ROS or something ubuntu would make more sense

  2. Yep, you can route PPS to a Raspberry Pi GPIO and use Linux’s PPS infrastructure (pps-gpio/pps-tools) for time synch; see PPS section of hookup guide

  3. That kind of depends on what you’ll be doing…tilt compensation is useful if you need to move it several times during a survey and will be positioning the setup in various places with different ‘grades’ or hills…it’s really handy for that kind of stuff, but can be overkill for other workflows

  4. On the Pi you’ll typically end up with something such as /dev/serial0 or /dev/ttyAMA*, depending on how the Pi UART is configured (be sure to enable the hardware UART with raspi-config, and disable the serial login console) to enable reading the NMEA stream. The pHAT also provides USB access to the GNSS module, but I’d favor the Pi’s hardware UART for a permanent rover install. PyGPSClient is our recommendation for a Linux/Raspberry Pi package option for viewing/configuring the LG290P and connecting to an NTRIP caster (but you can also use RTKLIB and similar!)

  5. See replies above

  6. Absolutely :slight_smile:

18

Thank you sir!

19

Welcome! This sounds like a cool project. I’m curious to see how it works out, especially with the RTN coverage in a hilly area. The base station idea is interesting too. Hope you’ll share your experience once you get everything running!

20

Thanks! For a peek into what I’m building, it’s basically a scaning rig for mapping roadways. I am publishing a lot of info on the site about the project, but I’ll definitely let you know on this site as well what I learn!