Kompassmodul GY-271 läuft nicht am UNO

Liste der Anhänge anzeigen (Anzahl: 2)

Hallo,
nachdem ich schon viel getestet hatte, dann dachte mein Sensor ist kaputt und jetzt auch mit dem Nachbestellten kein Erfolg habe streck ich die Flügel. Anbei Bild der Verdrahtung der (Standard-)Sketch sowie die Ausgabe der wirren Zahlen.

Folgende Fakten:
Schon mit unterschiedlichen UNO-Clones erfolglos versucht
Mit zwei GY-271 versucht
I2C sollte an den Clones arbeiten da ich schon einen erfolgreichen I2C-Zugriff auf einen 24LC64 gemacht habe.

Kann mir jemand helfen oder ist mir nicht mehr zu helfen :(

Danke
Frank

Hallo,
hab jetzt an die 10 Programme aus dem Internet getestet, mal mit HMC5883L.h mal nur mit Wire.h und hab auch den Sensor mit 30 cm langen Kabeln separiert .... nix
Ich vermute es ist der Arduino Clone der sich nicht mit dem Sensor verträgt. Habe da aber auch unterschiedliche UNO's getestet. Die Clones haben alle den SCL und den SDA separat - beim originalen Arduino sind es ja die Anschlüsse A4 und A5.
Wahrscheinlich investiere ich in einen professionellen CMPS10 und lass den GY-271 sausen.

Zitat:

Zitat von stepbystep

Hallo,
hab jetzt an die 10 Programme aus dem Internet getestet, mal mit HMC5883L.h mal nur mit Wire.h und hab auch den Sensor mit 30 cm langen Kabeln separiert .... nix
Ich vermute es ist der Arduino Clone der sich nicht mit dem Sensor verträgt. Habe da aber auch unterschiedliche UNO's getestet. Die Clones haben alle den SCL und den SDA separat - beim originalen Arduino sind es ja die Anschlüsse A4 und A5.
Wahrscheinlich investiere ich in einen professionellen CMPS10 und lass den GY-271 sausen.

Das kannst du natürlich machen und wie der Zufall es so will, könntest du auch Erfolg haben. Wenn man mit genügend verschiedenen Teilen lange genug rumspielt, hat man möglicherweise irgendwann Erfolg. Du hast ein Problem mit deiner Schaltung und/oder deiner Software und mußt jetzt anfangen den Fehler zu finden und zu beseitigen. In diese Situation wirst du immer wieder kommen, es lohnt sich also mal mit dem Debuggen anzufangen. Und Fehlersuche heißt sicher nicht, immer wieder irgendwelche Software aus dem Internet zu laden.

Ich verwende keine Arduino, kann daher im einzelnen nichts zu sagen. Ich würd aber so anfangen und Schritt für Schritt vorgehen:.

Zuerst den Schaltplan mal aufzeichnen und die Schaltung auf dem Papier nachvollziehen. I2C ist ja einfach, sind nur zwei Leitungen. Haben alle Beteiligten eine passende Versorgung? Sind SCL und SDA möglicherweise vertauscht? Sind die Pullups da? Hängen möglicherweise andere, störende Bauteile am I2C Bus?

Wenn das alles gut aussieht, gehts an die Software. Dazu ein kurzes Programm, das ein START, ein Byte und ein STOP ausgibt. Damit kann man dann mit Scope oder LA (hier besser mit Scope) die Signale ansehen. Die Frage, die sich hier ergeben sind: ist die I2C Hardware richtig initialisiert, sind die Pins richtig gewählt?

Wenn das soweit funktioniert, sucht man im Datenblatt des Sensors nach seiner I2C Adresse und gibt diese aus. Jetzt sollte der Slave mit einem ACK reagieren. Dies kann man mit dem LA aber auch in der Software erkennen. Nun kann man schon mal mit dem Chip kommunizieren.

Jetzt kann man sich um die Register des Sensors kümmern, sie nötigenfalls setzten und auslesen. Da hilft wieder das Datenblatt. Und am Ende wird es funktionieren. Ich hab noch jedes I2C Device zum Laufen bekommen, ob "professionell" oder Breakoutboard.

MfG Klebwax

Hallo,
danke für die Motivationszeilen.

Schaltplan ist ok, Pullups mit den richtigen Werten sind eingebaut
Alle Spannungen gemessen und alles durchgepiepst
Es hängt nur der GY-271 am I2C
Adresse 0x1E anhand Datenblatt überprüft und im Programm eingetragen
---> Scannerprogramm finden bei 100 kHz die Adresse 0x13D und bei 400 kHz 0xD ??????????
in anderen Programmen findet detectHMC5883L() jedoch wiederum "no device"
SDA und SCL sollten funktionieren und nicht vertauscht sein da ich schon einmal ein Eeprom per I2C erfolgreich angesprochen hatte

Wie sollte ich jetzt weiter vorgehen?

Frank

Zitat:

Zitat von stepbystep

---> Scannerprogramm finden bei 100 kHz die Adresse 0x13D und bei 400 kHz 0xD ??????????

0x13D kann nicht sein. I2C Adressen haben 7 Bit, der Maximalwert ist also 0x7f. 0x13d braucht mehr als 8 Bit.

MfG Klebwax

Das ist ein Fehler in der Konvertierung....13(dec) ergibt D(hex).

Liste der Anhänge anzeigen (Anzahl: 2)

https://github.com/mechasolution/Mecha_QMC5883

Hallo Frank!
Ich habe zwar den GY273, der hat auch den HMC5883L und hatte da mit und Arduino nie Probleme. Kann aber jetzt aus dem Stehgreif nicht auf ein Codebeispiel zu greiffen, weil es in den Tiefen der Datensicherung schlummert.
Ich hatte das Modul zu meiner aktiven QuadroKopter Zeit zu Testzwecken bei der Code Entwicklung verwendet.
Also wenn noch Probleme, schreibe mal ..ich bin aber erst mal einige Zeit im Urlaub

Gerhard

Zitat:

Zitat von Klebwax

0x13D kann nicht sein. I2C Adressen haben 7 Bit, der Maximalwert ist also 0x7f. 0x13d braucht mehr als 8 Bit.

MfG Klebwax

ich würde evtl auch noch mal die i2c Adresse(n) checken.
Probier mal mein Programm ;)

