gelegentliche Datenfehler auf RS485

[Andreas F. (Gast)]

Hallo liebe Gemeinde.
Erstmal: Alles Gute im neuen Jahr (wie sagt man in 
Mikrokontroller-Kreisen: Immer ein paar Millivolt über dem Logic-Level?)

Im Ernst: Ich habe hier einen RS485-Bus, der spinnt.
In unregelmäßigen zeitlichen Abständen (2 bis 5mal in 10 Sekunden - 
geschätzt) läuft irgendwelcher Mist über die Leitung.
Für die meisten angeschlossenen (anschließbaren) Geräte scheint das 
nicht relevant zu sein. Solange ich nur Taster- und Schalterpositionen 
auslese (in der einen Richtung Slave -> Master) und per PWM die 
Helligkeit einiger LEDs steuere (andere Richtung) läuft alles 
einwandfrei.
Seit ein paar Wochen versuche ich nun einige Daten (ASCII in 10 Zeilen á 
24 Zeichen) auf einem 3,5"-LCD auszugeben (Master -> Slave). 
Grundsätzlich funktioniert das prima. Sofort nach Einschalten sind alle 
Daten angezeigt, jedoch häufen sich mehr und mehr Anzeigefehler (falsche 
Zeichen). Die werden aber dann auch irgendwann mal wieder von den 
korrekten Zeichen überschrieben und so geht das dann hin und her.
Hier ein kleines Beispiel:
https://www.youtube.com/playlist?list=PLRZCDlblnoeciZiOngsZEORYZjGBKxIxi

Master ist ein MEGA2650, die Slaves werden durch Atmega 328P (NANO) 
dargestellt.
Als Transmitter benutze ich MAX487ESA und MAX487CSA (unterscheiden sich 
meines Wissens nur durch andere Temperatur-Werte).
Die Übertragung erfolgt durch fertig gekaufte Cat5-Patchkabel, auf den 
PCBs verwende ich hochwertige (geschirmt und mit vergoldeten Kontakten) 
RJ45-Buchsen. Alles andere auf zweiseitig gedruckten Schaltungen. Mit 
Masse-Vias habe ich nicht gespart.
Die GesamtBusLänge ist deutlich kürzer als 10 Meter. Wenn ich mit 100 
Ohm terminiere, wird alles nur noch schlimmer.
Ich wollte heute mal 120 Ohm Terminierung probieren (die Meinungen gehen 
da auseinander): Keine passenden Widerstände im Haus (sind aber 
bestellt).
Ich habe auch schon neue PCBs entworfen und ausprobiert, auf denen ich 
den MAX487 mit seinen A- und B-Beinchen so dicht es ging an die RJ45 
herangebracht habe. Jetzt ist es ein wenig(!) besser, aber weit weg von 
dem, was ich möchte.

Die MAX487 haben 100nF am VCC, die Versorgungsspannungen (die 5V für die 
MAX487 "mache" ich direkt auf den jeweiligen PCBs mit einem AMS1117-5,0) 
haben ordentliche 22uF Tantal-Stützen. Am TXenable (RE/DE) habe ich 10k 
PullDown gesetzt.

Die Daten- und 12V-Leitungen sind mit TVS-Dioden ausgestattet.
Die Gesamtstromversorgung (12V) kommt aus einem Labornetzteil. So kann 
ich den Strom begrenzen, falls es auf dem Labor-Tisch mal einen Kurzen 
gibt.
Damit will ich sagen, daß die Stromversorgung auf der Liste der 
Verdächtigen ganz unten steht.

Da ich am Ende meines Lateins bin und ich einen Hardware-Murks 
meinerseits ausschließen möchte - bevor ich mich an den Entwickler des 
Bus-Protokolls wende) her meine Frage: Habe ich in der Kabelbelegung 
vielleicht Mist gebaut?

Meine Kabelbelegung (Liste ist paarweise geordnet):
1/2 RS485-A und -B

3 GND
6 GND

4 GND
5 12V

