RTKbase on Futro S900 x86 thin client

Build Reports
1

Need a base station. Want to leverage all of UM982 potential.

Local LFPS ntrip service delivers only MSM4 and afaik not all bands supported by UM982.
Show dropouts and allow only one connection per account.
Their terms of use are somewhat restrictive, and they charge I think 50 € every second year for admin fees.

My plan:

  • UM980 complete kit
  • RTKBase (current version is 2.6.3)
  • debian 12 on Fujitsu futro S900 x86 hardware
  • short SMA, UM980 module in a somewhat unaccessible location, 10 m active USB to the computer
  • str2str as ntrip-caster in a managed root internet server

This is the kit I bought:
‘Unicore UM980 GNSS Module EM-980 Seires board EM-980D1 D2 D3 D4 D5 Multi-frequentie Hoge Precisie RTK Voor GNSS RTK Basisstation - AliExpress 30’
EM-980D5 board with EM-500 antenna and 5m cable for < 170 €.

Had discouraging experience with the stability of RasPi long ago.
The user reports in Stefal’s RTKBase thread indicate that affairs didn’t grow to the better.

Got a bunch of refurbished S900 for < 30 € each (including case and power supply).
They have a 1.2 GHz AMD G-T44R and consume << 4W (no fan).
Solid PC-style mainboard/chipset layout, GB NIC, couples of independent USB.
Basically the same components as used in laptops.
Have some of those spread around my premises, running stable for years.
There were 920 (4 core, 4W) and larger models (with fan and much more power need), but let’s try single core first.

“GitHub - Stefal/rtkbase: Your own GNSS base station for RTK localization with a Web GUI” recommends debian 12.
Fine, that’s what I’ve running on a couple of boxes already.
The UM98x-support sounds promising.
I don’t like the python, would never install such a thing on a production machine beneath other applications. But since I need a dedicated box close to the antenna, anyway, that’s not the issue.

Decided for an 8 GB m-SATA (was that a mistake?) and 4.5 GB RAM.
A pristine debian with just basic tools and ssh-server already consumes 1.3 GB.

Stefal’s install.sh works like a charm.
Had my UM980 plugged during setup, so it was configured automagically. Great.
Just pointed the browser to the box, and alas, lots of satellites and a cursor moving to my home.
df reports 2.3 GB=39 % disk usage. Let’s keep an eye on disk space.

I found that the rtklib executables (str2str in particular) run on my (ubuntu) managed-root internet server. In contrast to the rtklib 2.4.3 coming with even recent debian and ubuntu, it’s supposed to supply ntrip-caster. Stefal mentions this option in his thread.
‘RTKBase: a GUI for your own Gnss Base Station’
Let’s see.

Precise antenna coordinates raise some challenge.
Since I want repeatable tracks in cm-precision, after months, even if I had to change or move the antenna inbetween, PPP is not enough.
The Rinex-postprocessing seems cumbersome, at least I haven’t found yet a service indicating covering Germany.
But I have alread RTK in place, so why not use that (just forgetting to read LFPS terms and conditions …)?

RTKlib’s rtkplot_qt somehow does not like the NMEA from UM980 testruns, however.
So I hacked a PERL-Skript to average coordinates from GGA sentences, logged with BNG ntrip client:
‘perl-nmea/get_center.pl at master · wolfgangr/perl-nmea · GitHub’

After ~ 5 hours, standard deviation of position stabilizes at < 4mm horizontally and 8 mm vertically

total lines processed: 131768
lat cnt: 18824 - lon cnt:   18824 - alt cnt:       18824
skipped: 112944 - qual miss: 0 - format errors: 0

lat - cnt: 18824  - sum: 645.746446 - sum of squares: 2.215196e+01 
        min: 49.98430427650 - max: 49.98430454183 - diff: 0.00000026533
        average: 49.98430442231 - stddev: 0.00000003480 
        diff = 29.5 mm; stdev = 3.9 mm

lon - cnt: 18824  - sum: 187.586161 -isum of squares: 1.869346e+00 
        min: 12.25996513150 - max: 12.25996539983 - diff: 0.00000026833 
        average: 12.25996526568 - stddev: 0.00000003743 
        diff = 19.2 mm; stdev = 2.7 mm

