RS-485 im VM

Du liegst genau richtig:)
Allerdings sind die Leitungen, die vom Knoten abgehen, eher kurz, die längste ist vom Heckknoten in der Hutze zum Rücklicht.
Vorne liegt alles beisammen, im Schaltkasten in der Mitte auch, und beim Tiller ebenfalls. Beim rechten Mittelknoten sind die Leitungen zur RGB Unterbodenbeleuchtung auch noch rel. lang, dafür blinkt und bremst die aber mit , da die die Services ja mitliest:D
 
Ok, also die Kabel zu den Komponenten sind an keiner Stelle besonders lang.

Aber jedenfalls sind die Knoten ziemlich auf die Gegebenheiten und Anforderungen in Deinem Velomobil zugeschnitten, denke ich mir.

Mir würden eher etwas allgemeinere Knoten vorschweben, die man flexibel miteinander kombinieren könnte. Ich erkläre am Schluss, wie ich darauf komme ...

Beispiel:
Ein Knoten, der drei Ausgänge schalten kann. Das wäre also im einfachsten Fall ein uC, der drei Mosfets in Open Drain Schaltung steuert. Da es kaum Mehraufwand ist, kann man PWM vorsehen, dann kann man die Ausgänge auch dimmen.
Damit könnte man einen Kellermann Atto steuern und bei Bedarf einzelne Ausgänge runterdimmen.
Für einen weiteren Atto nimmt man einfach noch so einen Knoten.

Wegen des einfachen Aufbaus ließe sich der Knoten gut miniaturisieren. Ich glaube, dass man die reine Elektronik locker auf ca 2 cm² bekommen könnte, was wiederum den Einbau erleichtert. (Das setzt voraus, daß der uC in einem kleinen Gehäuse verfügbar ist.)

Für Rück/Bremsleuchten sowie Blinker im Heck kann man identische Knoten verwenden.

Wie spricht der Primary jetzt diese Knoten an, die ja alle identisch sind ? Damit die Knoten für den Primary unterscheidbar werden, brauchen sie eine eigene Knotenadresse, oder ?

Ich würde also die Knoten nach Typen sortieren. Der Knoten Typ "Schalter/Dimmer 3 Ausgänge" hätte die Basisadresse 0x3x.
Weitere verbaute Knoten dieses Typs erhielten aufsteigende Adressen : 0x30, 0x31, ...
Da kein Mensch in seinem Velomobil mehr als 8 Blinker braucht, wäre bei 0x37 Schluss. Danach wären Adressen frei für den nächsten Knotentyp.

Für die 8 verschiedenen Adressen reichen 3 Bits. Lötbrücken vielleicht, oder Adresse von aussen programmieren -> Flash
Wichtig ist, dass die Knoten aus Sicht des Primaries unterscheidbar sind. Dann lässt sich das System weitestgehend durch den Primary initial konfigurieren.

Konfiguration des Systems:
Also die Grundkonfiguration, die nur bei der ersten Inbetriebnahme durchgeführt wird, oder nachdem eine neuer Knoten hinzugefügt wurde.
Die Knoten haben einen Service, über den sie Auskunft über ihre Services geben. Der Primary sendet an alle erlaubten Knotenadressen eine Diagnosenachricht. Erhält er eine Antwort, fragt er die verfügbaren Services ab und legt diese in einer Liste ab.

Ein Ausschnitt aus dieser Liste würde z.B. so aussehen:

Blinker0 Knoten 30
Blinker1 Knoten 31
Blinker2 Knoten 32
...
Rücklicht0 Knoten 30
Rücklicht1 Knoten 31
...
RGB Output0 , Knoten 90
...

Mittels einer Servicesoftware wird dann ein Mapping zwischen Funktion ("Blinken Links") und den Services hergestellt und im Master abgespeichert (Flash). Die Servicesoftware kann entweder auf einem Notebook laufen, das über einen RS-485 Dongle mit dem Netzwerk verbunden wird. Oder auf dem Master selbst, wenn dieser z.B. über ein TFT verfügt.

