Go Down

Topic: Probleme mit Display (+I2C) und Ultraschallsensor (Read 806 times) previous topic - next topic

ElEspanol

In dem Amazon link stand was von 6V und 18Watt

Essa93

-->wenn Du das delay() weglässt, muss das Display ja noch öfters aktualisiert werden.... Und was hast Du mit millis() versucht, einfach nur das delay() damit ersetzt?

Thema Anschlussplan: möglicherweise liegt das Problem auch darin, dass der Sensor nicht richtig arbeitet, weil das Display schon ne Menge Strom zieht. Entweder eine andere 5V-Versorgung nutzen (z.B. einen Step-Down-Wandler hinter die Batterien, und mit den 5V dann den Arduino, den Sensor, die LEDs und das Display versorgen. Aber mal ausrechnen, was der Wandler an Strom liefern muss.....), oder mal prüfen, ob der Sensor überhaupt korrekte Werte liefert, indem Du die Messungen auf der seriellen Konsole ausgibst....
Ich hab es einmal mit delay() weglassen probiert dann mit delayMicroseconds(2)/delayMicroseconds() -> Wie die Messung vom US-Sensor.

Also wenn ich grob über den Finger alles ausrechne langt das netzteil locker um das alles zu versorgen!

Ebenfalls die Serielle Ausgabe hab ich kontrolliert diese liefert Top Werte (sehr genau)


wie gesagt das Problem liegt darin das sobald wir das Display anschließen wirklich die komplette Performance von unserem Aufbau in den Keller wandert. Das Display flackert bei aktualisierung der Messergebnise (egal wie delay() eingestellt ist) und der LED-Strip aktualisiert den Stand der LED's gefüllte alle 1-2 Sekunden gleich der Aktuallisierung des Displays.
\(°_°)/

DerLehmi

#32
Aug 12, 2017, 10:15 am Last Edit: Aug 12, 2017, 10:17 am by DerLehmi
Quote
wie gesagt das Problem liegt darin das sobald wir das Display anschließen wirklich die komplette Performance von unserem Aufbau in den Keller wandert. Das Display flackert bei aktualisierung der Messergebnise (egal wie delay() eingestellt ist) und der LED-Strip aktualisiert den Stand der LED's gefüllte alle 1-2 Sekunden gleich der Aktuallisierung des Displays.
-->Während die serielle Konsole plausible Werte ausgibt?

Quote
Also wenn ich grob über den Finger alles ausrechne langt das netzteil locker um das alles zu versorgen!
-->Tjo, denn mach doch die Versorgung auf 5V-Basis, dass der lineare Regler des Arduinos gar nicht erst genutzt werden muss...

Quote
Ich hab es einmal mit delay() weglassen probiert dann mit delayMicroseconds(2)/delayMicroseconds()
-->Beides keine gute Lösung...

Schaut Euch mal dieses Tutorial an, und baut den Sketch entsprechend aus.... die delays müssen wie gesagt weg. Dann verwendet Ihr bestimmte Routinen (zur Anzeige/ Messung/ Strip-Aktualisierung), welche unabhängig voneinander operieren können

HotSystems

#33
Aug 12, 2017, 11:06 am Last Edit: Aug 12, 2017, 11:37 am by HotSystems
Ich habe die Befürchtung, uns wird nicht geglaubt.

Warum fragt ihr hier, wenn ihr doch nicht die Tipps beherzigt ?

Es wurde alles schon erörtert.

Quote
Also wenn ich grob über den Finger alles ausrechne langt das netzteil locker um das alles zu versorgen!
Und wie hast du das ausgerechnet ?
Wenn alle Dioden weiß leuchten, brauchst du 3,6 A, da reicht dein Netzteil nicht.

Ihr solltet einfach mal einen Aufbau machen, ohne die Leds und den Sketch so schreiben, dass die Messungen nur am Display gezeigt werden. Baut es als eigene Funktionen auf, dann ist der Ablauf auch besser zu prüfen und übersichtlicher.

Danach eine weitere Funktion mit den Leds einsetzen, da kann man dann besser sehen, wo euer Fehler liegt.
I2C = weniger ist mehr: weniger Kabel, mehr Probleme. 8)

Essa93

Ich habe die Befürchtung, uns wird nicht geglaubt.

Warum fragt ihr hier, wenn ihr doch nicht die Tipps beherzigt ?