7 12V
8 12V

Shield GND

Ich wollte ein Bullet-Proof-Design erreichen, bin aber - wie es aussieht 
- noch sehr weit davon entfernt.

Herzlichen Dank schonmal für's Mitdenken.
DRESI

[Hauke Haien (Gast)]

Also ist dein Bus überhaupt nicht terminiert? Mit 120ohm wird es 
schlecht? Dann Terminierung mal auch auf 5v u gnd legen. Fail safe halt.

[Jim M. (turboj)]

Andreas F. schrieb:
> Seit ein paar Wochen versuche ich nun einige Daten (ASCII in 10 Zeilen á
> 24 Zeichen) auf einem 3,5"-LCD auszugeben (Master -> Slave).

Warten die Slaves auf den Master? Nicht das da ein Slave einfach nur 
dazwischen funkt.



Ansonsten müsstest Du folgendes:

> läuft irgendwelcher Mist über die Leitung.

mal mit einem Oszi einfangen.

Falls Du die Zeilen regelmäßig neu schreibst: Stack Overflow auf dem 
Master µC wäre auch eine Möglichkeit.

[Rufus Τ. F. (rufus)]

Welche Baudrate verwendest Du?

Wirds besser, wenn Du die Baudrate drosselst?

Was für eine Taktquelle verwenden Deine µCs?

[posti (Gast)]

Hi

Wie es aussieht, sendest Du laufend den kompletten Display-Inhalt?
Würde die zu übertragenden Daten auf ein Minimum reduzieren und eine 
Prüfsumme mitschicken.
Dann musst Du aber auch 'nachhören', ob die Daten korrekt empfangen 
wurden um Diese ggf. neu zu verschicken.

Die Sequenzen, wo nur noch Müll auf dem Display erscheint, sieht schon 
nach Daten-Gulasch aus, ein verschobener Pointer hört sich da für mich 
schlüssig an.

Die kleineren Fehler werden Übertragungsfehler sein - aber schon bei 10 
Metern?

MfG

[oszi40 (Gast)]

Andreas F. schrieb:
> Die Übertragung erfolgt durch fertig gekaufte Cat5-Patchkabel, auf den
> .. Die GesamtBusLänge ist deutlich kürzer als 10 Meter

Dann nimm doch mal ein kurzes Kabel zum Test
und achte auch auf die richtigen Paare.

[Johann Klammer (Gast)]

Wenn du half duplex machst, dann musst du failsafe terminieren, oder
irgendwie anders sicherstellen, dass die Pegel nicht wandern.

[Anja (Gast)]

Andreas F. schrieb:
> Die Daten- Leitungen sind mit TVS-Dioden ausgestattet.

Ist evtl. die Kapazität der TVS-Dioden zu hoch?

Gruß Anja

[Andreas F. (Gast)]

Wow. Mit so viel Resonanz (und so schnell) hatte ich nicht gerechnet.
Habe morgen Frühdienst und muss mich vorbereiten (Schlaf).
Ich finde aber sicher eine Gelegenheit mir das Obige in Ruhe 
durchzulesen und noch am Vormittag entsprechend zu antworten.
Danke schonmal :) N8 (AFK)

[U. M. (oeletronika)]

Hallo,
> Andreas F. schrieb:
> Im Ernst: Ich habe hier einen RS485-Bus, der spinnt.
> In unregelmäßigen zeitlichen Abständen (2 bis 5mal in 10 Sekunden -
> geschätzt) läuft irgendwelcher Mist über die Leitung.
> Seit ein paar Wochen versuche ich nun einige Daten (ASCII in 10 Zeilen á
> 24 Zeichen) auf einem 3,5"-LCD auszugeben (Master -> Slave).
> Grundsätzlich funktioniert das prima. Sofort nach Einschalten sind alle
> Daten angezeigt, jedoch häufen sich mehr und mehr Anzeigefehler (falsche
> Zeichen).
Und du bist sicher, dass dies durch das Interface bedingt ist und nicht 
durch Macken im Display selbst?