alt - cnt: 18824  - sum: 2093.422700 - sum of squares: 2.339311e+02 
        min: 554.4772 - max: 554.5400 - - diff: 0.0628 
        average: 554.5112 - stddev: 0.0077 
        diff = 62.8 mm; stdev = 7.7 mm

One thing that was not clear for me was Stefal’s recommendation to go for local UTM coordinate systems.
In his thread, he mentions that coordinate system can easily configured, but I don’t find how.
Anyway, isn’t it that WGS84 ist GNSS lingua franca?
Or ist continental drift spoiling my repeatable antenna position?

Regarding altitude, compared to the first postitons from RTKlib, the altitude converged towards a value about 50 m above my sea level (geoid?) altitude, so I think it ist WGS ellipsoid altitude that is required and I have to add the offset reported quite at the end of any GGA sentence.

I think that precision is fine for the test antenna & mount.
Have to repeat that with the final mount anyway.
However, I planned to keep the module in an unaccessible location, connected by 10 m active USB-cable to a powered HUB.

It took me some time to reconfigure the module back to rover mode.
And I don’t want to install the BNG on my 8GB Futro.
So I had to unplug an repower the module - requiring access.
May be I’ll drop that long USB cable and have a 10m SMA-cable instead.

What about connecting modules COM2 to a second USB-UART and use this for NMEA and maybe even RTK? Does this conflict with BASE mode?

1 Like
2

after a day of testing, some findings:

  • it works :slight_smile:
    tested with UPrecise, AgOpenGPS and crude console client
  • my WIN11 per default cuts USB-connections when the screen saver hits.
    … nothing wrong with my ntrip-casters …
  • single core 1.2 GHz processor can handle RTKBase with ntrip-caster, but web admin response may slow down
  • we can forward RTKBase to some public access server and run a simple rtklib str2str as ntrip-caster there (…no need to spoil the system with ever incompatible python versions as required by a full fledged RTKBase installation…)
  • firewall settings are a bitch, in particular if hidden in my hoster’s web-admin-labyrinth
  • RTKBase is great not only as no-brainer out-of-the-box base-station solution,
    but also as template for customized rtklib hacking

Some details for the courious:

have tested my local ntrip-caster as provided by RTKBase with UPrecise and AgOpenGPS.
Setup works like a charm. Even with my window sill secondary testing antenna (the top-of-roof-antenna still serves the base…) I get some RTK float and even rare RTK fix. (LC29HE…whatever as test gadget).

BKG ntrip client seems to dislike RTKBase (well, actually rtklib) caster’s source table.
And ist limited to 115200 baud, while LC29HE by default runs on 430800.

Never mind, I figured out to check a ntrip-caster’s mere connectivity on a linux command line with (venerable debian 2.4.3) rtklib onboard tools is as easy as:
str2str -in ntrip://user:password@IP.of.RTKBase.box:2101/my_mount_point | xxd
If it spits myriads of incomprehensible hex numbers, that’s proof of receiving RTCM.

Below is a top print of my RTKBase box.

top - 01:13:55 up 2 days, 39 min,  3 users,  load average: 0.47, 0.57, 0.56
Tasks:  89 total,   1 running,  88 sleeping,   0 stopped,   0 zombie
%Cpu(s): 20.1 us, 10.2 sy,  0.0 ni, 69.0 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st 
MiB Mem :   4505.7 total,   2761.8 free,    525.6 used,   1472.8 buff/cache     
MiB Swap:    928.0 total,    928.0 free,      0.0 used.   3980.2 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                             
    347 message+  20   0    9416   5152   4244 S   9.9   0.1 298:20.43 dbus-daemon                                                         
      1 root      20   0  168080  12512   9144 S   7.6   0.3 243:34.36 systemd                                                             
   4238 root      20   0   89820  68956  11032 S   4.3   1.5 140:41.32 python                                                              
    350 root      20   0   50012   8064   6932 S   1.7   0.2  50:09.34 systemd-logind                                                      
  59701 wrosner   20   0   12784   1208   1092 S   1.7   0.0  24:41.97 str2str                                                             
  60664 wrosner   20   0   16636   7316   2372 S   1.3   0.2  20:37.90 str2str                                                             
 127958 wrosner   20   0   12784   2540   2284 S   1.3   0.1   0:40.71 str2str                                                             
    .....

No reason to worry or to switch from 1-core to 4-core - yet.
Load average close to 1 and 1/3 CPU utilisation i’d consider as “still safe, but don’t add more” for time critical jobs.

