Qqqwxs

I'm running a Raspberry Pi based GNSS receiver from a 26 Ah SLA battery and an 80W panel. Just passed 2 weeks of uptime in a cloudy period of southern hemisphere autumn.

A monte carlo simulation using historical conditions said it had a ~95% chance of no downtime over 3 winter months. A slightly larger battery would bring that up to 99%.

The Pi (3b+), GNSS reciever (u-blox ZED F9P), and Waveshare 7600G 4G modem average about 3.5W idle. The GNSS reciever is about 0.1 - 0.2 W of that. Wifi would be more energy efficient, I imagine.

To expand upon this:

>> They're measuring it by looking for phase differences in the received L-band (~2GHz) signals

The "L-Band signals" are GNSS signals, for example GPS L1 and L2, which use a carrier wavelength of 1575.42 MHz and 1227.6 MHz, respectively. Both L1 and L2 signals are emitted at the same time, but experience differing levels of delay in the ionosphere during their journey to the receiver. The delay is a function of total electron content (TEC) in the ionosphere and the frequency of the carrier wavelength. Since we already know precisely how carrier frequency affects the ionospheric delay, comparing the delay between L1 and L2 signals allows us to calculate the TEC along the signal path.

Another way to think of it is: we have an equation for signal path delay with two unknowns (TEC, freq). Except, it is only one unknown (TEC). Use two signals to solve simultaneously for this unknown. Use additional signals (like L5) to reduce your error and check your variance.

Is paid software OK? Have you looked at Revit?

This comment made me curious.

Apparently, TAI specifically defines the second (in terms of cesium transitions) at sea level (where gravitational potential is equal). I never knew that second part.

If you want to go further down the LIDAR path, you might be able to improve the public data by making manual improvements to the point cloud classification.

For that sort of terrain it's common for classification algorithms to put vegetation (e.g. deadfall, small bushes) into the "ground" class, so when the terrain model gets triangulated using all the "ground" points there is erroneous bumps. If this is the case, you could reprocess the point cloud yourself and tweak the settings being used or make manual adjustments.

I'm not sure of the quality of the linked dataset, so maybe it would be difficult to find improvements. But you knowledge of on-the-ground conditions (and smallish scale of the area) means it's definitely possible.

Also, just in case you haven't stumbled across it, a "Digital Surface Model" (DSM) is different than a "Digital Terrain Model" (DTM)!

(surveying student here, very much enjoyed the writeup!)