Hallo, ich habe vom Magnetfeldsensor im Anhang das Evaluierungsboard. Der Sensor kann im Single Supply Mode und im Dual Supply Mode betrieben werden. Ich möchte Single Supply. In der Beschreibung zum Eval-Board steht, dass beide Modi unterstützt werden vom Eval-Board. Nun zu meiner Frage: In der Beispielbeschaltung im Datenblatt sieht man im Single Supply Mode eine Verbindung zwischen DVDD und C1. Diese wird wohl im Chip hergestellt, sobald ich VREN auf high lege. Oder irre ich mich? Warum messe ich denn dann unterschiedliches Potential bei diesen beiden Pins? DVDD: 0V C1. 1,79V Hoffe jemand wirft mal einen Blick über das Datenblatt und hilft mir weiter. mfg
Moin, ich kämpfe auch grad mit dem Evalboard rumm, wollte genau wie du im single supply modus arbeiten. Habe dann festgestellt, dass auf dem Board die verbindung von DVDD zu C1 fehlt, diese musst doch noch selbst verbinden, außerdem musst du aufpassen, dass die pullups an der richtigen spannung liegen, sie sollten ebenfalls an dvdd liegen. Ich musste ganz schön am board rumm löten. Zwar liegt bei mir jetz eine spannung an, aber ich bekomme kein ack vom hmc. Ich habe das I2c via software programmiert, bei anderen bausteinen funktioniert es, aber bei dem sensor irgendwie nciht, weißt du oder vielleicht jemand anders ob er in irgend einer form vom i2c protokoll abweicht?? gruß, darnok
@darnok Danke für die Antwort. Das mit der Verbindung zwischen DVDD und C1 hab ich mir auch schon gedacht. Die mach ich dann auch manuell rein. Du hast dann wohl die Pullups R1, R3 nach R2, R4 umgelötet? Ich habe ein wohl etwas älteres Datenblatt vom Sensor bei dem ich festgestellt habe, dass die Beispielschaltung für den Single Supply Mode anders ist. Schau mal in den Anhang. Wenn du Neuigkeiten hast, dann lass ruhig hören. Das I2C-Protokoll muss schon stimmen. gruß
@Guest Genau, ich habe die Pullups R1, R3 nach R2, R4 umgelötet. Das mit dem älteren Datenblatt musste ich auch schon schmerzlichst feststellen. Ich beschäftige mich jetzt schon ne ganze weile mit dem Hmc 5843, habe aber erst neulich das evalboard bestellt. Da ich mit der software i2c bisher nicht viel erreichen konnte, versuche ich gerade die hardware i2c meines controllers in betrieb zu nehmen. wenn ich was neues hab, meld ich mich, grüße darnok
Weißt du eigentlich warum im Lieferzustand, der offensichtlich für Dual Supply gedacht ist, die Pull-Ups auf AVDD geschalten sind und nicht auf DVDD? Immerhin ist in der Beispielschaltung für Dual Supply ein µC angeschlossen der mit 1.8V (sowie bei DVDD). Also sollten doch auch die Leitungen SDA und SCL dieselben Pegel wie der µC besitzen. Es liegen dann 2.5V auf SDA und SCL und somit auch an den Pins am µC. Darf das eigentlich sein?
kann ich dir auch nicht sageen, warum das ding in dual supply ausgeliefert wird, stand ja auch nirgends. meine I2c leitung läuft auf 3,3 V. Weiß auch nicht so richtig warum die die pullups an dvdd liegen, aber so stehts nun mal im Datenblatt. Hast du den Dualsupply schon einmal getestet?
Bin noch nicht dazu gekommen, hab allerdings von Honeywell eine quasi AppNote bekommen. Damit muss ich mich auch noch mal richtig beschäftigen. Funktionieren deine I2C-Funktionen auf anderen I2C-Bausteinen?
Laut einem ERRATA scheint der Dual-Supply-Modus nicht richtig zu funktionieren. Wir haben das IC heute endlich zum Laufen gebracht. Man muß die neuesten Unterlagen verwenden. Die älteren Versionen enthalten Fehler.
Also habt ihr wohl im Single-Supply-Mode gearbeitet. Was habt ihr den für einen Controller verwendet? Könntest du euren Code mal posten? Könntest du vielleicht mal deine Unterlagen uploaden, damit ich auch sicherstellen kann ob ich die neuesten habe? Auf welche Probleme seid ihr den gestoßen? Ich weiß das sind viele Fragen, aber bin schon am verzweifeln mit dem IC.
@guest: ja ich habe andere Bausteine probiert, habe sogar verbindung zu dem hmc 6352 bekommen, welcher ja ein älterer sensor von honeywell ist. Somit dachte ich eigentlich, dass mein software i2c funktioniert. Jetzt bin ich aber auch erst mal wieder verwirrt über die pullups. Im Design guide steht weiter oben (auf seite 10) dass die pulllups an AVDD müssen und weiter unten (seite 25) steht dass die pullups an DVDD müssen, beides gald für single supply. Ich werde mich da wohl nochmal mit honeywell in verbindung setzen müssen. @olaf: würde mich auf jeden fall auch interessieren, wie du das problem gelöst hast.
Also mittlerweile kann ich auf die Register lesend und schreibend zugreifen. Hab die Brücke auf dem Evalboard zwischen DVDD und C1 hergestellt und die die Pullups auf AVDD gelassen. Hat mich auch gewundert aber laut I2C-Spec ist es egal welchen Pegel der High-Zustand hat.
@guest: Und woran hat es nun gelegen, ist das entscheidend wo die pullups sind, wie sieht bei dir die software aus, hast du es per hardware i2c gemacht? Was für einen Controller benutzt du.?? Wie sehen denn die messwerte aus, hauen die einigermaßen hin?
Ich kann mir nicht vorstellen, dass es entscheidend ist wo die Pull-Ups hängen. Hab den Hardware I2C meines ATmega16L benutzt. betreibe den mit 3V. Die Messwerte hab ich noch nicht verifiziert. Allerdings sehe ich, dass sich diese ändern sobald ich ihn bewege. Muss ja so sein.
Ich kann jetzt auch den Ic ansprechen, nur hauen die Werte, die er ausgibt nicht richtig hin. Ich habe mich genau an das Beispiel auf den der letzten seite gehalten. Hat jemand vielleicht einen Teilcode dafür, oder kennt die genaue syntax um den hmc anzusprechen? Für jegliche Hilfe wäre ich sehr dankbar! Gruß, darnok
@darnok Kannst du vielleicht mal deinen Quelltext posten? Wie sieht bei dir die Verdrahtung aus? Wo hängen die PullUps?
@guest Also die Pullups hängen bei mir an AVDD. Wie gesagt, ich kann ihn ja auslesen, also scheint die vertrahtung richtig zu sein. Zur zeit hab ich einen Atmega 16 auf 16 MHZ dran. Dadurch hab ich natürlich einen 5 Voltpegel so dass ich zwischen sensor un µC noch einen I2C-Pegelwandler hab. Ich hab das gefühl, dass der mir auch ne gewisse störung drauf macht. Mein programm hab ich in bascom geschrieben. Der code sieht folgendermaßen aus: Waitms 5 I2cstart I2cwbyte &H3C I2cwbyte &H02 I2cwbyte &H00 I2cstop Waitms 150 Ich bekomme auch ein Acknowledge nach allen 3 bytes. Nach diesem code lese ich die register nacheinander aus. Im moderegister ist nach wie vor eine 1, was ich mir gar nicht erklären kann, die configregister, idregister und das status register hauen aber auf jeden fall hin. Zur zeit programmiere ich alles auf c um, das ergebnis scheint aber das gleiche zu sein. Wie sieht denn dein Code zum registerbeschreiben aus??
@darnok Also ich mache das gleiche. Doch egal welches Register ich lese, es kommt immer 0xFF raus. Außerdem gibt es eine ERRATA in der steht, dass der Sensor die I2C-Spezifikation nicht ganz erfüllt. Zitat: "Some customer I2C slaves are not compliant with I2C standards and desire up to 300nsec of SDA input data delay. Future HMC5843 SDA output data delays of 150nsec are planned to offer more I2C slave compatibility. Revision 1 of ASIC has this issue with the fix in revision 2 and beyond." Revision 1 sind übrigens alle auf denen eine größere Nummer steht als A816. Wie oben bereits erwähnt funktioniert nur der Single Supply Mode laut dieser ERRATA. Wie liest du denn die Register aus. Sendest du die Addresse, also 0x3D und dann die Registernummer und bekommst dann eine Antwort oder? Meinen Code findest du im Anhang.
@guest: Vielen Dank für deine schnelle Antwort. Ich bin nun auch auf das avr studio umgestiegen, hatte aber genau das gleiche resultat. Ich hab mal mit deinem Code vergleichen, sieht meinem sehr ähnlich, kannst aber selber noch mal schauen, er ist im anhang, mein Auslese befehl ist etwas anders, bin halt auf nummer sicher gegangen und hab den pointer nach jedem auslese vorgang wieder neu gesetzt. Hattest du nciht zuvor gesagt, dass du schon messwerte auslesen kannst? Weil du schreibst, es steht nur 0xff drin. Jup das mit der Erata wusste ich auch schon. Meine Sensoren sind glaub auch etwas älter (A844). Habe aber auch noch einen neueren von dem ich mir jetzt mehr erhoffe, muss ihn noch auf eine adapterplatine bestücken lassen. Ansonsten probier ichs morgen noch mal ohne den pegelwandler, da ich jetzt auch einen atmega 16 (L) hab, dann weiß ich hoffentlich mehr Halt mich auch dem laufenden, irgendwie muss das ding doch laufen ;-) Gruß, Konrad
Hallo zusammen, ich versuche auch gerade diesen Sensor in Betrieb zu nehmen, leider bisher auch ohne Erfolg... Ich habe auch einen der Revision 1 und versuche ein Software I2C zu emulieren. Ich kann bisher die identification registers auslesen. die data registers der magnetfeldwerte ergeben komische werte... zudem ist mir aufgefallen dass ich die config register nicht verändern kann, ich kann den sensor beispielsweise nicht in den continuous mode setzen. übrigens seien bei der revision 1 die achsen vertauscht (hat mir distributor gesagt). welche genau weiss ich auch nicht, wahrscheinlich nicht mal honeywell...
@fred Bekommst du bei den Datenregistern immer die gleichen "komischen" Werte oder variieren diese bei dir, sobald du die Postion des Sensors veränderst. Ich kann bisher alle Register lesen und auch schreiben(diejenigen die beschreibbar sind). Allerdings hat der Sensor sproadisch mal immer wieder dieselben Werte im Datenregister stehen. Sobald ich dann das Statusregister auslese erhalte ich RDY=0. Allerdings ist der Pin DRDY auf high. Wie soll man denn das deuten? Wenn ich mich nicht täusche sollte diese beiden immer denselben Wert haben. Ab und zu bekomme ich wirklich vertrauliche Werte aus den Datenregistern. Und dann wieder mal dieselben unerklärlichen Werte. Kann mir das ganze nicht erklären. Die Kommunikation ist einwandfrei. Bekomme zur richtigen Zeit ein Ack usw.
ich bekomme immer die gleichen Werte egal wie der Sensor liegt. die kommunikation scheint aber zu funktionieren, habe diese mit oszi überprüft (ja, jedes einzelne bit...). bekomme ACK, d.h der Sensor ist wenigstens nicht völlig lahm. aber was der ausgibt ist unerklärbar. du setzst (habe ich im code gsehen) den sensor ja auch in den continous mode am anfang. das funktioniert bei mir aber nicht. überprüfe das mal bei dir, ob er dieses register (mode regsiter 0x03) wirklich wie gewünscht schreibt. wenn nicht wäre das sicher eine mögliche erklärung für das seltsame verhalten. ja mal schauen, was ich morgen hinkriege, sonst wird der sensor eingestampft und mit bestem dank zurück geschickt...
Das ModeRegister wird mit mit 0x03 adressiert nicht 0x02. Ich kann es beschreiben und damit in den Continous Mode wechseln. Das Register habe ich ausgelesen. Wenn ich nicht in den Continous Mode wechsle ist das Register auf seinem Defaultwert, also Single Measurement Mode.
@fred: ich habe exakt das gleiche Problem, wie du. In den continous mode will er einfach nicht gehen. Was meinst du denn mit Achsen vertauscht? Sind da etwa pins an einer stelle, die da nicht hin gehören? Heute hab ich endlich einen sensor neuerer baureihe auf einer adapterplatine, ich bin gespannt was dabei rauskommt @guest: wird das mode register tatsächlich mit 0x03 angesprochen? Demnach müssten sich doch die kompleten registeradressen um 1 nach hinten verschieben und das ist definitiv nicht der fall, da ja die id register die richtigen werte liefern
Hi, ich habe den HMC5843 seit ein paar Wochen im Einsatz und alles funktioniert, wie im Datenblatt beschrieben. (Bis auf die Beschaltung eines Pins, steht weiter oben im Thread) Continuous Mode: 0 ins Mode-Register (2) schreiben, fertig. Wenn sich die gelesenen Daten bei Bewegung des Sensors nicht ändern, prüfen, ob die Set/Reset-Spulen ihre Impulse bekommen. Die liegen um 1A, ca. 1µs lang. Die beiden entsprechenden Kondensatoren sind nicht unkritisch. Wenn der Sensor sich ändernde Daten ausgibt, die aber nichts mit der Himmelsrichtung zu tun haben, alle metallischen Gegenstände mindestens 1m weit entfernen. Auch aus der Schublade unter der Arbeitsplatte. Ein magnetischer Kompass hilft, beeinflußt den Sensor aber auch. Abgesehen von dem einen Fehler in einem Datenblatt ist der HMC5843 pflegeleicht. HTH, Falk P.S.: Ich habe kein eval-kit, sondern direkt angelötet.
Sorry ich habe mich bloß verschrieben. ModeRegister natürlich mit 0x02. 0x03 ist ja MSB der x-Koordinate. Ich kann im Gegensatz zu euch doch auf das Moderegister schreiben un die Werte werden auch übernommen. Hab Sie ausgelesen. Ich lese bei jeder Messung gleichzeitig das Statusregister mit aus. Falls dieses auf 0x05 steht bekomme ich auch glaubwürdige Werte. Die vertauschte Achse ist laut meinen bisherigen Messungen die x-Achse. Geb aber keine Garantie darauf. Vertauscht ist hierbei das Vorzeichen.
Habe vorhin einen neueren Sensor getestet, mit dem selben Ergebnis so dass ich zur zeit gar nicht so richtig weiter weiß @guest: Hast du es mit dem Programmcode geschafft, die register zu beschreiben oder hast du noch was daran verändert, weil ich erst mal kaum einen unterschied zu meinem sehe? @dl3daz: wie hast du das I2c programmiert, per hard- oder software und welchen controller verwendest du. Könntest du deinen Programmcode mal zum download zur Verfügung stellen @Fred: also bei mir ändert sich das moderegister definitiv nicht, dass hab ich schon überprüft, aber acks bekomme ich vom sensor, deswegen wunderts mich. Für mich verhält sich der sensor so als hätte er eine art write protection, aber davon stand nichts im datenblatt
darnok schrieb: > Habe vorhin einen neueren Sensor getestet, mit dem selben Ergebnis so > dass ich zur zeit gar nicht so richtig weiter weiß ... > @dl3daz: > wie hast du das I2c programmiert, per hard- oder software und welchen > controller verwendest du. ARM7 mit HW-I2C. Das ist ein kommerzielles Gerät für andere Zwecke. > Könntest du deinen Programmcode mal zum > download zur Verfügung stellen Darf ich leider nicht. Gruß, Falk
irgendwie ist es mir heute gelungen, dass ich das mode register usw. auch schreiben kann. fragt mich aber nicht wie, es ging plötzlich. habe ein bisschen an der frequenz rumgeschraubt, vielleicht hat das geholfen. das war aber auch schon alles was ich zu stande gekriegt habe heute. jedenfalls kann ich jetzt lesen und schreiben. alle register werden auch richtig ausgelesen, bis auf die datenregister. diese verändern ihren wert nie! keine ahnung woran das liegt. habe deshalb mal das status register ausgelesen: RDY wird nie gesetzt. wenn ich aber DRDY am pin messe ist der immer high. unerklärlich... (gleiches problem wie von "guest" oben beschrieben) die werte, die ich auslese sind aber für alle achsen gleich. das MSB ist immer 0x00 und das LSB ist immer 0x20. jetzt weiss ich langsam auch nicht mehr weiter, wenn alles funktioniert, aber die magnetfeldwerte nicht in die register des sensors geschrieben werden.
Wer von euch verwendet einen Quarz? Habe je länger je mehr das Gefühl, dass dieser sensor sehr senisibel bezüglich Clock-Frequenz ist?
@darnok Also mot BASCOM hat es bei mir auf Anhieb funktioniert die Register zu beschreiben. 'Continuous-Measurement Mode I2cstart I2cwbyte &H3C I2cwbyte &H02 I2cwbyte &H00 I2cstop 'Auslesen des Registers I2cstart I2cwbyte &H3C I2cwbyte &H02 I2cstart I2cwbyte &H3D I2crbyte Modereg , Nack I2cstop Print "Modereg:" Print Modereg Print "" @fred Also an der Frequenz kann es nicht liegen. Ich verwende den internen RC-Oszillator mit 4MHz meines ATmega16L. Ich habe genau die gleichen Werte wie du in den Datenregistern stehen. Das RDY-Bit wird auch nicht gesetzt und der DRDY-Pin ist auf High. Weiß nicht wie das sein kann.
Also ich habe mir jetzt so ein demo starter kit gekauft. Ich hoffe ich kann mit hilfe eines oszis genau rausbekommen, was an den sensor geschickt wird, ich hoff einfach mal damit weiter zukommen...
ich will dir die hoffnung ja nicht ganz rauben, aber ich habe mit dem oszi auch schon jedes einzelne bit überprüft. alles wird korrekt geschickt, der sensor sendet ein ACK usw. , aber eben es tut sich nichts...
Also, bei wurde jetzt das projekt mit dem kompass sensor eingestellt, somit hab ich auch das starter kid nicht bestellt. Der Sensor sollte eigentlich meine diplomarbeit werden, aber da hab ich jetzt schon genug zeit rein verschwendet. Ich werd jetzt wahrscheinlich den hmc 6042 nehmen und den an nen ad wandler von einem µC hängen. Find die Lösung auch nicht schlecht, der ist halt nur teuerer...
Stichwort "clock-stretching" ... vielleicht mal interessant auszuprobieren. bei mir geht das leider nicht so schnell, da ich ein sw i2c habe.
DIE LöSUNG: ok ich sags euch jetzt was los ist ;-) der 4u7 kondensator ist zu klein. wenn ihr die pulse messt an setn, setp werdet ihr sehen dass diese nur vielleicht so 100ns lang sind und das ist definitiv zu kurz. also habe ich anstatt des 4u7 kondensator 47u verwendet und das funktioniert so einwandfrei! viel spass!
ey alter das isses! Kondensator ausgetauscht und es ging! Da werd ich mir gleich mal den Supporttypen aus Amerika vorknöpfen. Es kann nicht sein, dass sowas fundamentales im Datenblatt falsch ist. Man sieht wie der sensor in sättigung geht, wenn ich nen magneten rann halte. Jetzt stört mich nur noch, dass er scheinbar einfach so zwischendurch in sättigung geht, ohne dass ich was bewege, damit kann ich mindestens jeden 2. messwert vergessen. Wie läufts denn bei euch, habt ihr relativ konstante werte?
darnok schrieb: > ey alter das isses! Ich hatte ja weiter oben schon empfohlen, die Pulse zu kontrollieren. > Kondensator ausgetauscht und es ging! Da werd ich > mir gleich mal den Supporttypen aus Amerika vorknöpfen. Es kann nicht > sein, dass sowas fundamentales im Datenblatt falsch ist. Mein HMC5843 funktioniert mit 4,7uF. Das passt auch zu den Daten der SET/RESET-Coils. > Man sieht wie der sensor in sättigung geht, wenn ich nen magneten rann > halte. Jetzt stört mich nur noch, dass er scheinbar einfach so > zwischendurch in sättigung geht, ohne dass ich was bewege, damit kann > ich mindestens jeden 2. messwert vergessen. Wie läufts denn bei euch, > habt ihr relativ konstante werte? Ja. Die passen auch zu den entsprechenden Komponenten des Erdmagnetfelds hier. Falk P.S.: "Erst wußte ich nicht, wie man Indschenjör schreibt, jetzt bin ich einen" war früher mal ein Scherz...
Also bei mir kamen auch immer die Werte 0x0020 für die drei Achsen raus. Nach dem ich den Pin SVDD gemessen hab (das ist die Spannung für die magnetosresistiven Brücken) habe ich festgestellt, dass diese immer auf 0v liegt. Nach Durchprobieren mit einem anderen Evalboard hat auf einmal alles geklappt. Also am Kondensator hat es bei mir nicht gelegen, sondern einfach daran, dass ich einmal Überspannung angelegt habe und dadurch der Analogteil kaputtging. Bei dem Evalboard hat es auch mit dem 4µ7 Kondensator geklappt.
Hallo! Hat hier jemand das Demo-Board des HMC5843? Ich schau mir grad das Übertragungsprotokoll der I2c-Schnittstelle auf dem Oszi an,allerdings find ich dies etwas konfus in dessen Ablauf. Dort hängt zwar noch der Beschleunigungssensor des Demo-Boards mit dran,aber wenn ich mir die Registerinhalte der einzelnen Magnetsensorachsen nach dem read-Befehl "0x3D" des HMC anschaue,stimmen die Werte nicht mit denen überein, die ich auf der Grafik des mitgelieferten Programms sehe!?
Ich nochmal. Den HMC5843(hab ihn auf meinem Demo-Board drauf gelassen) habe ich an meinen Fujitsu-Controller drangehängt. Die Config-Register und so bekomm ich auch einwandfei zurück. Meines Erachtens läuft die Kommunikation auch fehlerfrei.Allerdings hab ich wie von einigen oben bereits beschrieben das gleiche Problem,dass in den Datenregistern konstante Werte stehen,selbst wenn ich den Sensor bewege. Weiss aber nicht warum.Glaub nicht das es an den 4,7µF Kondensator liegt und mein SVdd-Pin liegt auch auf High. Das Mode-Register habe ich auch erfolgreich beschrieben. Hat jemand noch eine andere Idee woran das liegen kann??
Für die Nachwelt: :) das Problem mit den konstanten Datenregisterwerten von 0x0020 hab ich gelöst.Das Problem ist der Kondensator C2 (0,22µF).Im Datenblatt des HMC5843 ist dieser sowohl für den Dual-als auch den Single-Supply Mode mit diesem Wert angegeben. Hab ihn durch 100nF ausgetauscht (so wie er auch im Schaltplan für das Demo-Board angegeben ist) und schon funktionierts!
Ich bin es nochmal.Vielleicht kann mir jemand helfen. Die Werte in den Datenregistern schwanken in einer Spanne von etwa +/-10 Counts.Ich weiss aber nicht warum bzw. was ich evtl falsch mache?! Die anderen Register kann ich auch beschreiben bzw. lesen und dort stehen auch die erwarteten Werte drin. Ich habe den Continuous Mode eingestellt mit der (default) Verstärkung von 1. In meinem Statusregister steht immer 0x04,d.h. Bit REN ist immer 1. Hat jemand einen Tipp??? Danke
Hallo. Bei mir tritt grad folgendes Problem mit dem HMC5843 auf: Obwohl ich im Mode Register den Continuous-Mode eingestellt habe,gibt mir der Sensor beim Auslesen dieses Registers 0x03 zurück,d.h. er befindet sich im sleep-Modus! In meinen Datenregistern stehen beim Auslesen jetzt auch unerwartete Werte drin. Das ganze trat auf,seit ich das HMC5843-Demoboard mal direkt auf die Leiterplatte draufgeklebt habe,wo sich auch mein HMC5843-Sensor allein befindet. Damit wollte ich in etwa die Inhalte der Datenregister vergleichen.Das heißt die Werte,die in meinem EUROScope-Debugger stehen mit denen,die die mitgelieferte SW des Demoboards ausgibt! Kann es sein,dass durch die nahe Anbringung zweier HMC5843 Fehler verursacht werden die nicht reversibel sind?z.B. das irgendwelche EMV-Probleme veruracht wurden??? Danke für jede Antwort
Angehängte Dateien:
-
HMC5843-Dead-Bug.jpg
150 KB
Ich habe eine Anfrage per PM, die ich hier öffentlich beantworte, weil so evtl. auch die Anderen etwas davon haben. Falk Willberg schrieb: > Hi, > ich habe den HMC5843 seit ein paar Wochen im Einsatz und alles > funktioniert, wie im Datenblatt beschrieben. (Bis auf die Beschaltung > eines Pins, steht weiter oben im Thread) > > Continuous Mode: 0 ins Mode-Register (2) schreiben, fertig. Hier ein paar Codeschnipsel. Definitionen:
1 | #define HMC5843_I2C_ADDRESS 0x1E
|
2 | #define HMC5843_MODE_REG 2
|
3 | #define HMC5843_X_MSB_REG 3
|
4 | #define HMC5843_X_LSB_REG 4
|
5 | #define HMC5843_Y_MSB_REG 5
|
6 | #define HMC5843_Y_LSB_REG 6
|
7 | #define HMC5843_Z_MSB_REG 7
|
8 | #define HMC5843_Z_LSB_REG 8
|
9 | #define HMC5843_STATUS_REG 9
|
10 | |
11 | #define HMC5843_MODE_CONT 0
|
12 | |
13 | #define HMC5843_MEASUREMENT_DATA_LEN 6
|
Initialisierung:
1 | data_out[0]=HMC5843_MODE_REG; |
2 | data_out[1]=HMC5843_MODE_CONT; |
3 | send_I2C_data(HMC5843_I2C_ADDRESS, data_out, 2); |
Auslesen:
1 | //Test ob Statusregister lesbar
|
2 | data_out=HMC5843_STATUS_REG; |
3 | I2C_read_request(HMC5843_I2C_ADDRESS, &data_out, 1, 1, data_in); |
4 | |
5 | data_out=HMC5843_X_MSB_REG; |
6 | //6 Bytes auslesen (2*X, 2*Y...)
|
7 | I2C_read_request(HMC5843_I2C_ADDRESS, &data_out, 1, HMC5843_MEASUREMENT_DATA_LEN, data_in) |
8 | |
9 | hx=(data_in[0]<<8)+data_in[1]; |
Die Richtung rechne ich einfach mit Dir=atan2(hy/hx) aus. ... Die Rohdaten sehen bspw. so aus:
1 | 167 -147 278 |
2 | 161 -154 272 |
3 | 164 -155 274 |
4 | 156 -151 271 |
5 | 160 -143 277 |
6 | 158 -148 276 |
7 | 158 -146 278 |
8 | 165 -148 273 |
9 | 153 -156 286 |
10 | 155 -156 269 |
11 | 129 -129 276 |
> P.S.: Ich habe kein eval-kit, sondern direkt angelötet.
Die Beschaltung entspricht dem Datenblatt des HMC5843, Siehe Foto ;-)
@Falk: hast du bei deinen Beispielrohdaten den Sensor bewegt?Wenn ich ihn nicht bewege,schwanken die Datenregisterinhalte auch in einer Spanne wie von dir angegeben.Ist das denn normal? Solltest du nicht einfach mit "atan(hy/hx)" rechnen und nicht mit "atan2"?? So steht es auch in einem DesignGuide des HMC!
Ron schrieb: > @Falk: > > hast du bei deinen Beispielrohdaten den Sensor bewegt?Wenn ich ihn nicht > bewege,schwanken die Datenregisterinhalte auch in einer Spanne wie von > dir angegeben. Hier mal eine aktuelle Ausgabe:
1 | 156 111 668 |
2 | 164 110 669 |
3 | 157 104 670 |
4 | 158 111 664 |
5 | 165 105 665 |
6 | 163 102 666 |
7 | 162 100 665 |
8 | 158 99 666 |
9 | 160 101 665 |
10 | 168 108 670 |
11 | 159 103 663 |
12 | 170 100 670 |
13 | 159 104 661 |
14 | 159 106 661 |
15 | 153 108 660 |
16 | 163 104 665 |
17 | 158 105 670 |
18 | 166 110 665 |
Es wurden 8 Werte/s gesampled und gemittelt und so ein Wert/s ausgegeben. > Ist das denn normal? Ich denke, das ist normal. Bedenke nur mal die ganzen Störfelder, die in einem Gebäude herumschwirren. Ich hatte mit dem Ding Meßfahrten gemacht. Über Straßenbahnschienen mißt man nur noch Mist. Werte: http://falk-willberg.de/Suchbild1.png, die Örtlichkeit: http://falk-willberg.de/Suchbild2.png > Solltest du nicht einfach mit "atan(hy/hx)" rechnen und nicht mit > "atan2"?? Atan2() ist nur eine Variante der atan()-Funktion, die Vorzeichen und Nullwerte behandelt. atan(Y/0) gibt Mecker. Ich rechne noch mit einem perl-script. > So steht es auch in einem DesignGuide des HMC! Das habe ich erfolgreich ignoriert ;) Falk
> Ich denke, das ist normal.
Bin ich ja beruhigt! ;-)
Die atan2-Funktion gibt dir ja Werte im Bereich von +90° ... -90° aus.Um
dies auf die 360° umzurechnen addierst du sicherlich noch je Quadrant
entweder 180° oder 360° dazu oder?
Meine Funktion mit Neigungskompensation sieht wie im DesignGuide
beschrieben so aus:
double calculate (signed int d,signed int e,signed int f,signed int
tilt_X,signed int tilt_Y)
{ // Funktion zur Berechnung des nautischen Kurses
x = (double)tilt_X*0.0039; // Neigung X-Achse
y = (double)tilt_Y*0.0039; // Neigung Y-Achse
calc_x = d*cos(x) + e*sin(x)*sin(x) - f*cos(x)*sin(x); // X-Wert mit
Neigungskompensation
calc_y = e*cos(y) + f*sin(y); // Y-Wert mit Kompensation
heading = atan(calc_y/calc_x); // Berechnung des nautischen Kurses
return heading; // Ergebnis an Funktion zurueck
}
Ich hab halt hier Probleme dies auf den 360°-Bereich umzuwandeln.
Hast du noch eine Funktion zur Offset-Calibration hinzugefügt?
Meine Datenregister gehen jetzt übrigens wieder.Eine Leitung war
abgegangen. :)
Ron schrieb: >> Ich denke, das ist normal. > > Bin ich ja beruhigt! ;-) > > Die atan2-Funktion gibt dir ja Werte im Bereich von +90° ... -90° aus.Um > dies auf die 360° umzurechnen addierst du sicherlich noch je Quadrant > entweder 180° oder 360° dazu oder? Nein, die atan2()-Funktion in perl macht das alles schon richtig. Der Vergleich mit den GPS-Daten zeigt das. In C wird das über Tabellen implementiert werden. ... > Hast du noch eine Funktion zur Offset-Calibration hinzugefügt? Nein, das ist bei meiner Anwendung nicht nötig. Die Gründe darf ich leider nicht nennen. > Meine Datenregister gehen jetzt übrigens wieder.Eine Leitung war > abgegangen. :) ;-) Falk, jetzt Drähte anlöten gehend.
>Nein, die atan2()-Funktion in perl macht das alles schon richtig. Der >Vergleich mit den GPS-Daten zeigt das. In C wird das über Tabellen >implementiert werden. also müsste ich noch eine Tabelle programmieren, die mir entsprechend der Werte der Magnetsensordatenregister einen entsprechenden Winkel im Bereich von 0...360° ausgibt?Hab ich das so richtig verstanden? MfG,Ron
Ron schrieb: >>Nein, die atan2()-Funktion in perl macht das alles schon richtig. Der >>Vergleich mit den GPS-Daten zeigt das. In C wird das über Tabellen >>implementiert werden. > > also müsste ich noch eine Tabelle programmieren, die mir entsprechend > der Werte der Magnetsensordatenregister einen entsprechenden Winkel im > Bereich von 0...360° ausgibt?Hab ich das so richtig verstanden? Nein, ich werde sin() und cos() "in Tabellen machen" und atan2() selbst implementieren. Versuch's doch mal mit perl. Mit dem Modul Device::SMBus (http://www.perlmonks.org/?node_id=99568) soll man auch I²C-Slaves ansprechen können. Das habe ich aber noch nicht probiert, am PC nutze ich i2c-dev mit der C-API. Falk
Was mich halt wundert: die Magnetsensorachsenwerte X,Y,Z des Demoboards führen mit den Berechnungen für X' und Y' (nach dem DesignGuide) und anschließender Formel: Heading = atan(Y'/X') zu Ergebnissen, wo anscheinend um auf einen Kurs von 0° bis 360° zu kommen entweder 90° oder 270° zum "Heading"-Wert dazuaddiert werden. Die Werte sind +/-2° genau.Weiss nicht ob das nur Zufall ist. Wenn ich dies mit meinen Sensorwerten berechne kommen völlig andere Ergebnisse raus.Mich würde interessieren,wie dies bei dem Demoboard intern berechnet wird? Mit perl bzw. i2c-dev möchte ich jetzt aktuell (noch) nicht rumprobieren.Aber danke für den Tipp
Hallo Falk, vielen Dank für die Infos!! Hallo Ron, was setzt du denn für einen Beschleunigungssensor ein? Welche Lage nimmt denn der HMC bei dir im Design ein? Horizontal, oder Vertikal? Gruß, Michel
@ Michel: Ich hab den SMB380 Beschleunigungssensor von Bosch.Ist aber erstmal nebensächlich,da ich ja z.B. eine fest definierte Neigung nehmen kann,trotzdem sollten dann meine Kursdaten nach den Berechnungen laut DesignGuide Werte zwischen 0...360° bringen. Der HMC5843 ist horizontal auf meiner LP positioniert.Das einzige,was ich nach dem Einlesen der Magnetachsen über I2C ändere ist,dass ich die Y-Achsenwerte negiere,so wie es im DesignGuide steht,da X-und Y Achse vertauscht sind.
Hallo Ron, Dank Dir! Bekommst du stabile Werte, auch ohne den Beschleunigunssensor? Ab welcher Neigung fangen die Werte an zu "schwingen"? Bei mir schwanken Sie doch schon relativ stark. @all: Könnt Ihr dem Datenblatt entnehmen, welche Berechnung notwendig ist, wenn der Sensor in vertikaler Lage angeordnet ist? -> arctan(Z/Y) bzw. arctan(Z/X) ? Schönes WE! Gruß, Michel
@ Mi Mo: Was sind bei dir stark schwankende Werte?Bie mir liegen die Messwerte in einer Spanne von etwa +/-7 Counts.Falk hat weiter oben schon geschrieben,dass dies normal sei,betrachtet mal die Störeinflüsse die wirken. Soweit ich das lesen konnte, steht da keine Extrarechnung für eine Anbringung in vertikaler Lage.
Ron schrieb: > @ Mi Mo: ... > Soweit ich das lesen konnte, steht da keine Extrarechnung für eine > Anbringung in vertikaler Lage. Ist doch trivial: Man kippt den Sensor um eine Achse. Diese bleibt, die beiden anderen werden vertauscht. Falk
Hallo ich bin es nochmal. Wie kompensiert ihr bei einer Neigung des Sensors diese?Mit den Formeln für X' und Y' und darausfolgend Heading = (Y'/X') ist man da ja auf einem Irrweg. Ich steh da gerade etwas auf dem Schlauch. :( MfG,Ron
Hallo Leute, was wäre die Welt ohne Probleme. Beschäftige mich auch seit einiger Zeit mit dem HMC5843. Habe ein eigenes Testboard entworfen. Pullups liegen auf AVDD (4,7K). Steuere den Sensor mit einem MSP430 Controller von TI. Versorgung: Single Supply (3V). I2C über Software. Alle Register lassen sich problemlos auslesen und auch beschreiben (also die ersten drei). Mein Problem: Die Werte in den Datenregistern ändern sich im Continuous-Mode über den gesamten Wertebereich in zufälliger Reihenfolge bei gleicher Ausrichtung des Sensors. Ob sich bei Drehung was tut ist schwer zu sagen. Im Single-Mode lese ich zumindest immer die gleichen Werte aus (wie erwartet). Nach einem Power-up ändern sich diese allerdings auch wieder stark bei gleicher Ausrichtung. Vielleicht hat ja mittlerweile jemand eine Lösung für dieses Problem. Was mir auch aufgefallen ist. Nutzt man die auto-increment Funktion des Addresspointers, werden nicht 6 sondern 7 Werte (also zusätzlich das Statusregister) ausgelesen. Hat jemand gleiches festgestellt? mfg strommann P.S.: Wo habt ihr die Errata notes her? Kann mal jemand was aktuelles hochladen
Hi! Mich hatte das Ding, Breakout SEN-09371 mit Honeywell's HMC5843, die letzten Tage auch geärgert, jetzt aber nicht mehr, die Sau, die.:) Am Ende habe ich mein Weltbild von Sparkfun korrigiert, überteuerte $50 USD für das Ding (der Chip kostet $20), und dann so eine Billgheimernummer. (OK, Honeywell will für sein Eval-Board sogar $100.) Es sah zunächst so aus, als läge es am TWI (I2C), aber: Denkste! Ich hatte fortlaufend die drei ID-Register ausgelesen und es kam immer wieder zu Hazards. In den Datenregistern stand nur Schrott, das Statusregister zeigte immer 4, sprich, dass der interne Voltage-Regulator für das Erzeugen der Digitalspg. (1,8V) benutzt wird. Auch fiel der Chip immer wieder in den Default-Mode Single-Measurement zurück, siehe ausgelesenes Mode-Register. Habe dann mal mit dem TWI-Bus-Clock gespielt, was bewies, dass es nicht am TWI liegen kann. Es gab keinerlei Veränderung bis zu einer minimalen Taktfrequenz von 6,25kHz. Der HMC spielte auch noch bei 1,8MHz. Ein mit auf dem Bus befindlicher ADXL345 machte bis 7,2MHz mit, mehr ließen meine Prescaler nicht zu. Die Theorie um einen ungenauen Clock, Bedarf nach einem Quarz und so, entbehrt jeder Grundlage. Zur Anwendung kommt hier ein "erweitertes Abtasttheorem", theoretisch sollte der Takt des Slaves wenigstens 16x höher sein als der TWI-Bus-Clock. Was zu beweisen war...;), siehe mein 7,2MHz-Extremismus. Ein anderer Verdacht rankte sich zunächst um die Signalpegel auf dem TWI. Ich verwende einen Arduino Nano 16MHz in meiner Sensoreinheit (außer o.g. Sensoren noch SP1000 Drucksensor und 3x ADXRS610 Drehratensensor drin). Die serielle Console geht via FTDI, in dieser Variante speist der FTDI-Chip über eine Schottky-Diode 5V in den AVR als Versorgungsspg. Die Specs des HMC verbieten aber solche Pegel von bis zu 5V. Ein anderer Freak im Inet hat nun Sparkfun's BOB-08745 Logic Level Converter dazw. gesetzt. Hey, das Breakout ist doppelt so groß wie der Sensor! Außerdem ist diese Maßnahme Unsinn. Warum? Erstens kann ich die beiden externen Pull-Ups gegen die Versorgungsspg. des HMC legen, bei mir 3,3V. Zweitens kann ich die internen Pull-Ups gegen Vcc (5V via mein FTDI!) abschalten, - UND NICHT EINSCHALTEN, wie es einschlägige Implementierungen im Inet tun. Drittens hat ATMEL der TWI Unit im AVR eigene Driver gegeben, die gemäß I2C Spec 9398 393 40011 natürlich Open Collector sind! Viertens spielt es ganz praktisch gar keine Violine für den HMC, ob die Pull-Ups nun gegen 5V gehen (zumindest die internen zwangsläufig), wenn's auch design-technisch unschön wäre. Die Ursache für einen etwas wackeligen TWI und Null Funktion (leere Datenregister) ist eine andere: Man muss sich dazu das Funktionsprinzip ansehen, die Wheatstone-Brücke mit den magnetoresistiven Elementen und vor allem die beiden Spulen im Sensor! Die werden mit einem brachialen Nadelimpulsstrom zu über 40 Gauss beflügelt, die Elemente werden damit u.Anderem immer wieder einem Degauss unterzogen. Honeywell's Spec sagt daher zu C3: Mind. 4,7uF und SUPER LOW ESR. Nicht ohne Grund: In der Single-Voltage Konfiguration, die Spar-Sparkfun auch auf dem Breakout fährt, gibt es nur die analoge Vcc, nominal 2,5V, 3,3V max. Die Digitalspg. von 1,8V wird via Chip-internen Volatge-Regulator erzeugt. Allerdings ist dann die Dicke-Tal-Spg. auch in Mitleidenschaft gezogen, wenn C3 im Betrieb über die Maßen einbricht. Bingo! Daher funktionierte der Sensor nicht (Analogteil), bei jedem Degauss ging es in den Keller, und es gab Hazards beim Lesen der Register, was zunächst mal nach Wackel-TWI roch. Sparkfun hat hier einen 10uF Tantal Elko drauf, SMD. Der ist aber alles andere als Low ESR!! (In der Vor-Revision wurden sogar nur 4,7uF verwendet.) Einen Low-ESR-Elko als SMD-Lötfurz gibt es nun mal nicht, außerdem kostet der etwas mehr als das Tantal-C. Ich habe nun einfach einen kleinen 100uF-Elko (kein Low ESR) platzsparend (seitlich) über C3 genagelt, und schon ist die Welt i.O. Oh Mann, Sparkfun! Es kann nur Zufall gewesen sein, wenn mal ein Breakout gleich spielte. Ihr seht die im Inet propagierten Probleme Eurer Kunden.. - und ignoriert sie, - sogar in den Comments der HMC-Produktseite auf Eurer Website! Das hat mich richtig Zeit gekostet, hatte vorher noch einen TTL-zu-RS232-Konverter zusammengebrutzelt, um für die Console vom FTDI mit 5V Output wegzukommen und den AVR mit max. 3,3V betreiben zu können. Das war's natürlich alles nich.. Leider war der HMC bei mir so eingebaut, welhalb ich mich lange darum drücke, ihn wieder rauszubrutzeln, um an C3 zu kommen. Hätte ich mal gleich machen sollen.. Honeywell, my apologies. Sparkfun, bück Dich mal.. God save the States. So long. Tom
Hallo. Ich probiere mich gerade an dem HMC5843 und dessen Neigungskompensation. Leider habe ich gerade ein Verständnisproblem bezüglich der Beschleunigungssensorwerte aus denen ja die Werte für Pitch und Roll resultieren. Auf dem HMC5843 Demo-Board (was ich habe) befindet sich dafür der KXPS5-2050 Beschleunigungssensor von Kionix,der eine Auflösung von 12Bit besitzt.Mit dem Messbereich von +/-2g ergibt sich danach eine Genauigkeit von 0,000976. Entsprechend der Achsenwerte des Kionix (MSB-Register + LSB-Register und danach die unteren 4Bit rausschieben) sollten nach der Formel Winkel X-Achse = asin(Registerwert_X * 0,000976)/Pi*180 auch der dazugehörige Winkel rauskommen,den mir auch die mitgelieferte Simulationssoftware anzeigt. ...Tut es aber nicht! Hat einer eine Idee,was ich falsch mache? MfG,Maik
Hallo. Kennt einer von euch die "absolut maximum ratings" des HMC5843? Im Datenblatt ist dazu nichts zu finden. Gruß,Tom
Guten Morgen. Ich habe aktuell folgendes Problem: Ich habe mir letztes Jahr Muster vom HMC5843 bestellt.Einen Sensor habe auf eine Testplatine gelötet und der funktioniert auch relativ gut. Für die anderen Sensoren wurde eine LP entworfen, die dasselbe Layout besitzt,wie die Testplatine. Die gleichen Pull-Ups (jeweils 2,2K), Kondensatoren (100nF zwischen SETP und SETC;4,7µF ElKo von C1 nach GND und zwischen AVDD und GND auch 100nF) usw. . Die Sensoren werden im Single-Supply Betrieb versorgt. Das Problem ist nun: Sende ich die Slave-Adresse,dann bekomme ich auch ein ACK zurück (Stauts: 0x18).Will ich aber nun ein Register auswählen und sende den write-Befehl bekomme ich ein NoACK zurück (Status: 0x30). Der danach folgende repeated start-Befehl mit der Sensoradresse zum Auslesen gibt mir dann wieder ein ACK zurück (Status: 0x40) und beim Auslesen der Achsenregister bekomme ich auch ein ACK zurück (Status: 0x50),allerdings ist der Inhalt falsch. Hat jemand eine Ahnung warum mir der Sensor ein NoACK zurück gibt,wenn ich ein Register auswählen will?
Hier ein kleiner Beitrag: Im Anhang sind PR99SE CAD/CAM Dateien fuer eine kleine HMC5843 Sensor Platine mit 5V Versorgung und 5V kompatible I2C Datenschnittstelle. Das Design lehnt sich hauptsaechlich an die Single Supply Version des Datenblatt an. Da ich noch keine Gelegenheit hatte die Platine fertigen zu lassen kann ich nicht garantieren dass sie ohne Aenderungen richtig funktioniert. mfg, Gerhard
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.