Geospector GPS-Forum (vormals kowoma GPS-Forum)

Hallo, GPS-Gemeinde,
geiles Forum hier, was ich heute gefunden habe

Als Biobauer und begeisterter Hacketchnik-Bastler, der im früheren Leben schon mal heftig in die IT geschnuppert hat, läßt mich das Thema "Precision Farming" natürlich nicht los.
Ich hab' mich vor ein paar Jahren erstmals in die NMEA-spuckenden Mäuse eingearbeitet, aber da ist mit "precision" nicht viel zu holen.

Die Messlatte am anderen Ende:
http://www.trimble.com/agriculture/truetracker.aspx
Ein Gerät läuft hinter dem Traktor, einer oder mehrere Empfänger + Trägheits- und Rotationssensoren + intelligente Software sorgen für cm-genauen Nachlauf und Spuranschluss. So was hätt' ich gern.
Wolkige Preisandeutungen der Verkäufer: höherer 5-stelliger Euro-Betrag ..... danke für den Kaffee....

So wie es aussieht, wird die Zeit langsam reif, daß sich die Lücke zwischen "unbezahlbar" und "brauchbar" schließt.
Dieses Forum:
http://www.thecombineforum.com/forums/3 ... rover.html
hat mich auf die Kombination von rtklib und u-blox gebracht, was ich durch googeln hier im kowoma-Forum +- bestätigt bekommen habe.
Und natürlich sollte es auf Linux-Derivaten laufen (mein letztes WIN war 98SE...), evtl. mobil auf raspberry-pi, hab' aber auch noch ein beaglebone im Regal liegen.

Bin ich da auf dem richtigen Pfad?
Als nächstes wäre nun eine Testinstallation Basis + Rover zu stricken.
Ich kaufe mir zwei "passende" rohdatenfähige Empfänger - aber welche?

LEA-4T bei DHgate
US $34.20 pro Stück zzgl Versand aus China

oder Navilock NL-507TTL
vgl. http://opendgps.de/system-integration-m ... lox-lea-4/
für z. B. 23 Euro hier
http://www.amazon.de/dp/B0011EAYV4/?tag ... B0011EAYV4
oder wo auch immer - sind die schlechter als die chinesen-lea-4t?

Das alte navilock würde ich eigentlich nicht mehr nehmen wollen, vor allem brauch ich noch einen TTL-USB-Konverter, und mit 9600 baud komm ich vermutlich schnell an Flaschenhäsle, oder? Hm, gilt das Gleiche nicht auch für das 4T-Modul aus China?

Aslo doch besser weil "u-blox 6 recommended for new designs." und USB-Anschluss:
http://www.csgshop.com/product.php?id_product=127
UBLOX LEA-6T GPS receiver module für 146 $ aus USA

Es gibt auch noch diverse Navilock-Mäuse in der e-Bucht, aber nirgends finde ich einen expliziten Verweis auf die raw- bzw Timing-funktion. Also Finger weg? oder gibt es was brauchbares im < 100 Euro-plug-and-play-Bereich?
so 'ne Maus im fertigen Gehäuse mit angegossenem Stecker hätte schon was für sich...

Nächster Schritt wäre die Installation einer Basisstation auf meinem Büroserver.
Da läuft SuSE 10.0 drauf (never change a running system...) ... macht das noch Sinn?
Oder reicht ein Raspberry Pi für einen Referenzsignal-Server? Trenne Produktion und Basteleien...
Oder ein openwrt? Hab noch einen Asus 500 tralala übrig...

Für die Signalübertragung würde ich TCP-IP wählen, und zwar über diesen Weg:
Referenz-GPS <-> [evtl. extra Server] <-> Home-Server <-(DSL)-(Internet)> 1&1-linux-root-server <-(Internet)-(UTMS)-(USB-Stick)-> mobiler Rechner (raspberry?) <-> mobiler GPS-Empfänger