A single str2str process consumes a single-digit-%-number of CPU usage.
Watch it, but don’t be scared.

However, when the caster is running and the web interface was not used for some time, there is a delay of some dozens of seconds until the browser window updates. As long as the core function does not break, I can live with that. Proof of sound design of task priorities, I’d rather say :+1:

Forwarding local RTKBase RTCM to a remote virtual root with permanent IP address ist as simple as running a clone of RTKBase’s caster, albeit with a tcpsvr at input side (instead of tcpclient):

Just ps ax | grep stdr2str at the RTKBase box to find the template.
Change the -in clause from client to server (see str2str --help for details) and may be the mountpoint (twice!) and keep all the daunting rest (well, may play with the log level -t) and run this on the public server:

str2str -in tcpsvr://:5015 -out ntripc://user:password@:2101/my_UM980_base:my_UM980_base;rtcm3;1004,1005(10),1006,1008(10),1012,1019,1020,1033(10),1042,1045,1046,1077,1087,1097,1107,1127,1230;;GPS+GLO+GAL+BDS+QZS;NONE;NONE;49.98430442533;12.25996526660;0;0;RTKBase_Unicore_UM980,2.6.3;NONE;B;N;;#rtcm3 -msg 1004,1005(10),1006,1008(10),1012,1019,1020,1033(10),1042,1045,1046,1077,1087,1097,1107,1127,1230 -p 12.34530442533 12.34596526660 123.5547 -i RTKBase Unicore_UM980,2.6.3 R4.10Build13504 -a ADVNULLANTENNA -t 4

Now, on the local RTKBAse box, start a job to forward RTCM to the remote server:

str2str -in tcpcli://localhost:5015 -out tcpcli://remote.server.IP:5015 -t 2

Took me some times to figure out firewall issues of my virtual root (don’t change that very often…).
Of course, both port 2101 for caster clients and 5015 (for tcp upstream from RTKBAse) must be open.

I’ll have a test run for some (night) hours now and add service files tomorrow.
There are valuable templates from @Stefal at /etc/systemd/system :slightly_smiling_face: :+1:

3

Alas:
Here is the service file for the tcp client at the RTKBase box.
Does not use any of Stefal’s own code nor is it controlled or configured by it.
Just the rtklib str2str as installed by RTKBase.

:~/rtkbase$ cat  /etc/systemd/system/str2str_caster_upload.service
# templated from Stefal's str2str_local_ntrip_caster.service
[Unit]
Description=RTKBase upload to remote Ntrip Caster
#After=network-online.target
#Wants=network-online.target
Requires=str2str_tcp.service
After=str2str_tcp.service

[Service]
# Type=forking
Type=simple
User=wrosner
# ExecStart=/home/wrosner/rtkbase/run_cast.sh in_tcp out_local_caster
EnvironmentFile=/home/wrosner/rtkbase/caster_upload.conf
ExecStart=/usr/local/bin/str2str -in tcpcli://localhost:5015 -out tcpcli://${CASTER_ADDR}:${CASTER_PORT} -t ${LOGLEVEL} 
# Restart=on-failure
Restart=always
# TimeoutStartSec=infinity
# Restart=on-success
# Restart=no
RestartSec=10
#Limiting log to 1 msg per minute
LogRateLimitIntervalSec=10 minute
LogRateLimitBurst=1
ProtectHome=read-only
ProtectSystem=strict
ReadWritePaths=/home/wrosner/rtkbase

[Install]
WantedBy=multi-user.target

At the public server, I installed from Stefal’s RTKBase

  • rtklib executables (ntrip-caster capable)
  • a modified service file for the caster
  • a modified config
  • a modfied start wraper aka run_cast.sh

Before, I tried a direct call to str2str in the service file as well.
However, the parameters for a caster that go to the command line are quite clumsy, so I gave up reinventing the wheel.

The service file:

~$ cat /etc/systemd/system/str2str_ntrip_caster_realy.service 
[Unit]
# [wjr 2025-07-11]
Description=RTKBase hack to relay Ntrip Caster
#After=network-online.target
#Wants=network-online.target
# Requires=str2str_tcp.service
# After=str2str_tcp.service

