• Hallo TT-Modellbahner, schön, dass du zu uns gefunden hast.
    Um alle Funktionen nutzen zu können, empfehlen wir dir, dich anzumelden. Denn vieles, was das Board zu bieten hat, ist ausschließlich angemeldeten Nutzern vorbehalten. Du benötigst nur eine gültige E-Mail-Adresse und schon kannst du dich registrieren.
    Deine Mailadresse wird für nichts Anderes verwendet als zur Kommunikation zwischen uns.
    Die Crew des TT-Boardes

Digital HL / Fahrstraßen Controller für XpressNet

latin

Foriker
Beiträge
108
Reaktionen
73 4
Ort
Chemnitz
Hi zusammen,

nachdem ich hier die meisten Zeit eher der stille Mitleser war, dachte ich mir, ich nehme euch mal mit in mein neues kleines Projekt im Bereich digitale Bahn.

Vorgeschichte

Meine eigene Anlage besteht praktisch nur aus einem kleinen Endbahnhof und einer Abstellung. Steuerung erfolgt vollständig digital, die Weichen der Abstellung sind der Einfachhalt halber handbedient (Kuehn-Weichen mit Feder).
Zur Bedienung stehen eine Multimaus und die z21 App zur Verfügung. Auf letzterer habe ich Fahrstraßen eingerichtet. Das ist auf der einen Seite echt komfortabel, aber auf dem Bildschirm des iPhone geht es eng zu und so muss man zumindest ein bisschen zielen, wenn man die richtige Fahrstraße erwischen will. Das kann nerven, zumal ich im Kontrast dazu die Multimaus überwiegend blind bedienen kann. Und man hängt halt noch mehr am Telefon.
Dieses Jahr wird die Abstellung optimiert und auf Tillig-Gleis umgestellt und mit Weichenantrieben versehen. Jetzt stand ich vor einem Problem: alle Weichen einzeln schalten ist umständlich, in der App ist kein Platz mehr und PC-Steuerung kommt nicht in Frage. Ideal wäre ein Gerät, mit dem man komfortabel Fahrstraßen steuern kann, auch füe die Anlage an sich. Nur leider gibt es da nichts zu kaufen.