Wozu der ganze Aufwand ?
  • Trennung von Verdrahtung und Konfiguration
    • Das würde den Einbau der Elektrik vereinfachen, zum Beispiel in RO: Erst einbauen, dann per Diagnosesoftware konfigurieren
  • Flexibilität: man baut die Komponenten ein, die man braucht, und kann sie alle problemlos einbinden
  • Erweiterbarkeit: Ein zusätzlicher Knoten lässt sich jederzeit nachträglich einfügen, ohne, dass ein uC neu programmiert zu werden braucht
  • Möglichkeit, Knoten(Module) verschiedener Hersteller miteinander zu kombinieren
P.S.: Ich habe mir auch überlegt, wie man die zusätzlichen Knotenadressen in Deine @nikolauzi s 4-Byte Struktur hineinbekommt.
Eine Möglichkeit wäre, sie irgendwie in das Service-Byte mit einzubauen.
Eine andere Möglichkeit wäre, entweder nur Knotenadresse oder Service-Id zu übertragen, auf demselben Byte. Die Knotenadresse benötigt man streng genommen nur zur Initialisierung.
Oder man hijackt das Sync-Byte und verzichtet dafür auf die Baudratenanpassung.

Das war jetzt ziemlich viel, fürchte ich. Bitte gerne kommentieren !
 
Zuletzt bearbeitet:
Ok, ich mache mal einen Vorschlag für ein Protokoll. Es ist an @nikolauzi s Vorschlag angelehnt, sieht aber ein zusätzliches Byte vor, das den Knoten adressiert.

Obwohl ich finde, dass das Auto-Bauding ein interessantes Feature ist, lasse ich das Sync Byte erst einmal weg. Man kann es bei Bedarf jederzeit wieder hinzunehmen, ohne am restlichen Protokoll etwas zu ändern.

Damit bleibt eine Nachricht vier Bytes lang:

message.png

Nachdem der Primary eine Nachricht verschickt hat, wartet er die Antwort ab.

Die Antwort des Knotens enthält als Node ID die Adresse des Primaries (z.B. einfach 0x00). Anstelle des Service sendet er die Knoten ID. Das Option Byte enthält einen einfachen Status (Ok oder Fehlercode).

Hier als Beispiel die Nachricht an Knoten 3, die den Blinker Nr. 1 auf "An" setzt:


protocol-01.png
 

Anhänge

  • protocol-01.png
    protocol-01.png
    8,5 KB · Aufrufe: 6
  • protocol-01.png
    protocol-01.png
    5,8 KB · Aufrufe: 7
  • protocol-01.png
    protocol-01.png
    35,9 KB · Aufrufe: 6
  • protocol-02.png
    protocol-02.png
    21,7 KB · Aufrufe: 5
Zuletzt bearbeitet:
Timeout / Fehlerbehandlung:

Für die Antwort setzt der Primary ein kurzes Timeout. Dies sollte nicht mehr als die zehn-fache Nachrichtenlänge betragen. ¹
Die Knoten müssen immer sofort antworten. ² Kommt keine Antwort, kann der Primary die Nachricht noch ein - oder zweimal wiederholen.
Kommt dann immer noch keine Antwort, signalisiert der Primary den Ausfall des Knotens (per LED / Display).

Falls der Knoten mit einem Fehlercode antwortet, wird, abhängig vom Code, die Nachricht noch einmal gesendet (Checksumme etc.) oder das Problem wird ebenfalls angezeigt. Der Status des Knotens wird abgespeichert und der Knoten wird ggv. nicht mehr angesprochen.


¹Beispiel: Bei 115 KBaud beträgt die Nachrichtenlänge 4 x 8 / 115200 = 278 uS. Ein sinnvolles Timeout läge dann zwischen 1 ... 3 ms.

² Falls der Service zum Beispiel die Abfrage von Sensoren etc. beinhaltet, die länger als das Timeout dauern würde, wird mit einer Nachricht die Abfrage gestartet und mit einer weiteren Nachricht, nach angemessener Wartezeit, der Wert abgerufen.
 
Zuletzt bearbeitet:
Grau ist alle Theorie ... :whistle:

Wie groß ist denn nun der Schaltungsaufwand für einen Knoten ?

Um dafür ein Gefühl zu bekommen, habe ich mal eine beispielhafte Schaltung für einen Knoten mit drei Ausgängen entworfen.
Die Mosfets an den Ausgängen schaffen 4A, das müsste für die Lampen, Blinker, Hupen etc. eigentlich reichen.

