Hallo Zusammen,

ich bin nun soweit fertig mit meinem Redesign.
Ihr dürft nun hier darüber herziehen ;-).

Hallo

Mehr Info wären nicht schlecht....

Hallo killagreg,

kannst du mich mal anmailen ?

deine mail ist nicht frei.


jürgen

Nunja, ich habe gründlich aufgeräumt.

1. Bisher wurde alles in der main.h includiert und diese wiederum in alle anderen C-Files includert.
Damit ist allen Modulen immer alles bekannt. Das fördert nicht gerade dir Übersicht und Modularität des Codes.
Daher habe ich saubere Header Dateien für jedes C-File erstellt die auch nur die Funktionalität exportieren, die in anderen Modulen zwingend notwendig ist. Oberstes Ziel sind hier saubere Schnittstellen.
Diese Header werden dann direkt i dem C-File includiert, in dem die Funktionalität auch gebraucht wird. Das ermöglicht eine viel bessere Übersicht, welcher Code von welchem abhängt.

2. Ich habe alle Variablennamen englisch nach einem einheitlichen Schema benannt. Das Menü ist nuch auch englisch.

3. Ich habe nicht benutzte Variablen, oder Code der zwar berechnet wird, aber nicht weiter in die eigentliche Funktion eingeht, gelöscht. Damit wird vieles sehr viel übersichtlicher.

4. Ich habe versucht so viel wie möglich durch Kommentare zu erklären. Damit man später auch noch weiss warum es genau so programmiert ist.

5. Die Konfoguration der IO Ports erfolgt nicht mehr in der main.c sondern dezentral in den jeweiligen init() Funktionen der
Module. Somit ist immer klar welches Modul mit welchen IOs kommunizert. Damit bringen die Init() Funktionen alles mit um die saubere Funktionsweise des jeweiligen Modules zu gewährleisten.

6. Der Zugriff auf den EEprom erfolgte ein einem Mischmasch jeweils in eeprom.c und main.c sowie in fc.c. Um hier eine saubere modulare Schnittstelle zu erhalten, habe ich alle EEProm Zugriffe in eeprom.c zusammengefasst und über eeprom.h eine Schnittstelle zur Verfügung gestellt.