Den root-server habe ich ohnehin, weil ich andere Verbindungen drüber aufbauen möchte.
Welches Protokoll? RTFM.... http://www.rtklib.com/rtklib_document.htm
Kann der Home-Server (variable IP) auf dem Internet-Server(feste IP) Daten ablegen (http, ftp, ...) und der Mobile sich diese dann dort holen? Wäre Netzwerkmäßig einfacher.
Alternative wäre eine transparente Tunnelverbindung (vermutlich n2n), so daß Basisstation und Rover sich direkt über private IP anpingen können. Das wollte ich für einen zweiten Betriebsstandort ohnehin für Mess- und Steuerzwecke konfigurieren, also kann ich es genauso gut auch nochmal parallel auf einen Traktor bauen. Bringt das für RTK Vorteile?

Welche Bandbreiten sind für die RTK-Signale erforderlich?
Welche Latenzzeiten sind akzeptabel?
Was passiert, wenn mal für einige Sekunden der Transfer ausfällt?
Ich denke, für Lenkzwecke muß ich sicher deutlich unter eine Sekunde Reaktionszeit kommen (typische Fahrgeschwindigkeit 2 m/s = 7,2 km/h, wäre 20 cm Korrekturabstand bei 10 Hz Signalfrequzenz).
Aber ändert sich auch das Korrektursignal so schnell? Was fließt da ein? Bahndaten, Ionosphäre, Reflexionen...????

Wie ist die erwartete Genauigkeit, wenn zwischen Basis und Rover viele Hügel, Landschaft und 10 km Luftlinie liegen?
Datenübertragungsmäßig sollte das nach meiner geplanten Architektur über Internet/Handynetz kein Problem sein, aber sind verfügbare Satelliten / Reflexionen / Ionosphäre / was weiß ich noch ... etc noch übertragbar?

Und wenn dann die statische Positionsbestimmung steht, geht die Arbeit erst richtig los.
Parallelfahren, Spur nachfahren, Spuren abspeichern und wieder nachfahren, Geländeneigungen und dgl. auskorrigieren etc...
Abweichung feststellen, Korrektursignal an Hydraulik senden, Räder drehen/Rahmen verschieben - real action eben
Gibt es da schon was im open-source-Bereich, worauf man zurück greifen kann? Autopiloten?
Oder gilt es, ein neues Fass aufzumachen?

Hat jemand Lust, mit zu basteln und Erfahrung einzubringen?
Nicht, daß ich das ganze Budget eines Trimble Truetrackers verheizen könnte, aber ein paar Euros wäre es mir schon wert, wenn ich mich auf Netzwerk, Schweißen und Hydraulik konzentrieren könnte, was ich mir zutraue.

Grüße
Wolfgang Rosner

Hallo Wolfgang,

na, nach dem Durchlesen werden einige erstmal luftholen - und sich dann melden.

Ich kann nur Michael verpetzen (es muss unter uns bleiben) was die Kombination ublox-Raspberry betrifft. Die hat er mir schonmal empfohlen.
Wenn man hier aber regelmäßig mitliest, weiß man nicht mehr, was man anschaffen soll

big

Grüße Roland

Roland hat geschrieben:Wenn man hier aber regelmäßig mitliest, weiß man nicht mehr, was man anschaffen soll

Ja, genauso ging es mir gestern abend, als ich hier reingegoogelt habe.

Aber ich denke, ich werde es mal mit Raspberry und u-blox ( NL 507ETTL ) versuchen.
Der Raspberry war mir auf Anhieb sympathisch, und ich will ihn auch noch für einige andere Projekte nutzen. (Anlagenüberwachung, Meßdatenerfassung, GPS-Tracking mit Online-Datentransfer zur Dokumentation auf dem Schlepper...)

Die Kombination wird auch hier empfohlen:
http://opendgps.de/turbomodus-beim-rasp ... mment-1002

Inwieweit überschneiden sich die Akteure hier im Forum mit den Leuten in opendgps?