Der verwendete uC von ST lässt sich entweder per Arduino IDE oder mit der STMCube IDE programmieren. Dies geschieht über den SWD Port.

Vorgesehen sind ausserdem zwei RS-485 Ports mit jeweils 4 Pins. Der Idee dabei ist, die Ports an gegenüberliegenden Seiten der Leiterplatte anzuordnen. Der Bus geht dann auf der einen Seite rein und auf der anderen wieder hinaus. Im einfachsten Fall als vierpolige Flachbandleitung.


node-a-sch.png
 
Zuletzt bearbeitet:
Ein paar Anmerkungen vielleicht noch zu den Bauteilen.

Die Transistoren kommen im SOT23 Gehäuse (2.9 x 1.5 x 1 mm). Die Ausgangstransitoren kosten bei Reichelt 21 Cent, die Treiber 7 Cent.
Der uC hat ein TSSOP20 Gehäuse (6.4 x 4.4 mm). Das ist gerade noch Hand-lötbar. Kosten z.B. bei JLCPCB < 70 Cent.
Der RS-485 Treiber, SP3485CN, kostet bei Reichelt 1,20 €, bei JLCPCB 40 Cent.

Man sieht, die Kosten halten sich in Grenzen, die benötigte Platinenfläche auch.

Wichtig im Velomobil ist immer die Leistungsaufnahme. (Denn wer will schon, dass ihm der schicke RS-485 Bus den Akku leersaugt ;) )
Wie hoch ist also der Leitungsbedarf eines Knotens ?

RS-485 Treiber, Controller und der 3.3V Festspannungsregler haben jeweils einen Ruhestrom von ca 1 mA. Damit kann man davon ausgehen, dass der Knoten weniger als 5 mA aufnimmt. Bei 10 Knoten sind das 50 mA. Der Linearregler macht daraus direkt 50 mA @ 12V.
Man müsste also mit einer Leistungsaufnahme von 600 mW rechnen. Der Steuerknoten kommt noch obendrauf, aber eine Leistungsaufnahme < 1 W erscheint schon realistisch.
 
Zuletzt bearbeitet:
Dann ev. einen HT7133 als Spannungsregler (Ruhestrom 10uA, der 1117 geht glaube ich nur bis 12V Input?) und den obigen MAXIM Treiber mit 100uA. Dann lohnt sich auch der Sleepmode beim Controller und das ganze könnte dauerversorgt werden (z.B. Hupe/Blinker für Alarmanlage). Noch eine z.B. 4A Polyfuse in die Versorgung der Lasten als Kurzschlußschutz, safety first;) Erhöht auch die Verfügbarbeit bei Kurzschluß in einem Knoten. 6/8 pin Stiftleiste zur Knotenkonfiguration per Jumper (3/4 bit) über interne Pullups, werden nach dem Startup/Auslesen abgeschaltet, spart dann auch Strom.
 
Dann ev. einen HT7133 als Spannungsregler (Ruhestrom 10uA, der 1117 geht glaube ich nur bis 12V Input?) und den obigen MAXIM Treiber mit 100uA. Dann lohnt sich auch der Sleepmode beim Controller und das ganze könnte dauerversorgt werden (z.B. Hupe/Blinker für Alarmanlage).
Der HT7133 ist an der Stelle auf jeden Fall besser geeignet, als der 1117, das werde ich anpassen. Beim Treiber hatte ich einfach mal den billigsten von Reichelt genommen ;). Da die alle Pin-kompatibel sind, ist hier der Austausch besonders unproblematisch.

Noch eine z.B. 4A Polyfuse in die Versorgung der Lasten als Kurzschlußschutz, safety first;) Erhöht auch die Verfügbarbeit bei Kurzschluß in einem Knoten.
Full Ack.

6/8 pin Stiftleiste zur Knotenkonfiguration per Jumper (3/4 bit) über interne Pullups, werden nach dem Startup/Auslesen abgeschaltet, spart dann auch Strom.

... lässt sich das vielleicht vermeiden ? Der Platz am Rand der Platine ist knapp, und Jumper sind ziemlich groß, auch im Vergleich zu den restlichen Bauteilen. Vielleicht kann man die Knoten über RS-485 einzeln konfigurieren, bevor man sie einbaut ?
 
