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

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

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...

hey, wie siehts bei euch den momentan so aus? hat sich noch etwas
ergeben?

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!

Danke Edgar!

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?

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

@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!

> 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. :)

>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

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

@ 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.

@ 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.

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

Hat hier keiner einen Tipp/einen Ansatz?

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?