Seite 2 von 2

Re: I2C-Blockade durch Motoren

Verfasst: 14 Sep 2021, 10:54
von MasterOfGizmo
Wo siehst Du da Störungen? Vor dem ACK? Wenn Du genau schaust müsstest Du ja sehen können, ob das einfach nur der kurze Moment im Wechsel der Kommunikationsrichtung ist.

Re: I2C-Blockade durch Motoren

Verfasst: 14 Sep 2021, 14:37
von Harald
Die kreischenden Gorillas werden mit Öl nicht lange ruhig zu stellen sein. Die Motorwelle hat zwei "selbstschmierende" Sinterlager (d.h. da ist Graphit mit eingebacken), und die verschleißen mit der Zeit. Da ist nix zu retten.

Was für eine Art Schirmung ist das denn, was du da machst? Wenn da ein Mantel um die Signaladern liegt, darf der nur an einer Seite geerdet werden. Und am besten an einem Punkt, den du als die Mitte (Sternpunkt) definierst.

Ich bevorzuge verdrillte Zweidrahtleitungen, neudeutsch "twisted pair". Das ist bei Telefon und Netzwerken Standard. Wenn mehrere Twisted-Pair-Leitungen parallel geführt werden, sollten sie sich in der Schlaglänge (~Steigung der Verdrillung) unterscheiden. Hardcore wäre ein Dieselhorst-Martin-Vierer (--> https://de.wikipedia.org/wiki/Viererverseilung )

Gruß,
Harald

Re: I2C-Blockade durch Motoren

Verfasst: 14 Sep 2021, 15:28
von atzensepp
Hier sieht man den kleinen Peak deutlicher:
2b.jpg
2b.jpg (62.97 KiB) 2833 mal betrachtet
Das ist die erste Seuqenz mit der I2C-Adresse (0x63 = 0b0110110)
Nach dem 8-ten Clock-Impulse tritt dann dieser verhundste Peak auf, als ob da Gatter gegeneinander arbeiten.

Re: I2C-Blockade durch Motoren

Verfasst: 14 Sep 2021, 16:35
von elektrofuzzis
Hallo,

der verhunste Peak kann wie MOG schreibt durch das ACK vom Baustein kommen. Ansonsten sieht das Signal sehr gut aus; ESP-Spikes lassen sich aber auch nur sehr schlecht auf das Scope bekommen.

Um das mit dem kleinen Peak zu analysieren musst Du einen Sensor ohne Multiplexer an Deinen Arduino anschließen und schauen, ob das Bild genauso aussieht. Wenn ja, unbedenklich. In jedem Fall kommt der Peak nicht per ESP-Spike vom Motor.

Um weitere Fehlerquellen sicher auszuschließen: Den Multiplexer brauchst Du nur auf der SDA-Leitung. Auf SDC kann nach Protokoll (auch bei Multiplex) immer nur ein Baustein senden; da alle wieder OC-Technik sind brauchst Du hier weiter nichts.

Du schreibst "ab und zu bleibst Du auch so hängen". Wirf nochmal einen Blick auf Deinen Scatch und reduziere ihn auf das Wesentliche. Für erste Tests, ob Mechanik, HW und SW zusammenpassen auf jeden Fall Interrupts weglassen. Die sind bei mir eine nie endende Fehlerquelle bei globalen Variablen und der Frage to-volantile-or-not-to-volantile?

Wenn Du mit 250000 Baud spielst, dann nimm auf jeden Fall #include <HardwareSerial.h> in den Scatch, dann benutzt Du die HW des ATMEL und nicht die SW-Implementierung. Sonst brauchst Du nichts zu ändern, geht einfach.

Bin echt gespannt, was es am Schluss ist,

Stefan

Re: I2C-Blockade durch Motoren

Verfasst: 14 Sep 2021, 22:09
von atzensepp
Hallo Stefan,

beim direkten Anschluss an den Arduino war der ominöse Peak tatsächlich weg. Beim Oszillografieren der Steuerleitungen A0 und A1 für den 2:4-Decoder (74LS139) ist mir aufgefallen, dass diese nur ca. 1.2V Spannungshub erzeugen konnten. Ich bin jetzt auf andere Pins umgestiegen, die jetzt 3V liefern.
Jetzt ist der Peak weg und die Schaltung läuft bis jetzt anscheinend fehlerfrei. D.h. die Leitungen A0, A1 haben einen Schuss weg oder sie werden vom Motor-Shield anderweitig belegt. EDIT: Arduino ohne Motorshield mit separatem Testprogramm zeigt, dass A0 und A1 nicht defekt sind. Tatsächlich werden im Motor-Shield A0 und A1 für SENS verwendet und sind daher mit Ausgängen eines LMV358-Operationsverstärkers verbunden. :(
(Bleibt noch zu prüfen, ob diese Opamps überlebt haben)

Das mit dem Multiplexer hätte ich von vorne herein machen sollen! :? Nachdem das in reinen Schaltungen problemlos geklappt hat habe ich daran nicht mehr gedacht. Meine Theorie ist nun, dass die 1.2V für die Multiplexer-Schaltung grenzwertig sind und wenn dann die Motoren laufen sinkt das Signal minimal ab und es kommt zu Hängern.

Ich werde weiter probieren aber bis jetzt sieht es gut aus. Danke für den Anstoß, es ohne Multiplexer zu probieren.

Wenn es das war, waren es eigentlich nicht die Motoren. Die haben nur das Fass zum Überlaufen gebracht.
jetzt müsste ich eigentlich alle Verbesserungen rückgängig machen um zu sehen ob es dann immer noch funktioniert.
Erst mal vielen Dank an Alle, die geholfen haben! War sehr lehrreich.

Re: I2C-Blockade durch Motoren

Verfasst: 03 Okt 2021, 08:53
von Defiant
Harald hat geschrieben:
14 Sep 2021, 14:37
Ich bevorzuge verdrillte Zweidrahtleitungen, neudeutsch "twisted pair". Das ist bei Telefon und Netzwerken Standard. Wenn mehrere Twisted-Pair-Leitungen parallel geführt werden, sollten sie sich in der Schlaglänge (~Steigung der Verdrillung) unterscheiden. Hardcore wäre ein Dieselhorst-Martin-Vierer (--> https://de.wikipedia.org/wiki/Viererverseilung )
Mal aus Neugier: Bei Zweileiter verdrillst du beim I2C SDA und SCL miteinander und bei dem Vierer wären noch Spannung und Masse dazu?

Re: I2C-Blockade durch Motoren

Verfasst: 03 Okt 2021, 10:40
von Dirk Fox
Hallo Florian,

eine (auch für mich beim Mitlesen) lehrreiche Geschichte...

Solltest Du mit dem Arduino häufiger bis zu vier (oder sogar mehr) Motoren ansteuern, empfehle ich Dir wärmstens das Motor-Shield von Adafruit. Wir haben uns auch in unserem Buch gegen das Arduino-Shield (liegt jetzt hier herum und verstaubt) entschieden, weil es haufenweise Pins "zweckentfremdet". Das Adafruit-Shield wird via I2C eingebunden und ist daher komplett entkoppelt - alle Pins werden vom Arduino durchgeschleift. Außerdem können mehrere davon "gestapelt" werden, sodass Du bis zu 32x4 Motoren ansteuern kannst. Und es ist extrem zuverlässig; ich habe hier sechs oder sieben im Einsatz und hatte noch nie ein Problem.

Herzliche Grüße,
Dirk