Naze32 - rev4 vs. rev5 - Ein erster Vergleich

[r0sewhite]

Für die farblich Harmonie hätte ich auch gern mal die schwarzen M3 Kst-Muttern ..wo sind die her?

Ich geb Dir demnächst mal welche, wenn Du hier bist.

[aBUGSworstnightmare]

Moin Leute,

da ich die NAZE32 mittels Android-App konfigurieren will hab' ich mir einige Bluetooth Module (und einige OLEDs) beim China-Mann bestellt. Konkret handelt es sich dabei um diesen Artikel: http://www.wide.hk/products.php?product ... ART-serial.

Als die Teile dann angekommen sind waren es - für jemand der es öfter mit Chinesen zu tun hat keine Überraschung - doch andere! Also, da die Doku auf der Webseite für die Tonne ist hier einige Infos zu den Modulen. Könnte ja sein dass der ein oder andere von euch auch solche in die Finger bekommt!

Gruss
Jörg

Kurzinfo:
So sehen die Teile aus die ich gekommen habe; passen eigentlich ganz gut zur Rev4 und Rev5 (Modul ist purple, Carrier Board ist weiß).

Schickes Design in Purple und weiß --> passt 'farblich' sowohl zur Rev4 als auch Rev5

SANY0198.JPG (279.28 KiB) 3322 mal betrachtet

Der Schiebeschalter auf der Unterseite dient dazu um zwischen AT-Modus (z.B. um die Parameter einzustellen) und Normal-Modus zu wechseln. Auf dem Bild steht er beim unteren Modul im AT-Modus!