> Als Transmitter benutze ich MAX487ESA und MAX487CSA
Ich kann keine Angaben zur verwendeten Baudrate finden.
Aber MAX487 sind Baudraten begrenzte Treiber, die Baudrate ist dann wohl 
eher moderat? Diese Treiber sind auch mit fehlerhafter Terminierung und 
schlechten Leitungen sehr gutmütig.
Auch die Kapazität von Schutzbeschaltungen (z.B. Suppresordioden) ist da 
eher nebensächlich (im Gegensatz zu den Treibern für hohe Baudraten).

>(unterscheiden sich meines Wissens nur durch andere Temperatur-Werte).
ja.

> Die Übertragung erfolgt durch fertig gekaufte Cat5-Patchkabel, auf den
> PCBs verwende ich hochwertige (geschirmt und mit vergoldeten Kontakten)
> RJ45-Buchsen. Die GesamtBusLänge ist deutlich kürzer als 10 Meter.
Das ist unter diesen Bedingungen Popelkram. Die Hardware sollte mit 
jedem beliebigen Klingedraht zurecht kommen.

> Wenn ich mit 100 Ohm terminiere, wird alles nur noch schlimmer.
Hast du die Pegel mal mit einem Oszi besichtigt.
100 Ohm, egal ob auf einer oder beiden seiten , sind bei den genannten 
Bedingungen völlig unkritisch.

Problem könnte sein, wenn die Leitungen nicht vorgespannt sind.
-> Leitung A mit ca. 470R ... 1k gegen +Ub
-> Leitung B mit ca. 470R ... 1k gegen gnd

> Ich wollte heute mal 120 Ohm Terminierung probieren (die Meinungen gehen
> da auseinander):
Das macht bei den bandbreitenbegrenzten Treibern und der kurzen Leitung 
nix.

> Ich habe auch schon neue PCBs entworfen und ausprobiert, auf denen ich
> den MAX487 mit seinen A- und B-Beinchen so dicht es ging an die RJ45
> herangebracht habe.
Unwichtig, sofern keine Schaltungsfehler vorliegen.

Natürlich müssen auch auf der TTL-Seite korrekte Signale anliegen.

> Die MAX487 haben 100nF am VCC, die Versorgungsspannungen (die 5V für die
> MAX487 "mache" ich direkt auf den jeweiligen PCBs mit einem AMS1117-5,0)
> haben ordentliche 22uF Tantal-Stützen. Am TXenable (RE/DE) habe ich 10k
> PullDown gesetzt.
/RE ist Low-aktiv, also korrekt.

> Die Daten- und 12V-Leitungen sind mit TVS-Dioden ausgestattet.
Welcher Typ? Ich nutze für solche Anwendungen z.B. SMBJ5 ohne Probleme.

Bei hohen Baudraten für z.B. Profibus sieht es ganz anders aus.

> Da ich am Ende meines Lateins bin und ich einen Hardware-Murks
> meinerseits ausschließen möchte - bevor ich mich an den Entwickler des
> Bus-Protokolls wende) her meine Frage: Habe ich in der Kabelbelegung
> vielleicht Mist gebaut?
Sofern die Leitungen alle A zu A und B zu B verkabelt sind, ist es ok.
Anders funktioniert erfahrungsgemäß gar keine Übertragung.

Folgende mir bekannte Kasperfallen gibt es bei RS485 noch:

-> Timings der Richtungsumschaltung  RE/DE ist nicht korrekt
z.B. weil es zu spät aktiviert wird (also nicht vor dem Startbit)

-> Busteilnehmer Antworten zu schnell, während der voherige noch den Bus 
mit RE/DE = High blockiert.

-> Baudraten (Bitzeiten) passen nicht gut zusammen (Mit Oszi 
korrigieren).

Gruß Öletronika

[ACDC (Gast)]

U. M. schrieb:
> Problem könnte sein, wenn die Leitungen nicht vorgespannt sind.
> -> Leitung A mit ca. 470R ... 1k gegen +Ub
> -> Leitung B mit ca. 470R ... 1k gegen gnd