[Service]
Type=forking
User=wrosner
ExecStart=/home/wrosner/test/RTKBase_part/run_cast.sh in_tcpsvr out_local_caster
Restart=on-failure
RestartSec=10
#Limiting log to 1 msg per minute
LogRateLimitIntervalSec=3 minute
LogRateLimitBurst=1
ProtectHome=read-only
ProtectSystem=strict
ReadWritePaths=/home/wrosner/test/RTKBase_part

[Install]
WantedBy=multi-user.target

In the config, I just changed the credentials and mountpoint.

In the wrapper, It boils down to one line for some in_tcpsvr-configuration, which is not part of Stefal’s code, and a debug to log the str2str command line.

...:~/test/RTKBase_part$ diff run_cast.sh.000 run_cast.sh
15a16,19
> # [2025-07-11 wjr] tcp server in for remote caster
> in_tcpsvr="tcpsvr://:${tcp_port}#${receiver_format}"
> 
> 
75c79,81
<     ${cast} -in ${!1} -out ${out_local_caster} -i "${receiver_info}" -a "${antenna_info}" -t ${level} -fl ${logdir}/str2str_ntrip.log &
---
>     cmd="${cast} -in ${!1} -out ${out_local_caster} -i ${receiver_info} -a ${antenna_info} -t ${level} -fl ${logdir}/str2str_ntrip.log" 
>     echo ${cmd}
>     ${cmd} &

I know that @Stefal is not in favour of private casters.
But may be that some users might be happy to find this in RTKBase, nevertheless.
Will drop him a note.

4

Harsh test of resilience:

closed the case, mishandling hardware, changed memory, BIOS battery,
unplugged power → watching ext4 log replay on test desk monitor
misfit memory module … memory boot issues … everydays sh … that always can happen
plugged (udev ruled) HUB in wrong port…

and as soon as I plugged the HUB in the right PORT so that udev could map UART as configured, within a couple of seconds - clients could connect again, and also the internet caster supplied RTCM such as nothing ever had happend.

no fiddling, no interaction, no extra reboot, no USB plug exercises, just watch and and enjoy

Chapeau to @Stefal :+1: :clap: for designing such a robust system
and of course :+1: :clap: to the giants from rtklib, on whose shoulder’s he ist working

1 Like
5

For deployment, I put the module in a metal box.

grafik
grafik640×414 69.2 KB

COM1 (used by RTKBase) is connected to the onboard USB-C of the module.
This also obviously deliveres enough power.
Put an active Hub in between to be sure.

For playing, testing, calibrating, and whatever I added old PL2303-USB-UART cables to COM2 and COM3.

This required persistent udev USB-device naming, since at boot / powercycle, the assignment of ttyUSB* to physical dongles it random.

I decided to distinguish them by port, thus I can even discern identical types.
All three UARTS are connected to the same hub as visible in the last three lines of the USB bus topology view:

...$ lsusb -t
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/4p, 12M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/2p, 12M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-pci/5p, 12M
    |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
    |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/4p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/5p, 480M
    |__ Port 5: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 4, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
        |__ Port 2: Dev 5, If 0, Class=Vendor Specific Class, Driver=ch341, 12M
        |__ Port 4: Dev 6, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M

This goes into a udev rule file

...~$ cat /etc/udev/rules.d/92-UM980.rules 
SUBSYSTEM=="tty", KERNELS=="1-5.2", SYMLINK+="ttyUM980_COM1"
SUBSYSTEM=="tty", KERNELS=="1-5.1", SYMLINK+="ttyUM980_COM2"
SUBSYSTEM=="tty", KERNELS=="1-5.4", SYMLINK+="ttyUM980_COM3"

… and produces a device assignment like

....~$ la /dev/ | grep USB
lrwxrwxrwx  1 root root           7 Jul 11 14:57 gps0 -> ttyUSB0
lrwxrwxrwx  1 root root           7 Jul 11 14:57 gps2 -> ttyUSB2
lrwxrwxrwx  1 root root           7 Jul 11 14:57 ttyUM980_COM1 -> ttyUSB1
lrwxrwxrwx  1 root root           7 Jul 11 14:57 ttyUM980_COM2 -> ttyUSB0
lrwxrwxrwx  1 root root           7 Jul 11 14:57 ttyUM980_COM3 -> ttyUSB2
crw-rw----  1 root dialout 188,   0 Jul 11 14:57 ttyUSB0
crw-rw----  1 root dialout 188,   1 Jul 11 14:57 ttyUSB1
crw-rw----  1 root dialout 188,   2 Jul 11 14:57 ttyUSB2