7. Ich habe die von abecker (http://forum.mikrokopter.de/topic-2972.html) vorgeschlagene Code-Optimierung der UART-Interrupt -Routine im Groben übernommen.

8. Ich habe nach Nick666s Vorbild (http://forum.mikrokopter.de/topic-3167.html) die twimaster.c aufgeräumt.

9. Einige kleinere Bugs, die mir wärend der Arbeiten aufgefallen sind habe ich gleich mit behoben. (Siehe http://forum.mikrokopter.de/topic-3307.html)

10. Die Notlandefunktion wurde verbessert. (Siehe Diskussion von JoKo und Holger http://forum.mikrokopter.de/topic-2839.html)

11. Ich habe auf der Grundlage von Nick666s MM3-Code ebenfalls eine MM3 Unterstützung mit verbesserter Neigungskompensation eingebaut. Die Berechnungen laufen ebenfalls auf den zeitsparenden Lookuptables für Sin und Cos (siehe mymath.c) die von Nick666 ud Joko eingeführ worden. Zusätzlich zum bisherigen Code wird hier ein Kommunikationsfehler zum MM3 erkannt und der CompassValue dann auf -1 gesetzt sowie mit 10Hz gepiept. Die Steuerung von SS-Not wird nicht statisch gesetzt, sondern vor jeder Kommunikation mit dem MM3. Das verhindert besser ein mögliches Einfriehren des MM3. Abweichend von Nicks Code wird PC4 ud PC5 der Erweiterungsschnittstelle genutzt um die SS-Not und RESET Leitung des MM3 zu steuern. Die mechanische Ausrichtung des MM3-Boards ist nun beliebig. und wird über einen Userparameter eingestellt. Ein möglicher Adresskonflikt der EEProm Kalibrationsdaten des MM3 mit den anderen Parametern im EEProm wurde behoben.

12. Die 2. UART des ATMEGA 644P wird nun voll unterstützt.

13. Ein Modul für das Dekodieren des GPS-UBX Protokolls wurde hinzugefügt. (Siehe ubx.c/ubx.h)

14. Eine GPS-Steuerung für Position Hold und Home ist nun ebenfalls integriert. Die Bedienung orientiert sich im Groben an JoKos Idee, also Home-Lernen bei Motren ein, und Position Hold wenn Roll/Nick-Sticks in Mittenposition etc. Wenn GPS aktivert wird, und keine Daten vom GPS empfangen werden gibts nen dauerpiepser. Falls kein 3D-Fix 4Hz Piepen, wenn alles ok ist schweigt der Summer. Sollte der MM3 bei aktivem GPS keine Daten mehr übermitteln wird die GPS-Regelung abgeschaltet. Insgesamt ist die GPS-Iplemetierung so ausgelegt das nur minimale Rechenzeit verwendet wird. Der PD-Regler wird also nur dann berechnet, wenn neue Daten vom GPS da sind. Das GPS wird derzeit nur über die 2. UART angesprochen. Die GPS Funktion habe ich noch nicht bis ins letzte Detail verifiziert.

So das wars für Erste.
Grüße Killagreg

Ich finde es toll, dass sich jemand so viel Mühe gemacht hat am Code zu arbeiten. Und besonders die Aufgabe freiwillig durchführt die sonst niemand gern macht (aufräumen). Bleibt aber für Standard MK-Piloten wie mich die Frage offen was bringts? Nun so lange niemand an dem Code weiter arbeitet (was jetzt evtl etwas leichter fallen sollte) und neue Funktionen integriert erstmal nicht viel (die meisten neuen Funktionen fallen für mich auch flach, da ich bisher weder Kompass noch GPS besitze)

Bleibt die Frage, weil es ja nicht der offizielle Code ist, was passiert bei Änderungen/wie lange hast Du Lust Updates einzupflegen? Im SVN sind schon einige überalterte Branches zu finden. Und im schlimmsten Fall, also wenn kaum jemand Deinen Code nutzen wird, eben weil der vermeintliche Vorteil für wenige bisher spürbar ist, wie lange bleibt die Lust für Updates erhalten?

Dein neuer Code geht besser an die Leute zu verteilen wenn Funktionen drin sind, die man schon immer haben wollte oder super toll sind
Ich selbst habe auch mal drüber geschaut und finde den Code wirklich übersichtlicher. Aber wie gesagt, den sieht ja niemand wenn der MK fliegt. Und da tut er (fast) genau so wie vorher auch. Bleibt erstmal zu hoffen das diese überarbeitete Version der Entwicklergemeinde noch einen positiven Schub nach vorne bringt.

Ich persönlich habe einen stabilisierten Sinkflug bei Minimalgas (damit man bei Wind einfacher Sinken kann) noch ganz oben meiner Wishlist . Holger hatte hier schon mal etwas in die Richtung durchblicken lassen.


Nächste Frage: Wurde der Code und die neuen Funktionen schon von mehreren Leuten getestet und für tauglich befunden oder ist alles bisher graue Theorie?

Was ist in Zukunft geplant - den Code möglichst kompatibel zum Original zu halten (nur "Codeclean") oder eher als Fork, der seinen eigenen Weg geht (wie es ja bereits angefangen hat mit den neuen Funktionen)?

Noch ein Vorschlag: Was haltet Ihr von einer minimalen Doku/Wikiseite zum Code, der zumindest die wichtigen Variablen und verfügbaren Funktionen in einer Übersicht darstellt?

erstens: gute arbeit! Ich hoff holger übernimmt das in den trunk.
leider kann ichs noch nicht übersetzen ums zu testen:

Compiling: uart1.c
avr-gcc -c -mmcu=atmega644 -I. -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=uart1.lst -std=gnu99 -DVERSION_MAJOR=0 -DVERSION_MINOR=68 -DVERSION_COMPATIBLE=7 -DVERSION_INDEX=3 uart1.c -o uart1.o
uart1.c: In function `USART1_Init':
uart1.c:35: error: `UCSR1B' undeclared (first use in this function)
uart1.c:35: error: (Each undeclared identifier is reported only once
uart1.c:35: error: for each function it appears in.)
uart1.c:35: error: `RXCIE1' undeclared (first use in this function)
uart1.c:37: error: `TXCIE1' undeclared (first use in this function)
uart1.c:39: error: `UDRIE1' undeclared (first use in this function)
uart1.c:52: error: `UBRR1H' undeclared (first use in this function)
uart1.c:53: error: `UBRR1L' undeclared (first use in this function)
uart1.c:56: error: `UCSR1A' undeclared (first use in this function)
uart1.c:56: error: `U2X1' undeclared (first use in this function)
uart1.c:58: error: `TXEN1' undeclared (first use in this function)
uart1.c:58: error: `RXEN1' undeclared (first use in this function)
uart1.c:60: error: `UCSR1C' undeclared (first use in this function)
uart1.c:60: error: `UMSEL11' undeclared (first use in this function)
uart1.c:61: error: `UMSEL10' undeclared (first use in this function)
uart1.c:63: error: `UPM11' undeclared (first use in this function)
uart1.c:64: error: `UPM10' undeclared (first use in this function)
uart1.c:66: error: `USBS1' undeclared (first use in this function)
uart1.c:68: error: `UCSZ12' undeclared (first use in this function)
uart1.c:69: error: `UCSZ11' undeclared (first use in this function)
uart1.c:70: error: `UCSZ10' undeclared (first use in this function)
uart1.c:73: error: `RXC1' undeclared (first use in this function)
uart1.c:73: error: `UDR1' undeclared (first use in this function)
uart1.c: In function `USART1_RX_vect':
uart1.c:142: error: `UDR1' undeclared (first use in this function)
make: *** [uart1.o] Error 1

Hinweise:
bei Holgers Version gings noch. Mein env kennt aber auch keinen atmega644p, da ich keinen habe - hatte schon den MCU im makefile umgestellt ( sonst aber keine aenderungen ):

ligi@localhost ~/prj/FlightCtrl/branches/V0.68d Code Redesign killagreg $ diff makefile makefile~ 
3,4c3
< #MCU = atmega644p
< MCU = atmega644
---
> MCU = atmega644p

- damit bekomm ich zwar weniger fehler aber es bleinbt halt der obige. Es scheinen noch defines vom 644p genutzt zu werde - obwohl dieser ja nicht das target ist.

Hi killagreg,

na dann werde ich mir mal Dein Werk anschauen, besten Dank für Deine Arbeit!!!!

@ligi

MCU = atmega644p

Size after:
Flight-Ctrl_MEGA644p_V0_68d.elf :
section size addr
.data 942 8388864
.text 38464 0
.bss 1213 8389806
.eeprom 2048 8454144
.stab 888 0
.stabstr 95 0
Total 43650



Errors: none
-------- end --------


> Process Exit Code: 0
> Time Taken: 00:26

ging ohne Probleme....

Specky

Hallo killareg,

genau diese Arbeitsweise finde ich so super! Einzelne User oder Gruppen arbeiten an bestimmten Programmteilen bzw. Komponenten
und Einer, der auf die Ordnung achtet und was von C versteht, fügt das Ganze dann zusammen. Dann noch die Beta-Tester ran
um den Code zu testen und es entsteht eine geniale, übersichtliche und fehlerfreie FC-Software.
Weiter so mit diesem Konzept.

Ich hoffe diese Arbeitsweise setzt sich durch. Wäre doch schade um die Resourcen der Programmierer, wenn mehrere Leute
parallel und unkoordiniert an der gleichen Aufgabe brüten. Das ist ja wie im kalten Krieg.

ein paar Fragen habe ich doch:
- hat sich an den Settings was geändert?
- du hast Änderungen in der Hardware vorgenommen. PC4 steuert SS-Not und PC5 schaltet RESET des MM3 - richtig?
(bisher war das PC6 und PB2) Für mich ist die Änderung auf meiner Lochrasterplatine kein Problem aber weshalb die Änderung ?
- die Ausrichtung des MM3-Boards ist nun beliebig und wird über einen Userparameter eingestellt. Welcher und wie sind die Werte einzustellen?
- Die 2. UART des ATMEGA 644P wird nun voll unterstützt. Heißt das BT an UART0 und GPS an UART1?
- kannst du den Code dahingehend anpassen, dass die beiden Ausgänge J16 und J17 der FC (LED1 und LED2) für die Statusanzeige des GPS
verwendet werden? Eine für GPS-Empfang aktiv und eine für GPS-fix? Ich denke als Beleuchtung haben wir mittlerweile bessere Lösungen
gefunden und so eine Statusanzeige vermisse ich. Die LEDs auf der FC kann ich (und sicher die Meisten hier) nicht sehen, weil mein Navi-Board drüber sitzt
- einen anderen Namen für dein Hex-File im SVN solltest du aber schon wählen, damit es nicht zu Verwechslungen kommt
z.B. Flight-Ctrl_MEGA644_V0_68d_redesign_killareg_v_xx.hex oder sowas
- und irgendwer sollte sich mal die Mühe machen und eine komlette Doku für diese Software schreiben, in der alle Funktionen und Parameter
ausführlich und verständlich beschrieben sind. So ein MK-Hanbuch eben. Ich denke, es ist höchste Zeit dafür
wenn mir die entsprechenden Infos zu Verfügung gestellt werden, würde ich das gerne machen. (wäre dann wenigstens ein Beitrag auch von mir)

danke für diese tolle Arbeit

weiter so !!!

Absolut tolle Arbeit ! Werde das im Laufe der Woche mal aufspielen

Ich hätte einen noch einen Vorschlag / Bitte:

Für das Coming home wäre es hilfreich, wenn bei aktiviertem CH
ein langsames Piepsen eingebaut werden könnte um zu signalisieren,
daß die Funktion aktiviert ist. Könnte man ja auch abschaltbar machen,
dann nervt es die anderen nicht so ...
Ich habe aktuell das Problem daß mein MK absolut nichts macht wenn ich mit
der Jokosoft das CH aktiviere. So könnte man erkennen, ob es wirklich aktiv ist.

Eine gute Doku ist echt wünschenswert, da manche nicht so tief in der Software
stecken und man alles auf einmal zusammen hat.

Wie wärs ?


Grüße

Joachim

@specky: jo - aber a) hab ich keinen 644p und b) ist bestimmt noch n wurm drinn wenn 644p definitionen bei der 644er version genutzt werden - daher meine anmerkung

@ligi

So wie es im SVN steht läst es sich compilieren. richtig ?

Wenn du nun im makefile auf 644 (ohne "p") umstelllst dann mußt du im makefile auch die "uart1.c" aus der "SRC" Liste nehmen (ist weiter unten im makefile)

meine Empfehlung hierzu wäre es so zu machen: (bedingt)

##########################################################################################################
# List C source files here. (C dependencies are automatically generated.)
SRC = main.c uart.c printf_P.c timer0.c timer2.c analog.c menu.c
SRC += twimaster.c rc.c fc.c GPS.c spi.c eeprom.c mm3.c
SRC += mymath.c ubx.c fifo.c
ifeq ($(MCU), atmega644p)
SRC += uart1.c
endif
##########################################################################################################


ein weiteres Problem besteht dann noch in der "main.c" und zwar an der stelle an welcher die inittialisierungen stattfinden, denn dort wird bedingt (je nachdem wie rum die rote LED auf der FC verlötet ist (FC 1.0 oder FC 1.1) die uart1 routine aufgerufen oder auch nicht. Der Compiler braucht jedoch in jedem Fall die Referenz zur USART1_Init() was zu dem Fehler führt

Meine Lösung hierzu wäre auch dieses abhängig von der makefile Prozessordefinition zu machen, also z.b. so:

// initalize modules
TIMER0_Init();
TIMER2_Init();
USART0_Init();
#if defined (__AVR_ATmega644p__)
if (BoardRelease != 10) USART1_Init();
#endif
RC_Init();
ADC_Init();
I2C_Init();
MM3_Init();
//SPI_MasterInit();



Mit diesen zwei Änderungen sollte sich das ganze sowohl für 644 wie auch für 644p compilieren lassen.


was ich noch nicht geschaut habe ist wie es sich mit MM3 und GPS verhält. (bin ich grad am stöbern)

Ansonsten auch von mir ein "Respekt" zur Säuberungs Aktion, da hat sich doch einiges getan.


Grüße,
Walter

@walter - jupp so laesst sichs compilen - nur das define noch umdrehen

#if defined (__AVR_ATmega644__)

zu:

#if defined (__AVR_ATmega644p__)

@killareg - kannst du walters diff übernehmen?

killagreg meinte

ich bin nun soweit fertig mit meinem Redesign.
Ihr dürft nun hier darüber herziehen ;-).

... oder loben

Das ist ja mal genial... Da kann ich gleich meine "Arbeit" einstellen und einfach deinen Code hernehmen.
Hatte mal begonnen die Funktionen ausführlicher zu beschreiben (z.B. http://speedyweb.at/mk/20080302/air_pressure.pdf)
Du hast das jetzt schon mit ALLEM gemacht *lob*

Na da werde ich mich jetzt gleich mal hinter deinen Code klemmen und mal alles durchlesen.

nice job!

Ich habe die Änderungswüsche gerade eingechecked. Es gibt noch eine kleine Modufikation un der ubx.c. Dirt bin ich von der UBX-MSG NAV-STATUS auf NAV-SOL umgestiegen um neben dem Satfix auch noch die Anzahl von Satelitten und die Positions- und Geschwindigkeits-Genauigkeitsschätzugen zu erhalten. Beim Aktivieren einer GPS Funktion und nicht vorhandenem 3d-Fix piepsts es jetzt immer kürzer je nach Anzahl der Sats.

Um eine höhere Kompatibilität zu haben, sollte in Abhängigkeit der MCU im Makefile noch der Aufruf des ubx_parser() aus der ISR in uart1.c in der ISR in uart.c verlagert werden. Damit dann das GPS von der 1. Uart ausgewertet werden kann.

Die Steuersignale für den MM3 an PC4 und PC5 halte ich eigentlich für recht glücklich gewählt, da diese bei der FC 1.0 und FC 1.1/1.2 gleich belegt sind. Zusätzlich spart man sich noch das Löten auf dem FC-Board.

Als nächstes würde ich noch ein CMPS03 Modul erstellen, das den Code von Salvo umsetzt und über eine Option im Makefile entsprechend kompilierbar macht. Dann können alle nach Ihren Wünschen einen Kompass-GPS Code erstellen, der Ihrer Hardware gerecht wird.

Hallo killagreg,

welche Version von WinAVR benutzt Du?

- 20070525
- 20071221

Viele Grüße,

mifi

Ich habe die hier installiert: WinAVR-20071221-install.exe

Hallo killaqreg,

su
für welchen Prozessor ist das hex File im SVN ?
Ich kann leider kein Hex File erstellen und habe eine FC1.1 mit
dem 644. Könntest Du mir da weiterhelfen ?

Grüße

Joachim

@ Joachim
Was hast du denn vor?
Welche Erweiterungen willst du an welchen Ports betreiben. Das sollten wir zuvor klären.

Hi,

ich möchte das Ublox und den MM3 mit dem Walterboard anschliessen. Als Soft habe ich bis jetzt die Joko Soft
genutzt. der 644 hat ja nur einen Port.

Angeschlossen ist das Board bis jetzt so:

http://www.file-upload.net/view-689740/MM3_GPS_Board_von_Walter.JPG.html

Wobei PC4 von der Jokosoft nicht unterstützt wird
Ich nutze eine FC1 auf 1.1 umgebaut mit dem 644, d.h. ohne
zweite Schnittstelle
Ich vermute mal, daß ich SS und Reset dann umverdrahten muß ?

Kommst Du damit schon mal weiter ?


Viele Grüße

Joachim

So nun hab ich mal noch die Unterstützung für den CMPS03 als Option hinzugefügt. Alles dazu notwendig habe ich in cmps03.c/.h ausgelagert. Im Makefile gibt es jetzt die Option COMPASS. Wenn COMPASS = MM3 wird der Code für den MM3 mit erzeugt, wenn COMPASS = CMPS03 dann der Code dafür. Wenn man kompiliert und die COMPASS Option im Makefiule verändert hat, sollte man vor dem "make" unbedingt ein "make clean" aufrufen.

Den in der originalen Version von Holger vorhanden Code habe ich leicht verändert, damit ein Kommunikationsproblem zum Kompass erkannt werden kann. (Dann wird ggf. auch die GPS-Funktion deaktiviert.)
Da ich leider diesen Kompass nicht besitze wäre es schön, wenn dass mal jemand ausprobieren kann.
Kompass dran: Werte zwischen 0 und 360deg.
Kompas ab: Wert = -1 und 10Hz piepen.

Was noch für diesen Kompass fehlt, ist die von Salvo vorgeschlagene Neigungskompensation mit Hilfe des GierGyros bei merklicher Roll/Nick-Neigung, sowie die Auswerung des Userparameters zu Kompassorientierung (Pfeil auf Paltine) zum Head des MK.

Ach ja fast hätte ichs vergessen. Wenn man im Makefile auf MCU=atmega644 umstellt, dann werden die GPS-Daten von der ersten Uart geparsed. Damit ist der Code vollständig abwärtskompatibel zur FC1.0.

Hi killagreg,

ich finde es auch sehr beachtlich, wieviel Mühe Du Dir mit dem Code gibst und beobachte das schon ne Weile sehr interessiert.
Wie Joachim verstehe ich allerdings auch nicht viel vom Compilieren.
Ich würde Deinen Code aber auch mal gerne ausprobieren. Daher von mir auch die Bitte,
dass Du mal ein hex-File bereit stellst. Am liebsten wäre mir eines mit MM3 und uBlox für
die FC 1.0. Notfalls hätte ich auch einen 644p hier. Dann muss ich halt eine FC auf 1.1
umbauen - wäre aber auch kein Problem.
Perfekt wäre evtl. natürlich noch ein Beispielsetting wie es joko gemacht hat und ne kleine
Kurzanleitung was die Fütterung des MM3 anbetrifft (wo genau wird SS und Reset abgegriffen).

Ja, ich werde das noch diese Woche tun. Damit ich aber nicht reihenweise mit Supportanfragen zugeschüttet werde, wollte ich nochmals recherchieren, wie die meisten ihr GPS und den einen oder anderen Kompass einschließen.

Wenn dass GPS beim Atmega644 über die RXD der 1. Uart hereinkommt, werden doch viele die Umschaltung des RXDs vom Bluetooth/Sercon auf den GPS wünschen wenn die Motoren eingeschaltet werden. Daher überlege ich den PC4 als Input für den Muxer bereitzustellen. Der wird auf der FC 1.0 an pin 5 der Ext herausgeführt. Das populäre Walther Board sieht diesen Pin ebenfalls als Muxerinput vor, wenn JP1 auf 1-2 steckt.

Leider beißt sich das mit dem bisherigen Anschluss des CMPS03 an PC4. Besser man verlegt den
2D-Kompass auf PC5. Der ist noch frei.

Mein eigenes Board nutzt den PC4/PC5 um SS-Not und Reset am MM3 zu steuern. Ein Muxer brauch ich nicht, da ich mir die Daten über die 2. Uart reinhole.

bezügl. PC4:
das wird von meinem Addon Board bereits als Umschaltsignal zwischen BT und GPS auf USART0 verwendet , wäre schön wenn man das optional dafür freihalten könnte, halt wählbar. (per define oder wie auch immer)

Grüße,
Walter

@killagreg
Sag mal, wie sieht es in deinem Redesign mit der zeitlichen Auslastung aus ?
Bei der original v0.68 gab es mit MM3 und GPS Code teils schon erhebliche 2ms Überläufe in der main loop.

Das konnte man auch wunderbar feststellen wenn keine PC Komunikation mehr möglich war.
Holger hat seit der V.068 die PC Kom. für den Fall des zeitlichen Überlaufs gesperrt.

durch diese "IF"

 if(SIO_DEBUG && !UpdateMotor)
 {
 TransmitTxData();
 ProcessRxData();
 }

Hast du diesbezügl. schon Erfahrung ?


Ich hatte mich diesbezügl. auch schon mal durhc weite Teile der Firmware durchgekämpft um gegebenfalls zeitkritische Passagen zu entschärfen, nur muß man dann schön langsam leider eingestehen, das ein weiterer Prozessor schon was schönes wäre. Diverse andere hier aus dem Forum wären da durchaus auch nicht abgeneigt ein kleines AVR NAVIBoard zu basteln. Was meinste.


Grüße,
Walter

killagreg meinte

Ja, ich werde das noch diese Woche tun.

Das wäre super!

killagreg meinte

Damit ich aber nicht reihenweise mit Supportanfragen zugeschüttet werde, wollte ich nochmals recherchieren, wie die meisten ihr
GPS und den einen oder anderen Kompass einschließen.

Ich vermute, dass jokos MM3-GPS-Lösung derzeit am verbreitesten ist. Funktioniert bei wenig Wind ja auch sehr gut.

killagreg meinte

Leider beißt sich das mit dem bisherigen Anschluss des CMPS03 an PC4. Besser man verlegt den
2D-Kompass auf PC5. Der ist noch frei.

Warum kein separates Hex für den 2D-Kompass? Musst doch nicht auf Biegen und Brechen alles in einen Code implementieren.

@walter
hast Du evtl. noch ne Platine für mich übrig ?