Bluetooth-Module gibt es wie Sand am Meer; oftmals sehen sie sogar gleich aus, verwenden aber unterschiedliche Firmware Versionen. Bei meinen Modulen handelt es sich um die HC-05 Firmware. Diese verwendet andere AT-Befehle als die HC-06 die in vielen Beiträgen beschrieben wird (z.B. hier http://lazyzero.de/modellbau/multiwii/bluetooth).
Damit das Bluetooth-Modul an der NAZE32 genutzt werden kann sind die Kommunikationsparameter entsprechend einzustellen. Im Lieferzustand steht das Modul auf 9600 Baud.
Um die Parameter zu ändern habe ich den Serial-Monitor der Arduino-Toolchain (TOOLS-->SERIAL MONITOR) und einen Sparkfun FTDI-Adapter verwendet. Beachtet die Einstellungen bezüglich CR und LF! Unter 38400 Baud hat das Modul nicht reagiert (obwohl es auf 9600 Baud läuft. Wieso? Keine Ahnung ).

Anschlussbelegung ist wie folgt:
TX --> RX
RX --> TX
VCC --> 5V
GND --> GND

Die 3V3 sind der Ausgang des LDO vom BT-Modul.

Hier die verwendeten AT-Commands:
AT --> liefert OK falls das Modul antwortet --> die Kommunikation zwischen Terminal und BT funktioniert
AT+NAME? --> liefert den Namen des Moduls --> WIDE_HK (Default)
AT+UART? --> liefert die Baudrate, Parity, Stopbits -- 9600,0,0 (Default)
AT+VERSION? --> Infos zur Versionsnummer

Im Lieferzustand liefert das Modul die nachstehende Antwort.

Default Parameter des WIDE HK Bluetooth Moduls.

BT-default.jpg (36.06 KiB) 3323 mal betrachtet

Jetzt ändere ich den Namen unter dem das BT-Modul sichtbar ist, sowie die Baudrate.

AT
AT+NAME=NAZE32_0r5
AT+UART=115200,0,0
AT+NAME?
AT+UART?

Die beiden letzten Befehle dienen dazu das Ergebnis zu überprüfen. Im Terminal sieht das dann wie folgt aus:

Terminalwindow nachdem die Parameter geändert wurden

BT-custom.jpg (30.21 KiB) 3322 mal betrachtet

Jetzt kann das Modul angeschlossen werden!

[aBUGSworstnightmare]

Hi,

hier noch das User's Manual zu dem beschriebenen Modul. Es handelt sich dabei um ein 'Type A' Modul.

aBUGSworstnightmare

[Mezzo]

Sehr schöne Doku.

Hast du es schon am Laufen?
Kennst du eine gut Beschreibung für das Android App?

Ich hab immer noch Probleme mit der Vbat- Einstellung. Level 1 +2 ist mir noch suspekt.

Als Anmerkung nochwas: In der rev5 reagiert die ACC Einstellung per BT und App für Nick umgekehrt

[aBUGSworstnightmare]

Hi,

sieht jetzt so aus und tut tadellos.

Naze32 rev5 BT-brain - von oben

SANY0200.JPG (165.46 KiB) 3267 mal betrachtet

Ansicht von unten

SANY0201.JPG (166.03 KiB) 3268 mal betrachtet

Die Montage auf dem Copter steht noch aus (muss da noch was umbauen) --> kann noch nicht sagen ob sich die Kabel auf die Sensorik auswirkt (z.B. Vibrationen).

Die aktuelle Firmware scheint ein paar Probleme zu haben (zumindest laut multiwii-Forum). Leider habe es noch nicht geschafft die Toolchain (wollte mal die CoIDE + ARM GCC testen; Keil kostet Geld --> scheidet aus. Crossworks ist für den Normalsterblichen auch eher uninteressant; PlanB ist das iTAG.FIFTY --> 50EUR für Degugger + Toolchain, wenn jemand mit dem Teil mehr machen will sollte das preislich drin sein) aufzusetzen und die aktuellen Sources zu compilieren. Steht aber noch aus (wozu sonst auch der SWD-Header).
Mich stört aktuell auch dass nur 7 Kanäle bei Spektrum laufen --> muss in der SW einfach umgeschrieben werden. Ich dachte eher daran den Spektrum Code auf 12 zu erweitern; tut dem STM32 schließlich nicht weh wenn 10bytes mehr RAM benötigt werden.
Außerdem will ich meinen eigenen NEMA Parser reinpacken; da hab' ich noch was mit vor

Gruss
Jörg

[aBUGSworstnightmare]

Moin Leute,

hier http://www.multiwii.com/forum/viewtopic ... 415#p42415 beschreibe ich wie man die Keil 32KB ARM MDK um den ARM GCC Compiler ergänzen kann um die Baseflight (später auch Harakiri) Sourcen zu compilieren.

Auf den ersten Blick scheint das zu klappen; ich würde mich jedoch freuen wenn einige INTERESSIERTE von euch das überprüfen könnten. Ein How-To habe ich gestern bereits angefangen und wird veröffentlich wenn ich die Bestätigung habe.

Gruss
Jörg
aBUSGworstnightmare

[r0sewhite]

Hi Jörg,

an einer brauchbaren Methode zur Kompilierung der Baseflight habe ich schon länger Interesse. Werd das allerdings erst nach der Modellbaumesse in Friedrichshafen angehen können, da ich bis dahin noch einen Berg Arbeit vor mir habe.

[Crizz]

Und ich - ich bin nur Anwender. Ich hab da gar nicht die zeit, in die Tiefen richtig einzusteigen, würde mir die Zeit an den anderen Projekten deutlich reduzieren und ich käme dann ins trudeln. Sorry.

[aBUGSworstnightmare]

Hi,

kein Problem! Wenn das wirklich so einfach klappt wie es sich zur Zeit darstellt ist die Vorgehensweise zum Setup einer IDE mit ein paar Screenshots und etwas Text schnell erklärt.
Compilieren ist jedoch nur die halbe Miete! Viel wichtiger ist es dass man damit auch debuggen kann. Dadurch wird ein lästiges Problem der Arduino IDE eliminiert. Da das ganze dann auch 'für Umme' zu haben ist finden sich u.U. auch weitere Softwareentwickler die an Harakiri und Baseflight mitarbeiten.

Jörg

[Crizz]

ich werd´s auf jeden Fall weiter mitlesen - und wenn sich Zeit ergibt mit Sicherheit auch probieren, hab schließlich 4 von den Naze32 im Einsatz.

[r0sewhite]

@Jörg: ich würde sehr gerne eine Möglichkeit haben, Baseflight- sowie AutoQuad-Quellen zu bearbeiten und kompilieren, da ich es nervig finde, für kleine Änderungswünsche irgend jemand darum zu bitten.

Ich hatte es mal mit Eclipse und dem ganzen Rattenschwanz an Geraffel probiert, was jedoch nicht zum Erfolg geführt hat. Mittlerweile war ich schon kurz davor, mir Crossworks zu beschaffen, was ja für den kleinen Privatanwender auch nicht soooo teuer ist. Wenn Du allerdings eine Lösung hast, die a) keine dreiseitige Installationsanleitung benötigt und b) solide funktioniert, bin ich gerne dabei.