As long as the dongles are plugged into the same place in the hub,
ttyUM980_COM1 always points to COM1, no matter of the kernels lottery of ttyUSB* numbers, so I use this in the config of RTKBase.

6

Deploying to the final antenna.
Ripped old terrestrial TV antennae and kept the pole.
3.5 m above ridge - not yet top of trees 30 m away, but getting close.

UM980 quite close to the antenna (5m RG 58 + 1 m RG174), 10 m active USB cable to the RTKBase machine in a maintainable place, close to network uplink.
No obvious problems with such a long USB cable - fine.
Well, active cable behaves like a hub, so I have to change my udev rules. No-brainer.

Challenge: get coordinates.
Don’t want to install BKG bnc - requires qt5 even in cmd line, would eat up 3/4 of a GB of disk space.
Might try cumbersome port forwarding stuff. Not really motivated for that…
Try Stefal’s postprocessing approach first, instead.

Collecting data and converting to rinex works like a charm with RTKBase web UI.
With regard to the experience that rtklib fails with memory protection error and unicore Converter (under wine) throws imcomprehensible “Please open insert file firstly”, some extra :+1: :+1: :+1: for Stefal.

The german SAPOS service require registring and charge 20 € p.a.
So give the french service a try.
First try with 1,5 hrs of log - works like a charm, too. Result comes within ~ 1hr.

As educated guess tells, it employs stations 100 km north and south of mine.
Didn’t translate all the text, but this figures look fine:

	SIGMA_0             :    0.0016 M 
PRECISION INTERNE ESTIMEE (MILLIMETRES) :
          SX :  52.1  SY :  55.8  SZ :  47.7  
          SN :  21.9  SE :  57.2  SH :  65.8

But when I enter these coordinates into my station and took my previous test base antenna as rover, I’m dozens of cm off laterally and 5 cm vertically, compared to the previous ETRS89 position.

Looks like the difference between
POSITION ITRF2020 EPOQUE 2025.540 (17/07/25) :
and venerable
EPSG25832 ETRS89/UTM 32N

Searching the web, I found

Just gleaned over the images, but indeed - they form a picture:
plate tectonics may account for dm difference in 35 years from 1989 to 2025.

Looking for online tools to convert, I did not find any one converting lat-lon between both systems - just X-Y-Z.

Looks like I have to make a decison.

Pro’s for EPSG:25832 ETRS89

  • matches the current offical maps
  • matches LFPS ntrip caster so I can use this as a fallback
  • presumably closer reference stations

Pro’s for ITRF2020

  • matches reality and take us on board of our continent, even when tectonics move us over time
  • free service
  • matches Stefal’s proposed workflow
  • no clumsy ntrip caster or workaround required on the RTKBase box
  • ETRS89 is labelled “accuracy 1m”

I think I can live with a map deviation of 25 cm.
But when I want reproducible tracks between operations some months or more apart, real match beats administrative precision. So the ITRF2020 (extrapolated to today) wins.

May be I’ll note down a known fix point’s coordinate to be able to recover just in case sh…t happens.

add-on:
watching my test anteanna’s position (< 10 m away from the new base) in Uprecise.
Sustained RTK fix over hours - and nearly all dots in a circle of 1 cm radius.

Compared to previous experiments with LFPS, an improvement by a factor of 3 …5.
There still were clusters, seperated by jumps of 2..3 cm .

7

hm … long plotting, drawing, estimating, thinking…
We are off from the maps by about 1.35 meter :see_no_evil_monkey: :face_with_peeking_eye:
… hear the markstones plopping in the plough…

Finally, I installed recent proj v. 9.6.0 from debian testing.
This allows “spatiotemporal” transformations, i.e. consider the plate tectonic movements at different times in the coordinate systems, as described in current proj documentation:

Rereading official map data, I found the expression “Amtliches ETRS89/DREF91 (R2016)-System”

I think this boils down to
‘ETRS89/DREF91 Realization 2016 - EPSG:1353’
" German national realization of ETRS89. "

Boilt on top of this, there are (among others)

  • EPSG:10282 (3D cartesian geocentric)
  • EPSG:10284 (Geodesy)

proj documentation mentions some ‘heuristics’ going on, so I found it’s more safe to start with 3D-geocentric models, as this seems closed to metal. Otherwise I get mixed results.