Es tut mir wirklich leid wenn wir den anschein dafür erweckt haben das wir an euren Tipps desinteressiert sein sollten. Das sind wir nicht, auf garkeinen Fall! Wir sind nur aktuell komplett am rumbastel und Tipps abarbeiten die wir von euch bekommen das wir einfach auch selbst alles in Frage stellen um verstehen zu können warum es den so ist oder sein soll... gleichzeitig hab ich ja hier meine ganzen Datenblätter von unseren Bauteile die wir abarbeiten um mögliche Fehler auszuschließen. Und das Thema Spannungsversorgung war jetzt ein Thema welches wir bis dato absolut nicht beachtet haben.

Wir halten euch des weiteren jetzt auf dem laufenden und berrichten sobald wir Fortschritte erzielen :)
\(°_°)/

HotSystems

Es tut mir wirklich leid wenn wir den anschein dafür erweckt haben....

Wir halten euch des weiteren jetzt auf dem laufenden und berrichten sobald wir Fortschritte erzielen :)
Ok, dann hoffe ich mal, dass ihr eine Lösung findet.

Spannung und Strom sind eine absolut wichtige Sache dabei, die man nie außer acht lassen darf.
I2C = weniger ist mehr: weniger Kabel, mehr Probleme. 8)

Essa93

So heute nach gefüllten 10 Stunden Fehlersuche haben wir endlich das Problem lösen können. Es lag tatsächlich an der Pinbelegung, aber nicht das wir es "falsch" belegt haben sondern wo wir es belegt haben. Wir haben herrausgefunden das durch die Bibliothek LiquidCristal_I2C die von uns belgeten Pin's als Bus reserviert hat und wir somit einige Pins garnicht nutzen dürfen. Dieses ''Falsche'' verkabeln sorgte dann dafür das der Pipser Spinnte und auch ebenfalls der US-Sensor.

An der Spannung an sich haben wir nichts geändert bzw. wollen wir nicht da unser System jetzt genau so funktioniert wie wir es uns vorgestellt haben.

An dieser Stelle bedanken Roschi und ich uns vielmals bei euch und den vielen Tips die uns schlussendlich zum Ziel gebracht haben :)
\(°_°)/

HotSystems

Das verstehe ich nicht.
Die Pins A4 und A5 sind doch eindeutig für I2C reserviert, was hattet ihr denn da noch drauf ?
I2C = weniger ist mehr: weniger Kabel, mehr Probleme. 8)

Essa93

Ja das hat auch gestimmt ... es geht eher um die bins 1-12 auf der Digitalseite... sobald man die Bibliothek einfügt haben einige Pins eine Art reservierung für den Bus ... bitte frag mich nicht wieso das so ist... nachdem wir die Pins getauscht haben auf die "nicht reservierten" ging unser system ohne Probleme
\(°_°)/

HotSystems

Ja das hat auch gestimmt ... es geht eher um die bins 1-12 auf der Digitalseite... sobald man die Bibliothek einfügt haben einige Pins eine Art reservierung für den Bus ... bitte frag mich nicht wieso das so ist... nachdem wir die Pins getauscht haben auf die "nicht reservierten" ging unser system ohne Probleme
Nein, da werden keine anderen Pins reserviert.
Das muss einen anderen Grund haben.
I2C = weniger ist mehr: weniger Kabel, mehr Probleme. 8)

Essa93

ich poste den Link später wo wir diese Aussage gefunden haben und warum wir uns dann für welche pins entschieden haben...

... wir sind nur froh das es jetzt funktioniert  :D
\(°_°)/

HotSystems

ich poste den Link später wo wir diese Aussage gefunden haben und warum wir uns dann für welche pins entschieden haben...

... wir sind nur froh das es jetzt funktioniert  :D
Glaube ich...ich bin aber gespannt auf den Link. Das habe ich bisher noch nicht gehört bzw. gelesen.
Naja, man lernt immer dazu, wundert mich dennoch.
I2C = weniger ist mehr: weniger Kabel, mehr Probleme. 8)

Essa93

https://m.heise.de/developer/artikel/Timer-Counter-und-Interrupts-3273309.html


ich hoffe wir haben es richtig verstanden
\(°_°)/

Klaus_ww

Also ICH sehe darin überhaupt keinen Zusammenhang - aber vielleicht habe ich auch nicht alle Postings hier mit Hirn und Verstand gelesen. Der Artikel selbst ist aber gut geschrieben und für alle Timer-Einsteiger nützlich.
Wenn ich hier sehr knapp antworte dann wegen der elenden Tipperei auf dem Tablet.

Essa93

macht uns jetzt nicht schwach... :D

als wir die Pins geändert haben ging es sofort!
\(°_°)/

Go Up