Hallo liebe Stummies und LocoNet-Interessierte
Der eine oder andere kennt vielleicht meinen arduinobasierten Zubehördecoder. Der hat bisher ein Interface, das auf DCC-Signale reagiert.

Nun bin ich schon darauf angesprochen worden, das es schön wäre, dem Decoder auch ein LocoNet Interface zu spendieren. Das Problem dabei ist (war ), dass die Loconet-Library von Alex Shepherd - genauso wie die MobaTools - einen 16-Bit TImer benötigen. Da es auf UNO/Nano nur einen gibt ist daher eine gleichzeitige Verwendung beider Libraries nicht möglich.
Anders ist dies bei Arduino Mega und bei Leonardo und seinen Derivaten ( Micro / pro Micro ). Hier gibt es zumindest 2 16-Bit Timer, sodass im Prinzip eine parallel Verwendung beider Libraries möglich ist. Die MobaTools sind inzwischen auch soweit ertüchtigt, dass das auch praktisch funktioniert, indem sie den Timer 3 verweden, wenn er vorhanden ist.

Ein erster Test ist auch positiv verlaufen, die Testversion reagiert direkt auf LocoNet Weichenbefehle. Als Testumgebung verwende ich einen Eigenbau-LocoBuffer, der über Rocrail oder JMRI angesprochen wird um die LocoNet-Telegramme zu erzeugen.

Nun hab ich noch das Problem der CV-Programmierung. Bei Loconet ist das Gegenstück dazu ja die SV-Programmierung. Ich habe schon herausbekommen, dass es dabei 2 Formate gibt, wobei das Format 1 für Neuentwicklungen nicht mehr verwendet werden soll. Die LocoNet Library unterstützt auch direkt nur das Format 2, Format 1 muss selbst implementiert werden ( gibt es aber bereits in Form eines Arduino LocoIO-Sketches).

Format-1 Telegramme kann ich per Rocrail erzeugen. Ich habe aber noch nichts gefunden, wie ich einen Decoder, der Format2 SV-Programmierung erwartet, ansprechen kann.

Was meinen die LocoNet Experten dazu. Gibt es Interesse an einem entsprechenden Zubehördecoder, und wie sollte die SV-Programmierung realisert werden?
Als HW-Plattform ist dabei auf jeden Fall nur Arduino Mega, Leonardo, Micro oder pro Micro möglich.

Hallo Franz-Peter,

wie du weißt, fände ich ein Loconet-Interface toll.

Ich zitiere mal mein an anderer Stelle bereits geäußertes Plädoyer für eine optionale Loconet-Schnittstelle:

- DCC ist zunächst für die Steuerung der Locomotiven gedacht. Schon für Zubehör sollte ein getrennter 'Kanal' benutzt werden, um DCC nicht zu überlasten.
- DCC hat zunächst keinen Rückkanal, dh. CVs kann man nicht im Betrieb auslesen.
- Loconet ist ein echter Peer-to-Peer-Bus, eine Zentrale ist nicht nötig
- ein Computerinterface für Loconet kann auch von Laien auf Arduino-Basis für etwa 10 Euro erstellt werden
https://klaus.merkert.info/eisenbahn/di ... index.html
- Loconet wird in den Arduino-Bibliotheken gut unterstützt,
http://mrrwa.org/loconet-interface/
- insbesondere gibt es Bibliotheks-Routinen zum Lesen und Schreiben sogenannter SVs, die die Rolle der CVs einnehmen, damit können Decoder im eingebauten Zustand gelesen und beschrieben werden
- Loconet darf für den privaten Gebrauch verwendet werden
http://www.digitrax.com/static/apps/cms/...onaledition.pdf

Hier sind die neuen Format 2 'SV-Befehle' beschrieben:
http://embeddedloconet.sourceforge.net/S...ages_v13_PE.pdf

Zur Programmierung sollte ein plattformunabhängiges freies Programm geschrieben werden. Hier würde ich, soweit ich das kann, mithelfen.

Viele Grüße

Klaus

Hallo Franz-Peter,

kann es sein, dass JMRI in DecoderPro SVs in Format 2 unterstützt?
http://jmri.org/help/en/html/hardware/lo...ssing.shtml#SVs

Viele Grüße

Klaus

Hallo Franz-Peter,

Link zu Format2-SVs in JMRI

https://sourceforge.net/p/jmri/mailman/message/34475681/

Viele Grüße

Klaus

Zitat

---

- DCC hat zunächst keinen Rückkanal, dh. CVs kann man nicht im Betrieb auslesen.

---