Zusätzlich betreue ich noch eine weitere Anlage, die wir letztes Jahr von den recht rustikalen Siba-Signalen auf die schicken HL-Signale von Erbert umgerüstet haben. Deren Funktionsumfang war mit der alten analogen Steuerung nicht sinnvoll nutzbar, also wurden diese Signale auf digitale Steuerung umgestellt. Zum Einsatz kommen hier die HL-Decoder von Sven Brandt (https://www.digital-bahn.de/bau_led/led_signal_005.htm) und eine Multimaus.
In der Praxis zeigte aber auch dieses System Schwächen: für die meisten Signalbebriffe sind zwei Schaltbefehle notwendig. Man ist also die meiste Zeit nur am Tippen, anstatt zu fahren. Komfortabler wäre es, könnte man einfach das Signal und den zugehörigen Signalbegriff direkt auswählen. Aber auch da fand ich keine fertige Lösung.

Die Lösungsidee.

Was es nicht zu kaufen gibt, wird selber gebaut. Momentan ist eh Lockdown, also los geht es.

Das Konzept ist einfach: eine Platine, mit der man je nach Bestückung und Firmware entweder Fahrstraßen oder Signale steuern kann. Auswahl des Signals/ des Signalbildes/ der Fahrstraße erfolgt über einen Endlosdrehregler, Anschluss an die Zentrale erfolgt über XpressNet.
Herzstück wird ein Arduino Uno Every: klein, günstig, große Community und ich habe früher bereits mit ATmega Mikrocontrollern gearbeitet.

Die Schaltung

upload_2021-1-19_21-56-10.png
Die Schaltung ist jetzt nicht übermäßig innovativ, wir bauen aber auch keine Rakete. Von links nach rechts:

  • 2 7-Segment-Anzeigen für die gewählte Fahrestraße bzw. Signal. Beide Elemente teilen sich die gleiche Ansteuerung, der Mikrocontroller schaltet hochfrequent mittels Transistor zwischen ihnen um.
  • Der Arduino selbst. Praktischerweise ist der Spannungsregler gleich integriert, aus den 12V vom Xpressnet werden 5V.
  • Oben befindet sich der Teil, der abhängig von der gewünschten Funktion anders bestückt wird. Für die Fahrstraßen werden an die Pinleiste beleuchtete Taster angeschlossen, für die Signale die LEDs bestückt (na, wer sieht schon das Ra12?).
  • Unten befinden sich XpressNet-Anschluss und Stromversorgung. Die ganzen Widerstände in der Signalleitung werden nur bei Bedarf bestückt/ gesteckt. Per Jumper kann gewählt werden, ob die Stromversorgung via XpressNet erfolgt.
Die Schaltung hatte auch eine Inspiration: http://pgahtow.de/wiki/index.php?title=XpressNet. Der zugehörigen XpressNet-Library werde ich auf jeden Fall auch eine Chance geben.

Das Layout

upload_2021-1-19_22-7-41.png
Da mir etwas die Erfahrung fehlte, mit welchen Strukturgrößen und Abständen man in die Fertigung gehen kann, ist das Layout eher konservativ ausgefallen. Hier könnte man mit SMD-Bauteilen noch viel Platz sparen. Aber als Prototyp soll das genügen.

Die Platine

upload_2021-1-19_22-12-38.png

Ich bin positiv überrascht. Bauteile sind auch schon bestellt und sollten die Tage kommen.

Ich habe übrigens noch 5 Platinen übrig. Also falls jemand Lust hat mit zu basteln, ließe sich da was machen.
 
Die Bauteile sind angekommen, es wurde also Zeit den ersten Prototypen zu löten. Und so sieht das Ergebnis aus:
IMG_20210123_095442.jpg

Kinderkrankheiten

Nach dem Zusammenlöten folgt immer der spannendste Teil: die Platine an die Stromversorgung anstecken und rätseln, warum sie nicht funktioniert.
Also voller Vorfreude den XpressNet-Stecker in eine der beiden Buchsen gesteckt und es passierte....nichts. Die Fehlerursache war schnell gefunden: als ich die Platine entwarf war ich der Meinung, dass in die Westernbuchsen der Stecker mit der Rastnase nach oben gesteckt wird (alte Gewohnheit von LAN-Buchsen). Tatsächlich zeigt die Nase aber nach unten, entsprechend sind alle Kontakte um 180 Grad gedreht und falsch verdrahtet.
Merke: die paar Cent für einen Verpolungsschutz machen sich schnell bezahlt. :rolleyes:

Das ist für die weitere Entwicklung aber gar kein großes Hindernis, da XpressNet auch als Schraubklemme verfügbar ist. Deshalb ist oben auf dem Bild auch das LA152 mit zu sehen. Die Tage erstelle ich erstmal eine erste Firmware, mit der man die restliche Hardware auf Funktion prüfen kann.

Da ich also die Platine eh nochmal korrigieren muss, werde ich gleich noch ein paar weitere kleine Schwächen beheben:
  • die Buchsenleiste unten links entfällt aus Platzgründen. Die Taster für die Fahrstraßensteuerung werden stattdessen einfach dort angeschlossen, wo in der Signalversion die LEDs sind
  • die LEDs für das Ra12 sind aktuell in Reihe geschaltet. Das ist ungünstig, weil die Versorgungsspannung 5V beträgt, eine weiße LED jedoch mindestens 3V Spannung benötigt. Deshalb hat der Prototyp auch gelbe LEDs. Die LEDs müssen parallel geschaltet werden.
  • Für den Anschluss von Drehencodern gibt es einen quasi-Standard für Arduino. Das ist praktisch, weil man sie so gleich fertig auf Platine kaufen kann. Das war mir damals beim Schaltungsentwurf nicht bewusst, deshalb ist der aktuelle Anschluss damit nicht kompatibel.
An die Interessenten an einer Platine

Stand jetzt gibt es schon zwei Interessenten, was mich natürlich erstmal freut. So eine Entwicklung ist umso sinnvoller, je mehr Leute sie nutzen. Es kam die Frage nach den Kosten auf, da mich die Platinen selber nichts zusätzlich kosten (ich kann sie eh nur im 10er Pack ordern) reicht es, wenn ihr mir einen entsprechend frankierten Rückumschlag zusendet.

Bis es soweit ist, wird es aber noch ein paar Wochen dauern: eh ich die neue Version fertigen lasse, muss der Funktionstest des Prototyps abgeschlossen sein. Der Versand zu mir dauert dann nochmal ein Stück, wenn man nicht für die Expresszustellung das 4 fache des Warenwerts bezahlen will. In Zwischenzeit kann ich schon mit der Firmware beginnen.
 
Sehr interessant. Allerdings frage ich mich, warum du das ganze nicht erst einmal auf einem Steckboard zusammen gesteckt hast. Bevor man "endgültige" Platinen bestellt. Mache ich immer so. Ist eine Lehre aus einem eigenen Fehler, den ich vor Jahren selbst gemacht habe. Damals ein ganze Serie von 40 Platinen--> nicht nutzbar= Schrott und entsprechendes "Lehrgeld" :-(
Wenn ich das richtig verstehe, muss man sich dann bei deiner Version 2-stellige Nummern für Fahrstraßen merken? Ist aber bei vielen dann auch nicht sehr übersichtlich. Und fremde (Gäste) können dann sicher nicht mit um.
Gruß Holger
 
Hallo latin,

interessantes Vorhaben. Den "Leidensdruck" kenne ich gut. Und da ich auch etwas mehr "elektroniklastig veranlagt" bin, bitte ich, mir ein paar Hinweise zu erlauben.
Schaltplan:
- Das (erstellte) Symbol für den Every enthält meiner Meinung nach einen kleinen Fehler. Pin 17 sollte RX1 und nicht RX0 sein.
- Den 7-Segment-Decoder IC4 könnte man sich sparen. Die paar mA für moderne Anzeigen kann der AVR auch liefern und genügend Pins sind ja noch frei. So wäre man bei den anzeigbaren Zeichen wesentlich flexibler.
- Die Dimensionierung der Blockkondensatoren (C2=1µ, C3=10µ) erschließt sich mir nicht wirklich.
- So richtig übersichtlich finde ich den Schaltplan nicht, aber das kann natürlich auch Geschmackssache sein.
Layout:
- Die Vorgaben für die Strukturen findet man üblicherweise bei den Leiterplattenherstellern.
- Die Leitungen mit VCC sollte man etwas breiter gestallten. Hier fließt ja auch mehr (der Summen-) Strom.
- Viele der Durchkotaktierungen könnte man sich sparen, indem man die Leitungen auf der Oberseite direkt z.B. an die Steckverbinder anbindet. Die müssen zwar von unten verlötet, aber nicht angeschlossen werden (bei industriel gefertigten Leiterplatten).
- Die Blockkondensatoren sollten besser, wirksam angeschlossen werden. Also von der VCC-Leitung erst zum Kondensator und von dort zum IC-Pin. Das gleich gilt natürlich auch für GND.
- Die Basiswidertsände für die Multiplex-Transistoren sind recht hochohmig. Nicht, dass es "Geisteranzeigen" gibt, weil die Transistoren nicht schnell genug abschalten?

Das Bedienkonzept habe ich noch nicht ganz verstanden. Ich hoffe, es ist bekannt, dass es über XpressNet (meines Wissens nach) NICHT möglich ist, eine Fahrstraße zu schalten (wie in der App). Natürlich kann man per XpressNet mehrere Weichenstellbefehle nacheinander absetz, aber das bedeutet, dass man die gewünschten Weichenstarßen auch in diesem Steuergerät anlegen (was wahrscheinlich recht aufwändig werden wird). Auch die Steuerung der HL-Signale (über mehrere Zubehörschaltbefehle) wird wohl so nicht funktionieren (ohne die Konfiguration hierfür im Gerät verfügbar zu ahben). Ich lasse mich aber auch gern vom Gegenteil überzeugen ;-)))

