poor mans precision farming

Fragen und Hinweise zu Software, die mit dem Thema GPS zu tun hat. Egal ob PC oder Handheld.

Moderator: Roland

archie
Beiträge: 32
Registriert: 11.04.2010 - 14:55

Re: poor mans precision farming

Beitrag von archie » 27.01.2013 - 12:17

@ Taurus
Die Gedanke ist mir vor einiger Zeit auch schon gekommen, vielleicht ein bisschen anders, wo ich gesehen hab das RTKlib rtcm 2 untersutzen soll.
Ich hätte gedacht ein rtcm 2 Signal zum rover zu schicken über Mobilfunk (oder wlan wenns dichter bei ist) welche direkt in ein Ublox Empfänger eingespeist wird.
Damit hab ich von der Ublox Empfänger ein dgps Code-signal mit ein kurze Entfernung zwischen Basis und Rover.
Ich das schon ausprobiert mit ein EUREF station aus Polen der rtcm 2 abgibt und kann sagen das es funktioniert mit der Ublox Empfänger, nur der Basis Entfernung ist zu groß, sodass es nichts bringt.
Man könnte sich so der Rechner am Rover teilweise einsparen. Er wird noch gebraucht um das rtcm 2 Signal an den Empfänger zu übergeben
Vorteil währe ein einfache Empfänger welche auch unter schlechte Bedingungen (Wald) ein hoffentlich genaueres GPS-signal abgibt.

Grüße Pieter

Hagen.Felix
Beiträge: 701
Registriert: 21.12.2008 - 12:07
Wohnort: Grimma
Kontaktdaten:

Re: poor mans precision farming

Beitrag von Hagen.Felix » 27.01.2013 - 12:51

archie hat geschrieben: ...
Ich hätte gedacht ein rtcm 2 Signal zum rover zu schicken über Mobilfunk (oder wlan wenns dichter bei ist) welche direkt in ein Ublox Empfänger eingespeist wird.
Damit hab ich von der Ublox Empfänger ein dgps Code-signal mit ein kurze Entfernung zwischen Basis und Rover.
...
Der mögliche Gewinn an Genauigkeit ist derzeit eher nur dort zu erwarten, wo man mit einem der "C/A-Code only" Empfängermodule aufgrund der lokalen Gegebenheiten (z.B. in den Bergen) gar kein EGNOS mehr hereinbekommen kann.

Hier bieten die in Frage kommenden aktuellen Module von u-blox (Firmware 7.x) zwar ein gewisses "Substituierungs-Potenzial", aber stehen Aufwand und Ergebnis dann tatsächlich noch in sinnvoller Relation?

Denkbar wäre ja auch, sich irgendwo in den Weiten des WWW einen älteren Beacon-Empfänger zu besorgen und dessen Datenausgabe seriell auf den UART eines LEA-6H zu leiten.

