Ah bummer I was afraid of that.
It does have the port expansion cable with a DT connector so maybe can work something out with that. Thanks,
Just installed RTKbase and found this in the syslogs:
... run_cast.sh[60664]: 2025/07/08 21:27:56 [CC---] 2564474 B 16063 bps (0) localhost (1) ...
Itâs running a UM980 with quite large coverage of systems and sigs, the msg are:
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
Educated guess lets us read bps as bits per second.
This bps figure is quite constant slightly above 16000, rarely touching 17000.
This would count up to 7.65 MByte/h and 5.7 GByte / 31 days in 24x7.
Or 130 hours for a GByte (relevant for the client download side)
Donât know how flexible this figure is for other message patterns.
@Stefal, Sorry, I donât understand your statements regarding coordinate systems.
As far as my understanding goes, ETRS89 is a UTM, i.e. a mercator projection.
This is great for maps as it reads in meters, however, our GNSS spit lat/lon coined WGS84 in degrees.
âEuropĂ€isches Terrestrisches Referenzsystem 1989 â Wikipediaâ
states that âat Jan 1 1989, ETRS89 and WGS84 were as close as 1m and thus be considered as identicâ
However, we are dealing with cm precision now.
When I want to exchange my data with public map services, they are in EPSG:25832 UTM 32N.
(may be that is a subset of ETRS89?)
But as I understand, GNSS-WGS84 coords have to be precisely mapped by proper calculation/application (e.g. proj.org), not just âbentâ by tweaking coordinates. Please tell me if Iâm wrong.
What I see however are the differences in altitudes.
Afaik $GNGGA in alt-field[10] prints geoid aka sea level height (changing with signal noise) and in field[12] an additional (fixed by location) undulation difference to ellisoid height.
So what I did is to average lat/lon/alt from a 5 hr log of RTK fix (same antenna and receiver, BKG ntrip client) and entered those values into RTKBase coordiante field. For averaged $GNGGA altitude (~550 m) I had to add the ellipsoid-geoid difference (~47m).
Without coordinates, the altitude computed by RTKBase converged to ~ 600m, so I think this is consistent âŠ
is it?
Just a line of GGA:
$GNGGA,161633.00,4959.05887230,N,01215.59843017,E,1,28,0.5,555.4857,M,47.0442,M,,*77
and the snippets from the Unicore Ref Cmd Manual:
[10] alt = Altitude above/below MSL (geoid),
[12] undulation = Geoidal separation, the difference between the Earth ellipsoid surface and mean-sea-level (geoid) surface. If the geoid is above the ellipsoid, the value is positive; otherwise, it is negative.
So:
555,4857 m is geoid height.
47,0442 m undulation is positive
hm - can we trust the Unicore manual? 
Here âNMEA 0183 â DR. BERTGES VT SUPPORTâ it reads
Die Höhenangabe an 11. Stelle ⊠Diese ortsabhĂ€ngige Geoidseparation wird im EmpfĂ€nger aus einem dort hinterlegten, grobmaschigen Geoidmodell intrapoliert. Dieser (ungenaue!) NĂ€herungswert wird nun von der ursprĂŒnglichen ermittelten und genauen ell. Höhe He abgezogen. Das Ergebnis, die MSL-Höhe Hmsl, steht im GGA-Datensatz an 9. Stelle
In short: ellipsoid-alt - undulation = geoid-alt ~~ mean sea level
Just the other way round as in the Unicore manual. 
On one of my rovers I use a xbee bluetooth receiver at 9600 bps, and it can manage about half the messageses from my base as you have, but not two more messages. So I think your calculation is OK.
My base run (when UP) on an old win tablet with Demo5_b33e (underscore between 5 and b) on it. It still work but I know there is newer versions, probably should update to b34l
Only thing needed to start is the strsvr program.
Here is also more (but older) information. RTKLIB Benchmarking: versions 2.4.2, 2.4.3, and demo5 â rtklibexplorer
Just see that UPrecise displays the size of RTCM messages.
1 Like
Just installed a relayed ntrip caster on a managed root server with fixed IP:
âRTKbase on Futro S900 x86 thin client - #3 by wjrâ
On the remote root, It runs a str2str TCP-stream-server as input and on the local RTKBase box a str2str TCP-stream-client as output.
This is just the other way round than in the common local RTKBase configuration.
The advantage is that since the connection is established âupwardsâ, no VPN is required.
First tests indicate a robust behaviour, even when IP of the uplink change regularly at night.
Client connection (UPrecise) survived a service restart of the remote caster.
The disadvantage is that I had to tweak a little bit, and the address of the public ntrip-relay cannot be configured in the RTKBase GUI.
On the public server, there is no Web-GUI, just a small subset of RTKBase.
Credentials are maintained by vi over ssh.
Maybe that some other users might look for something like this - including GUI integration.
However, I know that @Stefal is not in favour of private casters.
Respect that, and thus I donât dare to issue a feature request, but leave that open to the community.
ok, got it, finally:
âRTKbase on Futro S900 x86 thin client - #12 by wjrâ
The German reference system is called ETRS89/DREF91 (R2016)
âSatellitenpositionierungâ
And it looks like everybody is calibrating their systems to that.
No projection back and forth to WGS84, just bending - or defining, we might sayâŠ
hello, did you install rtkbase recently?
yesterday and today I have the same problem installing RTKbase, the installation is going well but it wonât start. I did it sometime in March like I did now and it went away.
now I look back at the log and I found something that I donât think is right, and thatâs why it wonât start? or what could be the problem Debian 11 Orangepi
Failed to stop systemd-timesyncd.servie: Unit systemd-timesyncd.service not loaded.
Failed to disable unit: Unit file systemd-timesyncd.service does not exist.
You can ignore these message. The installation want to disable timesyncd, but itâs not installed â no problem
then I donât know what the problem could be⊠the installation goes to the end and at the end it says
âEND OF INSTALATION
You can open your browser to http://192.168.1.72â
but rtkbase doesnât run
Could Debian 11 be old?
Update: I found an error with the installer, could this be the problem?
Yes!
Debian 11 is old now. Try with Debian 12.
I know it wonât work with Debian 13 until the next release.
1 Like
Just out of curiosity has there been any thought given to putting this in a docker image?
Anyone know why Iâm suddenly not getting any satellite data today? Rebooted many times. How would I go about testing the F9P isnât bricked? Has been flawless for idk 3-4 years
Update: Replaced F9P board with a spare, no change. Replaced antenna on roof - works! Wild, never would have expected a basic antenna to fail.
3 Likes
Hello Stefal, I had time to play a little, this is all a hobby, yes I installed Debian 12, started your RtkBase script and now it doesnât get stuck with the python installation.
It canât work on Debian 11 anymore.
With Debian 12, rtkBase starts but there is a bug in systemd-timesyncd which may not be a bug. Could this cause a problem with RtkBase?
Failed to stop systemd-timesyncd.service: Unit systemd-timesyncd.service not loaded.
Failed to disable unit: Unit file systemd-timesyncd.service does not exist.
Hi all! Iâve build my own RTK station following this thread and itâs working just fine! I was just wondering is there any way to see if someone is using my RTK base? Just out of curiosity, it would be very cool to see it being used by farmers in de area.
on my phone on rtk.data i can see if theres other rovers using mine
What caster are you using, for example emlid shows you how many rovers are connected at the moment
1 Like
If you send your stream to a caster, the base station canât know how many rovers are using it. Only the caster can know it. If you use the Centipede-RTK caster, itâs available.
Example:
RTKBase 2.7.0 is available
And the ready to flash images are available too
- The images use Debian 13 (Trixie)
- The same pipeline is used for the Raspberry, which means this is an Armbian image too
- Wifi is disabled on Orange Pi Zero 3 (not stable enough)
Changelog
[2.7.0] - 2025-11-28
Added
- Now compatible with Debian 13 (Trixie).
- Now compatible with Septentrio Mosaic-X5 firmware 4.15. Default login/password is
basegnss/basegnss!. - GUI â Settings: Add display of network interface mac address.
- GUI â Settings: Add Tcp host addr entry to open or block external access to the Gnss receiver. #490
- GUI â Add mount name in the web page title. Thanks to @sbonaime #484
- GUI â Logs: .sbf files get a type in the type column.
- GUI â Logs: .obs and .2?o files displayed as RINEX in type column.
Changed
- RTKLib upgraded to release v2.5.0-EX.
- Add Galileo inside rinex preset for Nrcan. #479
- U-Blox ZED-F9P settings : Dynamic model sets to static during configuration. Thanks to @Jef239 #488
Fixed
- GUI â Logs: Fix wrong path when using custom data directory. #471
- GUI â Settings: Better toggle buttons color behaviour.
Deprecated
- Operating systems older than Debian 12 / Ubuntu 24.04 canât update RTKBase anymore.
- Python release < 3.11 deprecated
Security
- Update various python module
- Update js library (leaflet, bootstrap-table)
Full Changelog: Comparing v2.6.4...v2.7.0 · Stefal/rtkbase · GitHub
Just a quick note about the Centipede-RTK network:
- Since march, it uses a new fully open source high performance caster : Millipede
- With this caster there is an automatic ânearestâ mount point : NEAR
- And a light NEAR mount point with âon the flyâ MSM7 to MSM4 conversion : NEAR4
NEAR4 is mainly for old gnss receivers and the John Deere tractors in which the guidance systems are crashing when they are connected to a full MSM7 triple band base station.
2 Likes