sollte es sein ;)

[Andreas F. (Gast)]

So. Bin auf der Arbeit und habe somit Zeit, mich dieser Sache hier zu 
widmen. Blöderweise kann ich wiederum hier keine Versuche durchführen :)

Ich danke Euch für die wertvollen Anregungen und Richtungsweiser. Ich 
versuche mal, auf alles einzugehen. Hierbei werde ich mich auch gleich 
als Noob outen.
Dies ist mein erstes Projekt dieser Art. Ich kämpfe nun schon seit einem 
Jahr damit (in der Freizeit). Vorher wusste ich von serieller 
Kommunikation nur soviel, daß ich sie immer mit paralleler K. 
verwechselt habe.

Um so wertvoller ist mir dieses Forum, in welchem ich auch sehr viel 
"nur" lese.

Jim M. schrieb:
> Warten die Slaves auf den Master?
Im Prinzip ja. Hatte auch schon so eine Idee. Ich müsste - zumindest zu 
Debug-Zwecken - mal an geeigneter Stelle ein delay() im ms-Bereich 
einfügen. So weit bin ich aber noch nicht, der Code sollte eigentlich(!) 
auch so funktionieren.
Die Sache ist die, das System stammt nicht von mir, ich bastele nur das 
"Frontend" aus vorgegebenen Code-Schnipseln zusammen. An den 
Bibliotheken herumzupfuschen, sehe ich nicht als meine Aufgabe. Ganz 
davon abgesehen, daß ich dafür auch zu blöd wäre :)

Jim M. schrieb:
> Ansonsten müsstest Du folgendes:
>
>> läuft irgendwelcher Mist über die Leitung.
>
> mal mit einem Oszi einfangen.
Das Problem ist, ich habe nur so eine (etwas ältere) Conrad-Krücke mit 
5MHz. Mein Versuch, den Bus abzuhören, ist daran gescheitert, daß ich 
kein auswertbares Signal angezeigt bekommen habe.
Ich habe aber einen Logic-Analyser benutzt. Der zeigte mir im Vergleich 
von A und B (die meines Wissens genau(!) spiegelverkehrt sein müssen) 
gelegentliche - scheinbar spontane - Pegelsprünge auf nur einem Kanal. 
Deren Ursprung ließ sich hierbei natürlich nicht ermitteln.

Hauke Haien schrieb:
> Also ist dein Bus überhaupt nicht terminiert? Mit 120ohm wird es
> schlecht? Dann Terminierung mal auch auf 5v u gnd legen. Fail safe halt.

Stimmt. Nicht terminiert. Es heißt im Allgemeinen, daß das bei meinen 
Buslängen nicht erforderlich sei. Maxim behauptet auch im Datenblatt, 
daß der MAX487 Failsafe "eingebaut" hat.
Und ich habe 100 Ohm getestet. 120 Ohm will ich noch versuchen, sobald 
die Widerstände da sind. (Ich lebe hier in der Provinz - Erfurt - und es 
gibt hier keinen gescheiten lokalen Dealer mehr. Muss alles online 
einkaufen).
Die Datenleitungen "vorspannen" habe ich als Einziges noch nicht 
versucht.
Mal sehen, ob ich das elegant auf meine PCBs bekomme. Will nicht extra 
neue anfertigen für einen Versuch.