Aktualisierter Schaltplan:
  • Linearregler gegen HT7133-2 ausgetauscht
  • Polyfuse eingefügt
  • ADM483 ARZ als RS-485 Treiber (ähnliche Eigenschaften wie MAX487, 3.3V, günstig bei Reichelt)
  • Terminierung entfernt
  • Debugfunktion über UART1 entfernt
  • UART2 -> UART1
UART1 als zusätzlicher Debug-Port ist eigentlich überflüssig, SWD ist ja vorhanden.
UART1 bietet mehr Optionen als UART2, z.B. kann er Autobauding. Daher treibt er jetzt den RS-485 Bus.

Für die Terminierung habe ich mir überlegt, dass man sie auch auf eine separate, kleine Platine auslagern könnte.
Diese liesse sich dann flexibel an den Anfang und ans Ende der Busleitung setzen. Daher habe ich sie aus der Schaltung entfernt.

node-a.png

Falls Ihr noch weitere Optimierungsvorschläge habt, immer gerne her damit.

Ansonsten mache ich in den nächsten Tagen mal ein (doppelseitiges) Layout der Schaltung.
 
Zuletzt bearbeitet:
Ev. noch 3 oder 4 kleine Lötbrücken nach GND vorsehen (0603) für die Codierung, falls das per SW nicht klappt. Oder hat der uC ev. eine interne Seriennummer? Damit ließe der sich identifizieren bei einem Netzwerkscan (autodetect).
 
Der uC hat momentan ja noch 9 freie Pins. Ich werde dann mal ein paar davon mit (unbestückten) 0603 Widerständen gegen GND terminieren.
Dann kann man diese entweder für die Adressierung nutzen oder z.B. auch weitere Ausgangsstufen etc. damit freifliegend verbinden.
 
Zuletzt bearbeitet:
Die Leiterplatte ist nun fertig, hier ein paar Bilder:

node-a-3d.png


node-a-3d01.png


node-a-3d02.png

Sie ist, mit 21 x 35 mm, noch einigermassen klein geblieben. Das Layout ist 2-lagig. Für einen ersten Test fand ich das ausreichend.
Geht man auf vier Lagen und verwendet etwas filigranere Header (2mm Pitch), lässt sich die Platine vermutlich bis auf ca 2 x 2 cm verkleinern.

Die Header haben jetzt einen Pinabstand von 2.54 mm, also das normale Rastermaß.
Links und rechts befinden sich die Header für den RS-485-Bus. Der Bus geht sozusagen auf der einen Seite rein, auf der anderen raus.
Am oberen Rand der PCB ist der Header mit den drei Ausgängen.

Wie man auf dem ersten Bild gerade so erkennen kann, befinden sich am unteren Rand die Widerstände R3, R5, R6 und R7. Die sollen nicht bestückt werden.
Auf den Footprints lässt sich dann mittels kleiner Lötbrücken die Knotenadresse festlegen. (4 Bit = 15 mögliche Adressen.)

Der zusätzliche Header ist der Anschluss für den Debugger bzw. dient zum Flashen der Firmware.

P.S.: Für die PolyFuse hatte der 3D-Viewer offensichtlich kein Modell, daher ist der Platz auf Leiterplatte leer.
 
Zuletzt bearbeitet:
@Goucho Ich habe mir den Schaltplan in #29 angesehen. Dabei ist mir aufgefallen, dass bei den P-MOS-FETs Q1, Q3, Q5 jeweils drain und source vertauscht sind, für einen High-Side-Switch. So wie sie im Schaltplan sind, kann immer ein Strom durch die Body-Diode zum Ausgang fließen. Auch wenn diese umgedreht würden, besteht ein weiteres Problem mit der Gate-Ansteuerung. Das Absolute maximum Rating für die Gate-Source Spannung ist mit ± 12V Angegeben. Wenn die Betriebsspannung schon 13V beträgt wird diese also beim Einschalten der FETs überschritten und sie könnten recht bald kaputt gehen.

(Als einfachste Lösung würde ich vorschlagen die Mosfets erstens umzudrehen und sie zweitens mit jeweils einem weiteren Widerstand zwischen Gate und BSS138-Drain als Spannungsteiler nur bis zur halben Betriebsspannung auszusteuern.)

