I2C-Blockade durch Motoren

Ersatz- und Fremdteile, Modifikationen, etc.
Special Hints - Spare- & foreign parts, Modifications, etc.

Moderator: Jan3D

Forumsregeln
Bitte beachte die Forumsregeln!
Benutzeravatar
MasterOfGizmo
Beiträge: 2320
Registriert: 30 Nov 2014, 07:44

Re: I2C-Blockade durch Motoren

Beitrag von MasterOfGizmo » 14 Sep 2021, 10:54

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.
Für fischertechnik: Arduino ftDuino http://ftduino.de, Raspberry-Pi ft-HAT http://tx-pi.de/hat

Benutzeravatar
Harald
Beiträge: 450
Registriert: 01 Nov 2010, 07:39

Re: I2C-Blockade durch Motoren

Beitrag von Harald » 14 Sep 2021, 14:37

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
--- Ich liebe es, wenn ein Modell funktioniert. ---

atzensepp
Beiträge: 146
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 14 Sep 2021, 15:28

Hier sieht man den kleinen Peak deutlicher:
2b.jpg
2b.jpg (62.97 KiB) 274 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.

Benutzeravatar
elektrofuzzis
Beiträge: 159
Registriert: 25 Jun 2016, 09:40

Re: I2C-Blockade durch Motoren

Beitrag von elektrofuzzis » 14 Sep 2021, 16:35

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

atzensepp
Beiträge: 146
Registriert: 10 Jul 2012, 21:40
Wohnort: Uttenreuth

Re: I2C-Blockade durch Motoren

Beitrag von atzensepp » 14 Sep 2021, 22:09

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.

Antworten