Rufus Τ. F. schrieb:
> Welche Baudrate verwendest Du?
Da bin ich mir nicht sicher. Ich habe nicht viel Ahnung von der Materie. 
Der Master wird per USB seriell mit 250000 angeschlossen. Per socat wird 
ein UDP-Stream "erzeugt" und an den Master geschickt (siehe Code).
Mehr verstehe ich davon nicht :( Wieviel effektive Baudrate das dann 
ergibt, weiß ich nicht. Ich habe mal versucht, das irgendwie zu 
errechnen... Habe es dann nach 10 Seiten "Internet" lesen aufgegeben.

REM Specify the number of the COM port your Arduino is connected to:
set COMPORT=5

set /A TTYNUM=%COMPORT%-1
mode COM%COMPORT% BAUD=250000 PARITY=N DATA=8 STOP=1 TO=off DTR=on
socat\socat -v UDP4-RECV:5010,ip-add-membership=239.255.50.10:127.0.0.1,reuseaddr!!udp-sendto:localhost:7778 /dev/ttyS%TTYNUM%

pause

> Wirds besser, wenn Du die Baudrate drosselst?
Um die Baudrate zu drosseln, müsste ich in die Library rein. Die wird 
dort vorgegeben.
> Was für eine Taktquelle verwenden Deine µCs?
Wenn ich das richtig verstehe, sind das wohl die 16 MHz des AVR. Oder?

oszi40 schrieb:
> Dann nimm doch mal ein kurzes Kabel zum Test
Habe ich auch schon versucht. Verschiedenste Kabel und -Längen. Manchmal 
hatte ich den Eindruck, daß die Störungen abnehmen, wenn ich mehrere 
Slaves in der Kette anschließe.
Ich schrieb auch: "deutlich unter 10m". Meistens habe ich bloß einen 
halben oder 2 Meter angeschlossen. Das Ganze läuft i.Moment noch auf dem 
Tisch.

Johann Klammer schrieb:
> Wenn du half duplex machst, dann musst du failsafe terminieren,

Das werde ich auf alle Fälle als Nächstes versuchen.

Anja schrieb:
> Ist evtl. die Kapazität der TVS-Dioden zu hoch?

Dazu kann ich mich nicht sachkundig äußern. Wieviel F sind "zu hoch"?
Ich benutze für die Datenleitungen die SM712 (angeblich speziell für 
RS485 geeignet), für die 12V-Leitung nehme ich (auf jedem Node) jeweils 
eine SMBJ12A.

U. M. schrieb:
>> ... jedoch häufen sich mehr und mehr Anzeigefehler (falsche
>> Zeichen).
> Und du bist sicher, dass dies durch das Interface bedingt ist und nicht
> durch Macken im Display selbst?
Das ist ausgeschlossen. Obwohl ich das nie in Erwägung gezogen hatte, 
habe ich schon verschiedene Displays ausprobiert. Die sind unschuldig :)

Es ist eindeutig der RS485-Bus. Ich hatte einen Versuch laufen, in 
welchem ich den LCD-"Treiber" AVR (UNO) direkt per USB betrieben habe: 
Keine Fehler!
> -> Timings der Richtungsumschaltung  RE/DE ist nicht korrekt
> z.B. weil es zu spät aktiviert wird (also nicht vor dem Startbit)
>
> -> Busteilnehmer Antworten zu schnell, während der voherige noch den Bus
> mit RE/DE = High blockiert.
>
> -> Baudraten (Bitzeiten) passen nicht gut zusammen (Mit Oszi
> korrigieren).
Klingt alles sehr einleuchtend.
Diese Punkte müsste ich aber mit dem Entwickler der Software 
diskutieren. Ich will erst mal meine(!) Fehler ausschließen, bevor ich 
den Mann belästige. Der hat mit seinem Studium genug um die Ohren. Das 
System befindet sich noch in der Beta-Phase und ich darf da (aufgrund 
meiner möglichen Schlamperei) nichts aufmischen.

Was ich aber auch interessant finde an Euren Antworten, daß niemand auf 
mein Breakout des Kabels eingegangen ist. Scheint wohl egal zu sein, wie 
ich Signal und Versorgung auf die 4 Adernpaare verteile?
Das Einzige, was ich hierzu gelesen habe, ist, daß das Signal auf 1 und 
2 (orange/orange-weiß) sein sollte, da diese am wenigsten übersprechen.

Nach der Lektüre dieses Thread liegen 3 Möglichkeiten oben:
- Failsafe für sicheren Pegel
- Timing der Halbduplex-Umschaltung