Code:

// -------------------------------------- // i2c_scanner // // This sketch tests the standard 7-bit addresses // Devices with higher bit address might not be seen properly. // #include <Wire.h> #define ESP_SDA 4 //GPIO4=D2 SDA ESP8266 default #define ESP_SCL 5 //GPIO5=D1 DCL ESP8266 default byte error, address; int nDevices; void setup() { // Wire.begin(ESP_SDA,ESP_SCL); // ESP8266 if not default Wire.begin(); // AVR, ARM, Leonardo, ESP8266 default Serial.begin(115200); while (!Serial); // Leonardo: wait for serial monitor Serial.println("\nI2C Scanner"); Serial.println("\nScanning..."); } void loop() { nDevices = 0; for(address = 0; address < 128; address++ ) { if (address%16 == 0) { Serial.println(); Serial.print( (address+1)/16); Serial.print(" "); } if(address==0 || address==127) { Serial.print("** "); continue; } Wire.beginTransmission(address); error = Wire.endTransmission(); if (error == 0) // no error, device found { if (address<16) Serial.print("0"); Serial.print(address,HEX); Serial.print(" "); nDevices++; } else if (error==4) // unknown error or conflicting { Serial.print("?? "); } else { Serial.print("-- "); // nothing found } } Serial.println(); Serial.print("found: "); Serial.print(nDevices); Serial.print(" devices \n"); delay(10000); }

Hallo Frank,

ich würde mir da die Kommunikation auf dem I2C Bus mit Skop oder Softwareoszi über die PC Soundkarte ansehen. Da siehst du, was tatsächlich passiert, und wo du genauer hinsehen musst. Das Herumprobieren mit Software und Komponenten, ohne sich die Ergebnisse auf elektrischer Ebene anzusehen ist nur ein Stochern im Nebel. Kurz kann man das machen, aber wenn das nicht schnell hilft, sollte man ganz schnell damit wieder aufhören.

