I encountered this stick even before I learned about the current stage of AgOpenGPS.
They take ~ 450 € for the hardware and onther 170 € for the stick.
Searching at Aliexpress for the F9P, I learned that there are even much cheaper alternatives available now.
So I got a UM626N (no, it’s not unicore, even if it resembles their naming pattern) - just to bin it.
No RTK fix, zero documentation, zero support.
But I also got a Quectel LC29HDAMD at about 30 €.
Nice part, plenty of documentation. My fist RTK fix since I experimented with RTKlib more than a decade ago.
Did some testing on debian, with LFPS ntrip caster and BKG ntrip client for RTK.
Works fine on my Samsung S7 android, too.
Use GNSSmaster there, following Ardusimple’s instructions.
After mastering the nuts and bolts of my local LFPS ntrip provider, this setup was a nobrainer.
Sadly no USB on board, so I picked an old PL2303 USB-UART cable from the shelves.
Fine with linux and android, but not with WIN11.
The PL2303 obviously is a nightmare of compatibility issues.
Still always the first hits when I search for the handy cabled format.
Got some new ones, work with WIN11, but not with deb 10.
And with deb12, both versions start to work, but drop out after short times.
So - sorry - without WIN, this build report is close to off topic for this forum.
And the LC29HDAMD is limited to 1 Hz - too slow for even simple AgOpenGPS testing.
So I ordered a LC29HDAME (10 Hz) for the tractor tests and kept the LC29HDAMD to build a survey stick.
That’s the (not really) secret content of the box.
Just quick and dirty protection for the module and fixing the cables.
No RF shielding, so not realy intended for top edge in harsh environment.
All the parts fit into an ammunition box I got from a local hardware discounter some times ago.
And that box (about 7 x 30 x 45 cm) fits into the top case of my motorbike.
There were even some place for the mobile and a power bank.
The phone holder is included with the monopod.
Unfortunately, the imperial threads are not easy to get in continental Europe, so I had to 3-D-print wings for the hex nut.
4 € for the OTG cable at eBay
1.40 € for the level bubbles (lot of 5) . Before I tried a more expensive and clumsy version that did not really fit nor hold.
So I decided to 3-D-print this flat yellow holder.
The upper pole and the groundplate are made out of the scrap bin.
As you see, it’s time to exercise my welding skills, anyway . The 30-cm-Monopod is 160 cm when extended. Thus my tall head at 190 cm might cause strong RF shielding. With longer monopod and/or smaller operator, this upper pole might be shortened.
The green insert for the antenna is just a test of TPU-3D-printing
The plastic case, the PL2303 USB-UART-cable (NEVER buy such a scrap) and the box were lingering in some corner
This adds up to
29+25+5+22+4+1.40 = 86.40 €
so there’s some gap left to account for imperial screws, printer filament, shelf warmers etc.
Of course you have to account the work of planning, building, configuring as learning cost.
Or get a stick from ardusimple (admittedly, painted) for sth. over 600 €.
install GNSSmaster from Google play store to an android device
plug the receiver into the USB-OTG and GNSS master will pop up, asking to handle serial connection
do as reqired and configure a suitable ntrip caster in your region as RTCM provider
enable “mock location” in your devices system setting and set GNSSmaster to deliver it
I tested it with
QField - search the Internet how to configure it for “mock location”
mendhak GPS logger app (my favorite track logger for years now)
BayernAtlas web service running in Firefox browser (didn’t try other)
delivering (among much else) 20 cm orthofotos and field boundaries in Bavaria
It (presumably mock location) does NOT work with
Bavarian FAL-By app of the agri-auhorities
most GNSS-status-Apps I tested (however, GNSS-master shows RTK status and skyview)
My old PL2303-shelf-warmer also does not work with WIN11. But that were an easy change, of course. CH340 UARTS are reported to work fine., but others may, too. I finally even found some mounted in the cable plug, but not yet received them.
Finally set up my base and hopefully figured out how to align it with the official German reference System aka ETRS89/DREF91 (R2016) aka EPSG:10284
‘RTKbase on Futro S900 x86 thin client - #12 by wjr’
Expect ~5 cm alignment to official maps.
Let’s check it
Survey stick as above
good old Samsung S7
GNSSmaster from Google PlayStore
my own internet ntrip caster, forwarding my own base stations rtcm
Open “Themen / Vermessung und Luftbild /Liegenschaftskataster” and activate “Luftbild mit Parzellarkarte”.
This opens an arial 20cm-pixel DOP whith buildings, estates boundaries from the official cadastral map.
RTK fix location from the mock provider can be activated in the web app.
Edged structures on the surface can be visually extrapolated beyond the 20 cm pixel limit.
Within this precision, it looks like my setup matches better than 10 cm to the DOP.
However, when I tried to find some covered markstones, it was not that perfect.
I first started searching nearly half a meter off the postion where I found it in the end.
Well, that’s 2 pixel…
Can we be sure that the markstones were surveyed that precise decades ago?
Can we rely on the precision of the DOP and the alignment of the cadastre?
When I compare the markstone’s coordinates to my desktop QGIS, it seems that the cadastre is off by ~80 cm.
In QGIS, DOP and cadasdre are imported as different layers from the public Bavarian WMTS server, but presumably generated from the same backend (vector?) data.
Just curious whether they do this on purpose to sell their paid services ?
This is the markstone with the coordinates as surveyed in the previous post
So my hope is that my base stations coordinate and the shape files from iBalis match.
Just sad that we cannot easily use BayernAtlas to look up markstones.
Discussed the problem with a survey engineer last evening.
She has been working in the fields for some time with the public surveying office.
She does not think that there are any better data available in the background.
As far as I understood, the problem is that cadasdral data are a patchwork of historic measurements with different precision and different coordinate (mis-)-alignment. Re-survey is only performed on local pressing needs. The results then are fitted into existing neighbourhood, [to minimize neighbours eating into each others premises, so to say.] Fit to a global reference is only secondary goal. [i.e. as skind of windfall at the end of another pipeline] Similiar pattern we find for processing arial photos into DOP. There may small areas with good fit (as it happened on my yard), and close by terrible fits.
So I assume that this locally distorted patchwork is bent by some smooth transaction and a couple of matching points roughly to fit ETRS89/DREF91 (R2016) in the end.
To locate borders and markstones, we may try to revert this process as good, feasible and economic as possible. Probably, single fields or adjacent fields with comparable posseive (i. e. surveying) history might safely be assumed to be subject to a homegenous distortion.
QGIS includes a georeferencer for raster images.
So we need raster per field / field cluster (is there an english word for “Gewanne”?) with structures that are aligned to our target system.
Re-align, then.
This is what I tried:
in iBalis, switch on both cadasdre borders and field borders
zoom to fields / clusters as appropriate, print to pdf, extract pdfimage and cut relevant areas using sth like gimp
georeference the field boundaries in the images to match the *.shp vector lines
in QGIS, I have
the WTMS DOP (high res raster background for orientation and control)
the (transparent) misaligned WTMS cadasdre (yellos hard bricks)
the *.shp export of field boundaries from iBalis as vector data assumed to match our target reference system (thin dark blue line)
From the back-referenced image, we have
best available cadasdre (blurred yellow pixels with circle marks)
low res raster background
field boundaries to be aligned (light blue and red blurred pixeled lines)
The distance marks are left over from yesterdays exercise and may proof that I really got the re-alignment I wanted.
Limitiations of the approach encountered until here:
Looks like all (most?) markstones are represented in circles, but obviously there are many more circles. Think that is in areas where no recent (>> 50 yrs?? old) surveys are available
size and resolution of iBalis pdf print is limited.
300 m field lenght allow decent georef’ing.
at 1000 m field length, pixels get coarse
subdividing long lines leaves us with lack of corners as matching points
So let’s pack a QField project to my phone, grab my survey stick and a spade and go digging for markstones.
good news:
surveying with QField works fine (for some time), could reproduce the position of my markstome as close as 7mm.
bad news: Looks like I killed my mobile.
no USB connection, does not load any more.
Obviously the USB connector is broken - may be mechanically, may be thermal overload?
… ah, after an hour, charging is on again. And OTG, then, too.
Looks like a transient thermal issue, may be even protective device?
Realised that QField and / or GNSSmaster where crashing repeatedly.
Suspected lack of memory, flash or CPU power first, due to the large and many Geotiff files.
But may be it is a power issue?
The GNSS module gets powered by a power bank even if the phone is disconnected.
Tho pole gets quite engarlanded by the cabling now.
At least, QField & GNSSmaster were running stable for half an hour now.
But still the phone draws its accu quite fast.
Looks like my old S7 cannot run on charge and OTG the same time.
Got a Makita-Akku-Adapter for USB so i can recharge in the field.
Could bluetooth keep the phone plug available for charging?
So I checked the situation here in Bavaria (well, sometimes they run conform whith German policy, sometimes they insist on their federal sovereignity - at least when it comes to surveying… btw - have you ever read Kafka? “Landvermesser K” … very revealing… … any way…)
There were “lateral fix points” on a per municiality level in thte past. Labelled as “not activeley maintained any more”. Visitied two of them, close to my fields. Both where gone.
There are many “elevation fix points”. Even surveyed in ETRS89_UTM32, but only at 6 cm accuracy.
What they say to maintain are “geodetic reference points” on a per “Landkreis” (county?) level.
The next one is 13 km from my base.
So I went to the spot and took readings with my poor-man’s-survey stick.
Happy that I designed the stick to fit in my top case .
Column B are the published coordinates (in ETRS89:UTM32).
Note that they are given only in cm-level precision.
Column C substracts “false eastings” as assumed from the UTM system (just educated guess, but happens to work out).
Column D are with RTK correction signals from my own base station.
Column E are with RTK correction signals from official LFPS service, supposedly running at the current offical refrence system ‘ETRS89/DREF91 (R2016)’.
Line 9 is the euclidian difference of measurements in mm:
The deviation of my measurement (D/E) from the published ETRS89 coordinates (C) is < 20 mm.
Note that the values are given in cm precision only, anyway.
The deviation between ref to my own base and public LFPS (C vs E) is 2 mm (Cell F9)
Just found out that some of my WMS / WTMS imports of official bavarian services in QGis where still in ‘EPSG:3468 / Gauss-Kruger zone4’
This was the official frame of reference until some years ago.
Now the official reference is EPSG:25832 ETRS89/UTM 32N.
Have to delete an reimport the layers to make a change of reference system effective.
Looks like most of the 70 cm offset I found earlier is due to the offset between those: the old and the new reference systems are offset by ~ 70 cm actually…
Well, if we really surf on 7 cm plate tectonics p.a. , that’s a mere decade…
.
?
… any way…)
top case 
.
I’d say.