In Deutschland ist ja quasi Vollabdeckung mit "Küstenfunk" gegeben, und manchmal ist solch ein Empfänger tatsächlich recht günstig zu bekommen. Um mal ganz konkret einen Namen zu nennen: Den "MobileMapper Beacon" (ftp://ftp.ashtech.com/Mobile%20Mapping/ ... ev%20C.pdf) bekommt man in der Bucht schon manchmal für einen Hunderter ... 8)

Aber wenn mit einem Hardware- und Einrichtungsaufwand in ähnlichem Umfang auch schon RTK-Genauigkeiten möglich sind, würde ich eigentlich immer in diese Richtung gehen.

Um jedoch mal ein wenig zu spekulieren: Wenn u-blox auf dieser Baustelle noch etwas weiter tätig wird, könnte man sich ja recht gut vorstellen, dass z.B. der Nachfolger des NEO-6P dann diese Option mitbrächte (in Verbindung mit dem "carrier smoothing" und dann natürlich auch GPS+GLONASS) .... :idea:

Das würde dann wohl tatsächlich auf den idealen "Wald-Empfänger" hinauslaufen! :D
Gewerbliche Tätigkeit u.a. im Bereich GNSS (siehe https://www.optimalsystem.de/os.aspx?x=411)
Nachrichten bitte bevorzugt als klassische E-Mail (siehe https://www.optimalsystem.de/os.aspx?x=8)

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 27.01.2013 - 14:25

Erst man ein riesiges Dankeschön :mrgreen: an die Gemeinde!

@taurus
bzgl. der Abweichung: Ziel sind 2 cm, und möglichst eine Warnung an den Fahrer wenn z. B. der Fix abreißt, damit er stehen bleiben oder Gegenlenken oder was auch immer kann. Gibt sonst so häßliche verhackte Löcher in den Beständen. Passiert aber auch bei zweibeinigen Lenksystemen, wenn der Koffeinspiegel unter den kritischen Wert fällt. Habe auch zwei Jahre gebraucht, um von 1 km/h in der Ebene auf 7 km/h mit Kurven und 20 % Querhang zu kommen..

Update rate liegt bei kommerziellen High-End-Systemen so bei 10 Hz aufwärts, entspricht also 30 cm Punktabstand bei 10 km/h.
Deutlich weniger sollte es nicht sein.

@tarus die 2.
Jede neue Idee ist willkommen.
Prinzipiell ist aber der Rechner im Rover kein Problem. Nebst Rasp- und ähnlichen Beeren aus der Portokasse gibt es ja auch schon PC-Skala barebones so um 200 Euro. Sollte halt nur robust sein (Temperaturen, Vibrationen) und am besten keinen Lüfter brauchen, um gegen Staub und Feuchte kapseln zu können.

Gewicht, Platz und Stromversorgung sind in/um einen Traktor ausreichend vorhanden.
Ist ja kein Quadcopter, oder Kaninchen, oder was immer in den Foren hier alles getrackt wird ;-)

Das Problem bei Rechenarbeit in der Basis sehe ich in kurzen Aussetzern und Latenzzeiten in der Datenübertragung.
Aber wenn das Ergebnis besser wird, immer her damit.

@tomash
danke für den Link zum Patch.
werde mir für heute Nacht vornehmen, rtklib auf RasPi zu bauen.
(Bin letzte Nacht am ntripcaster verzweifelt - SuSE-format sysv-init-skript läuft nicht auf Redhat-basiertem Centos - zu viel für 3 Uhr in der früh...)

@Hagen.Felix
Daher ist die am Anfang vom Beitragsersteller geäußerte Idee einer Sammlung all dieser Informationen (z.B. in der Art eines "Wikis") ja auch so sehr zu begrüßen!

Viel Arbeit für einen allein (ich würde ja gern, aber ... :roll: ), im Forum oder einer vergleichbaren "Community" jedoch viel besser realisierbar ... :D

Wobei natürlich (kleiner "Wink mit dem Zaunspfahl" an den Beitragsersteller ... :) ) eine ganze Menge dieser Informationen schon hier im Forum zu finden ist, wenngleich auch in unzähligen Beiträgen "verstreut" ... :mrgreen:
Ja, der gefühlte Lernfortschritt der letzten Tage ist hyperexponentiell :wink:
Ich habe zwar mal ein .odt -Dokument mit einer Projektgliederung angelegt, aber dann die Materialsammlung trotzdem in einer lokalen Notes-Datenbank (einfach weil ich all meinen Gedanken-Müll da absortiere) geführt. Taugt zumindest als copy/paste-fähige Quelle.

Hab' noch nie ein Wiki angelegt, das würde mich jetzt auch zu viel Zeit off-topic kosten. Aber wenn es ein solches gäbe, würde ich es gerne mit füttern.

@cr2_gps
Ich hoffte, opendgps.de wäre dieses Wiki. Da warten jetzt ca 5 meiner Beiträge auf Veröffentlichung. Es ist wohl nicht nur die technische Kompetenz dort entwicklungsfähig...

@hannes in diesem Thread
http://www.kowoma.de/gpsforum/viewtopic.php?f=1&t=2967
Danke für den Erfolgsbericht. Ohne diese Motivation ist alles nichts.

ssquare_de
Beiträge: 671
Registriert: 07.10.2006 - 16:23

Re: poor mans precision farming

Beitrag von ssquare_de » 27.01.2013 - 14:43

Hallo,


schön, dass scheinbar Alle gut im neuen Jahr an-, Neue dazugekommen sind, und natürlich, dass es hier wieder mit euch weitergeht...
:wink:

Servus Hagen,
man müsste mal eine Platine statt mit dem NEO-6P mit dem NEO-6T bestücken, der ja auch in der Firmware 7.03 den RTCM-Eingang zur Verfügung stellt.
Ich weiss es nicht genau, befürchte aber, dass das DGPS über RTCM nicht so leistungsfähig ist, wie die PPP-Variante NEO-6P, die neben EGNOS auch phasengeglättete Codeauswertung ins Felde führt.
Rein von den technischen Möglichkeiten her müssten von einer nahegelegenen Basisstation (<50-100km) korrigierte Pseudoranges in Verbindung mit Phasenglättung (smoothing) zu nochmals leicht verbesserter Genauigkeit im Vergleich zum NEO-6P, führen, so ungefähr (0,4-0,5m RMS)
Aber wie gesagt, die RTCM-fähigen ublox6/ublox7-Empfänger werden kaum über das Smoothing-Feature verfügen - zumindest sehe ich bislang keinen Anhaltspunkt dafür.
So wird die Genauigkeit im RTCM-Betrieb kaum oder nur minimal besser sein, wie bei EGNOS-Nutzung, dürfte also rund 1,0-2,0m RMS.
Aber wie gesagt, dass sind nur Vermutungen und Abschätzungen, die auf einem Vergleich mit entsprechend vergleichbaren Empfängern anderer Hersteller beruhen...

Interessant wäre die RTCM-Version im Wald, wo die Korrekturdaten ja zu 100% verfügbar gemacht werden, was speziell bei bewegtem Empfänger für EGNOS-Korrekturen nicht zutrifft.
Bei statischen Messungen kann man auf die EGNOS-Daten überraschend oft zugreifen.
Die Zuführung der EGNOS-Daten über einen Mobilfunk-Datenlink in ein dafür vorbereitetes Empfängermodul wäre natürlich der Königsweg, müsste aber von ublox mit entsprechender Hardware?/Firmware vorbereitet werden.



Was gibts Neues?

Software:
Tomoji s Ankündigung, der STOP-and-GO Modus werde demnächst in RTKLIB eingebaut, hat mich ziemlich angespitzt!
:)
Das verspricht eine echte Verbesserung im praktischen Handling draussen im Feld zu werden, wo hochgenau und schnell Punkt- und Linien-Features hochgenau aufgenommen werden sollen.
Da bin ich echt neugierig darauf, wie das umgesetzt wird.


