Hallo Foraner!
Meine Heizungssteuerung läuft nun seit ca. 2 Jahren zuverlässig. Ueber einen I2C Bus mit über 10m Länge und mehreren P82B96 laufen daran jeweils mehrere LM75B, zum Teil über TCA9548A, und mehrere PCF8574 erfolgreich. Im Zuge einer Erweiterung zum Messen des Füllstandes im Pellet-Bunker habe ich einen VL53L0X ToF-Sensor montiert. Aber dieser will nicht funktionieren, und zwar nur nicht über den P82B96!
Soweit konnte ich das Problem eingrenzen und kann nun gemütlich am Basteltisch probieren. Also Stand momentan:
Ich hatte den VL53L0X vor Jahren mal angeschlossen. Ganz normal I2C, keine Probleme. Auch die Nachfolge-Sensoren ..5X ..7X liefen problemlos.
An den STM-Sensoren kann es nicht liegen. Ich hatte die Sensoren an einem NXP LPC11U68 als auch an einem STM H743. Alles problemlos.
Zur Messung selber: die neueren 8*8 Sensoren liefern viel weniger Störungen in der Messung als der alte L0X.
Zum eigentlichen Problem kann ich nichts zusätzliches beitragen, aber vlt. die folgenden Hinweise:
Die Nachfolger vom VL53L0X sind ERHEBLICH besser und das ohne das man groß etwas ändern müsste (wurde ja schon geschrieben)
Falls der Sensor hinter einem Schutzglas sitzt unbedingt die Kalibrierfunktion aus dem Minitreiber ausführen, die einmalig ermittelten Werte werden im Sensor selbst gespeichert und verbessern die Performance erheblich.
Ja, habe ich nicht. Wie reagiert der wohl auf Staub?
Zum Problem: Habe jetzt mal eine 1N4148 in den GND reingemacht, so fällt der Low-Level aus Sicht des Sensors um etwa 0.6V (gemessen). Hilft aber nichts, immer noch der gleiche Effekt. Ach ja, der Effekt ist eigentlich: 500ms NAK, so lange ist der Timeout gesetzt...
Das Problem ist, dass man die Reichweitenangaben aus dem Datenblatt in der Praxis ruhig dritteln oder vierteln kann. Übrigens bringt die Kalibrierfunktion fast immer eine Verbesserung. Das sind ja so die Dinge, die man gerne weglässt, weil man vlt. keine Genauigkeit braucht. Aber hier geht es vorrangig um andere Parameter.
Habe jetzt mal eine 1N4148 in den GND reingemacht, so fällt
der Low-Level aus Sicht des Sensors um etwa 0.6V (gemessen).
Mache ich einen Gedankenfehler? Auch mit 2 Dioden bringt es nichts.
Ich habe also 2 Probleme, also eigentlich 3:
Warum ist der Low-Pegel vom P82B96 so hoch? Laut Datenblatt sollte der bei allerhöchstens 1V sein. Laut I2C-Spezifikationen https://www.nxp.com/docs/en/user-guide/UM10204.pdf Abschnitt 3.1.2: "Input reference levels are set as 30% and 70% of VDD; VIL is 0.3VDD and VIH is 0.7VDD." Also absolut innerhalb!
Der VL53L0X (auch alle VL53LnX-Varianten) sind aber mit
Möchte ich dann doch lieber den VL53L3CX verwenden. Ich würde dann
gleich einen Print machen lassen mit einem TCA9517, ich hoffe, der würde
das Problem lösen!
Normalerweise guckt man erst die Datenblätter durch und lässt dann einen "Print" machen.
Wenn du erst die Schaltung aufbaust und dann guckst, ob es funktioniert, kannst du nicht abschätzen, ob das Zufall ist, weil du sie zufällig gerade bei der richtige Kombination von Umgebungstemperatur und Versorgungsspannung betreibst, oder ob die Schaltung innerhalb der Spezifikation in jeder Lebenslage funktionieren wird.
Nun, I2C ist bidirektional. Die Treiber-ICs müssen daher bei einem Richtungswechsel den Pin kurz anliften, um zu erkennen, daß Low nun von der anderen Seite kommt. Auf dem Oszi kann man diese Spikes gut sehen.
I2C konforme ICs haben daher immer einen Filter implementiert, damit diese kurzen Spikes nicht stören. Vermutlich wurde das beim VL53L3CX aber nicht eingehalten, so daß er hinter einem Treiber-IC nicht mehr funktioniert.
Nö, im Datenblatt des P82B96 sind 750 R angegeben, paßt also.
Was hilft die Einhaltung des Datenblatt-Wertes wenn der Low-
Pegel nicht (mehr) eingehalten wird oder grenzwertig ist? Es
muss ja nicht (nur) der P82B96 befriedigt werden sondern auch
die angeschlossene Peripherie bzw. der Controller.
Von dem Wirrwarr muss man erstmal einen Schaltplan zeichnen, bevor das vernünftig lesbar ist.
Versorgungsspannungen kann man z.B. gerne über Label darstellen, damit die nicht zu einem über den ganzen Schaltplan verteilten Drahtverhau führen.
Normalerweise guckt man erst die Datenblätter durch und lässt dann einen
"Print" machen.
OT: Jaja, früher machten wir Printe, die Jungster heute machen nur noch "PCBs"...
Ja mit dem Studium der Pegel in den DaBlas bin ich mir sicher, das ich mit dem richtigen Pegelumsetzer Erfolg habe - denn die Low-Pegel sind ja das Problem!
Also die Prototypen sind da! Hab mal 5 Machen lassen. Der Low-Pegel nach dem TCA9517 ist bei 95mV. Elektronisch ist also jetzt mal gut. Aber:
der VL53L3CX ist anscheinend mit einem 8-Bitter nicht mehr machbar (kann doch nicht sein, das ein simples I2C-Device 50kB Flash und 10kB RAM braucht!), und
in der Doku fehlt jegliche Low-Level Ansteuerung, also auf I2C-Ebene. Es wird gleich auf die Funktionen der API verwiesen. Das habe ich ja so noch nie gesehen!
der VL53L3CX ist anscheinend mit einem 8-Bitter nicht mehr machbar
(kann doch nicht sein, das ein simples I2C-Device 50kB Flash und 10kB
RAM braucht!)
Was man so sehen kann, ist das auch typischer Spaghetticode, d.h. riesige Ketten an writeReg().
Ich hätte dafür erstmal eine Funktion geschrieben, die den ganzen Schrunz aus einer Tabelle als Schleife ausgibt. Dann entfallen schonmal die ganzen Ladeaktionen und Calls.
Um die eigentliche Lib anzusehen, muß man sich ja erstmal registrieren. Was daran wohl bloß so super geheim ist, oder ist es einfach nur schlecht gemacht.
Um die eigentliche Lib anzusehen, muß man sich ja erstmal registrieren.
Ja habe ich zuerst auch gedacht. Aber es erscheint auch ganz klein "Guest". Man muss zwar auch die E-Mail-Adresse angeben, um den DL-Link zu bekommen. Habe ich dann halt gemacht. Keine Ahnung, ob ich das hier hochladen darf...?