Jörg
 
Ideal wäre ein Gerät, mit dem man komfortabel Fahrstraßen steuern kann, auch füe die Anlage an sich. Nur leider gibt es da nichts zu kaufen.

Das ist so nicht ganz richtig. Rocrail zum Beispiel läuft auch auf dem Handy. Eine Himbeere mit Draufgrabschbildschirm geht noch besser. Damit lassen sich Fahrstraßen sehr komfortabel mit Start- und Zieltasten stellen. Daß das auch intuitiv bedienbar ist, hat sich mittlerweile bewiesen. Jeder, auch kleine Kinder haben mit ihren Zügen ohne jede Einweisung durch meinen Bahnhof "gefunden".

für die meisten Signalbebriffe sind zwei Schaltbefehle notwendig. Man ist also die meiste Zeit nur am Tippen, anstatt zu fahren.

Mit Qdecodern zur Ansteuerung der Signale ist das leicht lösbar. Der Decoder bekommt nur den Befehl "Fahrt" oder "Halt" und entscheidet dann selbst, welchen Signalbegriff er ausgibt.

Es ist zweifelsohne ein interessantes Projekt. Aber für "Fremdbediener", wie Holger schon schrieb, sicherlich nicht ganz einfach.

Gruß Jens
 
@TTbauer :
Natürlich war so das Risko etwas größer, dass die erste Ladung Platinen in die Tonne wandert. Aber das ganze erst auf Steckbrett zu bauen ist auch nicht ohne Zusatzkosten, in wenn auch in dem Fall nicht Geld, sondern Zeit.
Ein Steckbrettaufbau hätte den Fehler mit den Westernbuchsen auch nicht verhindert, denn diese passen vom Pinout her gar nicht drauf.