[aBUGSworstnightmare]

Hi Tilman,

also, compilieren und linken geht; die erzeugte Firmware funktioniert auch. Was jedoch bislang unklar ist ist die Tatsache dass im REALTIME DATA tab der Baseflight GUI Packet Errors angezeigt werden (10% der empfangenen Pakete). Die ist bei r443 und r447 der Fall. Ich kann aktuell noch nicht sagen woran es liegt da ich das Debugging noch nicht testen konnte.

Ich habe aber noch eine andere GUI im Auge die ich parallel prüfen werde (ebenfalls GCC Basis).

Ich bin mit Timecop im Kontakt; mal sehen wie weit er Lust hat mich bei der Fehlersuche zu unterstützen (falls es an der Toolchain liegt; könnte genauso die Baseflight GUI sein da die bei mir mit der im SVN enthaltenen Firmware regelmäßig abstürzt; meist wenn ich MAP klicke).

Noch kann ich kein grünes Licht geben

Autoquad werde ich ebenfalls prüfen; hier muss jedoch ich jedoch erst mal ein Linker Script File schreiben. Vielleicht geht es an der Baustelle einfacher da Crossworks auch den GCC nutzt.

Jörg

[cgiesen]

könnte genauso die Baseflight GUI sein da die bei mir mit der im SVN enthaltenen Firmware regelmäßig abstürzt; meist wenn ich MAP klicke).

Kannst Du mir das mal zeigen?
Bei mir stützt nix ab.

Wenn es an der Baseflight GUI liegt, würde ich das gerne korrigieren.

[aBUGSworstnightmare]

Hi Carsten,

Ein .hex File welches die Packet Errors zeigt ist im genannten Multiwii.com Thread zu finden.

Ich kann aktuell nicht sagen wieso dieser Effekt auftritt. Ich teste auf einer virtuellen Maschine --> ebenfalls eine mögliche Fehlerquelle. Ich versuche morgen mal ein Screenvideo zu erstellen.

Wenn du Zeit hast Teste bitte mal mit dem .hex-File. Würde mich interessieren ob du auch die Packet Errors hast.
Jörg

[cgiesen]

Ich finde es nicht, link hier bitte nochmal rein

Edit:
Meinst Du das : baseflight_gcc-generated.zip
Da ist das HEX ja mehr als doppelt so groß?!?!

Edit2:
Die Fehler kommen bei MSP_MISC (114)
Ich glaube da ist ein Fehler in Deiner Ausgabe.
Die Fehler kommen deshalb nur in der Realtime Seite, da ich den Wert bei den anderen Seiten gar nicht abfrage.

Edit3:
Ich habe meine GUI gerade etwas erweitert und dieses Problem näher erkunden zu können.
Es ist ein CRC Error.

23.10.2013 09:41:19.224 ERROR : Malformed packet (CRC-Error) CMD:114, Lenght: 50, Inbuffer: 0, 0, 0, 126, 4, 58, 7, 232, 3, 176, 4, 0, 0, 0, 0, 0, 0, 0, 0, 110, 33, 43, 0, 60, 36, 77, 62, 16, 105, 218, 5, 218, 5, 218, 5, 218, 5, 218, 5, 218, 5, 218, 5, 218, 5, 121, 36, 77, 62, 11, 101,

Mich irritiert die Länge (50) ist MSP_MISC wirklich so lang? Auswerten tue ich im moment nur die 1 beiden Bytes (PowerTrigger)