Jim M. schrieb:
> Falls Du die Zeilen regelmäßig neu schreibst: Stack Overflow auf dem
> Master µC wäre auch eine Möglichkeit.
Das habe ich eben noch gefunden.
Es werden immer ganze Zeilen neu geschrieben, aber nur, wenn sich ein 
Wert geändert hat.
Stack-Overflow??? Habe ich nur eine bildliche Vorstellung, was das sein 
könnte. Man müsste wohl einen Puffer(?) vergrößern oder schneller (oder 
mit besserem Timing) leeren.
Das müsste ich dann(!) mit dem Entwickler diskutieren.

Wenn ich alle möglichen Hardware-Kalamitäten (ich liebe: Kasperfallen) 
ausgeschlossen habe, lade ich ihn mglwse hierher ein (wenn er es nicht 
sowieso schon liest?) :)

Habe ich noch was vergessen? Fragt mich einfach.
Nochmal: Danke :)

[Nosnibor (Gast)]

Wie sieht es an der RO-Leitung (Empfänger-Ausgang) der RS-485-Treiber 
aus?
Worst case: während des Sendens ist der Pin hochohmig, so daß der UART 
sich irgendwelche Pegel zusammenphantasiert und Blödsinn empfängt. Die 
Software verläßt sich darauf, daß alle empfangenen Daten von einem 
anderen Busteilnehmer kommen, und versucht ihr bestes, dem Blödsinn 
gerecht zu werden...
Gegenmaßnahmen:
 - UART-Empfänger während des Sendens ausschalten
 - ignorieren, was während des Sendens empfangen wurde
 - Pullup an RxD

Aber zuerst würde ich Öletronikas Punkte prüfen: Leitungen vorgespannt? 
Timing bei der Übergabe geklärt? (wie schnell nach Ende des Stopbits 
schaltet der Master den Sender aus? Wie schnell antwortet der Slave? 
Dazwischen sollte genug Zeit für Baudratentoleranz liegen)

Und schließlich: verwendet das Protokoll eine gute Prüfsumme? Wenn ja 
(und wenn die beim Empfang auch beachtet wird), muß der Datenmüll durch 
einen Softwarefehler (Puffer-Überlauf, verbogener Pointer...) innerhalb 
eines der beteiligten Geräte entstehen.

[U. M. (oeletronika)]

Hallo,
> Andreas F. schrieb:
> Was ich aber auch interessant finde an Euren Antworten, daß niemand auf
> mein Breakout des Kabels eingegangen ist. Scheint wohl egal zu sein, wie
> ich Signal und Versorgung auf die 4 Adernpaare verteile?
> Das Einzige, was ich hierzu gelesen habe, ist, daß das Signal auf 1 und
> 2 (orange/orange-weiß) sein sollte, da diese am wenigsten übersprechen.
darauf bin ich aber in Prinzip schon eingegangen.

Ich schrieb ja, das solche Bandbreiten begrenzten Treiber an so kurzen 
Leitungen mit jedem Klingeldraht funktionieren sollten.
Mindestens auf einer Seite sollte aber terminiert werden.

Übersprechen kannst du unter solchen Bedingungen vergessen.
In Praxis sollten natürlich immer ein Aderpaar (miteinader verdrillt) 
genutzt werden.

> Das Problem ist, ich habe nur so eine (etwas ältere)
> Conrad-Krücke mit 5MHz.
Naja, ein Oszi ist da unverzichtbar, aber 5MHz reicht doch.

> Mein Versuch, den Bus abzuhören, ist daran gescheitert, daß ich
> kein auswertbares Signal angezeigt bekommen habe.
Die Leitungen A und B sind ja differentielle Signale. Meist wird keine 
Masse dazu herausgezogen.  Da solltest du mal in die Schaltung gehen und 
dir selber eine Oszi-Masse herbeizaubern -> Pin5 am MAX487.