Das mit den 2-stelligen Nummern für Fahrstraßen stimmt, allerdings teilen die sich in drei Gruppen auf (das hätte ich vielleicht erwähnen sollen :oops:), was das ganze etwas übersichtlicher machen wird. Mein Gedanke dahinter war folgender: in diesem Formfaktor sind große 7-Segment Anzeigen besser lesbar als ein Display. Bei der eigenen Anlage wird man die bis zu einer gewissen Größe schnell auswendig kennen. Gäste kennen die Fahrstraßen eh nicht, denen kann man auch einfach einen Zettel mit den Nummern und der jeweiligen Erklärung der Fahrstraße geben.
Aber du hast schon recht, das ist so keine Lösung, die für größere Anlagen gut skaliert. Würde man einen reinen Fahrstraßencontroller bauen, sähe das Bedienkonzept wohl auch etwas anders aus. Tatsächlich war das hier primär als Steuerung für die HL-Signale gedacht (für die braucht man wirklich kein Display), die Fahrstraßensteuerung eher die Zweitverwertung.

@JörgP :
- Tatsache, das stimmt. Ist zum Glück nicht schlimm.
- Du hast Recht, theoretisch sind die 3 Pins, die man bei direkter Ansteuerung bräuchte noch frei. D13 ist gleichzeitig LED_BUILTIN, das finde ich für Debugzwecke ganz praktisch. Deshalb wollte ich den Pin gerne freihalten. Dann reicht es schon nicht mehr. Aber da wäre im Zweifelsfall noch Potential drin, bisschen Platz und Geld zu sparen.
- Die Dimensionierung war tatsächlich eher geraten. C3 ist deshalb relativ hoch dimensioniert, weil ja permanent zwischen den beiden 7-Segmentanzeigen hin- und hergeschalten wird. Dieser Übergang verläuft nicht perfekt nahtlos, zusätzlich werden beide Anzeigen oftmals unterschiedliche Anzahl an LEDs leuchten haben. Hier ist also etwas Ripple zu erwarten.
- Das ist wirklich eher eine Stilfrage. Früher mochte ich es gar nicht, wenn überall Leitungen in Labels enden, heute bin ich da etwas toleranter.
- Korrekt. Damals wusste ich noch nicht, welchen Fertiger ich nehmen und es war ja kein Druck da, Strukturen möglichst klein zu machen. So könnte man die Platine theoretisch sogar zuhause ätzen.
- Guter Punkt, wird gemacht.
- Hier kommt wieder der Punkt ins Spiel, dass man beim Ätzen zuhause für gewöhnlich nicht durchkontaktieren kann. Ob das jemals von Relevanz sein wird ist fraglich, aber warum irgendwo für zusätzliche Einschränkungen sorgen, wenn man keinen relevanten Vorteil hat? Auf der linken Seite fallen nochmal viele Vias weg, wenn die Buchsenleiste entfällt.
- Guter Punkt, wird gemacht.
- Eigentlich wären hier MOSFETs am sinnvollsten, weil dann gar kein dauerhafter Steuerstrom fließen muss. Aber die sind halt empfindlicher. Ob es Geisteranzeigen gibt, wird der Prototyp zeigen. Falls ja, ändere ich das natürlich nochmal.

Die Fahrstraßen und Signalbilder müssen auf dem Arduino gespeichert werden, das ist richtig. Deshalb wird es für die Fahrstraßenversion wohl sogar gar kein Arduino Nano Every, sondern der "normale" Arduino Nano werden, weil der mehr EEPROM hat.
Das ist aber leichter einzustellen, als du es dir wahrscheinlich vorstellst: Die Fahrstraßen und Signalbilder können ganz bequem am PC editiert werden (aktuell plane ich da json), der Arduino hat zum Aufspielen ja einen USB-Anschluss. Die Umwandlung von json in Binärdaten erfolgt per Script.