Dann ist mir noch aufgefallen, dass der RS485 Treiber ADM483 ARZ für VCC = 5 V ± 5% spezifiziert ist aber mit 3,3V betrieben wird. Das ist außerhalb der Spezifikation. Ich vermute der Treiber wird dennoch weitgehend funktionieren. Es gibt aber auch Pinkompatible RS485 Treiber, welche für 3,3V spezifiziert sind.

Ansonsten eine Schöne Darstellung mit KiCad. Ich wollte auch schon länger mal was mit KiCad machen, und dabei lernen wie man es bedient. Bin aber noch nicht dazu gekommen.
 
Zuletzt bearbeitet:
Stimmt, die Anschlüsse sind vertauscht ! Gut, dass Du noch mal draufgeschaut hast ..
Da die Schaltung mit der unstabilisierten Ausgangsspannung eines 14V Lupine Akku klarkommen muss, werde ich zusätzliche Widerstände einfügen, entweder zwischen Drain BSS138 und Gate AO3401, oder in die Source-Leitung des BSS138.

Weil die Schaltung einen Minimalentwurf darstellen soll, ist die Ausgangsstufe maximal simpel ausgelegt. PWM-taugliche Ansteuerung der Mosfets oder High-Side Switches etc. habe ich mir erstmal verkniffen, damit es überschaubar bleibt.

Der RS-485 Treiber ist eher ein Platzhalter, aber Du hast recht, es sollte schon ein 3.3V-Typ sein.

Die Leiterplatten sind ja noch nicht bestellt. Noch lässt sich alles korrigieren.
 
Wenn man z.B. den DMP3098 anstelle des AO3401 einsetzt, der 20V UGS hat, braucht man keinen zusätzlichen Spannungsteiler. Da JLCPCB den günstig im Programm hat, und der Platz für zusätzliche Bauteile an der Stelle der Leiterplatte auch gerade ein bischen knapp war, zögere ich da nicht lange. Die Anschlüsse des DMP3098 sind getauscht. Ausserdem habe ich einen 3.3V Typen für den RS-485 Treiber eingesetzt.

Die Anschlüsse am RS-485 Bus haben sich geändert.
Sie sind jetzt in der Reihenfolge GND / B / +12V / A belegt. Das passt zu einer Flachbandleitung AWG22, die u.a. bei der Verkabelung von LED-Strips verwendet wird. Sie ist preiswert, robust und an jeder Ecke zu bekommen.

Eine Rolle mit 10 m sieht so aus:

P3050086-s.JPG

Die Dicke ist AWG22. Zu den Eigenschaften der Flachbandleitung später mehr...
Die Reihenfolge der Farben ist, wie man sieht, schwarz - grün - rot - blau.

Folgende Zuordnung der Farben erschien mir halbwegs intuitiv:

schwarz <=====> GND
grün <=====> B
rot <=====> +12V
blau <=====> A


-> daher die Änderung im Schaltplan an der RS-485 Schnittstelle.
 
Zuletzt bearbeitet:
10 bestückte Leiterplatten sind jetzt bei JLCPCB bestellt.
Bin mal gespannt, wie lange sie brauchen ...

order-confirmation.png
 
Really cool!

Personally I like the idea of having dipswitches for setting the address as that means you can simply take a spare (or two) PCB with you on a long trip in case one breaks without having to bring a soldering iron as well ;). Also easier for manufacturing, JLCPCB can solder it in place. Dumb question about that (I have 0 experience making electronics), but why don't you have JLCPCB solder the connectors too? Saves you the work of soldering those 40 pin headers.
 
JLCPCB don't do through-hole, so you either use SMT connectors, or you have to solder them by yourself. Then again soldering through-hole connectors will just take you a couple of seconds anyway. And we are not talking about mass production, aren't we ? ;)

Also, with these PCBs I might want to experiment with different kind of connectors.
DSC03307-s.JPGDSC03306s.JPG
My favourites are JST XH connectors, since they are cheap, compact and can take AWG22.

Another option would be to not use connectors at all and instead directly solder the wires to the PCB.
 
P.S.: For the DIP switches: The adress pins are fall-backs anyway. The idea is to configure the node adress by software.
And of course you won't need any spares, because they'll never break ;)
 
Zurück
Oben Unten