Hardware:
ich habe gestern mal im Receiver-Survey 2013 von GPS-World geschmökert.
http://www.gpsworld.com/gps-world-receiver-survey/

Aufgefallen ist mir beim ersten Überflug:
+ SKYTRAQ Venus8410, ein Riesenempfänger, der hoffentlich auch mit Rohdatenausgabe kommen und vergleichsweise preiswert bleiben wird! Multi-GNSS, 50Hz Datenausgabe, aberwitzige 6ns Zeitgenauigkeit...das wäre auf allerhöchstem Niveau

+ für die Fastrax-Module, nun im Besitz von ublox, namentlich die 530er-Serie, wird als Rohdatentauglich ausgewiesen! Kommt da demnächst eine erweiterte/angepasste Firmware? Hoffentlich kein Druckfehler!

+ in den Receiver-Survey hat es auch eine Antenne geschafft, weiss nicht warum, aber egal... :wink:
die gut bekannte Trimble Bullet III soll es 2013 auch in einer Multi-GNSS-Ausführung geben, also L1 GPS/GALILEO, Druckfehler?!?

Schauen wir mal, was 2013 bringt...



Stefan

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 27.01.2013 - 15:24

Genug des Overheads, ad substantiam:

Meine Idee vom Grundaufbau ist geblieben, vor allem nach hannes's Erfolgsberichten aus Österreich.

:arrow: Internet-IP-Technologie als etablierte, flexible Kommunikationslinie.
ntrip-caster auf dem 1und1 virtual root server mit fester IP-Adresse als Sternpunkt.
Der Rest des Datenmanagements sollte eigentlich lt. Doku mit ggf kaskadierbaren rtklib-strsrv-Instanzen zu schaffen sein.

Evtl. würde ich zwei Basisstationen an meinen beiden 7 km entfernten Betriebsstandorten montieren, wenn der Einzelpreis im Rahmen bleibt.
Und / oder eine "mobile Tagesbasis" am Feldrand.
Das sollte die Basislänge verkürzen (< 1 km). Die kann über die permanente Basis schön gemütlich sich statisch präzise verorten.
Evtl. kann man da auch den Internetzugang einrichten und per wlan an den Rover übertragen, um das Problem von Empfangslöchern zu minimieren.

:arrow: Was die Module betrifft, ist mein aktueller Stand dieser:
http://michelebavaro.blogspot.de/2012/0 ... nd-up.html
the S1315F-RAW has 20Hz raw measurements update rate, which is still unmatched performance by other low-cost receivers
the uBlox NEO-6P has integrated PPP for high accuracy standalone mode, no other low-cost receivers claims that
the NVS NV08C-CSM has Glonass!
Für die Basisstation(en) wären es somit wohl die uBlox-Module.
Für den Rover überlege ich, jeweils einen S1315F-RAW und einen NVS NV08C-CSM auf dem Traktor und auf dem Anbaugerät einzusetzen.
Der S1315F-RAW bringt die geforderte hohe Auflösung längs der Fahrstrecke.
Der NVS NV08C-CSM bringt robustere Fixes durch die mit Glonass größere Satellitenanzahl.
Zwei Empfänger pro Fahrzeug brauche ich ohnehin zum Ermitteln der Gierung (Drehung um die vertikale Achse), vor allem bei der Abdrift am Seitenhang oder in Furchen.
Rollen und Kippen würde ich über Trägheitssensoren ermitteln, dazu evtl einen Kreisel.
Ich denke, diese Sensoren gibt es aus dem Flugmodellbau für mittlere zweistellige €uros. Hat jemand Erfahrung damit?

:idea: Alles zusammen ergit hoffentlich genügend Redundanz, um damit das Problem mit den Phasensprüngen weitgend in den Griff zu kriegen:
4 GPS-Empfänger auf dem Rover
1 bis 3 Basisstationen
je 1 bis 2 Beschleunigungs- und Drehsensoren
evtl. eine Geschwindigkeitsmessung vom Traktorrad

:?: Ein Phasensprung würde imho nur dann unauffällig detektiert, wenn gleichzeitig
- alle 4 Rover-Empfänger gleichzeitig einen solchen melden
- der Zug mit allen 4 bis 6 Rädern gleichzeitig in ein entsprechend tiefes (20 cm?) Loch fällt
- der Beschleunigungssensor ausfällt und das Fallen nicht mitkriegt
Oder bin ich da mathematisch-statistisch zu optimistisch?

Womit wir wieder bei den Filtern wären. Kalman?
Hab' ich derzeit nur hochgefährliches Viertel-Wissen.
Kann jemand ein gutes Tutorial empfehlen?

:?: :?: :?: Wie würde man das konfigurieren?
  • Erst mal jeden Empfänger (bzw die ihm zugeordnete rtklib-Instanz) sein eigenes Tracking-Süppchen kochen lassen und dann die Ergebnisse samt der weiteren Sensoren in einem extra Modell zusammen führen? So habe ich es beim RTFM irgendwo für die Tunnelüberbrückung der PKW-Navis gelesen.
  • Oder die Daten der Sensoren und der anderen Empfänger zrück in die jeweilige rtklib-Instanz führen (ich nehme mal ann, daß bei Rohdatenverarbeitung im Modul nichts nenneswertes mehr gerechnet wird). Erlaubt das die rtklib (sorry, stecke in der Hälfte des Manuals)?
  • Oder eine einzige Filter-Instanz, die sowohl alle Rohdaten als auch die anderen Sensorsignale in einem Aufwasch verarbeitet. Aus halbwissenden stochastischen Überlegungen heraus würde ich das bevorzugen. Aber ist die rtklib da noch flexibel genug? Oder macht man da ein komplett neues Fass auf?