@jf- : Bitte nochmal das Kapitel "Vorgeschichte" genau lesen. Per Touchscreen/ Handy Fahrstraßen steuern kann ich jetzt schon, das ist nicht das Problem. PC-Steuerung steht auch nicht zur Debatte. Es geht darum, die Modellbahn über rein haptische Bedienelemente zu steuern (da ist die Kombination aus Drehencoder + 7 Segmentanzeige schon grenzwertig, aber viel Funktion geht halt nicht mit nur Tastern/ Schaltern), einem PC habe ich schon auf Arbeit die ganze Zeit vor der Nase. Das muss ich zum Abschalten mit der Modellbahn nicht auch noch haben.
Rocrail habe ich mir aber tatsächlich mal angeschaut, an sich feine Software.

Woher weiß der QDecoder denn, über welche Weichenstraße es geht (aka "Wie schnell darf im nächsten Block gefahren werden") und welches Signal als nächstes kommt (aka "Was muss im Vorsignal angezeigt werden")? Für Blocksignale ist das trivial, das können die Decoder von Sven Brandt auch (man beachte aber den Preisunterschied!). Aber die meisten unserer Signale sind Ausfahrtsignale, da müsste man die konkrete Fahrstraße kennen um das korrekte Signalbild zu ermitteln.
 
Woher weiß der QDecoder denn, über welche Weichenstraße es geht (aka "Wie schnell darf im nächsten Block gefahren werden") und welches Signal als nächstes kommt (aka "Was muss im Vorsignal angezeigt werden")? Für Blocksignale ist das trivial, das können die Decoder von Sven Brandt auch (man beachte aber den Preisunterschied!). Aber die meisten unserer Signale sind Ausfahrtsignale, da müsste man die konkrete Fahrstraße kennen um das korrekte Signalbild zu ermitteln.

Indem man den Decoder sagt, welche Schaltbefehle er "mithören" soll, in dem Fall die Schaltbefehle für die in der Ausfahrt befindlichen Weichen sowie die Schaltbefehle für das nächste Hauptsignal im Fahrweg. Das funktioniert tatsächlich.

Gruß Jens
 
Das ist ja richtig edel. Für meine Anlage wäre das tatsächlich eine denkbare Lösung, nur der Preis schreckt mich etwas ab.

Auf der anderen Anlage würde man allerdings nicht weit kommen, denn es werden nur die Signale digital geschaltet, die Weichen hingegen analog. Das wird sich wohl auch nie ändern, die Kosten für eine Umrüstung wären jenseits von gut und böse.
 
Klar, billig sind die nicht, dafür aber definitiv sehr preiswert! Auf meinem Bahnhof steuert jeder dieser Decoder zwei Signale. Bei einigen dieser Decoder blieben dabei noch Ressourcen übrig, welche genutzt wurden, um noch ein oder zwei Rangiersignale mit zu steuern. Damit halbiert sich im Prinzip der Preis.

Die andere Anlage wäre ebenfalls kein Problem. Der Decoder kann auch außerhalb eines Digitalsystems betrieben werden, braucht dann nur zur Programmierung eine Zentrale. Nimmt man z.B. den Decoder mit 16 Ausgängen, dann kann man beispielsweise definieren, daß 10 der 16 Anschlüsse als Eingänge dienen sollen. Dort lassen sich dann Schalter, Taster oder eben die Information über die Lage einer Weiche anschließen.
Ebenso geht ein Mischbetrieb. Bei mir kommen die Befehle für Weichen und Signale digital. Ein Belegtmelder hinter dem Signal, welcher dem Haltfall nach Vorbeifahrt dient, wird dagegen direkt eingelesen. Ebenso die Information über das nächste Signal, welches ja auf dem Modul eines anderen Modulisten steht.

Für Deine Anwendung sicher nicht relevant, kann der Decoder sogar zusätzlich noch auf Lokbefehle von bis zu vier Adressen gleichzeitig hören. Das alles auch im Mischbetrieb. Diese Möglichkeit habe ich im LVT von Kress ziemlich ausgereizt.

Und nein - ich bekomme keine Provision, sondern bin lediglich wirklich echt begeistert von den Dingern.

Gruß Jens
 
Hallo latin,
wenn die Weichen nur analog geschaltet werden, kann der Qdecoder trotzdem genutzt werden. Das DCC-System prüft die Anwesenheit von Decodern nicht. Einfach einen Adressbereich für die vorhandenen Weichen bestimmen und jeder Weiche eine Adresse zuweisen. Dann die entsprechenden Fahrstraßen programmieren und schon kann die Funktionalität genutzt werden.

Gruß
ruhri
 
Rocrail zum Beispiel läuft auch auf dem Handy.
Aber nur auf Windowphone oder was mit Linux, auf Android läuft nut "Rocview" (hier Androc genannt).