> Ich habe aber einen Logic-Analyser benutzt. Der zeigte mir im Vergleich
> von A und B (die meines Wissens genau(!) spiegelverkehrt sein müssen)
Der Logikanalyser betrügt dich nur, wenn die Pegel nicht sauber sind.

Leider ist es so, dass es keinen einheitlichen Standard gibt, der die 
Pegel von den Leitungen a und B definiert.
Bei originärer "RS485" sollte aber die Leitung A im Ruhepegel = High 
haben und B = Low.
Bei Profibus ist es genau umgekehrt, obwohl der auch physikalisch auf 
RS485 beruht.

> gelegentliche - scheinbar spontane - Pegelsprünge auf nur einem Kanal.
> Deren Ursprung ließ sich hierbei natürlich nicht ermitteln.
Das solltest du genauer untersuchen.
Das könnte ein Hinweis  Datenkonflikte sein.

Entscheidend sind aber am Ende nur die Differenzpegel.
Gruß Öletronika

[Werner (Gast)]

1. Hier sind noch sehr gute Tips zu RS485:
http://www.ti.com/lit/an/snla049b/snla049b.pdf
2. Sind die GNDs von den Busteilnehmern sicher miteinander verbunden?

Werner

[spess53 (Gast)]

Hi

>Die Leitungen A und B sind ja differentielle Signale. Meist wird keine
>Masse dazu herausgezogen.

Ten Ways to Bulletproof RS-485 Interfaces (AppNote 1057)

sagt dazu

A typical mistake is to connect two
nodes with only two wires. If you do this, the system may radiate
high levels of EMI, because the common-mode return
current finds its way back to the source, regardless of where
the loop takes it. An intentional ground provides a
low-impedance path in a known location, thus reducing
emissions.

MfG Spess

[Andreas F. (Gast)]

Die bestellten Widerstände wurden heute geliefert. Kam noch nicht zur 
Testinstallation.
Die oben genannten Dokumente habe ich gelesen und - zum wesentlichen 
Teil - auch verstanden :)
Werde ganz sicher hier beschreiben, wie der Krimi weiter geht :)
Bis dann.

[Andreas F. (Gast)]

Ich hatte einen Nachmittag frei und die Gelegenheit genutzt, ein 
komplettes Master-PCB neu herzustellen (das nachträgliche Drauf-Gebastel 
auf einer SMD-Platine bringt es nicht wirklich).

Nun habe ich Failsafe 2x 750 Ohm und als Terminator zwischen A und B 130 
Ohm gesetzt. (Zum Glück passt das Rechenbeispiel in den o.g. Papieren zu 
meinem Fall). Am anderen Ende bleiben 120 Ohm als Terminierung.
Als Differenz zwischen A und B habe ich jetzt (in Ruhe und mit dem 
Multimeter gemessen) 400 mV (falls ich mich richtig erinnere, bin auf 
der Arbeit).

Der Bus funktioniert einwandfrei, jedenfalls die Slaves, die nur die 
Änderung von Schalterpositionen zu senden und die Helligkeit einer LED 
mittels empfangener Werte zu steuern haben. Aber die gingen auch vorher 
schon.

Auf meinem Display kommt nun garnichts mehr an. Ich vermute aber, das 
liegt nicht am neuen Master, ich habe sehr wahrscheinlich irgendwas 
anderes vermasselt. Jedenfalls wird der AVR etwas warm. Da muss ich 
nochmal bei.

Nosnibor schrieb:
> Gegenmaßnahmen:
>  - UART-Empfänger während des Sendens ausschalten
>  - ignorieren, was während des Sendens empfangen wurde
Das wird doch m.E. durch das Verbinden von RO und DI gewährleistet (?) 
Außerdem hat der fragliche AVR nichts zu senden. TX hängt in "der Luft".
>  - Pullup an RxD
Welcher ist das? Mein Verständnis sagt mir, daß es sich um den RX0 am 
AVR handelt. Ein Pullup hier ändert auch nichts.

[Andreas F. (Gast)]