To yield lat-lon-alt format, I compared to
pipe ITRS (3D geocentric) -> EPSG:10282 -> WGS84
with ITRS (3D geocentric) -> EPSG:10284
Both approaches delivered exactly the same results.

I took the deviation of my test antenna measured with LFPS-RTK from the result with my new ITRF2020-calibrated base and substracted it from the ITRF2020 base antenna position.
In qgis with BayernAtlas DOP20, this looks quite close to the position on the roof where my antenna pole is located. So I took this as a yardstick.

Then I compared different input epoch values (empty, 1989. 2016, 2016.5, 2025.56) with this yardstick.
Best match was delivered with epoch = 2025.54 , i.e. the day of recording, as printed in the RGP report. Still 139 mm off my yardstick, but an improvement by a factor of ten, at least.
Empty or 2016 values are nearly half a meter off, 1989 135 cm, again.

$ proj
Rel. 9.6.0, March 15th, 2025

$ echo 4015871.2539 872670.3866 4862126.1898 2025.54 | cs2cs -d 8 +init=epsg:9988 +to +init=epsg:10284
12.26006242     49.98424044 605.41094798 2025.54

Still collecting 24 hrs log for precise location, don’t dare to disturb yet…
btw: in the while, I have UPrecise with a LC29HE* on my test antenna runnig as RTK client.
Have not seen any loss of RTK fix, and most dots in the trajectory plot are withoin the 1 cm cycle.

So the own station promises a huge improvement over LFPS in terms of precision and stability.

8

“keep your nose to the grindstone and your eyes to the sky”…the saying goes.
Well, still undecided on that question.
Shall we look up to WGS84 in the sky or keep our nose down to tectonic plate fixing?

Tried to figure with projinfo where moving plates go in and where not.

Obviously, in the official ETRS89/DREF91 (R2016), they don’t.
Looks like the system is redefined every couple of years to account for tectonic shift.
Seems to me the worst decision between the variants:
neither automagic update of station, surfin’ on european plate, in space
nor close to established map systems.

As far as I see, there is no reference datum included in ntrip data.
When I look at my client zoo, I’d assume all of them expecting WGS84 sky coordinates:

  • QField is a spinoff of qgis, so I expect it to implement full-fledged proj transformation

  • In AgOpenGPS, I plan to import my fields by KML, which is in WGS84 afaik
    and maybe export NMEA logs … see next

  • mendhak NMEA data logger just collecst plain NMEA, not asking any question about “datum”.
    In qgis, by default they are importet as WGS84.
    Might change this, but why making things complicated?

  • BayernAtlas Web app let’s display a couple of coordinate systems.
    WGS84 being the standard for lat/lon format, as it seems.
    No trace of ‘official’ DREF91
    This is what I plan to use with my survey-stick to recover markstones, reestablish lost field boundaries etc. dm-precision for that app would be great.

  • Bavarian tile server which I use in qgis for 20cm DOP supports quite a bunch of coordinate systems, WGS84 among them

So I consider as follows:

  • set the stations coordinates to current WGS84
  • reposition (either with a fresh survey or just by figuring out and adding tectonic shift) every year at harvest time
  • when I miss correction, maps are off for annual plate shift.
    can live with that, I think

Thus I have

  • WGS84 for interfacing 3rd party coordinates as close as the tectonic hift within a year
  • bound to plate within crop growth period, which is annually in my case
  • updating base coordinates between seeding and hoeing would break cm-level repeatability and is not a good idea, I think
9

Just relax. As long as your base is not on the other side of the tectonic plate as your field,:grinning_face:
But yes, never change base coordinates.
I have my base for years, at same place and coordinates, and stones and drains , are still where I marked them in AOG.
For government survey use, then you must find a nearby government known fix location, and make your base and survey stick match these coordinates.

10

Well, yeah…
Just hoped to go the “get it right first time and then forget” way.
Looks so so obvious in the first place, but hard at the end.

E.g. there’s a “ballpark” option in proj talking about “100s of m deviation”…
So I think we are working at the bleeding edge of progress here.

If that’s the case, I agree with you.
“just start with a reasonable value and let years pass by” might be the proper attitude…

11

In Denmark we have a homepage with access to fix points. Have been thinking about making a survey stick and go to the nearest post about 100 m from my base, and check which coordinates I would get there.

12

