http://www3.alps.co.jp/npv_product/1003_HSCD/HSCD_E.PDF Ein 3D-Sensor für das Erdmagnetfeld mit nur 2,5*2,5*0,7mm und I2C-Bus-Interface, +/-0,6mT 0,2mA
Muss man den direkt bei Alps bestellen, oder haben die auch Distributoren (habe keine auf deren HP gefunden)? Abgesehen von der Lötbarkeit wäre das Ding sehr interessant für mich. Gruß Reinhard
Scheint noch sehr neu zu sein. Mich wundert, dass es nicht als Kompass sondern als "Azimuth"- Sensor beworben wird. Gibts da einen Haken? Auch zum I2C-Protokoll und der max. Auslesegeschwindigkeit / Messrate gibts anscheinend noch nichts.
Das sieht ja eher aus, wie eine Projektstudie. Sehr spärliche Angaben, keine Pinbelegung. Das Gehäuse wäre für mich das KO-Kriterium. Geht das ohne Ofen?? Interessant ist das Teil schon. Ich habe allerdings gerade Probleme mit einem 3-Achs-Beschleunigungssensor, rauscht wie die Nordsee bei Sturm. Grüsse Lothar
Das Ding wird wahrscheinlich nur die drei Komponenten das Magnetfelds messen und sonst nichts. Für einen (3D) Kompass muss man noch wissen wie der Sensor ausgerichtet ist (z.B. mit Neigungssensoren) da das Erdmagnetfeld auch eine vertikale Komponente besitzt. In unseren Breiten ist die vertikale Komponente sogar größer als die Horizontale (Neigung ca. 70°). Reinhard
Da steht doch, dass es vertikale Neigung bis +/- 90Grad ausgleichen kann. Anscheinend kommt nur ein Messwert für die hor. Komponente raus, das andere wird schon intern weggerechnet. Es soll ja gerade teure Neigungssensoren vermeiden.
Ganz Allgemein kann das, ohne zusätzliche Informationen, nicht funktionieren, das ist mathematisch ein Ding der Unmöglichkeit (Rotationssymmetrie des Feldvektors). Allerdings wird es wohl möglich sein mit einem schlauen Algorithmus der gewisse Annahmen trifft ein brauchbares Ergebnis bei den meisten Situationen zu erzielen. Ich denke mal dass die Art und Weise wie Menschen Geräte in der Hand halten und bewegen da gewisse Rückschlüsse zulässt. Gruß Reinhard
Hallo. Nach langem Warten ist nun der ALPS Sensor auch endlich bei mir angekommen.Hat irgendjemand hier im Forum schon Erfahrungen damit gemacht? Ich versuch ihn gerade auszulesen.Allerdings ist die Beschreibung der Slave-Adresse recht spärlich. Ich habe versucht,ihn mit 0x18 zu beschreiben und 0x19 auszulesen.Meine SCL-Leitung zeigt auch auf dem OSZI sauber die 100KHz default.Leider sehe ich nichts auf der Datenleitung. Hat jemand nen Tipp? Gruß,Mike
http://www.alps.com/WebObjects/catalog.woa/E/HTML/Sensor/Magnetic/HSCD/HSCD_list.html http://www.alps.com/WebObjects/catalog.woa/E/HTML/Sensor/Magnetic/HSCD/HSCD.html
Stimmt,hatte vergessen paar Info´s anzuhängen.Danke Frank. Hat jetzt jemand eine Idee und kann mir weiterhelfen?
Ich kann auf der Seite nichts entdecken was einem detailliertem Datenblatt nahe kommt. So lässt sich nicht viel sagen, außer dass der Sensor wohl nicht trivial zu löten ist... Reinhard
@ Reinhard: Mit dem Löten hast du recht.Bei uns musste dies auch unser Lötexperte erledigen.Ist schon nicht einfach für ihn gewesen! ;-) Klar,Infos sind rar.Ich hab zwar das Datenblatt vor mir liegen (Stand Mai 2009) aber da steht "ALPS Confidential" drauf,d.h. wird wohl nicht für die Allgemeinheit gedacht sein!Sorry Dachte halt,dass evtl. hier auch jemand im Forum ist,der mit dem Sensor testet und dazu die nötogen Unterlagen besitzt. Gruß,Mike
Angehängte Dateien:
-
alps.png
18 KB
Wie berechnet sich der Heading-Wert des Sensors,wenn die Neigung schon intern kompensiert wird? Als Beispiel ist im Datenblatt des Sensors nur ein Diagramm (siehe Anhang) aufgelistet. Geht dies hier auch über heading = arctan(y/x) ?
Wo habt ihr denn die kleinen Dinger herbekommen? Genau so etwas könnte ich gut gebrauchen !
Bevor ich mich jetzt da sinnlos registriere: Kann mir noch jemand sagen was das schmucke Ding kostet?
Also ich hab 3 Stück zum testen.Kosten glaub ich um die 30Euro/Stk.Einer ist leider schon aufgrund der geringen Abmessungen beim Löten draufgegangen. :(
Ansonsten gibt es noch den ähnlichen HMC5843 bei Digikey, kostet ca. die Hälfte. Was den Heading Wert betrifft, arctan(x/y) ist die richtige Formel. Ich frage mich aber wie das Ding die Neigungskompensation intern erledigt. Rein magnetisch geht das ja bestenfalls näherungsweise. Reinhard
Reinhard R. wrote: >Was den Heading Wert betrifft, arctan(x/y) ist die richtige Formel. Hmm,ob die Formel richtig ist,kann ich nicht ganz nachvollziehen.Sollte man denn für x und y die Count-Werte einsetzen?Die können ja dann bei 12Bit Auflösung bis 4095 gehen (bei starker magnetischer Beeinflussung).Ich hatte eigentlich von arctan(y/x) geschrieben und nicht wie du andersrum. Wenn die ganze Sache neigungskompensiert ist und die Z-Achse außer acht gelassen würde,dann sollte ja allein mit dem X- und Y-Wert die Ermittlung erfolgen oder? >wie das Ding die Neigungskompensation intern erledigt. entweder über intere Berechnungen oder mit Hilfe von look-up Tabellen denke ich.
Wenn du es genauso wie in der Skizze haben willst, nimmst du arctan(x/y), aber auch arctan(y/x) ergibt sinnvolle Werte. Man vertauscht ja nur Achsen (und damit auch die Drehrichtung). Was du letztendlich willst hängt von deinem gewünschten Bezugssystem ab. Ob deine Werte von -1.0 bis 1.0 gehen, oder von -2048 bis 2047 ist egal, da du ja sowieso ein Verhältnis berechnest. Wichtig ist nur dass du einen allenfalls vorhandenen Offset abziehst. Eine simple Integerdivision mit den Rohwerten solltest du übrigens nicht machen, sonst werden zwei 90° große Sektoren in eine Richtung gerundet. Eine richtige Neigungskompensation, die in allen möglichen Ausrichtugen funktioniert, kann man weder mit einer Berechnung oder einer Look-Up Tabelle erledigen. Dazu braucht man noch zusätzliche Messungen, z.B. von einem 3 achsigen Akzelerometer (in einem unbeschleunigten System). Für viele Anwendungen dürfte es aber reichen wenn man annimmt dass sich die Neigung in Grenzen hält. Reinhard
Die Berechnung mit ArcTan hängt natürlich auch vom Quadranten ab.
Ich weiss nicht ob meine Achsenregister defekt sind,aber irgendwie stimmen die High-Byte Werte der X-/Y-/Z-Achsen nicht.Entweder liegen sie in einem Bereich von ca. 0....7 Counts oder nahe des Maximalwertes von 255 (d.h. mal 255Counts,mal 248Counts),aber nie in der Spanne dazwischen.Ich glaube nicht,dass dies am Programmcode liegt. Hat jemand ähnliche Erfahrungen gemacht? Gruß,Mike
Hi, das ist so schon in Ordnung, du hast einfach eine vorzeichenbehaftete 12bit Zahl in einem 16bit Register. Die kannst du, wenn du es richtig machst genauso weiterverwenden. Das müsste in etwa so gehen:
1 | int X_Val = (X_High<<8) + X_Low; |
Sieh dir mal an wie negative Zahlen in der Computertechnik repräsentiert werden. Betrachten wir mal nur ein einzelnes Byte mit Vorzeichen:
1 | //Hex == Dezimal
|
2 | 0x00 == 0 |
3 | 0x01 == 1 |
4 | ...
|
5 | 0x7F == 127 |
6 | 0x80 == -128 |
7 | 0x81 == -127 |
8 | ...
|
9 | 0xFF == -1 |
Da du im Highbyte nur 4bit benutzt werden hast du nur die möglichen Werte 0x00 bis 0x07 und 0xF8 bis 0xFF, dezimal entsprechend -8 bis 7. Gruß Reinhard PS: Habe das jetzt nicht nachkontrolliert (bzw. überhaupt richtig im Gedächtnis), kleinere Ungenauigkeiten bitte zu entschuldigen. ;)
Reinhard R. wrote:
>int X_Val = (X_High<<8) + X_Low;
anstatt dem "+" ein "ODER" dann ist das richtig so.
Ansonsten klingt deine erklärung plausibel.
Nur: wenn ich nun nach der Formel
kompasskurs = arctan(x_wert/y_wert) rechne wie du oben bereits
beschrieben hast,kommen auch unabhängig von der späteren
Berücksichtigung der 4 Quadranten komische Werte raus.
Wenn ich den Sensor nicht bewege,dann gibt er mit etwa folgende Werte
zurück:
x_wert y_wert kompasskurs
15 20 37,87°
7 28 14,04°
8 25 17,74°
8 28 15,95°
10 21 25,46°
Das ist schon recht ungenau,findest du nicht auch?
Der Betrag des Feldes in der XY-Ebene scheint etwas niedrig, und instabil zu sein. Laut Wikipedia hat das Erdmagnetfeld eine horizontale Komponente von ca. 20µT.
1 | x_wert y_wert Betrag Feld |
2 | [LSB] [LSB] [LSB] [µT] |
3 | 15 20 25,0 12,5 |
4 | 7 28 28,9 14,4 |
5 | 8 25 26,2 13,1 |
6 | 8 28 29,1 14,6 |
7 | 10 21 23,3 11,6 |
Kannst du mal die Werte der Z Achse posten? Meiner Erfahrung nach reagieren die Sensoren halt sehr empfindlich auf Felder in der Umgebung. Ich hatte mal zum Testen einen magnetischen Neigungsschalter mit einem KMZ51 gebaut, der nichts anderes tat als ein oder zwei LEDs (a 20mA) zu schalten. Das zusätzliche Feld durch den Strom der LEDs reichte für eine negative Rückkopplung, so dass die Schaltung in einem gewissen Neigungsbereich zu Oszillieren begann. Reinhard
Verwende statt arctan(x/y) die atan2(x,y) , dann gibt es auch kein Problem, wenn y 0 wird. Ergebnisbereich ist -pi .. +pi.
hier die Werte mit Z-Achse.Hab neue Werte aufgenommen: x_wert y_wert z_wert -11 -8 -5 -17 -6 -8 -15 -11 -4 -12 -12 -8 -17 -8 -6 -19 -11 -9 -14 -10 -7
Das hat mich leider auch nicht schlauer gemacht, eher im Gegenteil.
1 | x_wert y_wert z_wert Betrag Feld Azimuth Elevation |
2 | [LSB] [LSB] [LSB] [LSB] [µT] [°] [°] |
3 | -11 -8 -5 14,5 7,2 54,0 20,2 |
4 | -17 -6 -8 19,7 9,9 70,6 23,9 |
5 | -15 -11 -4 19,0 9,5 53,7 12,1 |
6 | -12 -12 -8 18,8 9,4 45,0 25,2 |
7 | -17 -8 -6 19,7 9,9 64,8 17,7 |
8 | -19 -11 -9 23,7 11,9 59,9 22,3 |
9 | -14 -10 -7 18,6 9,3 54,5 22,1 |
Sowohl das Feld als auch die Elevation sind schon mal weit von dem entfernt was man erwarten würde (48µT, 60°). Wie sieht es in der Umgebung des Sensors aus? Gibt es etwas dass hier stören kann (Magneten, Ferromagnetische Materialien, hohe Ströme,...)? Hast du mal längere Messungen gemacht (Drift vs. kurzzeitige Störung?). Ist ein Lötschaden ausgeschlossen? Hat der Sensor eine Möglichkeit zum "Reset" (wie z.B. eine KMZ51)? Wenn ja, wird die regelmäßig genutzt? Ich muss gestehen, ich fische hier gerade ziemlich im Trüben. Gruß Reinhard
@Reinhard R.: Danke erstmal für deine bisherigen Antworten.Auf dem Gebiet scheinst du dich auszukennen. >Wie sieht es in der Umgebung des Sensors aus? Das ist mein normaler Arbeitsplatz.Der Sensor hängt an einem Eval-Board.Sonst halt (wie wahrscheinlich bei jedem ;-) ) PC daneben und ein Oszi (ausgeschaltet).Ferromagnetische Materialien eher weniger. >Hast du mal längere Messungen gemacht (Drift vs. kurzzeitige Störung?) Bisher noch nicht so. >Ist ein Lötschaden ausgeschlossen? Würde ich jetzt mal ausschließen.Zwar ist der Sensor schwer zu löten gewesen,aber der Kollege der das gemacht hat,hat das gut hinbekommen denke ich.Mit der Lupe erkenne ich zumindest keinen Fehler.Die 3 Pads für die Sensorachsen sehen sauber aus.Ich weiss aber nicht inwieweit die Löttemperatur das "Innenleben" des IC´s beeinflusst hat. >Hat der Sensor eine Möglichkeit zum "Reset" (wie z.B. eine KMZ51)? Wenn du so einen "flip coil" meinst beim KMZ51,dann hat der HSCD so etwas intern nicht.Reset kommt nur vom Controller. >was man erwarten würde (48µT, 60°) Woher nimmst du die 60°? Gelten die auch für Mitteleuropa so wie die 48µT? MfG,Mike
@ Reinhard R. : Langsam glaube ich,dass mein Sensor trotzdem einen weg hat! Wenn ich ihm um die Z-Achse rotiere,dann sollten ja die Werte für x-bzw. Y-Achse wo oben im Bild zu sehen,einem sin-bzw. cos-Verlauf folgen. Komischerweise gehen aber nur die Y-Achsenwerte auch in den negativen Bereich. Die X-Achsenwerte sind ständig positiv.Das ist schon merkwürdig???!
Hallo ich bin´s nochmal. Wollt nochmal paar Meinungen einfangen. Ich hab den HSCD-Sensor nun einmal an einem Fujitsu-Board dran und ausgelesen und auch einmal am STK500 mit einem ATmega16L dran und ausgelesen. Bei beiden sind die "Self-Test"-,"Who I am"- und "More-Info"-Register mit den Werten wie sie im Datenblatt stehen beschrieben. Das "Self-Test"-Register an sich wurde auch erfolgreich getestet.Und dieses ist ja dazu da,um den Sensor auf fehlerfreie Funktionalität zu testen. TROTZDEM erhalte ich trotz (fast) identischem Programmcode unterschiedliche Werte in den 3 Datenregistern DATAX,DATAY und DATAZ. Lese ich den Sensor über das Fujitsu-Board aus,erhalte ich bei horizontaler Drehung des Sensors z.B. nur pos. Werte für die X-Achse,die aber eigentlich bei 360° Drehung auch mal neg. werden sollten.Y-und Z-Achse gehen auch in den neg. Bereich. Beim Auslesen mit dem ATmega16L liegen alle drei Achsen im neg. Bereich um die -1000 Counts. Dabei ist die Y-Achse meist permanent bei -2048. Bei beiden Boards ändert sich auch der Wert des Temperatursensors nicht,selbst wenn ich ihn etwa anhauche. Kann es dann sein,dass der Sensor oder zumindest seine Sensorpins die den analogen Magnetwert einlesen kaputt sind,trotz der Tatsache,dass der "Self-Test" funktioniert?? Antworten wären hilfreich.Danke,Mike
Zuerst einmal sorry, habe es übersehen auf deine letzte Frage zu antworten. Die oben erwähnten Werte hatte ich aus der Wikipedia. Ist der Fujitsu Controller auch ein 8bitter, oder etwas anderes. Stimmen die Variablentypen überein? Hast du mal von beiden Controllern dir typische Werte in Binärdarstellung angesehen. Das ist jetzt ziemlich spekulativ, aber eine besserer Ansatz fällt mir dazu leider mal nicht ein um das Problem einzugrenzen. Man kann auch mit dem Speicheroszi bzw. Logicanalysator direkt auf den Datenleitungen nachsehen um die Kommunikation zu überprüfen. Hast du die Möglichkeit einen anderen Sensor zu testen? Gruß Reinhard
Hallo Reinhard R.! Danke erstmal für deine Antworten.Der Fujitsu-Controller ist der MB96340.Er ist ein 16-bitter. Die Variablentypen stimmen soweit ich das sehen kann überein. Einziger Unterschied zwischen beiden Controllern ist halt,dass der ATmega16L mit 5V betrieben wird und der Fujitsu mit 3,3V.Die 5V des ATmega regle ich dann mittels Spannungsteiler auf 3V runter um den Sensor zu betreiben. Die Werte sehe ich mir bei beiden Controllern ständig mit dem Speicheroszi an.Die ACK´s erfolgen wie es erwartet und wie schon oben erwähnt ist der Inhalt der Self-Test und anderer "Info"-Register genau wie im Datenblatt beschrieben. Ich habe noch einen anderen Sensor den ich testen kann,was ich heute auch tun werde.bisher hatte ich Ihn nur am Fujitsu-Board dran.Aber ich schau mal was sich am ATmega tut. MfG,Mike
>Big-Endian vs Little-Endian Problem ???
Nein,da gibt es kein Problem diesbezüglich.
Ich habe jetzt einen anderen Sensor (ebenfalls ein Magnetsensor) jeweils mit dem Fujitsu-Controller und dem ATmega16L ausgelesen. -> Die Werte der 3 Magnetachsen werden entsprechend der beiden Controller fast identisch ausgegeben. Das festigt jetzt meine Annahme,dass der HSCD einen weg hat!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.