Zitat:

Zitat von vohopri

Hallo Frank,

ich würde mir da die Kommunikation auf dem I2C Bus mit Skop oder Softwareoszi über die PC Soundkarte ansehen. Da siehst du, was tatsächlich passiert, und wo du genauer hinsehen musst. Das Herumprobieren mit Software und Komponenten, ohne sich die Ergebnisse auf elektrischer Ebene anzusehen ist nur ein Stochern im Nebel. Kurz kann man das machen, aber wenn das nicht schnell hilft, sollte man ganz schnell damit wieder aufhören.

also, nee, da würde ich schon eher dann mit 2 Elektronenmikroskop-Manipulatoren die Elektronen in ihren Schalen in µC- und Sensor-Atomen einzeln setzen und löschen, um die Zustandsverteilungen quantenmechanisch zu evaluieren, allerdings ohne Doppelspalt dazwischen.
Oder alternativ vlt doch erstmal sicherheitshalber die i2c-Adressen per Software-i2c-Scanner checken, dann weiß man hinterher auch evtl besser wohin dann mit den einzelnen Elektronen.

Welche Widerstandswerte für die Pullups, welche Leitungslängen?
Hast Du die typischen Abblockkondensatoren (100n parallel zu 10..100µ) zwischen VCC und GND mal ausprobiert?
Kannst Du die Leitungen verkürzen? Kannst Du den Takt weiter verringern?

Auf'm Breadboard mit 400kHz halte ich für kniffelig.

Dem User HaWe sind - vermutlich wegen mangelndem Verständnis für die Hardware - nur mehr absurde Vergleiche eingefallen. Lediglich absurde Vergleiche zu posten finde ich äusserst unhöflich. Darum werde ich ihn bis auf Weiteres ignorieren - unabhängig von eventuell auftauchenden sachlichen Inhalten.

Zitat:

Zitat von vohopri

Dem User HaWe sind - vermutlich wegen mangelndem Verständnis für die Hardware - nur mehr absurde Vergleiche eingefallen. Lediglich absurde Vergleiche zu posten finde ich äusserst unhöflich. Darum werde ich ihn bis auf Weiteres ignorieren - unabhängig von eventuell auftauchenden sachlichen Inhalten.

das ist gut, damit tust du uns beiden einen Gefallen.

...

Zitat:

Zitat von Holomino

Welche Widerstandswerte für die Pullups, welche Leitungslängen?
Hast Du die typischen Abblockkondensatoren (100n parallel zu 10..100µ) zwischen VCC und GND mal ausprobiert?
Kannst Du die Leitungen verkürzen? Kannst Du den Takt weiter verringern?

Auf'm Breadboard mit 400kHz halte ich für kniffelig.

den Sensor des OPs kenne ich zwar nicht, aber mein CMPS11 läuft mit 1m Leitung per 400kHz über ein Breadboard, und nur mit 2.2k oder altrnativ 4.7k Pullups (am Raspi, am Arduino Mega und am Due sogar nur mit den eingebauten), ohne jegliche Kondensatoren.
Auskunft, ob der Sensor aber überhaupt erkannt wird, kann aber sicherlich der Software-I2C-Scanner geben, und im Zweifel würde ich ntl schon zunächst mit 100kHz Bustakt anfangen, bis es dann endlich erst mal funktioniert.

Hat er doch mit 100kHz und 400kHz ausprobiert - kam Müll bei rum.

Zitat:

Zitat von Holomino

Hat er doch mit 100kHz und 400kHz ausprobiert - kam Müll bei rum.

ja, schon, daher jetzt zurück auf 100, und dann den (neuen ;) ) Software-i2c-Scanner probieren, und dann müssen wir weiter sehen 8)

ps, der misst mit einstellbarer Wiederholgeschwindigkeit mehrmals nacheinander, und so kann man nebenher gleich sehen, ob die Ergebnisse konstant und reproduzierbar sind. Ist doch wirklich zu ungewöhnlich mit 0xE, 0xD, 0x13D, und dann wieder gar nicht.