Für mich wäre eine Art "Howto" für die Installation u-blox / Raspberry / ntrip-Server
sowohl als Basis als auch als Rover hilfreich.
Ich will auch gerne in Vorleistung gehen und mit einem Skelett als Rohling anfangen.
Werde ich eine Chance haben, daß mir jemand dann die offenen Fragen beantwortet?
Im Prozess der Installation würde dann eine erste Version des Howto's entstehen, die dann wieder an die Community geht.

Welche Plattform? Einfach ein OpenOffice Writer Dokument?

wrosner hat geschrieben: ...
Aber ich denke, ich werde es mal mit Raspberry und u-blox ( NL 507ETTL ) versuchen.
...
Die Kombination wird auch hier empfohlen:
http://opendgps.de/turbomodus-beim-rasp ... mment-1002

Inwieweit überschneiden sich die Akteure hier im Forum mit den Leuten in opendgps?
...

Hallo Wolfgang,
zunächst mal ein herzliches Willkommen hier im Forum!

Es gibt sicher keine bessere oder auch nur annähernd vergleichbare (deutschsprachige) Anlaufstelle, wenn man neu ins Thema "Low-Cost-RTK mit den günstigsten L1-Trägerphasen-Rohdatenempfängern" einsteigt.

Zumal sich hier auch einige Teilnehmer tummeln, die insbesondere die Verwendung im Ackerbau damit im Sinne haben.
Nicht nur ich selbst, sondern z.B. auch ein Kollege aus Österreich (http://www.kowoma.de/gpsforum/viewtopic ... 967#p13606) ...

Was speziell die Kombination eines Raspberry Pi mit der (unschlagbar preisgünstigen) Navilock-Platine betrifft, so ist wohl "cr_gps" hier im Forum der am stärksten erfahrene (und auch fachkundige) Anwender. Und ich glaube, er ist auch höchstselbst die personelle Verbindung zu der opendgps-Seite ...

Dein Vorhaben, die "ersten Schritte" mit diesem Navilock-Modul (oder auch einem etwas aktuelleren Empfänger) in Kombination mit RTKLIB@Linux@ARM hier ein wenig detaillierter zu beschreiben, wird sicher von vielen Interessenten freudig begrüßt!

Denn nicht nur Neueinsteiger, sondern gewiss auch etliche "alte Hasen" werden wohl doch sehr dankbar über genauere Informationen darüber sein, wie man RTKNAVI auf einem solch kleinen Rechnerlein zum Laufen bekommt.

Es gibt weltweit auch schon einige kommerzielle Projekte in dieser Richtung (an einem davon bin ich selbst auch mit am Rande beteiligt), aber von denen wird wohl kaum allzuviel an technischen Details bzw. gerade in Richtung einer "Selbstbauanleitung" an die Öffentlichkeit gelangen.

Viele Grüße aus dem Muldental,
Hagen

Hallo,

jetzt meld ich mich hier auch mal, nachdem ich schon etwas hier mitgelesen habe.

Ich interessiere mich auch für DGPS in Verbindung mit der RTKLIB im embedded Bereich. Dazu habe ich mir ein Board mit einem NV08C Modul gebaut, ähnlich dem Denga10
http://www.onetalent-gnss.com/ideas/usb ... rs/denga10
nur etwas kleiner und kommt im Selbstbau deutlich billiger
Die Module funktionieren bis jetzt gut, allerdings fehlt mir noch eine zweite aktive Antenne um wirklich DGPS realisieren zu können.
Als embedded Plattform würde ich entweder diverse ARM Boards, wie den RaspberryPI, wobei es hier für nur etwas mehr Geld deutlich bessere Alternativen gibt (Hackberry oder Cupieboard, neuere Prozessorgeneration und besseres Energiekonzept) oder man verwendet Android basierte Systeme. Hier ist die Schnittstelle nach aussen allerdings etwas problematisch und der kleinste gemeinsame Nenner ist mMn Bluetooth. Bei Android hat man den Vorteil von einem fertigen mobilen Gerät und man kann die Koordination über das Betriebssystem allen anderen Anwendung transparent zur Verfügung stellen. Allderings kann man nur unter Java und etwas eingeschränkt C/C++ programmieren.

Vorerst hab ich mir einen RaspberryPI besorgt und mal die RTKLIB darauf kompiliert. Wenn man rtkrcv verwendet muss man darauf achten, dass die *.sh Dateien ausführbar sind. Leider sind Teile der RTKLIB nicht ganz sauber geschrieben (zB nvs.c), dh es gibt bei manchen casts Alignment Probleme (float und double casts aus einem char Array) und rtkrcv verabschiedet sich mit einem "BUS ERROR". Hier hilft entweder das Tracefile (rtkrcv mit -t x starten) oder man startet rtkrcv mit dem gdb. Beim compilieren gibt es aber auch bereits Warnings bei den betreffenden Stellen. Das ganze fällt aber auf x86 Prozessoren nicht auf.
Im Hinblick auf die Weiterentwicklung der RTKLIB und Behebung der oben genannten Bugs wäre es von Vorteil wenn die RTKLIB etwas offener Entwickelt würde, ich werde wahrscheinlich nach dem neuen Release der RTKLIB eine Version mit den Fixes auf github stellen, damit ist es allgemein verfügbar und die Änderungen könnten auch wieder zurück fließen.

Ich denke mit etwas Einsatz und dem Knowhow der RTKLIB lassen sich solche System durchaus auch im Hobby/Semiprofessionellen Bereich realsieren.

lg
thomas

Hallo, thomash,

....eine Version mit den Fixes auf github stellen, damit ist es allgemein verfügbar....

wäre es vermessen, schon mal vorab um ein diff / patch zu bitten?
Ich hab' zwar eine grobe Ahnung, was es mit dem Alignment-Problemen auf sich haben könnte, aber ich fühlte mich jetzt nicht aus dem Stand in der Lage, das ohne Kenntnis der Programmdetails zu fixen.

....Dazu habe ich mir ein Board mit einem NV08C Modul gebaut....

Auch hier die Frage, ob Du nicht die Erfindung des Rades teilen und eine kleine Serie auflegen möchtest.

Ich hab' mir heute Nacht mal das "u-blox Antaris System Integration Manual" reingezogen und vor allem einen heiden Respekt vor den HF / Antennen / EMV-Details bekommen. Wenn mich mein Bauchgefühl nicht täuscht, liegt da mehr Optimierungspotential drin als in der Frage ob alte oder neue Receiverbaureihe.

Ist die Sandwichbauweise der Navilock-Billigmodule für Präzision wirklich geeignet?
Oder wäre es nicht besser, die Antenne vom Modul mit seinen digitalen Störsignalen räumlich zu trennen?
Das würde natürlich nach einem Board mit SMA-Stecker verlangen.

Abgesetzte Bauweise würde auch die Verwendung "professionellerer" Antennen erlauben, z. B. Trimble Bullet.
Vom Budget her würde ich sogar über eine Zephyr für die Basis nachdenken, wenn eine Einseitige Optimierung wirklich was bringt. Oder bewegen wir uns hier in der Region "95 % des Budgets für 5 % Verbesserung"?

Auch die Wetterfeste Montage ist mit abgesetzten Antennen einfacher.
Gut gefallen hat mir die Idee von Josef Gerstenberg mit dem Choke Ring.
http://www.kowoma.de/gpsforum/viewtopic ... 238#p14238

Wenn man da eine Patch-Antenne rein kriegt, könnte man da nicht auch genauso gut ein kpl. Sandwich-Modul a la NL-507TTL da einbauen?
Und dann noch einen Plastikdeckel drüber, entweder einen Eimer, oder vielleicht einen 250 mm KG-Rohrdeckel vgl. http://www.haus-reha-pool.de/contents/m ... topfen.jpg , der ist mehrere mm dick und sollte auch die Äste in den Waldwegen aushalten, die mich normalerweise jedes Jahr 1-2 Außenspiegel kosten.

Keine Ahnung, was so ein Deckel Dielektrizitätsmäßig mit dem Signal anstellt....
Neue Schlepper haben meist ein Plastikdach auf der Kabine, vielleicht wäre sogar drunter genug Platz, so eine Choke-ring-Konstruktion unterzubringen. Aber wenn da nun Carbonfasern drin wären... ???

grad gefunden:

kleines Minimal-Board für NV08C
http://shop.sysmocom.de/products/osmo-nvs-eval
EUR 107.10 (inc. VAT) ... DIY kit, PCB plus all components
Kit type: Only the PCB, no components (Subtract: EUR 95.20 (inc. VAT))
Kit type: Assembled PCB with all components (Add: EUR 71.40 (inc. VAT))

Wenn die 70 Euro nur für's Löten verlangen wird das wohl nicht so einfach sein???

Noch ein Modul mit dem ich liebäugle: Wholesale - ublox lea-4t ( gps module car )
http://www.dhgate.com/ublox-lea-4t-gps- ... a43d2.html
US $45.60 incl Versand (aber vermutlich zzgl Zoll)
Das "echte" hackerfreie lea-4t, für aktive Antennen, aber eben alten Technologie.

Was lässt sich vom gleichzeitigen Empfang der GPS- und Glonass-Satelliten beim NV08C erwarten?
Sollten mehr Satelliten nicht die Genauigkeit deutlich steigern?

wrosner hat geschrieben:grad gefunden:

Hab mir gerade das Schematic angesehen und das Board kann ich definitiv _nicht_ empfehlen, da ist nicht viel drann! Laut Datenblatt braucht das NV08C eine aktive Antenne, dh in die Atennenleitung wird am Board noch Geichspannung eingekoppelt und gleichzeitig HF abgeblockt, das sind zwar nur ein paar Bauteile, aber die fehlen auf dem Board. Backup Spannung würde ich nicht über eine Batterie sondern über Goldcaps machen, keine Levelschifter bei den seriellen Schnittstellen, damit kann man es nur über Konverter an eine PC-RS232 Schnittstelle anschließen. Und das Layout sieht auch nicht sehr überzeugend aus (eigentartig viele Vias neben der Atennenleitung, warum?)

wrosner hat geschrieben: Wenn die 70 Euro nur für's Löten verlangen wird das wohl nicht so einfach sein???

Das Löten ist ohne Erfahrung sicherlich nicht so einfach machbar, aber mit etwas Übung/Erfahrung überhaupt kein Problem. Allerdings sollte man auch das nötige Equipment dazu haben. Das Board kann man sicher noch ohne Mikroskop ferigen, aber wenn etwas wirklich mal nicht geht ist es mit freiem Auge meist mühsam. Aber den Preis finde ich völlig überzogen, nur mal so als Anhaltspunkt, die Bauteile (ohne Platine) bekommt man für unter 50 EUR.

wrosner hat geschrieben: wäre es vermessen, schon mal vorab um ein diff / patch zu bitten?

Nein eigentlich kein Problem, allerdings sollte das glaube ich derzeit nur beim NV08C Modul zu Problemen führen. Der Einfachheit halber würde ich es aber doch lieber auf github stellen, da muss ich es nicht jedem extra schicken. Werde das in den nächsten Tagen machen, und die offizielle Version bei späteren Update immer rein mergen.

wrosner hat geschrieben: Auch hier die Frage, ob Du nicht die Erfindung des Rades teilen und eine kleine Serie auflegen möchtest.

Auch kein Problem, allerdings braucht das Board noch eine kleines Redesign, aber nichts schlimmes bzw. hab ich noch nicht alles darauf getestet.
Mein Board sollte eigentlich genauso wie das Denga10 aufgebaut sein. Dh es gibt einen Dual USB to UART Konverter mit dem man beide Schnittstellen des NV08C ansprechen kann. Weiters ist noch ein FLASH für den UART Konverter drauf wo man USB Device Informationen persistent ablegen kann. Versorgt wird das ganze über USB, für die aktive Atennenversorgung gibt es eine Überstrombegrenzung. Man kann USB zu UART und NV08C über Jumper verbinden oder trennen. Damit kann man jeweils auch GPS oder UART Konverter alleine verwenden, ich häng mal ein Bild vom Layout an.
Allerdings werde ich wahrscheinlich eine neue Version davon machen mit dem NV08C-MCM und Bluetooth Schnittstelle.
http://www.nvs-gnss.com/products/receiv ... c-mcm.html
das ist nicht viel schwerer zu Löten, aber etwas billiger, kleiner und könnte sogar mit passiver Antenne betrieben werden. Aber das wird sicher noch einige Monate dauern, hab derzeit nicht so viel Zeit für das Projekt.

Bei DGPS Lösungen würde ich immer aktive externe Antennen verwenden, damit ist man viel flexibler. Ich würde mal mit dem Ublox Modul anfangen, das gibt es zu einem Fairen Preis und man kann später noch immer auf andere Module umsteigen. Wie gesagt das Löten und Fertigen ist keine Hexerei aber ganz ohne Equipment würde ich es eher wo kaufen.

Musste gerade schmunzeln: Hab eine Reportage auf ZDF_neo gesehen wo es um einen Farmer im Kongo ging. Er war dabei, entlang einer Schnur mitten auf einem riesigen Feld Kartoffeln zu stecken... da kam mir die Idee auf ein ironisches Wortspiel: Aus unserem Thema "poor mans precision farming" wird "precise mans poor farming"

So, Schluss mit Off-Topic...
Ich will an dieser Stelle mal den Hardware-Teufelskreis mit folgender Frage durchbrechen:

Welche Genauigkeits-Anforderungen hat Precise Farming ?

Hab so eine Idee im Hinterkopf an der ich selbst gerade mit einem Arduino Uno und einem Navilock NL-507ETTL bastle. Sobald ich die beiden zu meiner Zufriedenheit vernetzt habe kommt noch einmal die gleiche Ausstattung sowie zwei XBee-Module dazu.

Nun zu meiner Idee
Ziel:
Ein DGPS-System erstellen, welches auf Code-Messungen basiert und bei dem es ausreichend ist, lediglich an der Basis einen Rohdaten-Empfänger zu betreiben.

Grundidee DGPS:
Zum selben Zeitpunkt die selben Satelliten beobachten.

Annahme/Behauptung:
Solange an Basis und Rover die gleichen Satelliten empfangen werden kann bei einer kurzen Basislinie die Koordinatenabweichung der Basis als direkte Korrektur, ohne Berechnung von inosphärischen oder troposphärischen Korrekturen, an den Rover übermittelt werden.

Aufbau:
Ein Rohdatenempfänger als Basis. Ein nicht-Rohdatenempfänger als Rover, welcher an die Basis übermittelt, mit welchen Satelliten er seine Position ermittelt.
An der Basis werden nun zur Positionsberechnung lediglich die Satelliten verwendet die auch der Rover verwendet, womit die Bedingungen für DGPS wieder erfüllt sind.
Die ermittelten Ablagen der Basis von ihren Real-Koordinaten werden an den Rover übertragen und die Position verschlimmbessert.

Anmerkung:
Natürlich kann man so nur einen Rover bedienen. Wenn man die Positionsberechnung vom Arduino auf einen leistungsstärkeren Rechner verlagert und dabei verschiedene (sinnvolle) Satelliten-Kombinationen zur Positionsberechnung verwendet kann man auch mehr Rover bedienen.
Hab mich mal auf das wesentlichste beschränkt. Natürlich ist eine kurze Basislinie besser als eine lange Basislinie, die Formate müssen stimmen, etc. , etc. , etc. ...

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

Hagen.Felix hat geschrieben: Und ich glaube, er ist auch höchstselbst die personelle Verbindung zu der opendgps-Seite ...

Die Idee von "opendgps" finde ich gut, nur bei der technischen Kompetenz hapert es dort gewaltig und kein einziges Wort über die Flash-Empfänger von Navilock

thomash hat geschrieben: Allerdings werde ich wahrscheinlich eine neue Version davon machen mit dem NV08C-MCM und Bluetooth Schnittstelle.
http://www.nvs-gnss.com/products/receiv ... c-mcm.html

Die offizielle RAW-Firmware von NVS gibt es nur für -CSM

cr2_gps hat geschrieben: Die offizielle RAW-Firmware von NVS gibt es nur für -CSM

http://www.nvs-gnss.com/news/65-nvs-tec ... eries.html

soweit ich das sehe sollte das schon gehen?

cr2_gps hat geschrieben:

Hagen.Felix hat geschrieben: Und ich glaube, er ist auch höchstselbst die personelle Verbindung zu der opendgps-Seite ...

Die Idee von "opendgps" finde ich gut, nur bei der technischen Kompetenz hapert es dort gewaltig
...

Oh je, kleines Missverständnis meinerseits!

Ich glaubte bisher, Du wärst einer der Jungs beim OpenDGPS-Projekt ...

thomash hat geschrieben: ...
Laut Datenblatt braucht das NV08C eine aktive Antenne, dh in die Atennenleitung wird am Board noch Geichspannung eingekoppelt und gleichzeitig HF abgeblockt, das sind zwar nur ein paar Bauteile, aber die fehlen auf dem Board. Backup Spannung würde ich nicht über eine Batterie sondern über Goldcaps machen, ...

Hallo Thomas,

eine vom Platinenentwickler noch zusätzlich bereitgestellte Möglichkeit, aktive Antennen mit geeigneten Gleichspanungen zu versorgen, ist sicher recht sinnvoll.

Viele Antennen auf dem Markt (insbesondere die höherwertigen Modelle) benötigen ja eine Versorgungsspannung, deren spezifizierter Bereich häufig erst bei 5 Volt beginnt.

Aus diesem Grund gestaltet Michele (OneTalent GNSS) seine Platinen zumeist auch so, dass über einen dreipoligen Jumper auf eine solch höhere Spannung für die Antenne umgeschaltet werden kann.

Die Kosten der dafür erforderlichen Bauteile sind ja tatsächlich kaum der Rede wert.

Andererseits stellen natürlich die gängigen GNSS-Module für unsere Zwecke auch schon selbst zumindest eine kleine Versorgungsspannung für aktive Antennen bereit.

Wie dies im Blockdiagramm unter http://www.nvs-gnss.com/images/products/csm/bshcsm.jpg auch deutlich erkennbar ist.

Allerdings schränkt die Höhe dieser Spannung eben die Auswahl an möglichen Antennen etwas ein, weswegen ja z.B. NVS selbst auch die Tallysman TW2410 (http://www.tallysman.com/TW2410.php; Spannungsbereich 2,5 bis 5,5 V; LNA Gain 25 dB) und eben nicht deren ursprüngliche Ausführung (http://www.tallysman.com/TW2400.php; Spannungsbereich 3 bis 10 V; LNA Gain 28 dB) als höherwertige Alternative anbietet (http://www.nvs-gnss.com/products/antenn ... tenna.html).

Besonders schön wäre es natürlich, eine Option für 12 Volt (zusätzlich zu einer Option für 5 Volt) einer alternativen Versorgungsspannung für aktive Antennen vorzusehen, wenn man ohnehin schon ein völlig neues PCB-Design in Angriff nimmt.

Damit würde man sich manches schöne eBay-Schnäppchen erschließen können: ältere Modelle von seinerzeit sehr teuren Antennen, die gelegentlich aber doch noch 12 Volt benötigen. Wobei dies jedoch nicht unbedingt für den NVS-Empfänger gilt, da diese alten Schätzchen ja noch nicht auf den GLONASS-Frequenzen lauschen können. Aber für möglichst billige RTK-Systeme z.B. mit den bisherigen Modulen von u-blox durchaus noch recht interessant, um auch hier vielleicht noch mal einen Hunderter sparen zu können (z.B. im Vergleich zu zwei Stück TW2410).

Was die Batteriepufferung betrifft, so ist auch dies üblicherweise im GNSS-Modul bereits vorbereitet, so dass nur noch ein geeigneter Lithium-Akku am jeweiligen Pin des Moduls angeschlossen werden muss.

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 ...

Aber nun genug gemeckert!

Grundsätzlich ist ja erst mal der Ansatz zu würdigen, möglichst unkomplizierte und preisgünstige Platinen für die in Frage kommenden GNSS-Module mit Rohdatenausgabe zu entwerfen und diese Designs dann hier (oder auch irgendwo oder irgendwie anders) zur Verfügung zu stellen. Noch besser, wenn jemand ohne allzu viel kommerziellen Hintergrund eine entsprechende Kleinserie auflegt. Ich bin sicher, dass es schon allein in diesem Forum hier eine Menge Privatleute gibt, die dafür sehr dankbar wären!

Ich selbst hatte ja vor einiger Zeit "händeringend" nach einer solchen Möglichkeit gesucht, wobei ich natürlich dies nicht als Privatmann, sondern im beruflichen Kontext benötigt habe. Aber bei entsprechendem Herumfragen war es beileibe nicht so, dass hier eine Menge von alternativen Möglichkeiten zur Auswahl stand.

Zum Glück für mich hatte sich aus dieser Situation jedoch der Kontakt zu Michele in Pisa ergeben. Was nicht nur mein damaliges Problem zur vollsten Zufriedenheit gelöst hat, sondern auch völlig neue Wege eröffnete ...

Aber zurück zum usprünglichen Thema.

Wenn ich den Kollegen Landmann richtig verstanden habe, ist er ja mit Mikroelektronik ebenso schon vertraut wie mit Hard- und Software, die man eben so braucht für solche Low-Cost-RTK-Systeme.

Eine "lose" Platine (vielleicht aber schon wenigstens SMD-bestückt) würde ihm also möglicherweise schon völlig genügen (für solche Fälle könnte ich die Rohplatinen von Michele aber auch von Deutschland aus anbieten, auch wenn ich sie sonst nicht "offiziell" offeriere).

Der größte Bedarf scheint hier aber eher sogar an einer Art "Einstiegsleitfaden" zu bestehen, wenn sich jemand bisher noch nie mit der für RTK notwendigen (speziellen) Technik befasst hat:
Welche Art von Empfänger wird überhaupt benötigt? Welche Unterschiede bestehen beispielsweise zwischen einer dieser supergünstigen Navilock-Platinen (mit "erzwungener" Rohdatenausgabe), dem ebenso billigen Veteranen LEA-4T, einem LEA-6T (Stolperfalle: ROM-/Flash-Versionen) oder meinetwegen auch einem NEO-6P für diese ganz speziellen Anwendungen? Wie groß ist der Vorteil aus den zusätzlichen GLONASS-Rohdaten, die ein NVS-Modul liefern kann? Was gibt es beim Thema Antenne zu beachten? usw. usw.

Und dann kommt natürlich noch der Riesenbrocken des Einstiegs in die RTKLIB, dieser "ewigen Baustelle" ...

Also Fragen über Fragen!

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 ... ), im Forum oder einer vergleichbaren "Community" jedoch viel besser realisierbar ...

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" ...

Mit besten Grüßen aus dem Muldental,
Hagen