nicht ohne Zusatzkosten, in wenn auch in dem Fall nicht Geld, sondern Zeit.
Geld auch, weil du sämtliche Bauteile als Pin Variante brauchst. Allerdings kannst du die für das nächste Projekt weiter verwenden.

sondern der "normale" Arduino Nano werden, weil der mehr EEPROM hat.
Schon mal den ESP angeschaut? Den könntest du auch über ein (WLAN-) Webfrontend parametrisieren. Oder visualisieren, falls mal Gäste kommen.
 
Wow, da hat man ja beim QDecoder wirklich alles reingepackt was irgendwie möglich ist :eek:
Auf der Anlage stehen halt 15 HL-Signale, ob der Decoder 10€ oder 60€ kostet, macht dann doch einen ziemlichen Unterschied.
Aber gut, die Decoder auf der Anlage sind schon alle eingebaut, daran wird sich nichts.

@Per Webfrontend? Klar, technisch geht das. Aber wie oft nutzt man das denn, das Definieren von Signalen und Fahrstraßen macht man idealerweise einmal und dann erst wieder wenn was umgebaut wurde (okay, also doch etwas häufiger :D). Für die Gäste noch eine Steuerungsoberfläche bauen wäre wie das Rad neu zu erfinden. Das können Rocrail & co. oder die z21 App wohl besser als ich es jemals programmieren könnte.

Erstmal mit klar abgesteckten Features ein Projekt starten, das auch schaffbar ist, ansonsten bleibt es auf halber Strecke liegen, weil man keine Zeit oder Lust mehr hat. Später kann man ja immer noch darauf aufbauend eine Version 2 mit Weboberfläche, OLED-Display und Sprachsteuerung bauen :)
 
Zuletzt bearbeitet:
In kleinen Schritten geht es weiter....

Kinderkrankheiten Part 2

Die erste Inbetriebnahme verlief alles andere als gut, außer dem Arduino leuchtete gar nichts, so wie es halt immer ist. Die Ursache war schnell gefunden:
  • Die LEDs links für die Signalbildanzeige waren alle falsch herum eingelötet.
  • Der Treiber-IC für die 7-Segment-Anzeige ist im Layout auf der Rückseite, somit auf dem Prototypen falsch verdrahtet.
Also die üblichen Flüchtigkeitsfehler. Nach deren Korrektur habe ich schnell für den Arduino ein kleines Testprogramm erstellt, welches durch alle Signalbilder und Anzeigen durchblättert:
IMG_20210204_195913.jpg

Die von @JörgP befürchteten Geisteranzeigen lassen sich glücklicherweise nicht beobachten.
An und für sich war das bis jetzt keine Raketenwissenschaft: es leuchten ein paar LEDs und eine 7 Segmentanzeige. Aber ich merke schon, dass ich seit meinem Studium keine Schaltungen und Platinen mehr entwickelt habe, man vergisst die kleinen Dinge.

Neue Schaltung, Neues Layout

Auf Basis der bisherigen Erfahrungen habe ich eine Revision 1.1 von Schaltung und Platine entworfen:

upload_2021-2-4_20-10-18.png

Neu sind die Pull-Up Widerstände für die Taster in der Fahrstraßenversion und der geänderte Anschluss für den Drehencoder. Mir ist bewusst, dass die Pull-Up Widerstände eigentlich nicht notwendig wären, weil man auch die internen des ATmegas nutzen könnte. Aber so muss man nicht erst die passende Firmware laden, um an den Anschlüssen sinnvoll messen zu können. Von sieben zusätzlichen Widerständen wird auch keiner arm.
Außerdem werden jetzt auch Pin 1 & 6 des XpressNet Anschlusses durchgeleitet.

upload_2021-2-4_20-13-17.png

Ich habe mir nochmal den Hinweis von @JörgP bezüglich der überflüssigen Vias durch den Kopf gehen lassen. Er hat ja recht, und es ist heutzutage so leicht an durchkontaktierte Platinen zu kommen, dass man sich da auch keine Sorgen mehr machen muss.
Der auf der falschen Seite platzierte Treiber-IC auf dem Prototypen hatte mich zusätzlich noch auf die Idee gebracht, dass es doch gar nicht verkehrt wäre, generell mehr Bauteile auf die Rückseite zu packen. So kann man die Platine leichter hinter eine Frontplatte schrauben. Jetzt sind nur noch die LEDs, die 7-Segement-Anzeige und der Arduino (damit man an die Debug LED und den Resettaster kommt) auf der Vorderseite.
Die Platine ist auch insgesamt ca. 1,5 cm schmaler geworden.