Wo kriegt man Erfahrung zu dieser Frage her?
Von den Flugmodellbauern? Von den Tunnelnavigatoren?
Ist es schon an der Zeit, Meister Takasu höchstselbst damit zu behelligen?

Und wenn wir schon bei der Software sind:
:?: Was kann man für das User-Interface übernehmen?
Ich brauche wohl einen kleinen Panel-PC für Meldungen und Bedienung.
Vermutlich sollte der auch Karten mit Parallellinien/alten Tracks anzeigen und für einfache Anforderungen / frühe Testphasen ein optisches Lenksignal für den Fahrer anzeigen. Derzeit habe ich meine Flurkarten in qgis, mit shape-files und gpx-tracks. Teilweise habe ich schon Teilflächenplanung über dxf mit qcad ausgetauscht. Nervig, aber geht. Man kann die Planung ja vorher im Büro erledigen. Meinetwegen sogar als image abspeichern. Vielleicht reicht dann ein einfacher map-viewer fürs erste schon aus?

:!: Ein ganz wichtiger Punkt scheint mir die Antenne zu sein. Das beste ist da wohl kaum gut genug.
Hannes' Navxperience 3G-C steht grad für schlappe 1500 in der Bucht. Das wäre für eine Basis tolerabel, meintewegen auch für einen der 4 mobilen Empfänger. Aber 4 x 1500 = 6000 ... das wird schon heftig (wobei es daran noch nicht scheitern würde, wenn es der einzige große Kostenblock wäre).
Gibt es eine preiswertere Alternative? Zephyr?

:idea: :idea: :idea: Gut gefallen hat mir auch der Eigenbau-Choke-Ring von Josef Gerstenberg:
http://www.kowoma.de/gpsforum/viewtopic ... 231#p14238

Baut das schon jemand in Kleinserie? Würde jemand das kaufen, wenn ich eine solche auflege?
Was packt man am besten in's Auge?
Eine Tallysmann TW3400 für 100 €?
Oder gleich den kompletten NL-507-ETTL?
Ich würde den Choke Ring zum Schutz gegen Verdrecken in einen KG-Kanal-Deckel einbauen, aber die Antenne mit ihrem eigenen Gehäuse durch ein Loch (Silikonabdichtung) raus ragen lassen.
Das sollte nach meiner kindlichen Vorstellung die Problematik der Beeinflussung der Antenne durch die Abdeckung umgehen.
Hoffe ich. Der Choke Ring selbst soll lt Josef Gerstenberg ja in der Auslegung unkritisch sein.

:?: Wie kann man sowas messtechnisch erfassen?
Reicht der Werkzeugkasten der rtklib dafür aus?

Fragen über Fragen... wie recht Hannes doch hat ;-)

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 27.01.2013 - 17:10

wie man doch beim Wandern am Wegrand immer wieder die schönsten Blumen findet...

bin grad bei Sparkfun auf zwei imho interessante Produkte gestossen:
https://www.sparkfun.com/products/11058
süßes kleines Modul auf Breakout-Board für schlappe USD 48 (ja, ich weiß, Zoll, Versand...)
based on the Venus638FLPx, the successor to the Venus634LPx. The Venus638FLPx outputs standard NMEA-0183 or SkyTraq Binary sentences at a default rate of 9600bps (adjustable to 115200bps), with update rates up to 20Hz!
und dazu die Diskussion
Member #382322 | about 2 months ago 1
Any idea if this supports RAW GPS and Ephemeris data outputs through the Skytraq binary?
MikeGrusin | about 2 months ago 1
You can get ephemeris data via binary command (see the “binary command set” app note above), but I do not believe there’s a way to access the intermediate data products (please correct me if I’m wrong). SkyTraq does offer an SDK for purchase for this chipset, but I suspect for ITAR reasons the internal GPS loop is a closed binary. Let us know what you find!
Allerdings kein Ergebnis dazu.

Auch hier im Forum
http://www.kowoma.de/gpsforum/viewtopic ... raw#p11906
wurde die Frage für den Vorläufer-Chip 634 schon mal angerissen, aber nicht beantwortet.

Beim Aufräumen meines PC diese Datei offen: AN0024_v06-RawMeasurement.pdf
Application Note AN0024 Raw Measurement Binary Message Extension Of SkyTraq Venus 6 GPS Receiver
Ver 0.6 November 4, 2009
S..6:
0xDD 221 Output RAW_MEAS Raw channel measurements
... bis 20 Hz

S. 19 Raw data format
RAW_MEAS– Raw measurements from each channel (0xDD) (Periodic)
... pseudo Range ... accumulated Carrier cycle ... doppler frequency ... channel indicator ... cycle slip
Bliebe die Frage, ob der Chip das nun standardmäßig oder per einfach verfügbarer FW kann oder eben schwer zu kriegende / teure Updtates erforderlich sind.
Hat jemand Erfahrung damit? Oder Infos, daß es sicher nicht geht?
Falls nicht, würde ich mal den flinken Mausfinger riskieren und mir so ein Teil zum Testen holen.

ah, auch in Kontinentalnähe:
http://www.skpang.co.uk/catalog/venus-g ... -1093.html


