Hallo und guten Abend,
ich vertreibe mir seit längerem mit einem MPU6050 Board aus fernöstlicher Herstellung die Freizeit...
(Bild im Anhang, eine 6050 samt 3,3V Spannungsregler und einem I2C-Pegelwandler aus zwei FET und 4x 10K Widerständen).
Sehr merkwürdiges Verhalten, wie im Folgenden ausgeführt.
An einem Arduino Mini oder Nano am I2C Bus (A4, A5) angeschlossen - ja, ich habe noch so etwas, nicht nur komplette FC - und mit der aktuellen MultiWii 2.1 betrieben, wäre kein Flugbetrieb möglich:
es hagelt nur so I2C-Fehler und die Achsendarstellung im MultiWiiConf ist absolut katastrophal!
Mein Verdacht: der LLC (Logik-Level-Converter) aus FET und 10K Pullups ist sch...., vor allem sind 10K zu hoch.
Erstes Board umgehend reklamiert, Händler schickt ein zweites und schwört, dass alle bei ihm getestet sind und laufen.
Auf Rücksendung hat er verzichtet, bei ca. 8-9 Euro verständlich.
Zweites Board: kurzum, völlig gleiches Verhalten, unbrauchbar, liegengelassen und abgehakt.
In dieser Woche spielte ich ein wenig mit meinen Vorräten (Baro, Bluetooth, Arduinos, 128x64 OLED, dem vermaledeiten MPU6050) und habe z.B. mit dem Sketch "I2C-Scanner" getestet, ob und welche Adressen meine Schätzchen melden.
Das OLED ist zwar völlig stumm (an anderer Stelle schon berichtet), aber selbst der Krüppel 6050 meldet brav seine Adresse mit Dezimal 104 und Dezimal 232, was in Hex 0x68 und 0xE8 bedeutet.
Das heißt nichts anderes, als dass das Board I2C-pegeltechnisch funktioniert!
Eingedenk, irgendwo mal etwas gelesen zu haben, dass die MultiWii2.1 irgendeine Schwachstelle mit Sensoren "haben soll", besorgte ich mir heute sie r1241 oder so und habe noch einmal getestet.
Duemilanove-Board, an A4 und A5 SDA und SCL vom MPU6050 Board, +5V und GND angeschlossen --> gleiches Theater, massenweise I2C-Fehler.
Lege ich den zusätzlichen INT-Eingang/Ausgang(?) über 4,7K an Masse, beruhigen sich die I2C-Fehler deutlich und die Achsendarstellung wird etwas moderater ... aber nichts, was fliegbar wäre.
Nächster Schritt:
auf http://playground.arduino.cc/Main/MPU-6050 findet sich eine nette Abhandlung zu genau diesem Sensor und vor allem ein Sketch zum testweisen Betrieb.
Das ca. 7K große Programm liefert über die Serielle Konsole laufend die ausgelesenen Werte von Gyro, ACC und auch die interne Temperatur.
Große Überraschung:
mein krüppeliges 6050 Board liefert völlig saubere Werte ab, ohne jegliche technische Änderung, also SDA und SCL an A4 und A5 eines Arduinos, +5V und Masse, INT hängt frei, keine zusätzlichen Pullups.
Handauflegen erhöht sofort die gemessene Temperatur, die leicht schwankenden x,y Werte werden ruhiger, wenn das Board unter einem Papierlocher ;-) liegt ... völlig normales Sollverhalten!
Jetzt stellt sich mir natürlich die Frage, warum der aktuelle MultiWii-Code - mit diesem Board - völlig desolate Steuerdaten produziert!
Eine ansatzweise Erklärung "könnte" möglicherweise der interuptgesteuerte Ablauf sein, ist ja alles andere als die "Prozess-Monokultur" im Testprogramm.
Any idea?
Manfred
ich vertreibe mir seit längerem mit einem MPU6050 Board aus fernöstlicher Herstellung die Freizeit...
(Bild im Anhang, eine 6050 samt 3,3V Spannungsregler und einem I2C-Pegelwandler aus zwei FET und 4x 10K Widerständen).
Sehr merkwürdiges Verhalten, wie im Folgenden ausgeführt.
An einem Arduino Mini oder Nano am I2C Bus (A4, A5) angeschlossen - ja, ich habe noch so etwas, nicht nur komplette FC - und mit der aktuellen MultiWii 2.1 betrieben, wäre kein Flugbetrieb möglich:
es hagelt nur so I2C-Fehler und die Achsendarstellung im MultiWiiConf ist absolut katastrophal!
Mein Verdacht: der LLC (Logik-Level-Converter) aus FET und 10K Pullups ist sch...., vor allem sind 10K zu hoch.
Erstes Board umgehend reklamiert, Händler schickt ein zweites und schwört, dass alle bei ihm getestet sind und laufen.
Auf Rücksendung hat er verzichtet, bei ca. 8-9 Euro verständlich.
Zweites Board: kurzum, völlig gleiches Verhalten, unbrauchbar, liegengelassen und abgehakt.
In dieser Woche spielte ich ein wenig mit meinen Vorräten (Baro, Bluetooth, Arduinos, 128x64 OLED, dem vermaledeiten MPU6050) und habe z.B. mit dem Sketch "I2C-Scanner" getestet, ob und welche Adressen meine Schätzchen melden.
Das OLED ist zwar völlig stumm (an anderer Stelle schon berichtet), aber selbst der Krüppel 6050 meldet brav seine Adresse mit Dezimal 104 und Dezimal 232, was in Hex 0x68 und 0xE8 bedeutet.
Das heißt nichts anderes, als dass das Board I2C-pegeltechnisch funktioniert!
Eingedenk, irgendwo mal etwas gelesen zu haben, dass die MultiWii2.1 irgendeine Schwachstelle mit Sensoren "haben soll", besorgte ich mir heute sie r1241 oder so und habe noch einmal getestet.
Duemilanove-Board, an A4 und A5 SDA und SCL vom MPU6050 Board, +5V und GND angeschlossen --> gleiches Theater, massenweise I2C-Fehler.
Lege ich den zusätzlichen INT-Eingang/Ausgang(?) über 4,7K an Masse, beruhigen sich die I2C-Fehler deutlich und die Achsendarstellung wird etwas moderater ... aber nichts, was fliegbar wäre.
Nächster Schritt:
auf http://playground.arduino.cc/Main/MPU-6050 findet sich eine nette Abhandlung zu genau diesem Sensor und vor allem ein Sketch zum testweisen Betrieb.
Das ca. 7K große Programm liefert über die Serielle Konsole laufend die ausgelesenen Werte von Gyro, ACC und auch die interne Temperatur.
Große Überraschung:
mein krüppeliges 6050 Board liefert völlig saubere Werte ab, ohne jegliche technische Änderung, also SDA und SCL an A4 und A5 eines Arduinos, +5V und Masse, INT hängt frei, keine zusätzlichen Pullups.
Handauflegen erhöht sofort die gemessene Temperatur, die leicht schwankenden x,y Werte werden ruhiger, wenn das Board unter einem Papierlocher ;-) liegt ... völlig normales Sollverhalten!
Jetzt stellt sich mir natürlich die Frage, warum der aktuelle MultiWii-Code - mit diesem Board - völlig desolate Steuerdaten produziert!
Eine ansatzweise Erklärung "könnte" möglicherweise der interuptgesteuerte Ablauf sein, ist ja alles andere als die "Prozess-Monokultur" im Testprogramm.
Any idea?
Manfred