Sonstiges

Ursprünglich wollte ich für die Fahrstraßenversion den Arduino Nano verwenden, da dieser über mehr EEPROM-Speicher verfügt. Das ist mit der aktuellen Schaltung bei Speisung über XpressNet jedoch gar nicht so leicht: während der Arduino Nano Every seine 5 V Spannungsversorgung über einen Step-Regler erzeugt, nutzt der Arduino Nano einen Linearregler.
Der Arduino Nano würde also am XpressNet ca. doppelt so viel Strom verbrauchen und ich bin mir nicht sicher, ob der Linearregler das alles thermisch überhaupt schaffen würde.
Eine denkbare Lösung wäre, die Platine nicht über XpressNet, sondern über die Klemmen für separate Stromversorgung mit 7-8 V zu speisen. Dann ist die Differenzspannung und somit die Wärmeentwicklung geringer. Das möchte ich für mich allerdings vermeiden, es ist halt zusätzlicher Aufwand.
Eine neue Herausforderung wird also, möglichst effizient Fahrstraßen in 256 Byte EEPROM zu speichern. Ich habe da schon einen Plan.....
Es ist aber überhaupt kein Problem, die Software noch auf den Arduino Nano zu portieren, damit auch die Leute mit mehr oder größeren Fahrstraßen glücklich sind.

Leider scheint bei Reichelt aktuell Land unter zu sein, ich warte noch auf meine neue Lieferung mit den Bauteilen, dann geht es weiter. Die neuen Platinen sind schon da.
 
Hallo Latin,

Ja, ich werde auch stutzig, wenn etwas gleich funktioniert. Aber die meisten Fehler macht man nur ein mal. ;-))

Die externen PullUps haben auch eine „technische“ Berechtigung, denn die internen sind doch recht hochohmig. Manche Taster brauchen schon etwas Strom, damit sie ordentlich schalten (Mindeststrom). Und ein paar SMD-Widerstände machen einen nicht arm.

Wenn der interne EEPROM-Speicher des Arduino zu klein ist (bei deinem Exemplar ist es wohl streng genommen auch kein EEPROM) und man noch 2 Pins zur Verfügung hat, kann man natürlich auch mit einem billigen, externen EEPROM arbeiten. Die 24Cxxx oder so ähnlich gibt es bis mindestens 512kbit (also 64kByte). Der Zugriff ist zwar etwas umständlicher, aber beim Weichenstellen hat man doch Zeit. Im Idealfall nimmt man gleich die I2C-Pins des Arduino (A5 und A6 wenn ich das richtig erinnere), dann kann man das HW-TWI verwenden. Ansonsten ist I2C per Software auch keine Hexerei (erst Recht in einem so einfachen Single-Master-System). Ist vielleicht noch eine Überlegung, falls es noch geht.

Jörg
 
Stimmt, ein externer EEPROM wäre noch eine Option, die nötigen Leitungen sind noch frei. Wobei dann die Frage wäre, wie man von extern die Daten aufgespielt bekommt. Für den internen EEPROM kann man einfach avrdude nutzen.

Toolchain

Um den Quellcode zu kompilieren und auf den Arduino zu flashen, bedarf es einer Toolchain. Der auf dem Arduino Nano Every verwendete ATmega4809 ist noch verhältnismäßig neu, entsprechend darf auch der Compiler inkl. der zugehörigen Bibliotheken nicht ganz so alt sein.
Leider ist avr-gcc eher auf dem absteigenden Ast, wenn man den Foren Glauben schenken darf. Für viele Linux-Distributionen wird auch nur die steinalte Version 5.4 bereitgestellt.
Deshalb habe ich einen kleinen Trick angewandt: in der Arduino IDE ist bereits eine komplette Toolchain integriert, basierend auf avr-gcc Version 7.3 und avrdude. Diese nutze ich, indem ich die entsprechenden Programme aus der Arduino IDE Installation nutze.
Eine zusätzliche Herausforderung stellt das flashen des Arduinos dar: die Arduino IDE stellt zwar eine entsprechend eingerichtete Version von avrdude zur Verfügung, allerdings kann diese den Bootloader nicht aktivieren. Dies geschieht, indem der zugehörige COM-Port mit 1200 Baud geöffnet und wieder geschlossen wird. Da die Arduino IDE open source ist, habe ich die entsprechende Sequenz in dessen Quellcode gesucht und in python nachgebaut.
Die Toolchain basiert auf cmake und funktioniert erstmal nur unter Linux. Das wird später noch angepasst.