Yes, when I’d started again, that were the easiest approach I think:
Just align my station with known reference point.
But that still leaves open how to interpret reference coordinates.

Looked in the definitions of ntrip and RTCM - for vain.
Closest information I could get:
‘Discrepancy between points with NTRIP and local base station - RTK / PPK configuration - Emlid Community Forum’

A local plate fixed datum comes along for the ride and the coordinates don’t change, that’s why CORS normally use them.

All over our communities places, including Stefal’s recommendations, they say:
“for precision, collect 24 hrs, get 'em postrocessed and align to local official plate fixed system”.

OK, could have registered with SAPOS (the German official service), paid them 20€ p.a. and get my data processed to ETRS89/DREF91 (R2016) - without understanding what’s going on.

Or as I did before, run my Antenna with LFPS ntrip (part of SAPOS, 20 € p.a. already registerd) and get an average (see some posts above).

With my survey stick running on LFPS ntrip (i.e. ETRS89/DREF91 (R2016) as I suppose) I checked that BayernAtlas DOP where roughly OK at ~10cm, as far as one can match ground features.
This match to official maps is what I wanna have in the end.

Just received my postprocessed ITRF2020 coordinates from my yesterday 24hr-record and converted them to ETRS89/DREF91 (R2016) - as I hope:

...$ echo 4015871.3006 872670.2865 4862126.2068 2025.54 | cs2cs -d 8 +init=epsg:9988 +to +init=epsg:10284
12.26006092     49.98424037 605.43964324 2025.54

When I compare those coordinates whith what I’d exprect from earlier LFPS tests, this matches expectations as close as 22 mm (green line at the bottom).
Raw ITRF2020 as supplied from rgp.ign.fr (top blue line) and the plain WGS84 (which is quite close to it - second line) are more than a meter off.
Without proper epoch, we are still > 30 cm off (second last line)

label | lat | lon | alt | d lat ° | d lon° | d mm lat/lon/diag

grafik

Thus, I dare to odd that I figured it out.
Lets go test it.

13

Good you got it.
I just collected data (collected without rtk), and sent it to nrcan some years ago. Put returned position in F9P , haven’t changed them since.
Several posts about nrcan, here’s one.

14

Images in DOP look fine.
‘100 € survey stick - #5 by wjr’
As far as we can see from a 20cm-pixel aerial view, we are matching closer than 10 cm, I’d say.

For a single calibration measurement, you don’t even need a stick.
Just a receiver, Antenna, OTG cable.
60 … 70 €.

15

Regarding relative precision:
Plot with UM980 base and UM982 rover.
Impressive.

grafik
grafik339×291 54.6 KB

1 Like
16

Checked against current offical positioning reference point:
‘100 € survey stick - #9 by wjr’
Hit the spot as close as 2 mm :smiling_face_with_sunglasses: :+1:

1 Like
17

Starting real live testing.
Find that my base stations str2str are dropping out sometimes for reasons not yet identified.

Asked my son (who is owning the grid where the the module draws power) and he promises not to have powered off the module.

Restartign the service (may be done from the web UI) and the caster-forward service gets everything up again. No need to fiddle with the internet caster so far.

It’s easy to diagnostic and restart the situation from home, but it is very nasty if it happens when I’m out in the fields.
Looks like we need skd f watchdog?
Am I really the first one encountering this issues?
Any hints on deeper diagnostics?

18

I think there’s mention of service stopping in this (old) tread. And a way to monitor it.

I used this setup one year, before using rtkbase.

19

I have a suspicion:
There are USB disconnects / reconnects every couple of days logged in the kernels dmesg.
Just 0.3 s apart.

I know that we have short power dropouts occasionally.
(Gone are the great times, when Germany used to be a developped country :see_no_evil_monkey:)
Visible in flickering lights, but most PC supplies buffer power long enough to run on.
May be that the Hub / active cable do not so?

So what?
Need skd of automagic restart of the str2str services after such events.
Watchdog? udev-skript?
or a Mini-USV… or just a larger capacitor at the hub?

20

ah - you mean this cron job here:
‘RTK base with a Raspberry pi4 and SimpleRTK2B - #8 by Valentin’

Yes, running a cron job every minute boils down to a watchdog.
However, in my case, the str2str are not gone, and I have 3 of them:

~$ pidof str2str
633975 633859 633453

So I have to modify the idea.