Ich bin jetzt kurz davor, die Hardware als Problemquelle auszuschließen.
Nach einem weiteren Durchlauf - diesmal mit funktionierendem Display - 
kommt die Erkenntnis, daß sich NICHTS geändert hat.

Alle Slaves arbeiten wie erwartet, nur der, an dem das Display hängt, 
macht Zicken (spontan auftretende falsche Zeichen).

Werde wohl doch den Entwickler des Protokolls kontaktieren. (es sei 
denn, hier hat noch jemand eine zündende Idee.

Zur Belohnung habe ich mal ein Foto von meinem neuen Masterboard (ein 
Shield für den "Arduino MEGA 2560 R3". Zu sehen sind die drei MAX487 mit 
Failsafe-Widerständen, die drei Pull-Downs für die TXenable und die drei 
RJ45-Buchsen.

Jetzt will ich aber hören: "Das haste fein gemacht". :)

[posti (Gast)]

Hi

Andreas F. schrieb:
> Jetzt will ich aber hören: "Das haste fein gemacht". :)

Schaut doch nett aus :)

Hast Du von der Display-Platine noch einen Ersatz da und Diesen 
versuchshalber benutzt, oder Beide gleichzeitig?
Klar können vereinzelt Bytes verstümmelt ankommen, das muß man per 
Prüfsumme ect.pp. rausfiltern und die Übertragung neu anstoßen.
Wenn der Slave nicht selber 'oha, Fehler' senden darf, muß der Master 
abfragen, ob die Übertragung korrekt war, worauf der Slave dann ja 
antworten darf.
Oder ähnlich den Time-Slots beim 1-wire, daß jeder Slave, Der Probleme 
mit dem Paket hatte, den Fehler anzeigen kann, vll. wäre das Paket ja 
für Ihn gewesen und mit anderer Empfänger-ID könnte die Prüfsumme ja 
vll. passen.

MfG

[Andreas F. (Gast)]

posti schrieb:
> Hast Du von der Display-Platine noch einen Ersatz da und Diesen
> versuchshalber benutzt, oder Beide gleichzeitig?
Das ist eine SUPER Idee :)
Muss nur erst noch ein display-kompatibles Slaveboard bauen. Das ist 
kein Problem, muss nur die Zeit finden (dauert inkl. Bohren und Löten 
einen entspannten Tag). LCDs habe ich auch noch liegen.
Dann könnte ich sehen, ob auf beiden der gleiche Schrott läuft und wäre 
der Quelle einen Schritt näher. Danke.
> Klar können vereinzelt Bytes verstümmelt ankommen, das muß man per
> Prüfsumme ect.pp. rausfiltern und die Übertragung neu anstoßen.
> Wenn der Slave nicht selber 'oha, Fehler' senden darf, muß der Master
> abfragen, ob die Übertragung korrekt war, worauf der Slave dann ja
> antworten darf.
Meines Wissens gibt es (noch) keine Prüfsumme. Das Projekt ist noch in 
der Beta-Phase und ich bin einer der Minen-Hunde (Ian: Nicht böse sein. 
Mache ich sehr gerne.)
> Oder ähnlich den Time-Slots beim 1-wire, daß jeder Slave, Der Probleme
> mit dem Paket hatte, den Fehler anzeigen kann, vll. wäre das Paket ja
> für Ihn gewesen und mit anderer Empfänger-ID könnte die Prüfsumme ja
> vll. passen.
Das Problem ist, daß ich (aus welchem Grund auch immer) dem Slave durch 
Abtrennen des TX das Senden verbieten muss. Sonst bleibt das LCD dunkel.
Woran das liegt, habe ich auch noch nicht herausgefunden. Eventuell gibt 
es da Stress zwischen den "RS485"- und Adafruit-Bibliotheken (von deren 
Inneren ich NULL Ahnung habe).
Das liegt aber nahe... Wieso bin ich da nicht schon eher drauf gekommen, 
die Probleme begannen ja mit dem Display. Kann aber auch sein, daß die 
Probleme dadurch erst sichtbar wurden.