Hallo, wir haben diesen Beschleunigungssensor vom MiraMEMS und wenn wir diesen betreiben dann empfangen wir von Zeit zu Zeit (ca. 40 Minuten) Interrupts obwohl der Sensor total in Ruhe ist. Wir haben uns die Versorgungsspannung angeschaut und die zeigt keine Auffaelligkeiten. Schaltschwelle liegt weiter ueber dem Rauschen und so langsam gehen uns die Idee aus.
Sind denn die Werte, die den Interrupt ausgelöst haben, über der Schaltschwelle? seismische Ereignisse, Straßenverkehr, Bahnverkehr, Kollege der trampelt, ... oder habt ihr eine vollkommen erschütterungsfreie Testumgebung?
Fake Sensoren erwischt? Machen das alle Sensoren oder nur einige? Kommen die Interrupts auch wenn alle Interrupts wegkonfiguriert sind? Versuche einzeln die Interrups zu enablen und schauen welche es ist. Richtig gelötet? Datenblatt sagt max 260 Grad. Habe mal LEDs gehabt die hitze nicht gemocht haben. Da musste ich die mit eine spezial Lötpaste löten damit die LEDs nicht so heiss werden.
Laute Geräusche? einfach mal ein Video mitlaufen lassen und dann schauen, ob es irgendwas gab.
Da gibt es zwar Daten zur ESD-Festigkeit, aber keine zur Einstrahlfestigkeit. Liegt z.B. ein Handy daneben, das gelegentlich auf Sendung geht? Dem Blockschaltbild nach sind das differentielle kapazitive Sensoren.
Angehängte Dateien:
-
Schematic.png
110 KB
Danke erstmal fuer die Antworten... leider machen wir die Entwicklung nicht selber und haengen von unserem Supplier ab was die Sache nicht einfacher macht. Mein Kollege (Projektmanager) ist gerade dort und versucht das Projekt vorwaerts zu bringen. Die Schaltschwelle liegt bei 1.5m/s^2 was schon recht hoch ist. Da muss schon was so richtig wackeln. Vor lauter Verzweifelung und dem Umstand das wir immer vom Supplier abhaengen habe ich mir ein paar Breakout Boards gekauft um so die Sensorem mit einem Arduino verheiraten koennen. So haetten wir den Sensor wenigstens isoliert und volle Kontrolle...
Angehängte Dateien:
-
DA221_InterruptPin.png
48 KB
Daisy D. schrieb: > wenn wir diesen betreiben dann empfangen wir von Zeit zu Zeit (ca. 40 > Minuten) Interrupts Hast du da am Interrupteingang des µC gemessen? Was siehst du in diesem Augenblick am Interrupteingang, wenn der Interrupt kommt? Einen validen Interrupt oder nur einen ESD-Spike? Oder beobachtest du lediglich eine Reaktion in der Software? > wenn wir diesen betreiben Wie sieht der mechanische und elektrische Aufbau aus? Wie ist der Interruptpin konfiguriert (Push-Pull oder Open-Drain)? EDIT: Daisy D. schrieb: > Die Schaltschwelle liegt bei 1.5m/s^2 was schon recht hoch ist. Da muss > schon was so richtig wackeln. Wenns langsam hin- und herwackelt, dann braucht es tatsächlich eine ordentliche Amplitude. Aber wenn es nur leise "Knacks" macht, dann ist wegen der hohen Frequnez des "Knacksens" die Beschleunigung gleich ziemlich hoch. Oder andersrum: wenn du das Ding aus 1 cm Höhe auf die Tischplatte fallen lässt, dann ist die "Bremsentschleunigung" signifikant höher als der Grenzwert. Und noch eins: warum ist es schlimm, wenn da alle halbes Schaltjahr mal ein überflüssiger Interrupt kommt?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > wenn du das Ding aus 1 cm Höhe auf die Tischplatte > fallen lässt, dann ist die "Bremsentschleunigung" signifikant höher als > der Grenzwert. Wenn der auf einer harten Tischplatte liegt, werden auch ohne jede Berührung schnell 0.5g für 1ms erzeugt. Also abhängig von #27H active_dur
Warum ist VDD des Sensors mit 1µF und nicht mit 100nF wie in dem Datenblatt bestückt? Die Pins 3+4 sehen auch komisch aus.
:
Bearbeitet durch User
Angehängte Dateien:
-
DA221_App.png
41 KB -
DA221_Pins.png
55 KB
Pete K. schrieb: > Die Pins 3+4 sehen auch komisch aus. Pin 3 ist nicht NC. Und Pin 4 ist NC ohne interne Verbindung. Ich denke, da sollte man mal insgesamt genau drauf schauen...
Daisy D. schrieb: > wir haben diesen Beschleunigungssensor vom MiraMEMS und wenn wir diesen > betreiben dann empfangen wir von Zeit zu Zeit (ca. 40 Minuten) > Interrupts obwohl der Sensor total in Ruhe ist. Welche Interrupts denn?
Lothar M. schrieb: > Pete K. schrieb: >> Die Pins 3+4 sehen auch komisch aus. > Pin 3 ist nicht NC. Und Pin 4 ist NC ohne interne Verbindung. Ich denke, > da sollte man mal insgesamt genau drauf schauen... Autsch… Solche Schlampigkeiten im Schaltplan sind oft ein Indikator dafür, dass auch in anderen Aspekten nicht sauber gearbeitet wird. Ich kenne diesen Sensor nicht, aber grundsätzlich ist zu erwarten, dass der eine saubere Stromversorgung benötigt, also sauber auf einen Niveau, damit der analoge Teil richtig arbeiten kann. Das geht bis runter zu der Frage wie denn genau die Leitungsführung für die Stromversorgung ist, damit keine hochfrequenten Störanteile durch kommen.
Beitrag #7971339 wurde vom Autor gelöscht.
> ca. aller 40 Minuten
Könnte das gewollt sein? Ähnlich Totmannkontrolle bei der Lok?
Wo ist der Pullup fuer die Interruptleitung? Falls nur der Pullup Widerstand der CPU verwendet wird, geht das wahrscheinlich, wenn die Interruptleitung nur auf der Platinen verlaeuft. Beim STM32 z.B. ist der interne Pullup > 20 kOhm und typisch 50 kOhm. Falls noch Verdrahtung bei der Interruptleitung mitspielt, wuerde ich extern einen Widerstand im kOhm Bereich einfuegen um robuster gegen Stoerungen zu werden.
Lothar M. schrieb: > Pete K. schrieb: >> Die Pins 3+4 sehen auch komisch aus. > Pin 3 ist nicht NC. Und Pin 4 ist NC ohne interne Verbindung. Ich denke, > da sollte man mal insgesamt genau drauf schauen... Ich verstehe Deinen Einwand nicht. Was genau ist falsch?
Uwe B. schrieb: > Lothar M. schrieb: >> Pete K. schrieb: >>> Die Pins 3+4 sehen auch komisch aus. >> Pin 3 ist nicht NC. Und Pin 4 ist NC ohne interne Verbindung. Ich denke, >> da sollte man mal insgesamt genau drauf schauen... > > Ich verstehe Deinen Einwand nicht. Was genau ist falsch? Beschaltung Pin3+4 passen nicht zum Datenblatt. Genauso wenig wie die Abblockkondensatoren. Zuerst würde ich mal Pin4 abklemmen und schauen, ob sich etwas ändert.
:
Bearbeitet durch User
Sorry, ich habe den Schaltplan 25.11.2025 14:24 nicht gesehen...
Uwe B. schrieb: > Wo ist der Pullup fuer die Interruptleitung? Falls nur der Pullup > Widerstand der CPU verwendet wird, geht das wahrscheinlich, wenn die > Interruptleitung nur auf der Platinen verlaeuft. Laut DB ist der AUsgang auf PushPull oder OpenDrain konfigurierbar. Nach Reset ist der auf PP konfiguriert. Siehe 7.17. im obigen Datenblatt. Wenn den dann aber jemand nach OD umkonfiguriert, dann ist der natürlcih sehr störempfindlich. Deshalb schrieb ich ja das mit dem "Messen am Interrupteingang des µC".
Wenn das so gut reproduzierbar ist kann man ja einfach ein Oszi an den Pin hängen. Wenn was wackelt, dann ist der Interrupt des Controller berechtigt. Dann kommt es entweder vom Sensor direkt oder an fehlenden Pullups o.ä. wie von anderen schon geschrieben. Wenn aber nichts DAUERHAFT wackelt auf der Leitung, hat vielleicht auch jemand nicht vernünftig das ISR Flag abgelöscht oder ein anderer Software Fehler liegt vor. Und wenn es nur durch das anschließen des Oszi nicht mehr Auftritt, dann geht es auch eher in die Hardware Richtung.
Daisy D. schrieb: > dann empfangen wir von Zeit zu Zeit (ca. 40 Minuten) Interrupt Ist das denn so schlimm? Lest doch im Interrupt -Fall die Rohdaten aus und entscheidet in Software, ob genug Bewegung vorliegt. Einzelne Samples eines Accelerometers taugen sowieso nicht für eine Einschätzung der Aktivität, man kann z.B. die Varianz über mehrere Samples berechnen. Diese Activity Detection Interrupts sind sowieso nicht dafür gedacht dass man diese als Auslöser für eine Aktion nutzt - nur dafür, den Mikrocontroller aus dem Standby zu wecken, damit der dann eine bessere Entscheidung treffen kann. Daher sind solche Interrupts eher absichtlich überempfindlich - so verschwendet man im schlimmsten Fall alle 40 Minuten ein winziges Bisschen Energie. Der Interrupt ist eine Power-Saving Funktion, keine Datenverarbeitung. Wenn der Stromverbrauch egal ist, schaltet den Interrupt ab und macht die Verarbeitung in Software.
OK, erstmal Danke fuer die vielen Tips. Vielleicht noch ein wenig zum Hintergrund: a) Die Entwicklung findet in China statt und unser Projektmanager ist gerade dort. Natuerlich gibt es noch andere Probleme aber die sind loesbar. b) Es ist ein batteriebetriebener Bewegungsmelder, die meiste Zeit schlaeft der Prozessor daher der Interrupt Wie immer in solch einer Situation ist es schwierig zu beurteilen ob der Supplier nicht genug Resourcen (Zeit, Personal) zur Verfuegung stellt, nicht genug Skills vorhanden sind oder ob die Motivation nicht vorhanden ist. Das Projekt ist nun im dritten Jahr und die letzten 10% ziehen sich wie Kaugummi. Die Firma denkt ernsthaft darueber nach das Projekt nach Hause zu holen. Wir haben hier vor Ort jemanden der das koennen wuerde. Wir haben schon ein Oszilloskop angeschloessen und ja der INT ist sichtbar, Rechteck, 250ms lang. Ach ja, die Kondensatoren haben wir schon geaendert, nun 100nF. Ich wollte noch vorschlagen alle NC wirklich abzuklemmen. Nervoes macht mich hier der Mix von GND and VCC.
1) Ich würde den Sensor mal "alleine" sauber mit möglichst wenig drumherum an einen Arduino/STM32/irgendwas hängen und schauen, ob das da auch passiert. Das habt ihr ja auch schon geplant. 2) Dann mal alle 5 bis 40 Minuten oderso einen Soft Reset via I²C / Config Register (+reconfig wenn nötig) machen und schauen, ob das dann immer noch passiert. (Wenn es dann nicht passiert ist der Sensor halt komisch. Dann entweder via I²C prüfen - siehe 3 - oder als workaround regelmäßig resetten 😬) 3) Ich hab das Datenblatt nur kurz überflogen. Was sagen denn MOTION_FLAG und ACTIVE_STATUS? Ist active_int und ein active_first_* gesetzt oder nicht? Lässt sich sonst anhand der ausgelesenen Daten erkennen, ob es ein falscher Alarm war, oder nicht? Ansonsten sehe ich das wie Niklas. Alle 40 Minuten mal ein spurious IRQ (kennt man bei andern Anwendungen auch) ist vom Energieverbrauch her jetzt vermutlich nicht superschlimm. Solange man dann per I²C sieht, was jetzt Sache ist/war.
:
Bearbeitet durch User
Danke mein Verdacht ist das de Softwaremann relativ unerfahren ist. Alles hier vorgeschlagene haette ich auch gemacht. Aber ich weiss wirklich nicht was dort gerade gemacht wird. Ich habe vorgeschlagen mitzufliegen war aber nicht erwuenscht. Ich habe mir ein paat breakout boards besorgt, Kollege bringt ein paar Sensoren mit, aufloeten und dann wollen wir genau das ausprobieren.
Angehängte Dateien:
-
image__1_.png
22 KB
Der Kollege hat mir das gesendet und ich bekomme immer mehr den Verdacht das ist ein Problem mit dem Skillset. Seit wann muss man eingehende Interrupts alle 100ms Pollen? Und dann diese Counter Geschichte? I2C wird anscheinend nur zum Setzen der Register benutzt, nie um die eigentlichen Beschleunigungswerte (x,y,z) auszulesen. Jedenfalls ist es das was ich hier verstehe.
:
Bearbeitet durch User
Daisy D. schrieb: > Die Firma denkt ernsthaft darueber nach das Projekt nach > Hause zu holen. Wir haben hier vor Ort jemanden der das koennen wuerde. Warum nicht gleich so?
Ich habe auch schon mit diversen Sensoren gearbeitet. Kann man da nicht mal nachschauen, was überhaupt los ist. Einfach mal eine Stunde mit 10Hz mit samplen, und vielleicht nebenan mal auf und ab springen? Bei anderen Sensoren hatten wir Probleme, wenn nebenan die Straßenbahn gefahren ist. Dann bekommt man ein Gefühl, was der Sensor wirklich misst, und wo Schwellen anzusetzen sind. Vielleicht muss man sehen, dass mehrere Ereignisse pro Zeiteinheit kommen müssen, um einen Alarm auszulösen. Nur irgendein Ding in China bestellen, und dann einen G-Wert aus dem Datenblatt einzutragen ... das hat noch nie funktioniert.
Daisy D. schrieb: > Das Projekt ist nun im dritten Jahr und die letzten 10% ziehen sich wie > Kaugummi. Oh weh, und es scheitert an ein bisschen Accelerometer-Auswertung? Daisy D. schrieb: > das ist ein Problem mit dem Skillset Der Verdacht drängt sich auf. Ein fähiger Entwickler kriegt diese Activity-Detection in ein paar Tagen (höchstens) umgesetzt. Mit durchschnittlichem Standby-Strom von MCU+ACC < 1μA. Benedikt H. schrieb: > Alle 40 Minuten mal ein spurious IRQ Ganz genau, a priori können alle Arten von Interrupts einfach so sporadisch auftreten, man muss immer explizit die Ursache prüfen.
Daisy D. schrieb: > Vielleicht noch ein wenig zum Hintergrund: > a) Die Entwicklung findet in China statt So hart das klingt: Dienst nach Vorschrift. Sollen doch die BWLer, die das entschieden haben, weiter entscheiden.
Auch in China gibt es fähige Entwickler... Die wollen natürlich auch bezahlt werden.
Moin, Daisy D. schrieb: > das ist ein Problem mit dem Skillset. Da wuerde ich zuerst mal die Skills hochampern :-) scnr, WK
Daisy D. schrieb: > Seit wann muss man eingehende Interrupts alle 100ms Pollen? > Und dann diese Counter Geschichte? Uah, üble Sache. Eingang zyklisch einlesen und dann eine dubiose Filterung drauf aufsetzen? Daisy D. schrieb: > die meiste Zeit schlaeft der Prozessor daher der Interrupt ... nur alle 100ms wacht er auf und wertet den Interrupteingang aus. Da hat offenbar irgendwer eine ganz eigenartige Vorstellung von Interrupts und Stromsparen.
Daisy D. schrieb: > Jedenfalls ist es das was ich hier verstehe. Zumindest weißt Du jetzt, warum der Interrupt für 250ms anliegt. Das Datenblatt ist relativ kompakt, lass Dir bestätigen, welche Register wie beschrieben werden. Alles andere wäre eine interpretation, was wer warum verstanden hat oder machen wollte. Offensichtlich erklärt sich das Verhalten dann. Und falls nicht, musst Du verifizieren, ob dass Schreiben richtig umgesetzt wurde. Mit irgendeinem I2C-Mitlesetool (die ich letztmalig vor 20 Jahren benutzt habe, keine Ahnung, was da heute üblich ist)
Daisy D. schrieb: > Und dann diese Counter Geschichte? I2C wird anscheinend nur zum Setzen > der Register benutzt, nie um die eigentlichen Beschleunigungswerte > (x,y,z) auszulesen. Ich hatte ganz oben schon mal gefragt was der Sensor denn für Werte liefert wenn der Interrupt ausgelöst wird. Wenn ich das jetzt richtig verstehe habt ihr nicht mal die Sourcen um zu prüfen was da überhaupt programmiert wurde?
Bruno V. schrieb: > Mit > irgendeinem I2C-Mitlesetool (die ich letztmalig vor 20 Jahren benutzt > habe, keine Ahnung, was da heute üblich ist) DSO mit I2C-Decoder. Oder so ein kleiner Logikanalysator von Saleae.
:
Bearbeitet durch User
Bruno V. schrieb: > lass Dir bestätigen, welche Register wie beschrieben werden. Ich würde hier den µC den Sensor initialisieren lassen, dann den originalen µC in den Reset biegen und die Register mit einem anderen µC/Arduino/sonstwas auslesen. Denn angelogen ist man schnell. > Das Datenblatt ist relativ kompakt Das stimmt allerdings. Wenn ich das mit einem BMA456 von Bosch vergleiche...
Natürlich kann man den Sensor mithilfe eines Arduinos testen. Aber was kann dabei rauskommen? Dann funktioniert es oder auch nicht, die Ursache bleibt aber offen. Man hat ja dann eine andere Hardware und eine andere Software. Beide können sich anders verhalten als das Original. Kennt man die Ursache nicht, kann man sie nicht sicher beseitigen. Es könnte sogar sein, dass die interne Logik des Sensors (oder dessen Datenblatt!) fehlerhaft ist, was sich wegen anderer Programmierung beim Arduino-Test nicht zeigt, wohl aber mit der Original-Software. Deshalb: Wenn man die Original-Software nicht zum Kontrollieren in Source-Form hat, ist es ziemlich witzlos.
:
Bearbeitet durch User
Lothar M. schrieb: > Ich würde hier den µC den Sensor initialisieren lassen, dann den > originalen µC in den Reset biegen und die Register mit einem anderen > µC/Arduino/sonstwas auslesen. Denn angelogen ist man schnell. Und du müsstest dann hoffen, dass du genau das ausliest, was die Original-Software gemacht hat. Und was die Original-Software NACH dem Initialisieren macht, weißt du dann immer noch nicht. Die kann da irgendwas reinschreiben, und es gibt sogar Fälle, in denen durch Lesen von Registern deren interner Zustand verändert wird (z. B. beim Quittieren irgendwelcher Befehle oder Interrupts).
Rolf schrieb: > Und was die Original-Software NACH dem Initialisieren macht, weißt du > dann immer noch nicht. Nein, aber ich bin hinterher nur noch halb so dumm wie vorher. Fehlersuche funktioniert in den allermeisten Fällen so, dass man Puzzlestück für Puzzlestück zusammensammelt und -fügt. Und natürlich untersuche ich mit dem Picoscope (oder sonst einem LA) auch noch den Datenverkehr auf dem I2C-Bus. > und es gibt sogar Fälle, in denen durch Lesen von Registern deren > interner Zustand verändert wird (z. B. beim Quittieren irgendwelcher > Befehle oder Interrupts). Ja, das kenne ich nur von uralten Gurken. Bei halbwegs aktuellen ICs dieseits der Jahrtausendgrenze ist mir das nicht mehr untergekommen. Und entsprechend dem obigen Datenblatt passiert das auch beim hiesigen DA221 nicht.
Lothar M. schrieb: > Bei halbwegs aktuellen ICs dieseits der Jahrtausendgrenze ist mir das > nicht mehr untergekommen. Brandaktuelle IMUs von ST oder Analog machen das genau so, interne Peripherieregister vieler Mikrocontroller auch...
Rolf schrieb: > Und du müsstest dann hoffen, dass du genau das ausliest, was die > Original-Software gemacht hat. Warum? Erstmal geht es doch darum, zu klären, ob es am Sensor liegt. Falls mit dem Testsystem die sporadischen Interrupts nicht auftreten würden, wäre man doch schon einen Schritt weiter.
Ist der Interrupt Ausgang des Sensor Push/Pull? Hängt der Interrupt Eingang mit statischer Restladung in der Luft?
Nochmals vielen Dank fued die vielen Antworten. Ja das Problem ist das wir nicht einmal die Registerwerte des Sensors erhalten, geschweige denn den Sourcecode. Ich bin auch nicht vom Fach, kann ein paar Zeilen programmieren, usw. aber bei groesseren Dingen muss ich auf externe Resourcen zurueckgreifen. Ich schaue mir gerade den Schaltplan nochmal an und natuerlich gibt es fuer den I2C bus keine Testpunkte... clever. Schaue mir morgen das PCB an, eventuell kann ich I2C an den Pull Up Widerstaenden abzapfen. Habe so ein Digilent Analog Teil , das kann I2C decodieren.
Rainer W. schrieb: >> Und du müsstest dann hoffen, dass du genau das ausliest, was die >> Original-Software gemacht hat. > Warum? Weil er nur den Zustand zu einem bestimmten Zeitpunkt ausgelesen hat. Was die Software davor und vor allem danach gemacht hat, erfährt er so nicht. > Erstmal geht es doch darum, zu klären, ob es am Sensor liegt. Falls mit > dem Testsystem die sporadischen Interrupts nicht auftreten würden, wäre > man doch schon einen Schritt weiter. Das Testsystem hat andere Hardware und andere Software. Wenn es den Fehler nicht zeigt, liegt das Problem in der Original-Hardware (Sensor UND sonstige Hardware) oder -Software. Wenn es den Fehler zeigt, liegt es vielleicht am Sensor, vielleicht aber auch daran, dass die Testsoftware denselben Denkfehler enthält wie die Original-Software.
:
Bearbeitet durch User
Christoph M. schrieb: > Ist der Interrupt Ausgang des Sensor Push/Pull? Hängt der Interrupt > Eingang mit statischer Restladung in der Luft? Es wurde ein Rechteckimpuls mit 250 ms gemessen. Das macht ein unsauberes Signal unwahrscheinlich. Wenn man dann noch im Datenblatt liest, dass es einen Modus gibt, in dem der Interruptausgang für 250 ms festgehalten wird ...
Daisy D. schrieb: > a) Die Entwicklung findet in China statt und unser Projektmanager ist > gerade dort. Natuerlich gibt es noch andere Probleme aber die sind > loesbar. Basierend auf praktischen Erfahrungen: Holt das sofort nach Hause. Es ist schon schlimm genug was bei uns hier teilweise entwickelt wird nach dem Motto "wieso? Hat doch beim Rumbasteln funktioniert!". Aus China habe ich da Dinge gesehen, wo man echt keine Frage stellen musste, warum das nicht funktioniert. Die Fehler im Schaltplan deuten schon darauf hin, dass da jemand dran sitzt, ohne wirklich zu wissen, was er da tut. Da lohnt sich die Suche nach der Fehlerursache wahrscheinlich nicht mal. Weg werfen und richtig machen.
Daisy D. schrieb: > Ja das Problem ist das wir nicht einmal die Registerwerte des Sensors > erhalten, geschweige denn den Sourcecode. Der Arbeitsmodi macht keinen Sinn: Wenn man derart komplett eine Baugruppe extern entwickeln lässt, ist der externe Entwickler auch für die korrekte Funktion und ggf. die Fehlersuche zuständig. Macht die Baugruppe also nicht was sie soll, mit Fehlerbeschreibung zurück an den externen Entwickler.
Cyblord -. schrieb: > Der Arbeitsmodi macht keinen Sinn: Die Mehrzahl von "Modus" lautet "Modi"
:
Bearbeitet durch User
Christoph M. schrieb: > Cyblord -. schrieb: >> Der Arbeitsmodi macht keinen Sinn: > > Die Mehrzahl von "Modus" lautet "Modi" Du hast Recht. Vielen Dank für deine freundliche Korrektur.
Guido K. schrieb: > Basierend auf praktischen Erfahrungen: Holt das sofort nach Hause. > > Es ist schon schlimm genug was bei uns hier teilweise entwickelt wird > nach dem Motto "wieso? Hat doch beim Rumbasteln funktioniert!". Aus > China habe ich da Dinge gesehen, wo man echt keine Frage stellen musste, > warum das nicht funktioniert. Man muss bei jedem Projekt die Vor- und Nachteile gegeneinander aufwiegen. Nachteile hier: Die Kontrolle über das Projekt ist verloren. Die Kontrolle über die Hardware ist verloren. Die Kontrolle über die Software ist verloren. Vorteile: Man kann nun beruhigt schlafen gehen. Es wird nichts passieren, denn noch mehr kann man nicht verlieren.
Norbert schrieb: > Man kann nun beruhigt schlafen gehen. Es wird nichts passieren, denn > noch mehr kann man nicht verlieren. Sicher nichts Schlimmes. Aber Gewährleistungsansprüche der Kunden, ggfls. hohe Konventionalstrafen an die Auftraggeber, also die Kunden vom TO. Sieht mir nach einer sehr amateurhaften Klitsche aus.
Daisy D. schrieb: > Schaue mir morgen das PCB an, eventuell kann ich I2C an den Pull Up > Widerstaenden abzapfen. Mit Sicherheit. Selbst bei SMD hat das bei mir seither immer gut gereicht. Dann nimmst du gleich noch die ISR Leitung dazu beim aufzeichnen. Also gerade Mal 3 Kanäle. Lothar M. schrieb: > mit dem Picoscope (oder sonst einem LA) auch noch den Datenverkehr auf > dem I2C-Bus. Für I2C reicht selbst so ein 4€ Low Cost Logicanalyzer mit dem Cypress Chip drauf (24MSPS@8Ch). Oder ein Raspberry Pi Pico Board (ab 1,70€ bei Ali) mit dem Gusmanb Logicanalyzer (200MSPS@24Ch). Oder wenn ihr euch richtig in Unkosten stützen wollt ein vor kurzem rausgekommener Slogic16u3 für 70€ (800MSPS@4Ch). Geht scheinbar alles mit einem Sigrok Ableger.
Done.... 27, 0F, 60 0x0F → RANGE register Writes 0x60 Bits 1:0 = 00 → full-scale ±2 g (fs[1:0] = 00) (Upper bits are “unused” / vendor-internal, so don’t worry about the 0x60 vs 0x40.) 2. 27, 10, 03 0x10 → ODR_AXIS register 0x03 → ODR[3:0] = 0011 → 7.81 Hz output data rate 3. 27, 11, 06 0x11 → MODE_BW 0x06 → PWR_OFF = 0 → normal mode BW[1:0] = 11 → bandwidth = ½ × ODR autosleep_en = 0 → runs continuously at chosen ODR 4. 27, 16, 87 0x16 → INT_SET1 0x87 → INT_source[1:0] = 10 → filtered data active_int_en_x/y/z = 1 → active interrupt enabled on all 3 axes 5. 27, 19, 04 0x19 → INT_MAP1 0x04 → INT_active = 1 → map active interrupt to INT pin 6. 27, 28, 24 0x28 → ACTIVE_THS (active threshold) 0x24 = 36dec → threshold = 36 × K For ±2 g range: K ≈ 3.9 mg → about 0.14 g change needed to trigger 7. 27, 27, 00 0x27 → ACTIVE_DUR 0x00 → active_dur = 0 → needs just 1 consecutive sample over threshold → duration ≈ (0+1)/ODR ≈ 0.13 s at 7.81 Hz 8. 27, 20, 81 0x20 → INT_CONFIG 0x81 → reset_int = 1 now (clears any latched interrupts) INT_od = 0 → push-pull output INT_lvl = 1 → active-high INT pin 9. 27, 21, 01 0x21 → INT_LATCH 0x01 → latch_INT = 0001 → temporary latch for 250 ms Sieht alles nicht verkehrt aus. Wir jagen gearde einen Verdacht nach und morgen werde ich mehr wissen.
Daisy D. schrieb: > Upper bits are “unused” / vendor-internal, so don’t worry about the 0x60 > vs 0x40.) Habe mir nicht alle Register angeschaut. Aber mit solchen Aussagen wäre ich vorsichtig. Gerade in einem Register das Range heißt. Ihr habt Probleme mit Bereichen/Messwerten. Da würde ich persönlich nicht auf unbekannte Register schreiben! Das wäre im Code eine Aktion von 5s das zu ändern. Daisy D. schrieb: > RANGE register > Writes 0x60
:
Bearbeitet durch User
Daisy D. schrieb: > Sieht alles nicht verkehrt aus. > > Wir jagen gearde einen Verdacht nach und morgen werde ich mehr wissen. Wie sieht denn die Leiterplatte aus? Es gibt da das, was ich gehässig als "aufgeräumtes Design" bezeichne: Chips in der einen Ecke, Kondensatoren in der anderen. Grade bei Schaltungen die analoge und digitale Komponenten haben (und die hat der Sensor intern), muss man aufpassen wo die Leitungen für Masse und Versrogungsspannung lang gehen und wo genau welche Kondensatoren sitzen. Wir haben grad das Design eines Photoverstärkers hinter uns, der hat bis zu 10^8 Verstärkung, da muss man schon genau hin sehen was wo ist. Da hatten wir auch einen Denkfehler im Layout der Masse, der uns dann richtig Ärger gemacht hat.
Danke.... Kondesnatoren sind ganz nah am Sensor. Wir haben 4 Samples wo wir alls NC Pins entfernt haben. 2 Samples ohne Gehaeuse liefen ohne seltsame Interrupts. 2 Samples im Gehaeuse erzeugten alle 2 zwei Stunden einen seltsamen Interrupts.
Danke.... Kondensatoren sind ganz nah am Sensor. Wir haben 4 Samples wo wir alls NC Pins entfernt haben. 2 Samples ohne Gehaeuse liefen ohne seltsame Interrupts. 2 Samples im Gehaeuse erzeugten alle 2 zwei Stunden einen seltsamen Interrupts. Sorry mani, ich verstehe nicht ganz. Nicht zum Register schreiben und im Default value lassen oder 0x40, oder 0x00?
Ich komme aus der MEMS-Sensor-Ecke. Ich würde da nicht so viel drauf geben. Bau mal zwei direkt nebeneinander und korreliere das. Da gibt es einen haufen Dreck-Effekte. Und wie die Leute geschrieben haben: 1,5 ms^-2 sind nicht besonders viel für Spikes. Da reicht eine thermische Verspannung der PCB im Gehäuse, die sich "entlädt". Über Temperatur gibt es dann noch dass, was wir intern immer Flussmittelknacken genannt haben: Flussmittel kristallisiert über Temperatur teilweise schlagartig aus, sodss die Reste nach dem Rflowlöten, die unter dem Chip sind ziemlich zuverlässig an verschiedenen Temperaturpunkten einen "Knacks" auslösen. Einfach Postprozessieren und das event bei zu kurzer Dauer / zu geringer Energie (~Ausschlag * Zeit) einfach verwerfen.
Danke... ich versuche dies unseren Leuten und Supplier schon seit laengerem klar zu machen. Der Interrupt ist nur da um zu sagen das ist etwas. Der Processor wacht auf und schaut denn mal nach. - Gab es nur diesen einen Interrupt (falsch oder tatsaechlich) dann geh wieder schlafen. - Gibt es mehrere in einem gewissen Zeitrahmen, dann schau mal nach was da los ist. Man kann sich ja da ein paar verschiedene Situationen ausdenken.
M. N. schrieb: > ziemlich zuverlässig an verschiedenen Temperaturpunkten einen "Knacks" > auslösen Spannend, was für Temperaturen sind das denn ungefähr? Bei regelmäßigen Temperaturschwankungen um einen kritischen Punkt würde man ziemlich viele "Knackse" messen? Ist das dann wirklich nur ein einzelner kurzer Impuls? Sieht der immer gleich aus (Amplitude?), oder hängt der auch von der aktuellen Lage/Gravitationsrichtung ab? Wenn man kurze Events à la Tippen/Aufschlag messen möchte, könnte sowas recht schwierig davon unterscheidbar sein? Kann man das reproduzierbar testen?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.