Fehlerhafte RO Idle Polarität ESP8266 <- MAX485

2 Möglichkeiten

a) TXena an _RE und DE anklemmen. Der ESP sieht seinen eigenen TX nicht an RX. Empfangen wird nur wenn nicht gesendet wird. Transmitter ist nur aktiv wenn gesendet wird.

b) TXena an DE anklemmen. _RE an GND legen. Der ESP sieht seinen TX an RX. Empfangen wird immer, Transmitter ist dennoch nur aktiv wenn gesendet werden soll.

Nebenbei gesagt hat UART einen high Ruhepegel, aus historischen Gründen.

Dein "working" zeigt eigentlich, wie es eben nicht aussehen soll. Es sei denn, ein anderer Knoten sendete da einen laaaangen Break und dein Analyzer checkt's nicht mehr.

mfg mf

PS. Tipp nebenher, Datenblatt vom MAX485 bzw. SN75176 besorgen und mal lesen 👍

Danke für eure schnellen Anworten. Es läuft Tasmota auf dem ESP8266. Ich nutze TX Enable um die Richtungsumschaltung aktiv zu treiben. TX Enable get an DE und RE.

Der Tasmota-Modbus-Treiber meldet Fehler: "MBR Driver error 1", was für "Illegal Function" steht. Das verwundert nicht, da das Modbus-Protokoll verletzt wird.

Ich Prinzip ist es mir egal wie die Pegel im Idle-Zustand sind, solange es funktioniert. Auf meinem Breakout-board konnte ich das Problem lösen indem ich einfach Pins getauscht habe - ohne zu verstehen warum es das Verhalten verändert.

MAX485-Data-Sheet-Table.png zeigt den relevanten Teil aus dem Datenblatt. Ich werde bei Gelegenheit das Scope nochmal anwerfen um zu schauen, ob sich das China-Modul auch an die MAXIM-Spec hält.

Sven K. schrieb:

Ich Prinzip ist es mir egal wie die Pegel im Idle-Zustand sind, solange es funktioniert.

Wenn du eine RS485-Schnittstelle mit dem entsprechenden Treiber aufbauen möchtest, macht es die Sache deutlich übersichtlicher, wenn du dich an die RS485-Spezifikation hälst. Was soll dein Wasserpegelsensor wohl denken, wenn du ihm an Stelle eines korrekten Idle-Pegels einen Break-Pegel anbietest? Bei der Bezeichnungen der Bus-Leitungen gibt es wohl etwas Wirrwarr. Ich habe es schon erlebt, dass die Bezeichnungen A und B vertauscht waren. Prüfe erstmal die Pegel auf dem Bus mit dem Oszi, bevor du das Signal mit dem LA analysierst.

Sven K. schrieb:

Auf einem Breakout-Board stellte ich ein merkwürdiges Verhalten fest. Je nachdem welche Pins des ESP8266 mit dem MAX-Modul verbunden werden erhalte ich eine falsche Polarität, zumindest aber einen Low-Pegel im Idle Zustand.

Dann steuerst du das MAX485-Modul falsch an.

Hallo Rainer,

Die Abgriffe für das Scope waren nicht am RS485 Bus, sondern zwischen ESP8266 und MAX485 platziert.

In meinen Fall ist der Pegelsensor zufrieden mit den RS485-Bus-Signalen, denn er antwortet zuverlässig.

Die Firmware (Tasmota+Skript) auf dem ESP8266 sendet alle 10s eine Anfrage an den Sensor.

ModbusSend {"deviceAddress":1, "functionCode": 3, "startAddress": 4, "type":"int16", "count": 1}

Die Anfrage (ESP -> MAX485) ist in den Scope Bildern gelb dargestellt. Auch hier sehe ich im Idle-Zustand einen high Pegel.

Im Sweep ist die Antwort des Sensors hell blau dargestellt. Wieder zwischen ESP8266 und MAX485.

Mir sind keine Einstellungsmöglichkeiten bekannt um die Pegel im IDLE-Zustand zu ändern. Gibt es hier Möglichkeiten? Kennt sich jemand besser mit Tasmota aus?

Vermutlich ist es besser die Hardware-basierte Serielle (GPIO1+GPIO3) zu nutzen anstelle von SW-Serial an anderen GPIOs. Keine Ahnung...

Die Bus-Signale A und B scheinen richtig gepolt zu sein. Der ESP8266 kommt jedoch mit dem Ausgangssignal des MAX485 nicht klar.

Hier deckt sich die Meinung der Software auf dem ESP8266 mit dem Serial-Dekoder im Scope.

Irgendwo fehlt mir ein Puzzle-Teil im Verständnis. Irgendwo muss es einen noch unbekannten Parameter geben, der erklärt warum es in Aufbau A funktioniert, aber im vermeintlich identischen Aufbau B nicht.

Alles merkwürdig!

Ich habe einen kleinen Frannkenstein-Aufbau gebastelt und das MAX-Modul an die HW-UART (GPIO1, GPIO3) des ESP8266 verbunden. TX Enable blieb dabei mit GPIO14 verbunden.

Zu meiner Verwunderung funktioniert diese Variante. Siehe auch den Scope-Sweep.

Es sieht also so aus, als ob unter gewissen Bedingungen der Wasserpegelsensor inkorrekte Modbus-Pakete sendet.

Sven K. schrieb:

Der ESP8266 kommt jedoch mit dem Ausgangssignal des MAX485 nicht klar.

Der ESP8266 arbeitet mit 3.3V, der MAX485 ist ein 5V-Typ. Wie machst du die Pegelanpassung und warum nimmst du keinen RS485-Wandler für 3.3V? Im Datenblatt sind sogar Typen dafür angegeben.

Rainer W. schrieb:

Sven K. schrieb:

Der ESP8266 kommt jedoch mit dem Ausgangssignal des MAX485 nicht klar.

Der ESP8266 arbeitet mit 3.3V, der MAX485 ist ein 5V-Typ. Wie machst du die Pegelanpassung und warum nimmst du keinen RS485-Wandler für 3.3V? Im Datenblatt sind sogar Typen dafür angegeben.

VCC des MAX485-Moduls habe ich auf 3V3 gelegt. Es mag Out-of-Spec sein, aber Berichten im Netz zufolge funktioniert es. Das Scope bestätigt, dass die Pegel nicht zu hoch für den ESP sind. Das MAX485-Modul hatte ich noch in der Schublade liegen. Da es zunächst funktionierte, designte ich ein PCB mit eben diesem Modul. Es zeigt sich nun aber nickelig zu sein. Leider kann ich den Fehler nicht vollständig nachvollziehen. Sprich, die wirkliche Ursache liegt noch im dunkeln.

Sven K. schrieb:

Es mag Out-of-Spec sein, aber Berichten im Netz zufolge funktioniert es. ...... Sprich, die wirkliche Ursache liegt noch im dunkeln.

Nein, die wirkliche Ursache hast du ja schon erkannt! Da liegt nichts im Dunkeln.

Rainer W. schrieb:

Wie machst du die Pegelanpassung und warum nimmst du keinen RS485-Wandler für 3.3V?

Man kann für RX einen Spannungsteiler nehmen. Oder dreckig einen Serienwiderstand unter Berücksichtigung der maximalen current injection. Naja.

Für TX und die Steuersignale reicht 3.3V > V_IH locker aus. Die wollen nur Pegelwandler verkaufen...

mfg mf