Zweites Bonbon:
https://www.sparkfun.com/products/10981
...The GN3S Sampler v3 ...
designed to directly capture the low-level signal data (raw intermediate frequency samples) being delivered by the GPS
...
low level processing gives the user a keen insight into the signal processing of a GPS receiver. The provided algorithms encourage user modification to attempt to improved and design next generation GPS receivers.
...http://kom.aau.dk/project/softgps/
Geht das in die Ecke "software defined radio"? Sieht so aus:
kom.aau.dk/project/softgps/GNSS_SummerSchool_DGC.pdf

Könnte man damit L1/L2/Glonass abdecken?
Mit 450 USD ist das Teil nicht mehr wirklich billig, aber auch noch nicht teuer.
Und wenn es neu ist, wird uns Moore's law sicher noch fallende Preise bescheren.

Jedoch, mein Bauchgefühl sagt mir, daß ich mich da verzettle, wenn ich dieses Fass auch noch öffnen möchte.

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 27.01.2013 - 17:22

wrosner hat geschrieben: Beim Aufräumen meines PC diese Datei offen: AN0024_v06-RawMeasurement.pdf
google den Dateinamen - jetzt weiß ich auch wieder, wo ich den Link auf diese Datei her hatte:
http://www.onetalent-gnss.com/ideas/usb ... ers/yuan10
Hagen, weißt Du vielleicht mehr dazu?

und google findet das auch hier:
ftp://ftp.macrogroup.ru/Support/SkyTraq ... 24_v06.pdf

Hagen.Felix
Beiträge: 701
Registriert: 21.12.2008 - 12:07
Wohnort: Grimma
Kontaktdaten:

Re: poor mans precision farming

Beitrag von Hagen.Felix » 27.01.2013 - 18:27

wrosner hat geschrieben: ...
http://www.onetalent-gnss.com/ideas/usb ... ers/yuan10
Hagen, weißt Du vielleicht mehr dazu?
...
Hallo Wolfgang,
ja! :mrgreen:

Das wäre derzeit auch die einzige (entsprechend kostengünstige) Möglichkeit für 20 Hz RTKLIB-kompatibler Trägerphasen-Rohdaten.

Allerdings gibt es schon ab und zu mal etwas kritische Stimmen zur Messqualität (kann ich aber selbst nicht wirklich fachgerecht beurteilen).

Daher trotzdem keine Empfehlung von mir für den SkyTraq zur Anwendung auf dem Schlepper. Außer, Du bestehst ohne Wenn und Aber auf den 20 Hz. :shock:

Aber summa summarum dürfte momentan der NVS-Empfänger wohl das Mittel der Wahl sein, schon allein deswegen, um bei schlechterem Empfang zur Not auch mal die Elevationsmaske etwas stärker hochziehen zu können. 10 Hz sollten doch eigentlich auch genügen, oder?

Seit einer Weile kommen über OneTalent GNSS auch nur noch Ausführungen, die von NVS direkt ab Werk auf das "GLONASS group delay" kalibriert worden sind (leider aber auch etwas teurer).

Ich selbst bevorzuge trotzdem häufig noch den u-blox NEO-6P, allerdings nicht zuletzt aus ganz individuellen Kostengründen (infolge dreistelliger Abnahmemengen bei u-blox für mich preislich am besten) sowie natürlich auch wegen seiner einzigartigen Flexibilität: Autonom (bzw. mit SBAS) schon herausragend genau innerhalb seiner Preisklasse, als Rohdatenlieferant für RTKNAVI jedoch ebenso gut geeignet (trotz offizieller Spezifikation nur bis 5 Hz lässt sich die völlige Beschränkung auf RAW+SFRB auch bis 10 Hz "hochprügeln").

Letztlich gibt es aber immer und überall ein Für und Wider. Ich fürchte auch, Du wirst es bei Deinem erklärten Ziel einer 2-cm-Genauigkeit für kinematische Messungen nicht ganz einfach haben ... :roll:

Will durchaus nicht sagen, dass es gar nicht geht, aber das Problem der Fix-Abrisse wird Dich wohl etwas beschäftigen ... :?:
Gewerbliche Tätigkeit u.a. im Bereich GNSS (siehe https://www.optimalsystem.de/os.aspx?x=411)
Nachrichten bitte bevorzugt als klassische E-Mail (siehe https://www.optimalsystem.de/os.aspx?x=8)

thomash
Beiträge: 24
Registriert: 25.01.2013 - 19:38

Re: poor mans precision farming

Beitrag von thomash » 27.01.2013 - 19:48

Hagen.Felix hat geschrieben:
Bist Du Dir denn ganz sicher, dass ein Kondensator an dieser Stelle ebenso verwendbar wäre, ohne dass es dadurch zu Fehlfunktionen oder gar Schäden am Modul kommen kann?

Soweit ich solche PCB-Designs kenne (sowohl von industriellen Herstellern als auch aus den kleineren Werkstätten), werden eigentlich immer die üblichen Lithium-Akkus verwendet. Manche verzichten aber auch ganz auf diesen Puffer ... :?:
Sogar im Reference Manual vom NV08C ist die Schaltung mit Kondensator angegeben, wenn ich das gerade richtig überschlagen habe, sollte das ausreichen um bei einem 5F Kondensator, welcher auf 5V geladen ist bei einem Entladestrom von 4uA (mal konstant angenommen) kommt man auf ein du/dt von ca. 1uV/s. Minimalspannung ist 2.2V ergibt ein delta von 2.8V durch 1uV/s ist quasi ewig, also 2800000s ~ 1900 Tage. Und man hat kein Problem mit Lithium.

http://www.nvs-gnss.com/products/receiv ... ad/31.html

An die größer Antennenauswahl durch höhere Versorgungsspannung habe ich noch gar nicht gedacht, bei meinem Board kann man die übrigens auch über die Stecker extern zur Verfügung stellen und von der USB Versorgung trennen.

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 28.01.2013 - 02:34

cr2_gps hat geschrieben:
wrosner hat geschrieben: wäre es vermessen, schon mal vorab um ein diff / patch zu bitten?
In diesem Thread konnte ich (unter anderem) auch so ein Patch finden:
http://forum.openstreetmap.org/viewtopi ... 33#p296633
hm....
Ich habe soeben die rtklib (rtklib_2.4.2b9) auf raspberry gebaut.
Es gab zwar probleme mit libs die er nicht gefunden hatte, die waren aber mit zwei symlinks zu beheben.

Ich habe bewußt erst mal ohne diesen Patch gestartet.
Ein Blick in die sourcen zeigt, daß die Deklarationen noch unverändert drin stehen.

Ich finde weder Fehlermeldungen beim Übersetzen von ublox.c, noch die Variablen R4 / U4 beim grep im build log.

Starte dann ./makeall.sh test
bringt keine Fehlermeldung beim Konvertieren von ublox.ubx files, obwohl er da drin mächtig rödelt.

Ich habe zwei Fehler bei anderen Formaten, die aber identisch auch in der x86_64 Architektur auftauchen.
Schau'mer mal...

thomash
Beiträge: 24
Registriert: 25.01.2013 - 19:38

Re: poor mans precision farming

Beitrag von thomash » 28.01.2013 - 09:34

wrosner hat geschrieben: hm....
Ich habe soeben die rtklib (rtklib_2.4.2b9) auf raspberry gebaut.
Es gab zwar probleme mit libs die er nicht gefunden hatte, die waren aber mit zwei symlinks zu beheben.

Ich habe bewußt erst mal ohne diesen Patch gestartet.
Ein Blick in die sourcen zeigt, daß die Deklarationen noch unverändert drin stehen.

Ich finde weder Fehlermeldungen beim Übersetzen von ublox.c, noch die Variablen R4 / U4 beim grep im build log.
Es kommt auch zu keinen Fehlermeldungen beim Kompilieren, du bekommst maximal Warnings (cast increases required alignment of target type oder so) dazu musst du aber auch mit -Wall oder so kompilieren. Soweit ich weiß steht bei den Buildflags nur -pedantic und das genügt glaub ich nicht.
R4 ist übrigens kein Symbol sondern nur ein Präprozessor Makro für einen Cast, dh du siehst das im Log nicht, denn auch der Compiler sieht das nicht mehr, es wird schon vom Präprozessor ersetzt (du siehst dann nur die Zeilennummer mit der Warning. Dabei wird aus einem char Array (char[]) auf ein beliebiges byte ein float oder ein double Wert über Pointerzugriff gecastet.

Code: Alles auswählen

#define R4(p)       (*((float  *)(p)))
Das geht aber nicht auf jeder Architektur, weil diese Typen da nur auf bestimmten Speicherstellen liegen dürfen (Vielfache von 4 oder so). Das kann immer passieren, wenn man einen kleineren Datentyp über Zeigerzugriff auf einen größeren castet.

Abhilfe schafft dann manuelle kopieren der Bytes auf die Zielvariable, diese legt der Compiler schon auf eine gültige Stelle, weil es den Typ weiß, also so in der Art:

Code: Alles auswählen

static float R4(const unsigned char *p)
{
    float value;
    memcpy(&value, p, sizeof(float ));
    return value;
}
dazu muss man aber eine Konvertierungsfunktion schreiben, das geht mit einem einfachen Cast, wie dem Makro nicht. Lästig an dem ganzen ist, dass es sich erst zur Laufzeit auswirkt und dann der Kernel mit "BUS FAULT" abbricht, bzw wenn es nicht abgefangen wird einfach unerklärliche Fehler auftreten. Das ganze passiert aber auf x86 Prozessoren nicht, weil diese damit kein Problem haben.
Ich hab zuerst auch nur einen Zugriff umgeändert bevor ich dann R4 als Funktion geschrieben habe, dann hat es funktioniert, bis ich den ersten Glonass Satelliten gesehen habe und anderer Code ausgeführt wurde, den ich nicht gefixt habe -> BUS FAULT
Soweit ich gesehen habe sind diese Zugriffe vor allem in den Receiver Code Teile, wo die Daten mal eingelesen werden und dann die einzelnen Werte protokollspezifisch geparst werden.

wrosner
Beiträge: 72
Registriert: 23.01.2013 - 01:30

Re: poor mans precision farming

Beitrag von wrosner » 28.01.2013 - 21:55

Danke @tomash für die aufschlussreichen Erläuterungen.

Als 95%iger-C-Laie (mein dreckiges kleines Geheimnis: ich bin PERL-Fan) kann ich das schemenhaft nachvollziehen - aber selber drauf zu kommen hätte wohl Äonen gedauert.
Werde jetzt mal einen anderen Weg versuchen:
order: NV08C-CSM board
Von: Wolfgang Rosner <....>
An: "AR Wooldridge" <...>
Datum: Heute 20:06:48

Hello, Anthony,

> The price of the GPS +Glonass module is £### plus VAT in a nice small case.
> I can deduct the VAT if you have a valid EU VAT registration number.

I want to have one of those. Please, take this as and order.
.....
> I can supply modified RTKlib software to run on the GPS +Glonass chips
yes, please.
Hope this works....

Wie reagiert Meister Takasu auf die Himbeer-Epidemie?
Ich meine, wenn die Fixes bekannt sind, was steht dagegen, sie in die Sourcen einzubauen?
OK, Risiko von Regression bugs, muß wieder getestet werden, zieht Kapazität vom seines Erachtens nach Wesentlichen ab, ...
irgendwie kann ich es verstehen.
Scheint mir eine Ein-(Power)-Mann-Veranstaltung zu sein, diese rtklib?

off topic:
ein mir Bekannter - arbeitet bei Fendt in der Entwicklung - hat mir gesteckt:
Die hatten in den 1970 Jahren ihr Geräteträgersystem als "Ein-Mann-System" beworben.
Böse Zungen behaupten, das ginge darauf zurück, weil es in der Firma nur einen Mann gibt, der sich damit auskennt... :lol:


Aber je länger ich drüber nachdenke, desto mehr missfällt mir die Situation.
Soviel verstehe ich von C, daß mir klar ist, daß diese casts "quick and really dirty hacks" sind. So was "tut man nicht".
Jetzt wird mir auch klar, warum all diese Header files in den Linux-Libraries zu 90 % aus irgendwelechen #if-#else-conditionals bestehen. Und einen Heidenrespekt vor Leuten wie bei SuSE mit ihrer Autobuild-Factory, die es schaffen, Software so hinzutrimmen, daß jede Änderung im nächsten nightly build wieder funzt - auf so verschiedenen Plattformen vom raspberry bis zum turnhallenfüllenden Supercluster.

Aber wenn die ganze rtklib voll von deartigen quick hacks ist, weil es eben der Stil des Herrn Guru ist?
Und weil er eben stur nach vorne powerd, ohne Rücksicht auf Kollateralschäden?

Aber die rtklib ist kritischer Bestandteil meines Vorhabens.
Es gibt wohl nichts, was diese ersetzen könnte, oder?
Also muß die Hardware an die Software angepasst werden?

Es gibt für ca 120 Euro Barebones auf Intel-Basis, mit 1,8 GHz Dual Core Atom oder so.
Die passen auch in eine Traktorkabine. Dreck in der Lüftung könnte kritisch werden, mal sehen.
Aber die haben die gleiche Bitbreite der Variablentypen wie jeder andere intel-basierte PC.
Sollten also Takasu-Hack-kompatibel sein ... so I hope :|

Werde jetzt mal auf mein NV board warten und sehen was mit den diversen Patches auf Raspberry zu machen ist.
Vielleicht auch mal einen -Wall Build riskieren.
Aber eine Mördergrube aus meinem Herzen mache ich deswegen nicht.

Es gibt ja noch Unix-Bordmittel (Sockets, netcat/socat, perl ( ;-) , ... ) um dezentral von div Raspberries gesammelte Daten über ein kleines LAN zu einem zentralen Arbeitstier zu bringen.
Zuletzt geändert von wrosner am 28.01.2013 - 22:33, insgesamt 1-mal geändert.

Hagen.Felix
Beiträge: 701
Registriert: 21.12.2008 - 12:07
Wohnort: Grimma
Kontaktdaten:

Re: poor mans precision farming

Beitrag von Hagen.Felix » 28.01.2013 - 22:32

wrosner hat geschrieben: ...
Werde jetzt mal einen anderen Weg versuchen:
order: NV08C-CSM board
Von: Wolfgang Rosner <....>
An: "AR Wooldridge" <...>
Datum: Heute 20:06:48

Hello, Anthony,

> The price of the GPS +Glonass module is £### plus VAT in a nice small case.
> I can deduct the VAT if you have a valid EU VAT registration number.

I want to have one of those. Please, take this as and order.
.....
> I can supply modified RTKlib software to run on the GPS +Glonass chips
yes, please.
...
Hallo Wolfgang,
ist der "Denga10" bei Anthony in England denn tatsächlich bedeutend günstiger als bei Michele in Pisa selbst? :?:
Denn der Entwickler & Produzent ist ja in beiden Fällen identisch ... :roll:
Auch der NVS-Code in RTKLIB ist ja "Made in Italy" ... :lol:
Gewerbliche Tätigkeit u.a. im Bereich GNSS (siehe https://www.optimalsystem.de/os.aspx?x=411)
Nachrichten bitte bevorzugt als klassische E-Mail (siehe https://www.optimalsystem.de/os.aspx?x=8)

Hagen.Felix
Beiträge: 701
Registriert: 21.12.2008 - 12:07
Wohnort: Grimma
Kontaktdaten:

Re: poor mans precision farming

Beitrag von Hagen.Felix » 28.01.2013 - 22:45

thomash hat geschrieben: ...
Soweit ich gesehen habe sind diese Zugriffe vor allem in den Receiver Code Teile, wo die Daten mal eingelesen werden und dann die einzelnen Werte protokollspezifisch geparst werden.
Hallo Thomas,
es ist vielleicht am besten, wenn Du Dich damit mal direkt an Michele Bavaro wendest!

Er hatte in den vergangenen Monaten schon immer ziemlich herumgemeckert wegen den "Reibungsverlusten" an der Stelle, wo in der RTKLIB die Daten aus den verschiedenen Importmodulen für die jeweiligen Rohdatenformate zusammengeführt werden. :evil:

Wenn ich das richtig verstanden habe, stammt auch der NVS-spezifische Teil der aktuellen 2.4.2b komplett von Michele ...
Gewerbliche Tätigkeit u.a. im Bereich GNSS (siehe https://www.optimalsystem.de/os.aspx?x=411)
Nachrichten bitte bevorzugt als klassische E-Mail (siehe https://www.optimalsystem.de/os.aspx?x=8)

thomash
Beiträge: 24
Registriert: 25.01.2013 - 19:38

Re: poor mans precision farming

Beitrag von thomash » 28.01.2013 - 23:06

wrosner hat geschrieben: Wie reagiert Meister Takasu auf die Himbeer-Epidemie?
Ich meine, wenn die Fixes bekannt sind, was steht dagegen, sie in die Sourcen einzubauen?
OK, Risiko von Regression bugs, muß wieder getestet werden, zieht Kapazität vom seines Erachtens nach Wesentlichen ab, ...
irgendwie kann ich es verstehen.
Scheint mir eine Ein-(Power)-Mann-Veranstaltung zu sein, diese rtklib?
Keine Ahnung kenne die RTKLIB auch erst einige Wochen, aber wird soweit ich das sehe nur von ihm entwickelt. Aber die Änderungen kommen glaube ich schon auch von anderen Personen (zB NV08C BINR Protokoll von Michelle Bavaro?). Generell macht es alleinige Entwicklung einfacher, weil man sich nicht in Diskussionen über die Struktur und wo es hingehen soll streiten muss, dass kann ich durchaus verstehen.
Andererseits besteht aber dann das Problem, das andere Benutzer möglicherweise unabhängig Verbesserungen und Erweiterungen entwickeln, welche nicht zurück fließen.

Darum will ich die RTKLIB auf github Stellen und meine Änderungen und auch andere darin einpflegen. Auf github kann man ganz leicht ein Repo forken daran arbeiten und dem Entwickler vorschlagen die eigenen Änderungen wieder in den Main Branch einfließen zu lassen (Pullrequest). Weiters sieht man auch immer, was genau im Code bei den Änderungen passiert.
wrosner hat geschrieben: Aber je länger ich drüber nachdenke, desto mehr missfällt mir die Situation.
Soviel verstehe ich von C, daß mir klar ist, daß diese casts "quick and really dirty hacks" sind. So was "tut man nicht".
Aber wenn die ganze rtklib voll davon ist, weil es eben der Stil des Herrn Guru ist?
Und weil er eben stur nach vorne powerd, ohne Rücksicht auf Kollateralschäden.
Bitte meine Anmerkungen zum Code nicht falsch verstehen, ich finden den Code der RTKLIB sehr gut strukturiert und übersichtlich, da merkt man schon, dass das ein Profi geschrieben hat und auch Cast sind nicht generell böse oder schlechter Stil. Lästig wäre es gewesen wenn diese Casts im Code immer ausgeschrieben ohne Makro verteilt im Code gestanden wären. Ideal wäre es wenn man wahlweise eine Funktion oder einen Cast per Define Anweisung wählen könnte.
wrosner hat geschrieben: Es gibt für ca 120 Euro Barebones auf Intel-Basis, mit 1,8 GHz Dual Core Atom oder so.
Die passen auch in eine Traktorkabine.
Aber die haben die gleiche Bitbreite der Variablentypen wie jeder andere intel-basierte PC....
Hier geht es nicht um die Bitbreite alleine, es geht darum das gewisse Datenypen nicht auf beliebigen Stellen im Speicher liegen dürfen. Wenn ich jetzt aber aus meinem Empfänger in einem Rutsch Daten in ein Array schaufle (char[]) und dann je nach Protokoll irgendwo in diesem Array einige Bytes als float oder double zu interpretieren habe (zB über einen Cast), kann es sein, das diese eben nicht auf die für diese Datentyp gültigen Speicherstellen liegen. Allerdings ist das von Prozessor zu Prozessor unterschiedlich ob das erlaubt ist, oder ob die Zugriffe dann einfach transparent anders gehandhabt werden, wenn das Alignment nicht passt.
Allerdings kann auch noch ein weiteres Problem mit der Endianess auftreten, dh welches Bit wird als MSB und welches als LSB interpretiert? So etwas ist auch nicht auf jeder Architektur gleich, da bräuchte man auch wieder Unterscheidungen und eine Funktion, welche uU die Reihenfolge vertauscht. Aber jetzt genug von C.
Soweit ich das sehe, war die Lib zu Beginn nicht gedacht so portabel und generell anwendbar zu sein und bedarf daher etwas Zuwendung, wenn man die Architektur wechselt.
Das einzige was mich etwas stört, ist das C89 verwendet wird, C99 wäre mMn etwas netter.
wrosner hat geschrieben: Werde jetzt mal auf mein NV board warten und sehen was mit den diversen Patches auf Raspberry zu machen ist.
Vielleicht auch mal einen -Wall Build riskieren.
Aber eine Mördergrube aus meinem Herzen mache ich deswegen nicht.
Da würde ich dir aber den Import des Codes in eine IDE wie Eclipse nahelegen, das macht Vieles einfacher.

Antworten