RailCom?


Klaus (der andere Klaus)

Zitat

---

kann es sein, dass JMRI in DecoderPro SVs in Format 2 unterstützt?

---

Hallo Klaus (nicht der andere ),
ja, das hatte ich auch schon gelesen, aber bisher nicht geschafft, das zum Laufen zu bringen. Dein 2. Link im Post #4 brachte den entscheidenden Tip. Jetzt erzeugt JMRI SV-Telegramme im Format 2, die die LocoNet Lib auch als solche erkennt.
Danke!

Hallo Klaus ( der andere Klaus ),
da es hier nicht um Lok-Decoder, sondern um Zubehördecoder geht, wäre RailCom m.M. nach etwas 'oversized'. Da ist LocoNet definitiv die einfachere Variante.

Hallo Franz-Peter,

könntest stichwortartig umreissen, wie du JMRI/DecoderPro zu Format2-SVs überreden konntest? Insbesondere scheint da eine xml-Datei eine Rolle zu spielen.

Viele Grüße

Klaus

Zitat

---

Insbesondere scheint da eine xml-Datei eine Rolle zu spielen.

---

Hallo Klaus,
ja, xml-Dateien spielen bei JMRI generell eine große Rolle. Damit wird fast alles gesteuert.
Auch die Eigenschaften eines angeschlossenen Decoders werden in einer xml-Datei beschrieben. Sehr viele solcher Beschreibungsdateien ( vor allem für Lok-Decoder ) sind auch dabei. Inzwischen habe ich auch entdeckt, dass auch für Loconet-SV-Decoder eine generische Decoderbeschreibung dabei ist. Wenn Du eine neue 'Lok' in DecoderPro einrichtest, findest Du dies in der Auswahlliste unter "Public-domain and DIY -> LNSV2-using boards -> Basic definition .
Wichtig ist dann noch, dass beim ProgrammiererTyp 'Betriebsgleis' ausgewählt ist. Und natürlich muss in den Voreinstellungen als Systemverbindung der LocoBuffer eingestellt sein.
Damit erzeugt er bei mir jetzt beim Schreiben/Lesen ( geht bei dem generischen Decoder nur in dem Reiter 'CV-Tabelle ) jetzt Format-2 Telegramme, die ich mit dem Beispielprogramm LNSVTest.ino aus der LocoNet Lib auch verarbeiten kann.

Grundsätzlich kann man die xml-Datei auch sehr flexibel an den eigenen Decoder anpassen. Was da möglich ist, sieht man bei den verschiedenen mitgelieferten Decoder-Dateien.
Da habe ich aber noch so meine Probleme - das ist schon sehr komplex und das xml-Format ist nicht sehr übersichtlich. Manchmal bin ich eigentlich sicher es genauso zu machen wie im Beispiel - aber es funktioniert trotzdem einfach nicht.

Ich wäre an so einem LocoNet Decoder auch interessiert.

Die Frage ist, was er können soll

Aus der Uhlenbrockwelt kommend, kenne ich die SVs nur als LNCVs, aber das ist ja auch egal.

Prinzipiell wäre mir eine Programmierbarkeit über das Uhlenbrock Interface wichtig (also sowohl IB1 als auch IB2).

Hallo Klaus,
inzwischen bin ich etwas weiter, und habe erste Ansätze für eine Maske zur Programmierung des Decoders ( wobei PomLow/PomHigh bei LocoNet eigentlich keinen Sinn macht - aber ist ja auch nurmal ein erster Versuch so eine Maske in JMRI zu erstellen):

Das kann natürlich nur eine generische Maske sein, da die Konfiguration ja nicht bekannt ist ( wobei man natürlich für einen speziellen Decoder das XML-File auch entsprechend anpassen könnte ).
Das Erstellen der XML-Datei ist aber schon ziemlich friemelig - und die Fehlermeldungen bei Syntaxfehlern absolut unbrauchbar - weder Zeilennummer noch Text geben einen Hinweis auf das tatsächliche Problem.
Bisher habe ich das alles auch nur mit dem SV-Beispiel der Loconet - Lib getestet. Die entsprechenden Programmänderungen im Decoder fehlen noch. Mein Ziel ist noch, das bei einer Source zu belassen, und nur mit einem #define im Konfig-File zwischen Loconet- und DCC Schnittstelle umschalten zu können. Mal sehen, ob ich das hinbekomme.

@Derrick23:
Es freut mich natürlich das es noch mehr Interessenten an einer Erweiterung mit Loconet-Schnittstelle gibt.

Zitat

---

Die Frage ist, was er können soll

---

Naja, die grundsätzlichen Fähigkeiten des Decoders werden sich von der DCC-Variante nicht unterscheiden. Lediglich die Schnittstelle, das Ansprechen über DCC oder Loconet-Kommandos wird unterschiedlich sein. Für die Funktionalität sind es letzendlich immer Weichenbefehle.

Zitat

---

Prinzipiell wäre mir eine Programmierbarkeit über das Uhlenbrock Interface wichtig (also sowohl IB1 als auch IB2).

---

Da ich keine Uhlenbrock-Zentrale habe, kann ich sowas nicht testen. Ich weis auch bisher noch nicht, ob die LocoNet-Lib das LNCV-Format unterstützt.
Andererseits steht die CV-Programmierbarkeit des Decoders eigentlich auch nicht im Vordergrund. Die Eigenschaften stellt man mit der Arduino-IDE in einem Konfigurationsfile ein. Zwar kann man eine ganze Reihe Parameter dann auch später per CV/SV ändern, aber eigentlich geht es auch ohne.

Ohje,

ich versuche grade den 3D Drucker wieder ans Rennen zu kriegen, aber mit dem Arduino Code kann ich so gar nichts anfangen, ich stehe aber auch mit Java auf Kriegsfuß.

Ich warte ja eigentlich drauf, das jemand mal JMRI in C neu schreibt, dann wäre es doch wohl bedeutend schneller ...

Ich kann gerne versuchen, was mit der Intellibox so geht per LNCV.

Hallo Franz-Peter,

ich bin begeistert darüber, wie engagiert du die Sache angehst. Es ist toll, dass sich die SV-Programmierung, die eine Hürde schien, so gut entwickelt.

Ein Arduino-Micro liegt bei mir schon rum und wartet auf seinen ersten Einsatz.

Für die Hardware des Interfaces vertraue ich stark dem Design des Fremo-LN-Shields von Dirkjan Kaper http://nh-finescale.nl/fremo/dcc/fremo-l...moLNShield.html. Da haben schon einige Fachleute darüber geschaut.

Die Programmierbarkeit über IB1 und IB2 halte ich, sorry Derrick23, für nicht dringlich. Ein freies Plattform-übergreifendes Programm zur Programmierung, und das zeichnet sich mit JMRI ab, scheint hier so viel komfortabler, dass auch Intellibox-Besitzer umschwenken werden.

Mir scheint eine Aufspaltung in Computer-Interface, Servo-Ansteuerung, Lichtsignalansteuerung, Multi-IO mit optionalem 2803 sinnvoll. Dann können kompakte übersichtliche Platinen entwickelt werden und die Konfiguration über die SVs bleibt übersichtlich. Das ist natürlich nur ein Diskussionsbeitrag.

Viele Grüße

Klaus

Ich kann auch mit JMRI per LocoIO programmieren, was mich stört ist, dass die Software selbst auf einem DualCore unter Linux gelinde gesagt, lahm ist.
Das ist aber auch genau der Grund, warum ich lieber per LNCV programmiere, als per JMRI es dauert einfach viel länger.
Das die LNCV Geschichte grade auch bei Uhlenbrock "spärlich" dokumentiert ist, steht auch auf einem ganz anderen Blatt.

Demgegenüber steht die Funktionalität von JMRI natürlich auf einem ganz anderen Niveau.
Ich warte jetzt erstmal auf den Rückmeldedecoder von Digikeijs und die Zusammenarbeit mit der IB...

Zitat

---

ich bin begeistert darüber, wie engagiert du die Sache angehst.

---

Da wirkt wohl das 'Neugier-Gen'. Es interessiert mich halt schon, ob man das vernünftig zum Laufen bringt.
Da ich meine eigene MoBa aber dieses Jahr nicht so sehr vernachlässigen will wie letztes Jahr, wird es hier etwas gemächlicher vorwärts gehen.

Das 'Neugier-Gen' werde ich da etwas zügeln müssen, damit auch für die Weiterarbeit an der Moba Zeit bleibt ,

Der Zubehördecoder wird aber definitv weiterhin eine Source bleiben. Soweit bin ich bereits, dass das funktioniert. Im Sketch werden alle Aufrufe verallgemeinert, und die interfacespezifischen Dinge in einer 'interface.cpp' zusammengefasst. In der zugehörigen 'interface.h' wird man dann mit einem einzigen define die Übersetzung für DCC- oder LocoNet Schnittstelle umschalten können.
Wenn es Erweiterungen an der Funktionalität gibt, kommen die dann automatisch beiden Varianten zu Gute.

Hallo Franz-Peter,

ein großer Vorteil von LocoIO ist die freie Wahl der Adressen. Die stecken auch in den SVs. Wirst du das auch verwirklichen?

Viele Grüße

Klaus

wie horchst du denn auf den Loconet Bus?
Prinzipiell geht da ja ganz schön Leistung drauf, zumal ja auch gewartet werden muss, bis das Wort abgeschlossen ist!

Zitat

---

ein großer Vorteil von LocoIO ist die freie Wahl der Adressen. Die stecken auch in den SVs. Wirst du das auch verwirklichen?

---

Zunächst habe ich nur vor, die DCC-Schnittstelle durch die LocoNet Schnitstelle zu ersetzen. An der Funktionalität ist erstmal keine Änderung vorgesehen.

Zitat

---

wie horchst du denn auf den Loconet Bus?
Prinzipiell geht da ja ganz schön Leistung drauf, zumal ja auch gewartet werden muss, bis das Wort abgeschlossen ist!

---

Das verstehe ich jetzt nicht ganz. Wo siehst Du das Problem? Die Busleitung wird mit einer 15mA Stromquelle auf 'HIGH' gezogen. Werden Daten übertragen, zieht der Sender den Bus mit einem Open-Collecter Ausgang entsprechend der Bit-Übertragung auf 0 ( die 15mA fliessen auch nur während des '0' Zustandes). Die EIngänge sind rel. hochohmig (>47kOhm). Wo soll da Leistung bei drauf gehen?

Ich meinte die Rechenleistung, bzw. es wird ja nur das Wort abgewartet, aber das muss ja nun irgendwie über nen Interrupt laufen oder nicht?

Von der Rechenleistung her ist das für einen Arduino sicher kein Problem. Die Decodierung der LocoNet-Telegramme auf dem Bus macht die Library per Interrupt und HW-Timer im Hintergrund. Genau habe ich mir das noch nicht angeschaut, aber ich denke nicht, dass das mehr Ressourcen benötigt als die Decodierung des DCC-Signals. Im Sketch wird abgefragt, ob ein komplettes Telegramm empfangen wurde, und wenn ja wird es ausgewertet.

Das klingt doch gut.

Ich würde mich freuen, wenn ich testen dürfte

Hallo Franz-Peter,

tolles Projekt!

Ich habe zwar gerade keinen Bedarf danach, doch würde ich einen DIY-Zubehördecoder mit LocoNet-Interface äußerst praktisch finden, der dann auch äußerst flexibel den eigenen Anforderungen anpassbar wäre.

Als Protokoll rate ich auch auf jeden Fall zum neuen LNSV Format (format2), welches ja auch lt. Spezifikation für Neuentwicklungen empfohlen wird.
Sehr interessiert bin ich auch an Deiner im Werden befindlichen Programmieroberfläche für JMRI.

Ich hatte auch mal vergeblich nach einem Tool gesucht, welches es mir ermöglicht, beliebige LNSV zu lesen und zu programmieren. Ich hatte hier auch eine Anfrage gepostet:
https://stummiforum.de/viewtopic.php?f=5...689920#p1689920

An der Programmierung eines eigenen Tools habe ich mich nicht wirklich herangetraut. Ich fühle mich eher in der sehr hardwarenahen Programmierung von µC zu Hause.

Hallo,

die Bibliothek von Alex Sheperd unterstütz auch die Programmierung via LNCV, wenn man die "notifyLNCV*"-Funktionen implementiert (LocoNet.h, ab ca. Zeile 540).

Gruß,
fantux

Hallo an die LocoNet-Spezies
Da gibt's ja doch den einen oder anderen der sich dafür interessiert
Das Fragezeichen hinter dem Titel kann ich dann ja getrost mal wegmachen

@Derrick23:

Zitat

---

Ich würde mich freuen, wenn ich testen dürfte

---

Kein Problem, sobald die erste Beta-Version fertig ist, melde ich mich.
Den aktuellen Enwicklungsstand findest Du hier. Was ich da hochlade ist üblicherweise zumindest übersetzbar und kann auf den Arduino geladen werden. Inwieweit es schon halbwegs ordentlich läuft, ist eine andere Frage .
Den jetzigen Stand würde ich zwar noch nicht als Beta-Version bezeichnen, dazu habe ich ihn noch nicht genug getestet. Aber ein bissel geht schon was. Reaktion auf die Weichentelegramme und SV-Programmierung sollte grundsätzlich funktionieren. Wenn Du Lust hast .... Doku zur LocoNet-Schnittstelle fehlt aber noch ganz ( Ein bisschen was steht in BranchNotes.txt ). In den examples steht auch die xml-Datei für JMRI, die zur Standardkonfiguration in DCC_Zubehoerdecoder-Micro.h passt ( ist aber noch nicht vollständig ). Die Standardkonfiguration sollte auf Micro und Leonardo laufen. Für den proMicro müsste sie angepasst(gestutzt) werden, da der deutlich weniger IO hat.

@Fabian:

Zitat

---

Als Protokoll rate ich auch auf jeden Fall zum neuen LNSV Format (format2), welches ja auch lt. Spezifikation für Neuentwicklungen empfohlen wird.

---

So ist das auch vorgesehen. Das Format 1 unterstützt die LocoNet Library gar nicht.

Zitat

---

Ich hatte auch mal vergeblich nach einem Tool gesucht, welches es mir ermöglicht, beliebige LNSV zu lesen und zu programmieren. Ich hatte hier auch eine Anfrage gepostet:
https://stummiforum.de/viewtopic.php?f= ... 0#p1689920

---

Na, da war die Reaktion ja wirklich überschaubar . Die generische Maske von JMRI für LNSV erlaubt im Reiter 'CV-Tabelle' aber eigentlich schon eine ganze Reihe von Werten zu ändern. Mit der habe ich meine Tests angefangen.

@Fantux:

Zitat

---

die Bibliothek von Alex Sheperd unterstütz auch die Programmierung via LNCV, wenn man die "notifyLNCV*"-Funktionen implementiert (LocoNet.h, ab ca. Zeile 540).

---

Das ist ein guter Hinweis, das habe ich mir auch mal gleich angeschaut. Es gibt ja auch ein Beispiel dazu. Allerdings ist das wesentlich rudimentärer als die LNSV Unterstützung. Im Gegensatz zum LNSV, das die gesamte Speicherverwaltung selbst macht, und man nur von einer Änderung informiert wird, muss man bei LNCV die gesamte Speicherverwaltung selbst machen. Hat Vor- und Nachteile.
Erstmal werde ich das aber jetzt für LNSV im Format 2 umsetzen - dann sehen wir weiter

Hallo,

Zitat

---

Zitat

---

die Bibliothek von Alex Sheperd unterstütz auch die Programmierung via LNCV, wenn man die "notifyLNCV*"-Funktionen implementiert (LocoNet.h, ab ca. Zeile 540).

---

Das ist ein guter Hinweis, das habe ich mir auch mal gleich angeschaut. Es gibt ja auch ein Beispiel dazu. Allerdings ist das wesentlich rudimentärer als die LNSV Unterstützung. Im Gegensatz zum LNSV, das die gesamte Speicherverwaltung selbst macht, und man nur von einer Änderung informiert wird, muss man bei LNCV die gesamte Speicherverwaltung selbst machen. Hat Vor- und Nachteile.

---

Das Konzept ist ein ganz anderes. Bei den SV schreibst du einzelne Bytes im EEPROM deines Chips. Bei LNCV schreibst du sowas wie "Decoderadresse" oder "Weichenumlaufzeit". Wie dein Sketch diese Werte ablegt (und ob das überhaupt EEPROM-Werte sind!) ist dir überlassen. So ein bisschen kann man das auch daran sehen, dass die LNCV mehrere Byte lang sind, während die LNSV nur ein Byte haben.

Gruß,
fantux

Zitat

---

Hallo,
Das Konzept ist ein ganz anderes. Bei den SV schreibst du einzelne Bytes im EEPROM deines Chips. Bei LNCV schreibst du sowas wie "Decoderadresse" oder "Weichenumlaufzeit".

---

Nun ja, auch bei den SV werden die Werte ja als Adresse oder eben ein bestimmter Parameter, wie 'Weichenumlaufzeit' interpretiert. Die Werte sind ja kein Selbstzweck. Insofern sehe ich da keinen prinzipiellen Unterschied. Über die LocoNet-Lib bekomme ich bei LNCV auch nur eine 16-Bit-Adresse und einen 16-Bit Wert. Dass die Werte 16Bit sind, ist aus meiner Sicht da erstmal der einzige Unterschied zu LNSV. Der Rest ist in beiden Fällen Interpretationssache.
Inwieweit Uhlenbrock den Adressen feste Bedeutung zugewiesen hat entzieht sich meiner Kenntnis. Bei den DCC-CV's ist das ja bei vielen auch festgelegt.
Ein solche Festlegung ist mir bei den SV's allerdings auch nicht bekannt.