Hardware Rev. 1.1

Die Woche sind auch die neuen Bauteile gekommen, also habe ich einen zweiten Prototypen gebaut:

IMG_1426.jpg IMG_1427.jpg
Ein kleiner Fehler hat sich leider eingeschlichen: Die LED zu EXT4 hat keinen Anschluss, da ist im Entwurf noch ein Airwire. Der Perfektionist in mir hat sich geärgert, der Praktiker hat eine neue LED eingelötet, den einen Anschluss umgeknickt und auf den Anschluss für den Pinheader gelötet.

Gitlab

Die zu dem Projekt gehörigen Dateien sind jetzt auf gitlab verfügbar: https://gitlab.com/danielring.ch/hl-route-controller.
 
Kurzes Update:

Die Firmware für die Signalvariante nimmt langsam Züge an, gestern konnte ich bereits ein erstes Signal schalten:

Es gibt aber noch viel zu tun, die Tasterentprellung funktioniert noch nicht besonders gut, die XpressNet Kommunikation ist noch sehr rudimentär und es lassen sich noch keine Konfigurationen auf dem EEPROM speichern.

Die Signal-Variante ist bereit zum Nachbau

Mit dem obigen Test wurde zugleich der Nachweis erbracht, dass Schaltung und Platine so in Ordnung sind. Wer die Signal-Variante nachbauen möchte, kann mir eine PN schreiben, ich habe noch fünf Platinen übrig.

Für die Fahrstraßen-Variante muss noch ein ein zusätzlicher EEPROM mit auf die Platine. Es wird also noch eine Revision 1.2 geben.
 
Die Firmware nimmt langsam Gestalt an. Mit der Version 1.1 lassen sich bereits HL-Signale und zweibegriffige Signale schalten. Die Tastenentprellung wurde verbessert, hat aber noch Luft nach oben.
Die Konfiguration steht noch hart im Code, in der nächsten Version wird sie auf den EEPROM wandern. Außerdem kann man für HL-Signale nur einstellen, welche Geschwindigkeiten verfügbar sind, die entsprechenden Signalbegriffe werden dann errechnet. Das hat sich in der Praxis allerdings nicht bewährt, da vor allem bei Ausfahrsignalen unter Umständen einzelne Signalbegriffe gar nicht sinnhaft sind, man sie aber nicht abschalten kann. Das baue ich nochmal um, danach kann man jeden Signalbegriff einzeln einstellen.

Auf der Hardwareseite ist nicht so viel passiert, ich habe ein zweites Exemplar gelötet und dem ersten ein Gehäuse spendiert:

1.jpg 2.jpg
Meine Stärken liegen definitiv nicht in der Holzverarbeitung. Da wird wohl nochmal eine Alternative aus dem 3D-Drucker folgen müssen.

Und so sieht es dann auf dem Stellpult aus:
4.jpg
Stand jetzt werden so 17 HL- und 2 Hauptsignale gesteuert, Zentrale ist die Roco Multimaus.
Links oben auf dem Pult kann man gerade so zwei Reihen Kipptaster mit Beschriftung erkennen. Mit diesen lassen sich von den HL-Signalen Hp0 und Ra12 direkt schalten (via Lenz LW150). Darauf werde ich später nochmal eingehen, wenn ich euch die Einstellmöglichkeiten im Detail vorstelle.
 
Nachdem hier etwas Stille herrschte, möchte ich euch auf den neusten Stand bringen:

Mittlerweile gibt es von der Firmware eine Version 1.4:
  • vollständiger Funktionsumfang für die HL-Signal-Variante
  • es können jetzt sämtliche Signalbilder pro Signal einzeln konfiguriert werden
  • Speichern der Konfiguration auf EEPROM
  • neue Entprellung, Austausch der NoName Drehimpulsgeber durch Modelle von ALPS

Für meine eigene Anlage habe ich auch begonnen, ein Steuerpult zu bauen:
Front.jpg Back.jpg
Die Frontplatten sind aus Pappe und nur ein Provisorium (werden also noch laaange im Einsatz sein :D), rechts ist schon der Ausschnitt für die Fahrstraßenversion vorbereitet. Später werden Frontplatten aus dem 3D-Drucker zum Einsatz kommen, dann sieht auch der "Signalschirm" viel besser aus.

Nächster Schritt ist dann eine neue Revision der Platine mit zusätzlichem externen EEPROM.
 
Zurück
Oben