www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik HMC5843-eval


Autor: Guest (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Guest (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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ß

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Guest (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@darnok
Kannst du vielleicht mal deinen Quelltext posten? Wie sieht bei dir die 
Verdrahtung aus? Wo hängen die PullUps?

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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??

Autor: Gast (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: darnok (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Fred (Gast)
Datum:

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

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Fred (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stichwort "clock-stretching" ... vielleicht mal interessant 
auszuprobieren. bei mir geht das leider nicht so schnell, da ich ein sw 
i2c habe.

Autor: Lösung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Edgar!

Autor: darnok (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!?

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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:
#define HMC5843_I2C_ADDRESS 0x1E
#define HMC5843_MODE_REG    2
#define HMC5843_X_MSB_REG   3
#define HMC5843_X_LSB_REG   4
#define HMC5843_Y_MSB_REG   5
#define HMC5843_Y_LSB_REG   6
#define HMC5843_Z_MSB_REG   7
#define HMC5843_Z_LSB_REG   8
#define HMC5843_STATUS_REG  9

#define HMC5843_MODE_CONT       0

#define HMC5843_MEASUREMENT_DATA_LEN    6

Initialisierung:
data_out[0]=HMC5843_MODE_REG;
data_out[1]=HMC5843_MODE_CONT;
send_I2C_data(HMC5843_I2C_ADDRESS, data_out, 2);

Auslesen:
//Test ob Statusregister lesbar
data_out=HMC5843_STATUS_REG;
I2C_read_request(HMC5843_I2C_ADDRESS, &data_out, 1, 1, data_in);

data_out=HMC5843_X_MSB_REG;
//6 Bytes auslesen (2*X, 2*Y...)
I2C_read_request(HMC5843_I2C_ADDRESS, &data_out, 1, HMC5843_MEASUREMENT_DATA_LEN, data_in)

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:
167 -147 278
161 -154 272
164 -155 274
156 -151 271
160 -143 277
158 -148 276
158 -146 278
165 -148 273
153 -156 286
155 -156 269
129 -129 276

> P.S.: Ich habe kein eval-kit, sondern direkt angelötet.

Die Beschaltung entspricht dem Datenblatt des HMC5843, Siehe Foto ;-)

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
156 111 668
164 110 669
157 104 670
158 111 664
165 105 665
163 102 666
162 100 665
158 99 666
160 101 665
168 108 670
159 103 663
170 100 670
159 104 661
159 106 661
153 108 660
163 104 665
158 105 670
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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. :)

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mi Mo (mike123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Mi Mo (mike123)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Falk Willberg (dl3daz) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ron (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat hier keiner einen Tipp/einen Ansatz?

Autor: strommann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.
Kennt einer von euch die "absolut maximum ratings" des HMC5843?
Im Datenblatt ist dazu nichts zu finden.

Gruß,Tom

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gerhard O. (gerhard_)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.