Moin, Verwende den TCA9548a i2c Multiplexer um mehrere DHT12 Sensoren auszulesen, das klappt auch wunderbar. Der Multiplexer sitzt an ca 20m Leitung mit dem P82B96 als Line-Buffer vor und hinter der Leitung. Nun möchte ich noch uA einen weiteren Slave, in diesem Fall den BH1750 Helligkeitssensor verwenden, ich möchte mit diesem keinen Kanal am Multiplexer nutzen und habe ihn VOR dem TCA9548a an den Bus gehängt. Dort wird er auch erkannt, liefert aber nur Unsinn. Der TCA9548a und die DHT12 funktioneren weiterhin zuverlässig. Sobald ich den TCA9548a vom Bus nehme funktioniert der BH1750 wieder. Habe mit der Datenrate und den Pullups schon experimentiert, ohne Erfolg. Im Datenblatt zum TCA9548a steht nix dazu ob er irgendwie den Bus derart beeinflusst, eingentlich ist er ja auch nur einer von "vielen" Slaves.
Carsten schrieb: > Dort wird er auch erkannt, liefert aber nur Unsinn. Das heißt? Wie sieht das "unsinnige" Datentelegramm und die Kommnunikation vorher aus?
:
Bearbeitet durch User
Carsten schrieb: > Habe ... schon experimentiert Hast du auch einfach mal mit einem Oszi gemessen? Nur damit kannst du die Signalqualität wirklich beurteilen und klären, ob du im Bereich dessen liegst, was das Datenblatt fordert. Allein mit herumfrickeln, probieren und experimentieren wird das nichts Zuverlässiges.
Vorher bekomme ich einen Helligkeitswert der entsprechend der Auflösung und Tageszeit fünfstellig ist und um ein paar digits schwankt. Hinterher bekomme ich Einen Wert der um 8400 liegt und unregelmäßig bei 0,33,31 liegt. Das beginnt sobald ich den TCA9548a an den bus lege. Leider sind diese "shields" auch immer mit Beschaltung versehen die nicht immer gut dokumentiert ist, daher immer die Gefahr daß bereits Pullups etc dort vorhanden sind zb
Lothar M. schrieb: > Hast du auch einfach mal mit einem Oszi gemessen? > Nur damit kannst du die Signalqualität wirklich beurteilen und klären, > ob du im Bereich dessen liegst, was das Datenblatt fordert. Allein mit > herumfrickeln, probieren und experimentieren wird das nichts > Zuverlässiges. Mein Zweistrahloszi von Philips ist leider nicht in der Lage die Datenströme im Stillstand zu zeigen, und ich möchte es ungern raus in den Geräteschuppen schleppen.
am I²C-Bus sind 20 m Leitung laut Datenblatt nicht vorgesehen. So groß waren seinerzeit die von Philips gebauten Fernseher nicht :-)
Carsten schrieb: > Mein Zweistrahloszi von Philips ist leider nicht in der Lage die > Datenströme im Stillstand zu zeigen Zur Beurteilung der Flanken und der Pegel reicht auch die dynamische Darstellung völlig aus. Carsten schrieb: > und ich möchte es ungern raus in den Geräteschuppen schleppen. Wickle die Leitung auf. Mit 30cm Durchmesser sind das gerade mal 20 Windungen. Passt locker auf den Schreibtisch.
Nautilus schrieb: > am I²C-Bus sind 20 m Leitung laut Datenblatt nicht vorgesehen. > > So groß waren seinerzeit die von Philips gebauten Fernseher nicht :-) Der Multiplexer sitzt an ca 20m Leitung mit dem P82B96 als Line-Buffer vor und hinter der Leitung.
Dennoch: Wenn Du den Berg nicht zum Propheten bekommst, muss der faule Sack halt zum Berg laufen, d.h. Du Dein Kabel mit dem ganzen Gelumpe dran zum Oszilloskop bewegen. Nur mit dem Oszilloskop kannst Du sehen, wie das I2C-Signal tatsächlich aussieht. Alles andere ist blindes Herumgerate à la "Der Fehler liegt in Zeile 42".
Carsten schrieb: > Der Multiplexer sitzt an ca 20m Leitung mit dem P82B96 als Line-Buffer > vor und hinter der Leitung. Gut für das lange Kabel, evt. schlecht für den BH1750? Der Buffer ist genauso verdächtig wie der Multiplexer. In dem Datenblatt heißt es
1 | Bidirectional I2C signals do not have a direction control pin so, |
2 | instead, slightly different logic low-voltage levels are used at |
3 | Sx/Sy to avoid latching of this buffer. A standard I2C low applied |
4 | at the Rx/Ry of a P82B96 is propagated to Sx/Sy as a buffered low |
5 | with a slightly higher voltage level. |
6 | |
7 | In any design, the Sx pins of different devices should never be |
8 | linked, because the resulting system would be very susceptible to |
9 | induced noise and would not support all I2C operating modes. |
Meinen die jetzt (nur) mehrere P82B96 in parallel oder gilt das für beliebige I2C-Bausteine? Evt. ist der BH1750 auch besonders anspruchsvoll. Kannst du vielleicht einen Versuch ohne die Buffer machen? Schön langsam, damit das lange Kabel nicht stört; notfalls mit 1k5 Pull-Up. Oder mit dem BH1750 hinter den Buffern, parallel zum Multiplexer?
Bauform B. schrieb: > Meinen die jetzt (nur) mehrere P82B96 in parallel Ja. > oder gilt das für > beliebige I2C-Bausteine? Nein. Man beachte. Die P82B96 funktionieren nur bei 5V sauber auf der I2C Seite, auch wenn das Datenblatt 2-15V VCC angibt!
BINGO! Der BH1750 läuft mit typisch 3V und die I2C Pegel sind auch darauf bezogen! Also braucht er Pegelwandler auf 5V zum I2C Bus am P82B96! Korrektur! Das könnte eher schwierig werden! Den die normalen Pegelwandler für I2C können den Trick des 0,9V LOW vom P82B96 nicht filtern! Dieses hohe LOW, welcher nur normale 5V I2C Devices als solches SICHER erkennen, kommt auch durch die Pegelwandler durch und wird dann NICHT als SICHERES LOW vom BH1750 erkannt! Das wird eng. Da muss eine andere Lösung her. https://www.mikrocontroller.net/attachment/176906/notes_82b96.pdf https://www.alldatasheet.com/view.jsp?Searchword=AN460
:
Bearbeitet durch User
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.