RS485: Busauslegung und alternativ: CAN-Treiber-Chips?

[Beta-User]

Ist vielleicht hier OT, aber einen neuen Thread wollte ich auch nicht unbedingt aufmachen:
Wegen des beobachteten spontanen Reboots, habe ich jetzt mal das log aus Februar ausgewertet (um das besser zu monitoren, sind jetzt alle MySensors-Nodes in einem logfile vereint).

Das Ergebnis ist irgendwie nichtssagend, aber eben auch nicht lustig:
Die Nodes 2 (ID: 102) und 4 (ID: 101) fallen nicht nur immer wieder mal wieder aus, sondern haben auch die Angewohnheit, zwischendurch mal neu zu starten, manchmal nach einer gewissen offline-Zeit, manchmal auch nur "einfach so". Mind. 5 reboots für die ID 102, 4 für 101 (davon einige die letzten 48h).

Wenn man überhaupt ein Muster erkennen kann, dann evtl. das, dass man im zeitlichen Umfeld zu den tatsächlichen Sendungen bzw. dem erwarteten Zeitpunkt von neuen Werten Kollissionen mit anderen Nodes vermuten könnte.
Meine Spekulationen dazu poste ich gerne mal gesondert, aber ich werde wohl zum einen noch die 7,5k-Variante ausprobieren (seit den 4,7k könnte man unterstellen, dass Nodes eher "wiederkommen") und zum anderen noch überall wait()-Anweisungen einbauen (manche Nodes senden noch 2-3 Werte auf einen Rutsch.

Seltsam finde ich auch, dass gerade die Nodes mit den niedrigsten Nummern (oder ohne 0 bis 3 in der Nummerierung?) scheinbar nicht diese Symptomatik aufweisen.

Vielleicht hat ja sonst jemand noch eine Idee...

[Ranseyer]

Einbruch der Spannung am Node ? (47 oder 100uF oder so Kondensator an einem Node zum Test verbauen...)

[pula]

Woo, woo...
Ihr Jungs (und Mädels?) seid aber high sophisticated unterwegs, da bin ich leider ausgestiegen.
Da ich für meine MySensor-Nodes EIB-Kabel verlegt habe und noch 3 Pins frei habe (weil derzeit nur als Spannungsversorgung), überlege ich, auf ein verkabeltes Bus-Sytem umzusteigen. Aber was Ihr hier schreibt, ist mir um einige Größenordnungen zu hoch
Vielleicht mag mal jemand von Euch das zusammenfassen?
Cheers,
Pula

[Beta-User]

@Ranseyer: Hatte zwar insbesondere an der 102 (pro mini) auch noch einen weiteren AMS1117 in Modulform drauf gemacht. Da sind auf der Versorgungs- und 5V-Seite auch je Kondensatoren drauf. Aber scheinbar brauchen die MAXe doch richtig Saft...
Danke für den Tip, werde berichten!

@Pula:
Was genau willst du wissen bzw. was ist zu hoch? In Kurzform:
- RS485@MySensors funktioniert im Prinzip wie "normales" MySensors, nur dass man eben in den Sketchen den Kommunikationslayer tauscht. Einzige echte Besonderheit ist, dass man die Node-Id im Sketch festlegen muß. Schau dazu die Beispielsketche@MySensors.org an (GW+Motion, meine ich, sind am Namen zu erkennen).
- 2 bzw. 3 Adern sind erforderlich (A, B und ggf. (zu empfehlen) GND)
- Verkabelung kannst du auf MySensors.org nachsehen, was wir hier diskutieren, ist die Frage, wie die Widerstandswerte an der letzten Node bzw. als Busabschluss aussehen sollen und welche Transceiver man am besten nutzen sollte (und ggf. wie schnell die Daten übermitteln).

Zum Testen, wenn du nicht so viel löten willst (ohne geht es nicht!): Die LC-Electronics-Module vom MAX485 auf MAX487 umlöten (geht erst mal auch so mit MAX485), dann aber die meisten Widerstände auslöten (GW+Busabschluß behalten je den 120-Ohm Widerstand, meine Tendenz wäre dann, R5 und R6 bei den Modulen eher höher zu wählen, als sich das eigentlich nach dem verlinkten Widerstandsrechner ergeben würde (4,4kOhm bzw. 7,5kOhm statt ca. 400Ohm). Aber da beginnt die Magie (scheinbar bin ich im Moment der einzige, der wirklich einige Meter Kabel verlegt hat und das unter Echtbedingungen testen kann; leider bin ich aber weder der Held beim Löten noch in der theoretischen elektr. Auslegung solcher Sachen...).
Sehr wichtig scheint dabei zu sein, dass die MAX48x genug Spannung bekommen, sonst gehen die vom Netz und stören ggf. die gesamte Kommunikation - das ist dann nicht besonders erfreulich.

Wenn Ranseyer seine Platinen fertig hat, wäre es vermutlich besser, die zu nehmen und ggf. auch andere Transceiver (die scheinen in der Regel PIN-kompatibel zu sein, das sollte sich also ggf. tauschen lassen).

Zur Erläuterung noch zu den diskutierten CAN-Bausteinen:
Ich hatte häufiger den Fall, dass einer der Arduinos seinen Baustein auf Dauersenden geschalten hatte (DE high). Dann geht nichts mehr. Die CAN-Bausteine erkennen sowas und geben den Bus dann selbständig wieder frei. Die Frage ist nur, ob das einen anderen Kommunikationslayer in den Sketchen erfordert, oder ob das "einfach so" geht (wenn, dann muß man aber andere Bausteine/Platinen verwenden, die IC's sind nicht pin-kompatibel).

Ich hoffe, ich habe dazu nichts unterschlagen. Wenn es dann mal zuverlässig tut, ergänze ich auch den Einsteiger-Guide im Wiki (wenn es jemand jetzt schon besser weiß und zuverlässig am laufen hat: nur zu!).

Gruß, Beta-User

[Ranseyer]

Wenn Ranseyer seine Platinen fertig hat, wäre es vermutlich besser, die zu nehmen

Ich habe genügen Varianten in der Schublade um alles zu testen... => bei Interesse PN!

[Brasletti]

@beta-user: hast du die Nodes und das GW jetzt alle an einer gemeinsamen Masse? Lies dazu mal https://www.mikrocontroller.net/topic/306725#new (must halt filtern, ist auch etwas Mist dabei) Evtl. ist das ja auch ein Grund für deine Schwierigkeiten.

[Beta-User]

@Brasletti:
Steht auf der todo-Liste, bisher tanzen Node 3 und das GW noch aus der Reihe.

(Auch wenn ich im Moment eher noch die Probleme jeweils auf den einzelnen Nodes sehe, weil ja immerhin seit einigen Wochen 2 Nodes + GW sauber miteinander kommunizieren und jedenfalls seit Verwendung der höheren R-Werte nicht mehr der ganze Bus ausgefallen war).

Da aber die Einbeziehung von Node 3 ein größerer Umbau wäre (leider im Kalten), muß das noch etwas warten, zumal mich (und ggf. auch andere) auch interessiert, welche Einzelmaßnahme denn wirklich zu Verbesserungen führt. An sich war aber schon immer der Plan, auch diese Node an die zentrale 12V-Versorgung anzuklemmen, dann wäre auch da GND auf einem einheitlichen Potential, und eine Ader für das GW findet sich dann auch noch .

Prio 1 ist m.E. daher der Einbau der Kondensatoren, das schadet jedenfalls nicht. Die Spannungsversorgung hatte ich eh' schon länger in Verdacht (deswegen hatte ich teilweise ja auch die zusätzlichen 1117 eingebaut). Mir war offen gestanden allerdings bis dato nicht klar, wieviel Strom die MAX48x-e tatsächlich ziehen, wenn sie richtig am "arbeiten" sind. Prio 2 wäre dann, zu vermeiden, dass es zu längeren Kollissionsphasen kommt.

Zu den Platinen:
Habe zwei der 1. Generation mit den teilweise invertierten Beschriftungen im Einsatz , nochmal Danke @Ranseyer!
Die anderen (1, 2 und 5) sind umgebaute nRF-Nodes, da habe ich im Moment wenig Lust, alles nochmal zusammenzulöten. Siehe Post #38: Da sind einige Leitungen dran, deswegen ist es auch nicht so easy, die einfach mal abzuklemmen und dran rumzulöten... Bin ja froh, dass wenigstens die Arduinos und Transceivermodule ganz überwiegend gesockelt sind, dann geht wenigstens das Umflashen halbwegs flott. Nur Node 3 wollte ich diesbezüglich nochmal anfassen, aber da soll auch noch einiges an Funktionalität dazukommen , was aber waren kann bis wieder Frühjahr ist.

Generell würde ich aber noch für zukünftige Platinen-Versionen vorschlagen, HW-serial statt altsoftserial-PIN 8/9 als Option vorzusehen. Könnte eine Lötbrücke sein, die man halt schneidet (weg von 8/9) bzw. brückt (zu RX/TX). Ist der code fertig, braucht man ja keine debug-Ausgaben mehr bzw. uU. reicht der Speicher sonst nicht (BME280 mit forecasting ist schon recht eng...).
Oder eben einen ProMicro statt des ProMini vorzusehen, wenn wir das wollten und erfolgreich getestet haben.
An STM32F1 oä. als Basis mag ich gar nicht denken (wäre aber in der Planung für Node 6 ).

[Beta-User]

Zu der GND-Diskussion noch als Merkposten: https://www.mikrocontroller.net/topic/306725?reply_to=3299668#postform

Ich habe bisher gute Erfahrungen (mit industriellen Drehgebern per SSI
Protokoll) damit gemacht, das der Master den GND niederohmig verband und
die Slaves per Widerstand die Masse gegen ihren GND zogen (ca. 1k-10k).
SSI läuft allerdings zwar differentiell, benutzt aber verschiedene
Pärchen für Clock, und den Hin- und Rückweg. (Insgesamt also 3 Pärchen)

Das sieht mir vom Prinzip her nach einem Weg aus, meine Bauchschmerzen beim GND des GW zu unterdrücken, sollte es bis dahin nicht funktioniert haben . Also einfach dort einen Widerstand (beginnend mit 10k) einbauen..

[Ranseyer]

HW-serial statt altsoftserial-PIN 8/9 als Option vorzusehen

Haben wir in den aktuellen Versionen die in der Schublade liegen schon drin !

[Beta-User]

Haben wir in den aktuellen Versionen die in der Schublade liegen schon drin !

...hätte ich mir eigentlich denken können ...

Zu den Kondensatoren: habe gestern abend bei Node 2, 4 und 5 mal je einen Elko 100uF direkt an die Sockel für die LC-Module angelötet. Das brachte leider keine spürbare Verbesserung  . Insbesondere Node 2 hatte heute auch schon wieder (mind.) einen spontanen Reboot, Node 4 ist über Nacht auch wieder offline gegangen.

Dann werde ich mich am WE wohl mal warm anziehen und auch Node 4 noch mit auf die 12V aufklemmen , dann haben alle bis auf das GW einen gemeinsamen GND.

Dennoch würde ich weiter darauf tippen, dass es eher etwas mit dem Code zu tun hat. ixquick liefert bei der Suche nach dauer-schnellblinkenden Arduinos nämlich nicht "zuwenig Saft", sondern u.a. auch mind. einen Hinweis, dass es sich um eine Art Speicherüberlauf handeln könnte bzw. um einen auf den Bootloader verweisenden fehlerhaften pointer (was immer das heisst ).
Step 2 wäre dann der Versuch, die Sendungen noch etwas weiter zu entzerren (wait() einfügen bzw. die Zeiten noch etwas verlängern).

Schaun' wir mal, dann sehn' wir mal...

[Brasletti]

Senden die anderen Nodes denn weiter wenn ein Node abschmiert? Hört sich für mich so an als würde der Bus weiterlaufen, oder?

[Beta-User]

Jedenfalls seit der Erhöhung der Widerstandswerte am Busende auf 1k und höher hatte ich _keine_ Komplettausfälle mehr.

Vorher schon, was aber vermutlich daran lag, dass eine Node ihren MAX auf Dauersenden gezogen hatte (DE high). Ich habe auch teilweise immer mal wieder gemessen, da war auch erkennbar, dass die Spannung A-B immer weiter nach oben gegangen ist, bis eben am Ende ca. 2,5V erreicht waren. War die betreffende Node dann kurz ohne Spannung, ging häufig zumindest ein Teil der Nodes wieder online (am verläßlichsten die BME280-Node (98=Node 3, altsoftserial auf Ranseyer-Platine)
Am WE hatte ich mehrfach gemessen, die Werte habe ich ja gepostet. Von daher auch meine Annahme, dass der Bus von der elektrischen Seite her jetzt an sich in Ordnung zu sein scheint.

Ist immer schwierig, im Nachhinein zu rekonstruieren, was passiert ist, und an was es dann im einzelnen wirklich lag. Ziemlich am Anfang war es mal so gewesen, dass immer die 98 (Node 1) abgeschmiert ist. Da ist ein Bewegungsmelder dran, und die Logik hat der Arduino dann teilweise noch Stunden nach der letzten Meldung über den Bus sauber ausgeführt, bis dann irgendwann auch da Ende Gelände war. Daher auch die Vermutung, dass es sich evtl. um ein Speicherproblem handeln könnte.

Vielleicht hat das ganze auch (teilweise) mit dem hier zu tun: https://github.com/mysensors/MySensors/issues/954. Auch da scheint es so zu sein, dass sich die Kommunikation irgendwann verabschiedet hat, der uC aber weiter lief. Dann wäre es in den Untiefen des MySensors-Codes oder darin verwendeter libs verborgen...

[KarlHeinz2000]

Ich nutze jetzt auch die HW Serial für RS485. Allerdings gab es Probleme beim Programmieren des Arduino (ProMini), da der RX vom Bustreiber gegen den FTDI vom Programmieradapter gearbeitet hat. Ging nicht!
Lösung bei mir: Den /RE an einen Port und über 10k auf 5V. Während Reset/Programmieren ist der Port auf input und der Pullup schaltet den Receiver aus. In der Anwendung (Setup) wird der Port auf Output Low gesetzt und dann nicht mehr geändert. So geht es bei mir. Kostet halt einen Port...

[Beta-User]

Kostet halt einen Port...

Na ja, effektiv gewinnst du einen (8 und 9 werden ja frei) und eine ganze Menge Speicher.
Danke für's posten dieser Lösung!

[Brasletti]

Also wenn ich das richtig verstanden hab schaltest du im Sketch den RS485 Chip dann zu sobald der Sketch läuft, oder? Interessanter Ansatz!! Würde einem beim häufigen Flashen auf jeden Fall den Griff zum Lötkolben ersparen