Endlich GPS für Multiwii
- Themenstarter RC FAN
- Beginndatum
Nö mein video weiter vorn ist mit dem crius auf nmea am crius aoi und deiner baro version .
Wer Kabel anlöte und umprogrammieren will GPS in DE
http://www.ebay.de/sch/i.html?_trksid=p5197.m570.l1313&_nkw=u-blox+ttl&_sacat=0&_from=R40
http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011EAYV4
Für die Ublox GPS Module kann man eine Datei erstellen die alle nötigen Einstellungen enthällt dann spart man die ganzen Datensätze zu aktivieren.
Welche Daten braucht man ?
Alternativ baut Ublox auch module mit höherer Genauigkeit P type leider deutlich teurer.
http://www.csgshop.com/category.php?id_category=16
http://www.u-blox.com/en/gps-modules/neo-6p-/neo-6p.html
http://www.u-blox.com/images/stories/linecards_u-blox_gps_modules_2012.pdf
Wer Kabel anlöte und umprogrammieren will GPS in DE
http://www.ebay.de/sch/i.html?_trksid=p5197.m570.l1313&_nkw=u-blox+ttl&_sacat=0&_from=R40
http://www.amazon.de/Navilock-NL-507TTL-u-blox-TTL-Modul/dp/B0011EAYV4
Für die Ublox GPS Module kann man eine Datei erstellen die alle nötigen Einstellungen enthällt dann spart man die ganzen Datensätze zu aktivieren.
Welche Daten braucht man ?
Alternativ baut Ublox auch module mit höherer Genauigkeit P type leider deutlich teurer.
http://www.csgshop.com/category.php?id_category=16
http://www.u-blox.com/en/gps-modules/neo-6p-/neo-6p.html
http://www.u-blox.com/images/stories/linecards_u-blox_gps_modules_2012.pdf
Zuletzt bearbeitet:
Plausibilitätsprüfung
Hallo zusammen,
erstmal möchte ich zum Ausdruck bringen,wie toll ich die Arbeit der Programierer und Optimierer ,
aber auch der Tester die, die Software-Änderungen ausprobieren bewundere.
Da die NAZA-Steuerung keine Tri-Kopter kann, habe ich mich für eine LZ-Midi mit LZ-GPS
für meinen neuen Tri-Kopter entschieden und lese schon ein Weilchen länger hier mit.
Vom programieren speziell für Arduino bzw. in C habe ich keine Ahnung und kann somit auch mit
dem Open-Source-Code nichts anfangen aber die Idee von Roberto mit dem Spikefilter find ich gut.
Mir ist dabei aber noch die Idee gekommen, aufgrund der Werte der Beschleunigungs-Sensoren
die Werte des Baro und des GPS auf Plausibilität zu prüfen.
D.h. wenn der Beschleunigungs-Sensor keine bzw.nur geringe Werte auf der Z-Achse meldet,
sind größere Veränderungen bei den Werten des Baro's Blödsinn.
Ob diese Verknüpfung im Programm besteht kann ich leider wegen mangeldem Wissen nicht sagen,
sinnvoll wäre sie aber.
Gruß Plums
Hallo zusammen,
erstmal möchte ich zum Ausdruck bringen,wie toll ich die Arbeit der Programierer und Optimierer ,
aber auch der Tester die, die Software-Änderungen ausprobieren bewundere.
Da die NAZA-Steuerung keine Tri-Kopter kann, habe ich mich für eine LZ-Midi mit LZ-GPS
für meinen neuen Tri-Kopter entschieden und lese schon ein Weilchen länger hier mit.
Vom programieren speziell für Arduino bzw. in C habe ich keine Ahnung und kann somit auch mit
dem Open-Source-Code nichts anfangen aber die Idee von Roberto mit dem Spikefilter find ich gut.
Mir ist dabei aber noch die Idee gekommen, aufgrund der Werte der Beschleunigungs-Sensoren
die Werte des Baro und des GPS auf Plausibilität zu prüfen.
D.h. wenn der Beschleunigungs-Sensor keine bzw.nur geringe Werte auf der Z-Achse meldet,
sind größere Veränderungen bei den Werten des Baro's Blödsinn.
Ob diese Verknüpfung im Programm besteht kann ich leider wegen mangeldem Wissen nicht sagen,
sinnvoll wäre sie aber.
Gruß Plums
na, nur das Beste Was wo gibt. µ-BLOX 
ganz einfach mal guken.
- https://www.mikrocontroller.com/images/MKGPS_V2.1_CE.jpg
kannste auch im MWC verbauen.
ganz einfach mal guken.
- https://www.mikrocontroller.com/images/MKGPS_V2.1_CE.jpg
kannste auch im MWC verbauen.
@Plums: Die Integration von Acc und Baro ist erledigt (http://fpv-community.de/showthread.php?14199-Baro-Code-%C4nderungen&p=224135&viewfull=1#post224135) !!! Das war nur ein Beispiel, wie man verspikte Daten filtern kann, ohne eine grosse Latenz zu produzieren. Dazu habe ich einfach mal rohe Barodaten genommen, da ich im Haus keine GPS Daten habe. Draussen bin ich mit dem Laptop nicht lange, bei dem Wetter. Eigentlich habe ich auch rel gute ACC Daten für X und Y, die ich gerne mit dem GPS kombiniert hätte, das wirft für mich allerdings noch zu viele Probleme auf. Nur ACC ohne Korrektur (Baro/GPS/Gyro) geht nicht, da innerhalb weniger Sekunden ein riesen Fehler aufläuft.
@fdietsch: Danke, für Deine Info, jetzt habe ich noch ein paar Fragezeichen mehr .
Die APM verwendet 5Hz GPS Daten (egal ob ublox oder mtk). Bei der derzeitigen eos bandi Variante verbietet sich dann eine weitere Filterung, weil dann die Latenz zu hoch werden würde. Ich SCHÄTZE mal, dass in dem Fall der Spikefilter gute Dienste leisten würde, weil er quasi latenzfrei arbeitet und kurze Aussreisserwerte ignoriert und der letzte "gute" durchgegeben wird.
Ich kann ja mal die Baroversion ("MultiWii_dev_r1232_NewBaroPID.zip"), die auch mit ublox funktioniert, um den Spikefilter ergänzen, dann könnten hier die Ublox Nutzer mal testen, ob das etwas bringt.
LG
Rob
@fdietsch: Danke, für Deine Info, jetzt habe ich noch ein paar Fragezeichen mehr
.Die APM verwendet 5Hz GPS Daten (egal ob ublox oder mtk). Bei der derzeitigen eos bandi Variante verbietet sich dann eine weitere Filterung, weil dann die Latenz zu hoch werden würde. Ich SCHÄTZE mal, dass in dem Fall der Spikefilter gute Dienste leisten würde, weil er quasi latenzfrei arbeitet und kurze Aussreisserwerte ignoriert und der letzte "gute" durchgegeben wird.
Ich kann ja mal die Baroversion ("MultiWii_dev_r1232_NewBaroPID.zip"), die auch mit ublox funktioniert, um den Spikefilter ergänzen, dann könnten hier die Ublox Nutzer mal testen, ob das etwas bringt.
LG
Rob
Rob mir ist gerade noch was eingefallen beim Testen habe ich das PH Postition Hold eingeschaltet und schlagartig wollte er weg ? Da kannste gegenknüppeln...und es wird immer schlimmer . Aus und wieder einschalten und schon ist alles Gut.
Kann es sein daß ich da im Einschalten einen GPS spike erwischt habe oder daß da im Speicher noch datenmüll vom letzten mal stand.?
Kann es sein daß ich da im Einschalten einen GPS spike erwischt habe oder daß da im Speicher noch datenmüll vom letzten mal stand.?
Das ist ein Video vom Spätsommer, einer der ersten Flüge mit MW 2.1 und GPS
Wie groß der Radius ist, weiss ich nicht. Der Copter hat 45cm Diagonale, mal zur Orientierung.
https://docs.google.com/open?id=0B0Gg0xMWEdCOVUtiazN0WERlTFU
Wie groß der Radius ist, weiss ich nicht. Der Copter hat 45cm Diagonale, mal zur Orientierung.
https://docs.google.com/open?id=0B0Gg0xMWEdCOVUtiazN0WERlTFU
Hallo, hatte huete endlich die chance bei strahlendem sonnenschein wolles LZ-GPS zu testen,
zum Setup:
Oktokopter mit Microwii multiWii 2.1 auf standartwerten
am boden gewartet bis fix (dauerte 2 in, normal ?)
dann ein bissel auf höhe gegangen, baro und mag an (baro taumelt noch ein bissel)
dann einen moment gewartet (war windstill stand halbwegs an einer stelle)
und GPS Pos-Hold an,
funktionierte beim ersten mal ganz prima, irgendwan aus, ein bissel rumgedüst
pos-hold wieder an, es dauerte 5 sec und er prügelte schräg nach forn weg,
Pos-Hold aus, manuell zurück gesteuert,
Pos-Hold an, nach wieder 5-10 sec, prügelte er in die gleiche richtung weg, erst ein wenig nach hinten und dann recht stark schräg forn, wieder manuell zurück geholt,...
das ganze hab ich 4 mal so gehabt, beim 6. mal pos hold gings wieder prima,
also quasi :
+, -, -, -, -, +
Allerdings hab ich noch NULL PID's getuned an dem kopter weder für die normale steuerung noch für GPS... vllt kann mir jemand einen tip geben, wie ich die PID's für Baro und Gps einstellen muss // soll ??
Auf jeden fall gut zu sehn wie er sich selbst hält sieht schonmal toll aus
MFG Butcher
zum Setup:
Oktokopter mit Microwii multiWii 2.1 auf standartwerten
am boden gewartet bis fix (dauerte 2 in, normal ?)
dann ein bissel auf höhe gegangen, baro und mag an (baro taumelt noch ein bissel)
dann einen moment gewartet (war windstill stand halbwegs an einer stelle)
und GPS Pos-Hold an,
funktionierte beim ersten mal ganz prima, irgendwan aus, ein bissel rumgedüst
pos-hold wieder an, es dauerte 5 sec und er prügelte schräg nach forn weg,
Pos-Hold aus, manuell zurück gesteuert,
Pos-Hold an, nach wieder 5-10 sec, prügelte er in die gleiche richtung weg, erst ein wenig nach hinten und dann recht stark schräg forn, wieder manuell zurück geholt,...
das ganze hab ich 4 mal so gehabt, beim 6. mal pos hold gings wieder prima,
also quasi :
+, -, -, -, -, +
Allerdings hab ich noch NULL PID's getuned an dem kopter weder für die normale steuerung noch für GPS... vllt kann mir jemand einen tip geben, wie ich die PID's für Baro und Gps einstellen muss // soll ??
Auf jeden fall gut zu sehn wie er sich selbst hält sieht schonmal toll aus
MFG Butcher
@Butcher:
Deine Beobachtungen sind m.E Softwarefehler im eos bandi code. Ich habe dazu mal etwas hier gepostet: http://www.multiwii.com/forum/viewtopic.php?f=8&t=649&start=1480#p27600 mal sehen, wie da reagiert wird.
M.E. ist das serial.read() das Hauptproblem. Aktuell habe ich das GPS Modul hier mit http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q= auf eine binärmodus kompatible FW geflasht und den EOS Bandi code auf 57K serielle Geschwindigkeit programmiert, das scheint etwas zu bringen. Meine Befürchtung: Auf kurz oder lang wird man wohl den multiwii eigenen, seriellen code in die EOS Bandi Version einbauen müssen. Bis zum Beweis des Gegenteils, gehe ich von einer fehlerhaften, seriellen Datenaquisition/Auswertung aus, die zu den von Dir beschriebenen Symptomen führt.
LG
Rob
Deine Beobachtungen sind m.E Softwarefehler im eos bandi code. Ich habe dazu mal etwas hier gepostet: http://www.multiwii.com/forum/viewtopic.php?f=8&t=649&start=1480#p27600 mal sehen, wie da reagiert wird.
M.E. ist das serial.read() das Hauptproblem. Aktuell habe ich das GPS Modul hier mit http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q= auf eine binärmodus kompatible FW geflasht und den EOS Bandi code auf 57K serielle Geschwindigkeit programmiert, das scheint etwas zu bringen. Meine Befürchtung: Auf kurz oder lang wird man wohl den multiwii eigenen, seriellen code in die EOS Bandi Version einbauen müssen. Bis zum Beweis des Gegenteils, gehe ich von einer fehlerhaften, seriellen Datenaquisition/Auswertung aus, die zu den von Dir beschriebenen Symptomen führt.
LG
Rob
Ja, ich denke Deine Vermutung ist korrekt.
Grundsätzlich, und das betrifft auch meinen vorherigen Post, ist ein GPS nur im Freien beurteilbar, ohne Bebauung. Der Test im Hinterhof kann nicht aussagekräftig sein.
Bislang habe ich das GPS hauptsächlich unter ungünstigen Bedingungen (Balkon) getestet. Dennoch habe ich reproduzierbar Probleme mit 115K Baud serieller Übertragung zwischen GPS und eos bandi I2C code. M.E ist das arduino hauseigene serial.read() das Problem bei 115K, was vermutlich aus ähnlichen Gründen, im mwii code (Hauptsteuerung) nicht verwendet wird. Dort kommt ein selbst geschriebener Treiber zum Einsatz. Jetzt muss sich nur noch jemand finden, der den in den I2C code packt.....
LG
Rob
LG
Rob
Grundsätzlich, und das betrifft auch meinen vorherigen Post, ist ein GPS nur im Freien beurteilbar, ohne Bebauung. Der Test im Hinterhof kann nicht aussagekräftig sein.
Bislang habe ich das GPS hauptsächlich unter ungünstigen Bedingungen (Balkon) getestet. Dennoch habe ich reproduzierbar Probleme mit 115K Baud serieller Übertragung zwischen GPS und eos bandi I2C code. M.E ist das arduino hauseigene serial.read() das Problem bei 115K, was vermutlich aus ähnlichen Gründen, im mwii code (Hauptsteuerung) nicht verwendet wird. Dort kommt ein selbst geschriebener Treiber zum Einsatz. Jetzt muss sich nur noch jemand finden, der den in den I2C code packt.....
LG
Rob
LG
Rob
Zuletzt bearbeitet:
Servus Jungs,
habe mal was anderes, dass aber indirekt auch hierher passt.
Ich habe heute festgestellt, dass das Kalibrieren über Bluetooth offensichtlich nicht so ganz passt. Über die App " Multiwii EZ GUI"
habe ich Kompass und Mag kalibriert und dann in der GUI (über Kabel) festgestellt, dass Roll, Nick und Mag Abweichungen hatten.
Erklärung habe ich natürlich keine, aber wenn ich jetzt mal draußen kalibrieren muss werde ich wieder die Stick Kombinationen nehmen.
Gruß bigbretl
habe mal was anderes, dass aber indirekt auch hierher passt.
Ich habe heute festgestellt, dass das Kalibrieren über Bluetooth offensichtlich nicht so ganz passt. Über die App " Multiwii EZ GUI"
habe ich Kompass und Mag kalibriert und dann in der GUI (über Kabel) festgestellt, dass Roll, Nick und Mag Abweichungen hatten.
Erklärung habe ich natürlich keine, aber wenn ich jetzt mal draußen kalibrieren muss werde ich wieder die Stick Kombinationen nehmen.
Gruß bigbretl
Hi!
Update:
Es gibt sehr, sehr, sehr, sehr erfreuliche Neuigkeiten für alle MTK (MT3329) Nutzer (LZ GPS, APM, Flyduino usw.). Warum soll ublox so viel besser sein als MTK? Nach meinen Experimenten mit eos bandi code und nmea habe ich mich gefragt, wie die überhaupt ein Modul verkaufen können. Der Verdacht einer fehlerhaften Datenaquisition liegt nahe. NMEA ist immer die zweite Wahl, weil gegenüber einem Binärprotokoll (direkt die wichtigen Zahlen) das Datenaufkommen erhöht und meistens die Genauigkeit (Stellenanzahl) reduziert ist. Alles muss nämlich in Ascii Langtext übersetzt werden. Das MTK Binärprotokoll muss also funktionieren. Als erstes dachte ich an einen schwachen seriellen Teil des eos bandi codes und habe ihn durch die direkte mwii Version ersetzt (hat sich ja kein Freiwilliger gemeldet). Der gewünschte Erfolg, bis auf eine Reduktion der Codesize blieb aus. Es funktioniert, vermutlich besser als die original arduino serial.x Funktionen, also lasse ich es drin. Die geflashte FW AXN1.51_2722_3329_384.1151100.5.bin (http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q=) mit Unterstützung des APM "custom" Binärprotokolls (http://stuff.storediydrones.com/reference/CustomizeFunctionSpecificationv16.doc) brachte auch nicht den Durchbruch. Dann habe ich den Datenstrom mit Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) und Hexedit (http://hexedit.nextsoft.de/) (BTW: alles Freeware) untersucht und musste doch erhebliche Abweichungen von den Arducopter/APM Vorgaben feststellen (Dokument). Realität und Fiktion (APM/3DR-Dokument) treffen aufeinander. Die APM und eos bandi (Kopie) lesen den tatsächlichen, binären Datenstrom fehlerhaft aus. Diese Aussage trifft auf die APM natürlich nur zu, wenn dort nicht eine andere FW verwendet wird. Für die Mwii stimmt es auf alle Fälle. Auch die aktuelle APM Version macht da keine Ausnahme, das hätte mir nämlich viel Arbeit erspart. Es gibt mehrere Probleme. Zum einen wird eine Checksumme überprüft, die erst GARNICHT übertragen wird (!) und zum anderen wird das Kauderwelsch (eigentlich ein kontinuierlicher, verkürzter und gleicher Datenstrom, der aber nicht dokumentiert ist) bei nicht vorhandenen Satelliten/Fix m.E nur zufällig, wenn überhaupt adäquat, abgehandelt. Also musste ich den kompletten Binärtreiber neu schrieben. Dabei habe ich mich, als Praktiker (Motto: die SchXXXX muss laufen), daran gehalten, was das MTK Modul tatsächlich liefert. Die, für mich als nicht Programmierer, verwirrende Komplexität des original Treibers habe ich weg gelassen. Meine jetzige Version liesst jedes Byte wirklich "per Hand" aus. Das hat Vor und Nachteile. Vorteil: Schneller, idiotensicher, plötzlicher Sat Verlust führt nicht zu falschen Koordinaten. Nachteil: Für Programmierer lachhafter code, erhöhter Speicherverbrauch (immer noch fast 10K frei auf LZ GPS). Die Checksummenüberprüfung habe ich eliminiert da, erstens kein serieller Übertragunsfehler im Beobachtungszeitraum (mehrere Minuten) auftrat (vielleicht ein Benefit der Umsetzung der mwii-seriellen-Funktionen - die Hoffnung bleibt, dass die Arbeit etwas gebracht hat), zweitens eine 1-Byte Checksumme sowieso nicht besonders aussagekräftig ist und drittens ein einzelner Ausreisser (selbst jede Sekunde 2 Fehler) von meinem Spikefilter gefressen wird. So, jetzt kommt der Hammer, meine Arbeit kostet euch alle ein Päckchen Zigaretten pro Download, das geht nur als .hex File raus und ist gesünder für die Lunge! War nur ein übler Scherz (@mahowik - mwii forum), es bleibt OPEN SOURCE, alle sollen etwas davon haben!! Momentan habe ich noch 2 Probleme, die mich von einer Downloadversion abhalten:
1.: Der Code ist nur bei stehendem Copter getestet - Freiflug steht noch aus (Wetter ........)
2.: Um die Sat-Fix Meldung habe ich mich noch nicht gekümmert, deswegen meint die mwii schon beim powerup GPS wäre OK......
Fazit: Bei MTK ist noch ordentlich Luft unter dem Gaspedal. Es muss nicht immer ublox sein. Ich bin der Ansicht, dass ein MTK Modul mit gleich grosser Antenne, einem vergleichbaren ublox Modul (6) das Wasser reichen kann.
LG
Rob
Update:
Es gibt sehr, sehr, sehr, sehr erfreuliche Neuigkeiten für alle MTK (MT3329) Nutzer (LZ GPS, APM, Flyduino usw.). Warum soll ublox so viel besser sein als MTK? Nach meinen Experimenten mit eos bandi code und nmea habe ich mich gefragt, wie die überhaupt ein Modul verkaufen können. Der Verdacht einer fehlerhaften Datenaquisition liegt nahe. NMEA ist immer die zweite Wahl, weil gegenüber einem Binärprotokoll (direkt die wichtigen Zahlen) das Datenaufkommen erhöht und meistens die Genauigkeit (Stellenanzahl) reduziert ist. Alles muss nämlich in Ascii Langtext übersetzt werden. Das MTK Binärprotokoll muss also funktionieren. Als erstes dachte ich an einen schwachen seriellen Teil des eos bandi codes und habe ihn durch die direkte mwii Version ersetzt (hat sich ja kein Freiwilliger gemeldet). Der gewünschte Erfolg, bis auf eine Reduktion der Codesize blieb aus. Es funktioniert, vermutlich besser als die original arduino serial.x Funktionen, also lasse ich es drin. Die geflashte FW AXN1.51_2722_3329_384.1151100.5.bin (http://code.google.com/p/i2c-gps-nav/downloads/detail?name=MTK-firmware-tools-for-2.1.zip&can=2&q=) mit Unterstützung des APM "custom" Binärprotokolls (http://stuff.storediydrones.com/reference/CustomizeFunctionSpecificationv16.doc) brachte auch nicht den Durchbruch. Dann habe ich den Datenstrom mit Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) und Hexedit (http://hexedit.nextsoft.de/) (BTW: alles Freeware) untersucht und musste doch erhebliche Abweichungen von den Arducopter/APM Vorgaben feststellen (Dokument). Realität und Fiktion (APM/3DR-Dokument) treffen aufeinander. Die APM und eos bandi (Kopie) lesen den tatsächlichen, binären Datenstrom fehlerhaft aus. Diese Aussage trifft auf die APM natürlich nur zu, wenn dort nicht eine andere FW verwendet wird. Für die Mwii stimmt es auf alle Fälle. Auch die aktuelle APM Version macht da keine Ausnahme, das hätte mir nämlich viel Arbeit erspart. Es gibt mehrere Probleme. Zum einen wird eine Checksumme überprüft, die erst GARNICHT übertragen wird (!) und zum anderen wird das Kauderwelsch (eigentlich ein kontinuierlicher, verkürzter und gleicher Datenstrom, der aber nicht dokumentiert ist) bei nicht vorhandenen Satelliten/Fix m.E nur zufällig, wenn überhaupt adäquat, abgehandelt. Also musste ich den kompletten Binärtreiber neu schrieben
. Dabei habe ich mich, als Praktiker (Motto: die SchXXXX muss laufen), daran gehalten, was das MTK Modul tatsächlich liefert. Die, für mich als nicht Programmierer, verwirrende Komplexität des original Treibers habe ich weg gelassen. Meine jetzige Version liesst jedes Byte wirklich "per Hand" aus. Das hat Vor und Nachteile. Vorteil: Schneller, idiotensicher, plötzlicher Sat Verlust führt nicht zu falschen Koordinaten. Nachteil: Für Programmierer lachhafter code, erhöhter Speicherverbrauch (immer noch fast 10K frei auf LZ GPS). Die Checksummenüberprüfung habe ich eliminiert da, erstens kein serieller Übertragunsfehler im Beobachtungszeitraum (mehrere Minuten) auftrat (vielleicht ein Benefit der Umsetzung der mwii-seriellen-Funktionen - die Hoffnung bleibt, dass die Arbeit etwas gebracht hat), zweitens eine 1-Byte Checksumme sowieso nicht besonders aussagekräftig ist und drittens ein einzelner Ausreisser (selbst jede Sekunde 2 Fehler) von meinem Spikefilter gefressen wird. So, jetzt kommt der Hammer, meine Arbeit kostet euch alle ein Päckchen Zigaretten pro Download, das geht nur als .hex File raus und ist gesünder für die Lunge! War nur ein übler Scherz (@mahowik - mwii forum), es bleibt OPEN SOURCE, alle sollen etwas davon haben!! Momentan habe ich noch 2 Probleme, die mich von einer Downloadversion abhalten:1.: Der Code ist nur bei stehendem Copter getestet - Freiflug steht noch aus (Wetter ..
......)2.: Um die Sat-Fix Meldung habe ich mich noch nicht gekümmert, deswegen meint die mwii schon beim powerup GPS wäre OK......
Fazit: Bei MTK ist noch ordentlich Luft unter dem Gaspedal. Es muss nicht immer ublox sein. Ich bin der Ansicht, dass ein MTK Modul mit gleich grosser Antenne, einem vergleichbaren ublox Modul (6) das Wasser reichen kann.
LG
Rob
Zuletzt bearbeitet:
