THEMA: Gemeinsame Entwicklg eines univer Handreglers

Hallo Wassi,
wichtige Features wären: XpressNet, LocoNet und evtl. noch SX-Bus, dann wären die wichtigeren Regler-Busse abgedeckt. Evtl. könnte man das über kleine Busplatinen abdecken?

Grafikfähiges Display! Touch muss IMHO nicht unbedingt sein...

Regler: Sollte ein ordentlicher Drehgeber ohne Anschlag sein, mit einer Beschleunigung (beim schnellen Drehen werden Fahrstufen übersprungen).

Tasten: Auf jeden Fall eine komplette Zehnertastatur.

Gehäuse: Ähnlich wie HR3 oder Multimaus, also einhändig bedienbar ohne Verrenkungen.

Vielleicht fällt mir später noch mehr ein :)

Viele Grüße
Carsten

Hallo Wassi,

Ich bin technisch nicht versiert genug, um ihr etwas Produktives beisteuern zu können.

Ich denke mir aber wenn ich schnorpsers Bastelprojekt sehe, dass es günstiger ist, einen fertigen Industriehandregler mit mit frisierter (gepatchter) Software an einen Busadapter zu stecken. Der CAN-Bus kann nach Protokollbeschreibing mit Sicherheit auch SX übertragen. Wenn Märklin ein - meinetwegen kostenpflichtiges Softwarupgrade - anbieten würde, wäre das sicher die Lösung.

Aber vermutlich sehen die Produktmanager bei Märklin nur, dass die Kunden dann auch Fremdprodukte nutzen könnten und nicht, dass Kunden mit anderen Systemem plötzlich auch Märklin-Komponenten kaufen könnten. Mal sehen, lange es dauert, bis man bei großen Firmen merkt, dass man Kunden hàlt und gewinnt, wenn man ihnen die Wahl lässt - wenn man sie an sich knebeln möchte, laufen sie weg.

Jens

Hallo Wassi,
ich bin kein Techniker und kann Dir daher leider nicht wirklich behilflich sein.

Stelle mir die Entwicklung eines solchen universellen Reglers aber schwierig vor, da dieser ja nicht nur DCC und SX1/SX2 beherrschen müsste, sondern neben dem Selectrix Bus ja auch noch diverse Datenbusse aus der DCC-Welt unterstützen müsste.

Würde mich aber sehr freuen, wenn da etwas käme.

Für mich wäre das Beschleunigen/Abbremsen der Loks per Taste optimal. Könnte mich aber auch mit einem Drehregler ohne Anschlag arrangieren. Ein beleuchtetes Display wäre für mich ebenfalls wichtig. Dazu eine intuitive, einhändige Bedienung.

Bei der MS1 finde ich beispielsweise klasse, dass man die 8 Funktionstasten mit den gängigsten Loks zum Direktaufruf belegen kann. Ich habe 4 MS1 im Einsatz und so 32 Loks im Direktzugriff. Der Regler, der an der Nebenstrecke eingesetzt wird, hat dann die dort üblicherweise verkehrenden Dieselloks auf den Tasten F1-F8, ein anderer Regler ist für die 8 typischen Güterzugloks zuständig usw.

Bin gespannt!

Viele Grüße,
Mathias

Hallo Jens,
ich verstehe das Anliegen eher so, dass man einen Regler baut, der eben nicht die Schwächen der Industrieregler hat. Die MS1 und MS2 z.B. sind sowas von unhandlich, dass ich die schon deswegen nicht verwenden wollen würde. Und die größte Schwäche der Maus ist (für mich) der Regler.

Aber vielleicht könnte man mal mit Wolfgang Kufer Kontakt aufnehmen und anfragen, ob nicht der OpenDCC-Regler als Basis verwendet werden kann.

Viele Grüße
Carsten von 1001-digital

Hallo,
da wird sich dann wohl jeder seinen eigenen Regler basteln dürfen. Die eierlegende Wollmilchsau kann unterm Strich nur wenig befriedigen. Vielleicht macht man einigen Profis damit eine Freude. Die Masse wird wohl eher nach kabellosen Reglern schielen, welche ihre Einstellungen aus der Zentrale beziehen. Der ECoSControl Radio mit besserer Ergonomie würde mir schon reichen. Der Trend geht ja auch dahin, dass man bei Freunden deren Regler benutzt und nicht mit seinem auf Wanderschaft geht.

Gruß
Frank

Hallo,

so unterschiedlich die Geschmäcker - für mich iat der Regler der MM gerade eine ihrer Stärken...

Grüße,
RF

Hallo Carsten,
ich würde das zwar nicht so hart formulieren aber vollkommen unrecht hast Du sicher nicht.

Was mir an der MS1 aber gut gefällt ist die robuste Verarbeitung. Der Regler kann auch mal runterfallen ohne gleich Schaden zu nehmen. Ob die High-Tech Regler von Rautenhaus oder Müt das auch ohne weiteres überstehen, würde ich zumindest anzweifeln.

Ein alltagstauglicher Regler sollte daher meiner Meinung nach nicht zu empfindlich sein.



Worin liegt die Schwäche des Reglers begründet? Ich habe mit einer Roco Maus mal eine LGB Anlage gesteuert; kann mich im Detail aber nicht erinnern, weil das locker 3 oder 4 Jahre her ist.

Viele Grüße,
Mathias

Moin,

vielleicht liesse sich das ganze modular aufbauen.
So könnte jeder mit reinnehmen was er will, bzw. braucht.

Gruß Kai

Hallo,

hatte auch erst an den opendcc mft als basis gedacht, jedoch fand ich ihn dann für einen nachbau doch als zu "komplex" insbesondere für weniger Bastelerfahrene

Das  Discovery-Eval board gibt es ab ca 27€ und hat schon vieles drauf (auch den Programmieradapter)
mit dem touch könnte man während der Entwicklungsphase viele tasten erstmal emulieren

können dann ja später auch als (optionale) echte Tasten ausgeführt werden

Somit beschränkt sich der Aufwand für ein erstes Entwicklungsboard auf die elektrischen Businterface und den Drehencoder

Wireless könnte man ja später als Option auch via ZigBee oder Bluetooth Module realisiern.
Dann wandert die elektrische Busankoppelung samt W-Interface aus dem Handregler in eine "Basisstation"
Man brauch dann aber eine gute Ladeschaltung für den Akku

Aber erstmal auf das wesentliche konzentrieren, den Regler selbst

Mal sehen ob ich mit Woflgang K mal bezüglich des Reglers in Gespäch komme. Mü ist ja gleich um die Ecke bei mir

LG

wassi


PS : fuer die Businterface hatte ich mir auch kodierte Steck-Module gedacht, die jeder nach seinem Umfeld einsetzen kann nicht jeder braucht ja alle Interface (gleichzeitig)  

Joo, oder man kann nach und nach aufrüsten.

Gruß Kai

Ist nicht das Gehäuse das eigentliche Problem? Software & Elektrik ist ja mal noch relativ einfach zu bewerkstelligen. Oder ist die Idee sich das Gehäuse dann drucken zu lassen?

Wenn ich aber lese: Funk/(großes), (touch) Grafikdisplay, 10er Tatatur, usw. Na prima, da wird das Ding aber nicht wirklich "handlich" oder? Vom Preis ist man dann doch sicher mit 'nem älteren Smartphone und einer WLAN Verbindung eigentlich schon fertig. Eine ÄÄÄpp zu programmieren die dann mit der Bluetooth oder WLAN Schnittstelle quaselt ist doch keine große Aktion.

Wenn überhaupt 'ne Eigenbau-Funk-Lösung, dann würde ich auf die SeriellToRadio Bausteine zurückgreifen. Die gibts für ein paar Euro bei den einschlägigen Bastelschops und die lassen sich mit 2 Drähten an jeden uC klemmen.

Fertige Bluetooth Bausteine sind schweine teuer, weil jeder dieser Baugruppen eine eigene Zulassung haben muß ( jedenfalls mal offiziell ). Ob es da irgendwelche China-Dinger gibt, weiß ich nicht.

Also nur mal so als Fragenkatalog

Ich hätte auch Bedarf an einem entsprechenden Handregler, würde diesen dann aber für eine Analogbahn einsetzen... ( Dekoder am Gleis Technik ). Das Display sollte dann auch Teile des Gleisplans vereinfacht darstellen können, um Fahrstraßen stellen zu können. Wenn es "nur" ein LCD würde, dann reicht mir auch Start/Ziel-Nummer der Fahrstraße.


Gruß
Klaus

Hallo Rico,
wenn dir der Regler der MM gefällt, dann gibts doch kein Problem: Verwende die einfach weiter :)

Hallo Westerland,
ich finde die Formulierung nicht hart... Wenn ich zur Bedienung beide Hände brauche, dann ist das einfach unergonomisch. Die Maus liegt dagegen sehr schön in der Hand, alle Tasten und auch der Regler lassen sich mit einer Hand bedienen, lediglich bei Benutzung der Shift-Taste muss man zwei Hände benutzen. Das ließe sich aber auch besser realisieren.

Der Regler der MM ist suboptimal, weil er relativ schnell ausleiert. Die Mittelstellung hat eine Rastung, die über 2 Kunststoff-Nasen im Gehäuse realisiert ist. Sobald die sich etwas abschleifen, hüpft man schnell über die Mittelstellung drüber. Für mich persönlich ist auch der Regler mit Anschlag (wie beim Trafo) wenig optimal, aber wie man an Rico sieht, ist das Geschmackssache.

Viele Grüße
Carsten von 1001-digital

ganz andere Idee:

Stellt Euch Tastaturen und sonstige Eingabegeräte für Notebooks und PCs vor.
Dort gibt es Tasten "Cursors" "Bildlauf", "Lauter", "Leiser", "Play" "Pause" "Sleep" etc.

Im Grunde gab/gibt es schon alle möglichen Eingabegimmicks wie PC-Fernbedienung, Maus-Scrollrad, Touchpad, Steuerknüppel (IBM-Tastaturen), Joypad, Joystick, Cockpits für Flugsimulatoren, Lenkräder inkl. Fußpedalen und Bewegungserfassung bei den Konsolen Wii, Kinect etc. Sogar Dreh- und Schieberegler bzw. Register bis hin zur Pedalbedienung bei Midi-Geräten mit PC-Anschluss.

Es liegt an den Programmieren der Softwareapplikationen (also auch von Modellbahnsoftware), welche Funktionen der Software über diese Tasten, Regler etc. bedienbar sind.

Lange Rede kurzer Sinn:
PC-Fernbedienungen mit auf die Modellbahnsteuerung optimierten Knöpfen und Reglern könnten bei Goodwill der Softwareanbieter im Prinzip dann von jeder Steuerungssoftwareverwendet werden (was die Softwaren ja jetzt schon via Smartphone und Tablett ermöglichen). Vielleicht gibt es sogar schon was nahezu fertiges wie z. B. Cockpits und Lenkräder.

Über die verschiedenen Bussysteme müsste man sich an dieser Stelle keine Gedanken machen, denn dafür sorgt ja die Steuerungssoftware ohnehin schon.

VG
Andreas

Hallo,

teppichbanner@11 als ich habe hier ein btm222 für Bluetooth (damals für 10 Euro gekauft)
zwei davon kann man koppel und schon ist eine serielle via funk realisiert
gleiches geht auch ähnlich mit dem zigbees
Das Gehäuse kann man später via 3D Druck auch drucken, aber das sehe ich eher als Feinschliff am Ende der Entwicklung. Aber vielleicht gibt es ja auch mechanisch Handwerkliche Meister die nichts so viel mit Elektronik am Hut haben, die sich hier einbringen koennen, zbsp Gehäuse gegen Hard/Software

Preislich sollte die kabelgebundene Grundversion nicht viel teuer kommen als das eval board + die Teile für die jeweiligen Businterface (treiber,...)
Funk dann als option ist ja bei der MM(pro) auch nicht gerade billig

Gleisplan vielleicht so (siehe links unten)


3D-Track@13: die Idee eines solchen Handreglers ist es ja, das man auch ohne PC die Moba steuern will (manchmal gibt es solche auch )

Habe Wolfgang K. mal eine email bezüglich einer möglichen Kooperation geschrieben, mal sehen was für ein Feedback da kommt

LG

wassi

Die von wassi zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hallo Wassi,

schon klar, ich meinte ja nicht statt der Handreglersache sondern als taktile Ergänzung von PC-Steuerungen.

VG
Andreas

Hi,

wenn du die Software aus dem Aermel schuettelst, wird sich fuer das Gehaeuse sicher eine Loesung finden.

Gruss,
  pst

Hi wassi,

ich finde deine Idee genial! Ich könnte dir aus zeitlichen Gründen momentan bestenfalls als Tester und Ideenlieferant zur Verfügung stehen...
Als Zentrale habe ich eine FCC und könnte damit den Bereich SX1, SX2, DCC am SX-Bus abdecken...

lg Michi

Erlaubt mir, auch die Sicht des "ewigen Bedenkenträgers" einzubringen...

Die eierlegende Wollmilchsau gibt es nicht. Und falls es sie gibt, ist sie im Verhältnis zu teuer.

Du willst einen einfachen Handregler? -> Fremo Fred
Du willst einen kompelxen Handregler? -> Selbst bau viel zu aufwendig. Wähl igrendwas von der Industrie
Du willst einen Handregler, der "alles kann", "alles unterstützt" und trotzdem "einfach" ist? Nehmen wir an, die Forumanen hätten sowas entwickelt. -> Dann würde es zum Schluss doch nicht in genügender Stückzahl bestellt werden, und das Projetk scheitert doch noch, weil niemand Lust hat, fünfstellige Beiträge aus der eigenen Hobbykasse einzuschiessen.

Meine Befürchtungen sind nicht ganz unbegründet; ich habe schon mehrere Projekte, die auf privater Initiative und mit viel Enthusiasmus gestartet wurden, scheitern sehen.

Und wenn wir nun aus diesem Pessimismus etwas Positives machen wollen, wird daraus die Frage: Was werden für Vorkehrungen getroffen, um diese gefährlichen Klippen zu umschiffen?

Felix

Hallo fgee,

die Kosten bestehen ja im Hobbybereich im wesentlichen aus den Hardwarekosten.
Um die niedrig zu halten, ist ja auch das Eval Board mit schon ziemlich viel drauf ein vorgeschlagener Ausgangspunkt (vielleicht ja auch nicht nur für die Entwicklung). Für die Kosten dieses Eval-Boards bekommt man nichtmal die entsprechenden Einzelkomponenten.

Die Softwareentwicklung kostet im Hobbybereich "nur" Zeit

Das ist der Unterschied zu kommerziellen Projekten, wo meist der größte Posten in diesen Kleinstückzahlenbereich auf die Softwareentwicklung entfällt

Eine Produktion in dem Sinne glaube ich wird nicht stattfinden, ausser ein Hersteller findet es so gut und einigt sich mit allen an der Entwicklung Beteiligten.

Aber ich denke die Software bleibt erstmal "opensource non commercial use"
Auch hier müssen sich alle beteiligten Entwickler schon zu Beginn auf einen gemeinsamen Nenner einigen.

Wenn es entsprechend gut wird, kann ja dcc-versand oder ähnliche eshops einen Bausatz dafuer anbieten

Für alle die sich den Zusammenbau nicht zutrauen, wird sich auch jemand finden, der es dann übernimmt.

LG

wassi

Hallo Wassi,
wäre nicht eine Kooperation mit Doehler & Haas bzw. dem ModellbahnTechnikTeamMünchen denkbar.

Der Erfolg ihre FutureCentralControl (FCC) beruht ja nicht nur auf dem Multiprotokollkonzept, sondern vielmehr auch auf die direkte Einbeziehung der MS1, die ja sogar soweit geht, dass Modellbahner, die Gleisbox der MS1 in Zahlung geben können und so eine vergünstigte FCC erwerben können.

Nun wird die Mobile Station schon seit einigen Jahren nicht mehr produziert und Doehler & Haas sowie mttm müssten doch größtes Interesse an so einem Projekt haben. Allein schon deshalb, damit ihnen auch in Zukunft ein Handregler für die FCC zur Verfügung steht.

Know-How hinsichtlich DCC besteht genauso wie Know How für SX1/SX2. Eine erstklassige Software, die alle 3 Protokolle bedient, liegt in der aktuellen Softwareversion 1.01 für die MS1 auch bereits vor. Wenn man dann über ein Adapterkonzept die unterschiedlichen Digitalbusse bedienen würde, dann wäre ein Universalregler doch machbar.

Viele Grüße,
Mathias

Hallo Westerland,

auch das wäre möglich, wenn Interesse von deren Seite besteht.

Es wäre mir dabei wichtig darauf zu achten, dass die verschiedenen Busprotokolle (XpressNet,CAN(?) ,SX) gleichberechtigt behandelt werden und nicht ein Basisprotokoll(SX) und dann Wandler ala x2x für die anderen.
Mit dem Vorschlag eines Cortex-M4 für den Start sollte eine entsprechend leistungsfähige und dennoch preiswerte Plattform gegeben sein, um dieses parallel zu implementieren.

In wie weit eine Firma externe Hobby-Entwickler in die Entwicklung Ihrer Produkte mit einbeziehen kann und möchte, das ist sicherlich auch ein Punkt.

Eine Entwicklung zusammen mit einer Firma wuerde jedoch die kommerzielle Verfügbarkeit eines solchen fertigen Handreglers ermöglichen.

LG

wassi

Hallo

ich bleibe bei meiner Entscheidung, und werde mir im kommenden Jahr ein Smartfone als Handregler zu legen.

      Gruß Robby

Hallo Wassi,
auf solche Dinge müsste bei einem halb-kommerziellen Projekt natürlich geachtet werden. Ansonsten besteht natürlich die Gefahr, dass der kommerzielle Partner versucht, das Projekt in eine Richtung zu lenken, die dem Gedanken des Universalhandreglers entgegen steht.

Bestes Beispiel ist die MS2, die voll auf die Märklin Interessen abgestimmt wurde.



Das wäre aus meiner Sicht ein nicht zu unterschätzender Vorteil.

Viele Grüße,
Mathias

Hallo Robby,

Smartphone ist sicherlich eine Alternative zu einem klassischen Handregler.
Der Nachteil hier ist, dass man immer eine gewissen IT-technischen Aufwand betreiben muss (zbsp minimal raspberry pi mit rocrail und AP-packet oder gar eine PC/NB mit entsprechender Server-Software) um dann mit einer App die Kontrolle über die Moba zu haben.

Meines Wissens gibt es nur eine beschränkte Anzahl von Zentralen, für die es eine entsprechende App bzw Web-zugang gibt (zbsp Z21).

Aber auch hier ist doch noch ein externer Access-Point notwendig oder ?

Das Entwicklungsziel hier ist ein Handregler, der auch mit "einfacheren" Zentralen nutzbar ist (ohne externe IT Unterstützung/Server)

LG

wassi

Folks!
Das wesentliche bei einem Handregler ist das Haptische. Eingabeinstrumente die man erfühlen kann und die eine Bedienung ohne hinzusehen ermöglichen. Das ist für jene wichtig die Modellbahn mit dem *Ansehen* rollender Fahrzeuge in Zusammenhang bringen. Die Streicheltelefonie erfordert daß man den Blick von der Anlage abwendet. Hier spalten sich 2 Gruppen von Anwendern die im Bedienungskonzept wenig gemeinsames haben.

Zur Realisierung: ich habe einen Buskonverter angefangen, Projekt ist gescheitert - man kann auch formulieren noch nicht fertiggestellt. Bei der Realisierung ist mir aufgefallen, daß die Konzepte der Zentralen und Bussysteme sehr unterschiedlich sind. Das Benutzerinterface ist eine Sache die könnte in gewissem Maße geteilt werden, also die Abfrage von Eingabeelementen oder das Ansteuern einer Anzeige. Die Logik am Bus ist sehr unterschiedlich sobald man nur ein klein wenig Komfort bieten will. Selbst wenn man sich nur auch das Fahren und Weichenschalten beschränkt. Der Klassiker: was passiert wenn 2 Regler die selbe Lok anwählen?

Das Größte Problem war früher das Gehäuse ist seit der weiten Verbreitung von 3D Druckern kein Problem mehr. Selbst einfache 3D Drucker mit etwas raueren Oberflächen wären gut genug. Bisher waren die Bastlergehäuse von einer ausgesprochenen Hässlichkeit und haptisch unangenehm. Man bräuchte dann alt auch einen guten Gehäusedesigner und jemanden der das dann 3D zeichnet.

Die Wesentlichen Zentralen und Bussysteme sollten unterstützt werden. LocoNet, X-Press, SX Varianten und die 3(4) CAN Busse ESU ZIMO Märklin. Zusätzlich schlage ich noch vor USB einzuplanen für die TC Fraktion oder andere PC basierte Lösungen.
Funklösung ist mMn unbedingt einzuplanen, da meine ich sollte man was fertiges nehmen wie ZigBee odglm um keinen Entwicklungsaufwand zu verschwenden und um die Zulassungsproblematik bereits im Vorfeld erledigt zu haben.
-AH-

Das preiswerteste Wirelessteil ist doch (oder wird in naher Zukunft sein): Ein älteres Smartphone.

Also ist die Frage wie am einfachsten ein solches mit dem Bus der Zentrale verbindet. Also ein "schwarzes Kästchen" das auf der einen Seite WiFi hat und auf der anderen Seite an die von AH genannten Busse gesteckt werden kann. Ob dann in dem Kästchen ein Rasberry mit JMRI oder Rocrail werkelt spielt doch eigentlich keine Rolle, nur muss man es so verpacken, dass auch der Anwender der "zum Modelleisenbahn fahren keinen Computer hochfährt" das nicht merkt.

Eine andere Frage ist ob man dem Smartphone ein Haptikteil draufsetzen kann.

Gruß,
Harald.

Hat sich das Thema so schnell erledigt?

Gruss,
  pst

Hallo pst,

ich hoffe doch nicht

also das discovery hat jetzt schon einen Drehencoder dran,
Als Startpunkt für die ersten Entwicklungen habe ich jetzt schon ein coocox Beispielprojekt (gefunden im µc.net forum) am laufen , die grundlegenden funktionen (lcd,touch,...) kann man da reusen

Am Wochenende werde ich dann den Alps im Zusammenhang mit der quadraturencoder einheit auslesen.

Die nächsten Schritte werden dann ein xpressnet interface und ein rudimentäre Implementierung einer lokmaus sein

Kontakt zu Wolfgang (opendcc) ist auch schon geknuepft

LG

wassi

Hallo,

ich glaube, so einfach erledigt ist das Thema nicht
Aber: Ich glaube, soviel Hardware braucht man da gar nicht neu zu entwickeln. Ich habe vor kurzem mal mit einem Arduino rumgespielt, und damit lässt sich ja alles ansteuern und machen, was wir wollen:
Input:
- Analogeingänge für Potentiometer - für alle, die nicht endlos regeln wollen.
- Digitaleingänge für Drehräder - für alle, die endlos regeln wollen.
- Digitaleingänge für Taster, auch als Tastatur verwendbar.
Output:
- Digitalausgänge für Display (ob nun graphisch oder 7-Segment oder Punkmatrix)
- Digitalausgänge für Status-LEDs (z.B. Funktionen)
- Anschluss an Bus könnte über ein extra Shield gemacht werden.

Für DCC gibt es schon eine Library, wie das mit den Bussen aussieht, müsste ich suchen. Die Hardwarekosten sollten sich auf nicht mehr als 50€ belaufen, wenn man ganz viel Schnullifatz anbaut (beleuchtetes Display, vergoldete Knöpfe, Handgeschmiedetes Gehäuse)  vielleicht 100€.

Wenn ein vernünftiges Softwaregerüst da ist, wäre dieser Regler sogar sehr indivualisierbar.

Grüße,
RF

Hallo RF,

da könnte Dich ja folgende Seite interessieren:

http://www.pgahtow.de/wiki/index.php?title=Arduino_Loconet_Throttle
http://www.pgahtow.de/wiki/index.php?title=XpressNet

Gruß  Thorsten

Hi,

ein Smartphone als Handregler ?
Dann aber nicht von SAMSUNG, deren Akkus machen bei intensiver Nutzung schon nach wenigen Stunden schlapp.

Gruß aus Nordertown

Hallo RF,

ein AtMega basiertes Arduino wird wohl nicht genügend Leistung haben, um die Funktionen zu realisieren, selbst wenn man nicht die Arduino-Funktionen benutzt sondern diese selbst implementiert um diese zu entschlacken und damit zu beschleunigen.
So wollen wir ja neben dem eigentlichen Bedienfunktion den jeweiligen Bus sniffen, um auch bei einem Handover einer Lok, die aktuelle Geschwindigkeit im Regler als Basis für die incrementelle Veränderung via Drehgeber zu haben, um so die Bocksprünge zu vermeiden.
Toggle einfach mal einen LED-Pin mittels beider Methoden und messe die erzielbare Blinkfrequenz.
Wenn man dann aber die Hardwarezugriffsfunktionen selbst implementiert ist der "Vorteil" der Arduino-Plattform schon hin.
Es ist zudem zumindest bei der Prototypenentwicklung schön, wenn man etwas Luft nach oben (Rechenzeitreserve,Speicher,...) hat, und man nicht alles gleich aufs letzte Bit ausknautschen muss. Insbesondere beim Einbringen von Debug-Funktionen in der Entwicklung zeigt es sich, dass man lieber etwas großzügiger das Entwicklungssystem auswählen sollte.

Wenn der Funktionsumfang dann vollständig implementiert ist, kann man auch ans optimieren auf eine kleineres Derivat gehen. Jedoch sehe ich keinen Grund dort einen Schritt zurück auf einen 8bitter zu machen.

Preislich liegen die Adruinos auch deutlich über dem Niveau des 429Discovery, erst recht wenn man es mit einem fast leistungsmäßig equivalenten Arduino (Due) vergleicht.
Dazu kommt dann noch das nicht integrierte Display, beim 429discovery ist ein Farbtouch mit 320x240 drauf

So kompliziert ist DCC auch nicht, so das man diesen Kompromis eingehen muss. Das bekommt man selbst implementiert

LG

wassi

Hallo


Kein Problem, bei intensiver Eisenbahn-Nutzung mache ich auch schon nach wenigen Stunden schlapp.

Dietrich

Hallo,

es wäre natürlich richtig fein, die Vorteile eines Endlosreglers (kein Springen bei der Übenahme) mit den Vorteilen eines Poti-Drehknopfes (Haptischer Endanschlag usw...) zu vereinen: http://www.conrad.de/ce/de/overview/0241612/Motor-Potentiometer

Grüße,
RF

Hallo RF,

huch jetzt geht es aber ans eingemachte

Um das zu erreichen gibt es zwei Möglichkeiten:

1. Man muß den Encoder mit einem (Schritt)Motor koppeln, der beim Lok-Handover die Position entsprechend der aktuellen Fahrstufe und Richtung anfährt

2. man erzeugt den Endanschlag durch eine Magnetspule,  das bei erreichen der höchsten Fahrstufe zumindest in Drehrichtung einer weiteren Erhöhung den Drehknopf blockiert

Beides ist sicherlich nicht wirklich unter der Prämisse eines geringen Preises derzeitig machbar (aus meiner Sicht) und damit erstmal ein nice to have feature

Vielleicht könnte man ja durch Vibration wie im Handy das erreichen der Anschläge bzw der Nullstellung signalisiern ?

LG

wassi

Ich denke, da unterschaetzt due die Atmegas gewaltig. Ich habe damit eine Fernsteuerung fuer den Modellbau realisiert, da passt eine Menge rein. Aber das ist nun mehr ein akademischer Wiederspruch - fuer ein neues Projekt wuerde ich auch gleich eine groessere Plattform waehlen, aus den anderen von dir aufgefuehrten Gruenden.

Diskussionen wie die um den Drehknopf wuerde ich vermeiden - damit verzettelst du dich nur. Ueber sowas kann man sich Gedanken machen, wenn ein erster Wurf funktioniert.

Viel Erfolg,
  pst

Hallo PST,

nun das ich die AtMegas unterschätze glaube ich nicht, habe in der Vergangenheit auch viel mit 8bittern "gebastelt" (hauptsächlich Z8 derivate).

Doch an die Leistung der Cortex-M3/M4 kommen die einfach nicht ran, für kleine Projekte okay, wenn man nicht umsteigen will.

Der 1z160HR mit der Vielfalt der anvisiserten Busprotokolle braucht zumindest in der Entwicklungsversion da eine Leistungsklasse deutlich über den 8bittern (egal welcher Hersteller)

Ein schöner Nebeneffekt ist der super günstige Preis für das 429Discovery, da kann keine Arduino-Lösung mit Anzeige mithalten.

Nun aber wieder zum Projekt.

Ich habe von Uwe, dem Author einer kleinen Demo auf den 429Discovery die Erlaubnis erhalten, das wir seine Routinen ( http://mikrocontroller.bplaced.net/wordpress/?page_id=3014 ) für die Boardperipherie als Ausgangspunkt benutzen können (man muß ja vorher mal fragen)

Auf deren Basis habe ich gerade ein wenig rumgespielt, LCD Grafik und Textausgabe sowie Touch mit Position kann ich auf der Grundlage dieser Routinen schon benutzen.

Mit dem Drehencoder habe ich noch ein Problem, ich habe noch kein TimerChannel-Paar gefunden um einen der internen Timer im Encoder-Mode betreiben zu können. Da muß ich noch mal intensive in der Doku nachschauen, welche von den freien Pins noch dafuer geeignet sind.

Zur Not wird es sonst in Software gemacht , auch wenn die Auswertung in Hardware schon schön wäre

LG

wassi

Hallo,

die Diskussion um den Drehknopf geht ja auf meine Kappe, ich hatte die beim Stöbern gesehen...

Ich klinke mich dann hier erstmal wieder aus der aktiven Beteiligung aus...

Grüße,
RF

Hi,

kurzes Statusupdate

da auf dem 429 Discovery leider die entsprechenden multiplen IO-Pins für die Timerkanäle mit Encoder-Funktion durch anderen Funktionen belegt sind, habe ich nun die Encoder Dekodierung in Software via Pin-Interrupts erschlagen. Zum Glück können die IO-Pins beim STM32 so konfiguriert werden, dass sie auf beide Flanken (also LH und HL) reagieren.

So nun geht es daran eine rudimentäre GUI auf das Touch-LCD zu "zaubern", um dann den Ausgangspunkt für die Implementierung einer vereinfachten Funktion eines ersten Busprotokolls (Xpressnet) zu haben.

LG

wassi

Hallo Wassi

ich habe null Ahnung von dem was Du da schreibst aber Xpressnet hört sich gut an.Wenn ich mir einen HR wünschen dürfte, würde er so aussehen wie der Lenz LH 90. Obere Anzeige weg,Richtungsschalter in die Mitte und den Touch darunter.(Der Drehregler bleibt natürlich erhalten).Dann nehme ich  mindestens einen .

Gruß Michael

Hello Wassi!

Bin zwar jetzt etwas in die Schlichtheit der Arduinos verliebt aber gegen etwas Power ist nie etwas einzuwenden. Hab' soeben das EvalBoard bestellt, bei der Ausstattung kommt man sonst nie und nimma mit! Werd' mich an der Entwicklung beteiligen je nach Zeitbudget. Derzeit bin ich noch Landunter aber wird schon werden.

Zum Zusammenarbeiten schlage ich vor wir vereinbaren einen Filehoster um dort Zwischenstände bequem rauf schieben zu können. Damit vermeiden wir endlose E-Mail Kaskaden. Solange das noch in den Anfängen steckt würde ich noch ein öffentliches Repository meiden. Ich habe dazu für andere Projekte einen SkyDrive Ordner angelegt und gezielt für die Kollegen frei gegeben. Das ist recht bequem, könnten wir abermals machen.
-AH-

Hallo Wassi,

zum Erkennen der Nullstellung bei einen Drehimpulsgeber könnte ich mir einen Summer vorstellen, der 'Klick' macht bei Stellung Null. Dieser Klick könnte sicher auch für andere Dinge verwendet werden.
Auf der Seite des Boards kann ich keine Infos bzgl. Touch-Screen finden.
Kann das Board das wirklich?

Als Alternative könnte ich mir auch eine Märklin MS1 vorstellen. Prozessor und Display müssten doch mit der Trix MS1 übereinstimmen. Wäre sehr intressant, wenn man die Sourcen von D&H bekommen könnte, zumindet die Prozessor- und Display-Initialisierung.

Grüße
Stephan

Hallo Stephan,

ich kann zwar in der Sache nichts beitragen, glaube aber nicht, dass es Sinn macht, ein nicht mehr hergestelltes Gerät - MS1 Trix - durch ein anderes nicht mehr hergestelltes - MS1 Märklin - zu ersetzen.

Gruß Gerd

Hallo,

Arnold@41: mit SkyDrive habe ich so meine Problem, mal sehen wo es ein passendes öffentliches Repository- mit Versionskontrolle und eingeschränkbaren Entwicklerkreis gibt

Stephan@42: ein Summer ginge auch anstelle  eines haptischen Feedback (Vibrieren) wie beinm Handy. Ein akustisches Feedback hat in lauten Umgebungen (Ausstellung, Fahrtage,..) eventuell einen Nachteil
Auf dem 429Discovery ist ein STMPE811 verbaut, der den resistisven Touch verwaltet (UM1670 Seite 33 Schaltplan).
Hatte ich auch nicht auf dem ersten Blick gesehen und dann erst entdeckt, als es bei mir mit der vorgeladenen Demo auf dem Tisch lag.
Geht erstaunlich gut, trotz resistive, zumindest für die Entwicklung reicht es.

LG
wassi

PS: habe den mechanischen Alps an PE2,3 und den Taster an PE4 entsprechend dem Alps Datenblatt mit TP 10k/10nF angeschlossen (aktiv low)

PS 2.: habe mal bei sourceforge ein projekt angelegt, muss jetzt nur noch meinen bisherigen Stand einpflegen

http://sourceforge.net/p/hr1z160

Hi Wassi!
Kein Problem SkyDrive kann durchaus "religiöse" Aversionen auslösen , mir nicht unbekannt habe eine gewisse Guanoaversion. SourceForge ist auch OK. Man hat dort halt weniger Kontrolle über den Zugang was durchaus OK ist, wenn man das so will.
-AH-

Hi

Keine Ahnung ob das Ding wirklich irgendwann Serienreif wurde... Demo-Exemplare gab es.
Ist nur als Anreiz gedacht, das Teil ist/wurde sowieso zu teuer (sein)...
Aber schöne haptische Möglichkeiten auf Seite 2 dargestellt.

http://www.idsc.ethz.ch/Courses/embedded_contro...ises/VirtualKnob.pdf

Hi,

na das ganze soll ja noch bezahlbar bleiben.   Ich denke ein kleiner Handyvirbrationsmotor reicht für das Feedback völlig.

Zwischenstand: Touch-LCD-Keyboard geht. Kann man nur schlecht abfotografieren

LG

wassi

PS: habe mal im git unter http://sourceforge.net/p/hr1z160 den aktuellen Stand gepusht.

Die von wassi zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login

Hi,

habe gestern abend mal ein wenig überlegt wie die übergeordnete Busdatastruktur aussehen kann.

Hintergrund: dort soll unabhängig vom Protokoll der 1z160HR ja alle Aktivitäten auf dem Bus mit loggen, damit er einerseits mitbekommt, wenn durch einen anderen Handregler sein aktuelles Fahrzeug übernommen wird (also eine Änderung der Fahrtrichtung, Geschwindigkeit oder Funtkionen) bzw. er den aktuellen Status bereit hat um selbst ein anderes Fahrzeug mit den richtigen aktuellen Werten (anti bockspringen) übernehmen kann.

Ich möchte auf dieser ebene nicht unterscheiden, welches Fahrzeug SX oder DCC oder ... ist
Die Umsetzung soll dann das entsprechende Busankoppler-Softwaremodule machen.
Ebenso die Umsetzung vom spez. Bus in dieses allg. Busdatenformat.

Daher eine Frage: Wenn ich das richtig verstanden habe, wird bei SX doch dynamisch die Zuordnung zu einem Kanal hergestellt (oder?)

Wie wird eine Lok dazu adressiert ? Bei DCC hab ich ja zum Beispiel  die CV1 (oder das entsprechende lange Pendant)

LG

wassi

Hi,

nun da noch keine Antworten bezüglich meiner SX Frage gekommen sind vielleicht etwas allgemeiner:

für das übergeordnete Busprotokoll würde ich jetzt

1. eine Adresse ( noch zu klären wie man diese auf die einzelnen Busse abbildet)
2. die jeweilige Fahrstufe
3. die Fahrtrichtung
4. einen Funktionsvektor (aktivierte Funktionsbit)

vorsehen.

was nocht ?

Unter http://sourceforge.net/p/hr1z160 steht im git der bisherige code

LG

wassi

Hallo Wassi,

SX arbeitet mit einem fest vorgegebenen Datenrahmen, der vollständig regelmäßig wiederholt wird. Es gibt innerhalb dieses Datenrahmens 112 Systemadressen - hier erfolgt die Adressierung und alle weiteren Befehle. Siehe auch Morop NEM 680/681.

Die Dokumentation von SX ist im Netz an verschiedenen Stellen frei zugängig. Anders sieht es da mit SX2 aus.

Jens

Hi wassi,
ganz Allgemein siehe z.B.: http://steinhartw.de/selectrix/sx_protokoll.htm
SX1 hat: Fahrstufe, Fahrtrichtung, 2 Funktionen
Meines WIssens kannst von einem Bus aus nicht den anderen ansteuern... (@hajo: kannst du das bestätigen?)
SX2: hier gibts in der Anleitung der FCC auf Seite 16 eine Beschreibung: http://doehler-haass.de/cms/media/pdf/FCC_Interface_Doku.pdf

lg Michi

Hi,

die NEM's kannte ich schon, wollte jedoch noch mal sichergehen, ob für das übergeordnete Busprototokoll die Werte aussreichend sind, d.h.

das man eine eineindeutige Abbildung eines SX-Signals in diese Busdatenstruktur und wieder zurück machen kann, oder ob man dort noch zusätzliche Informationen speichern muß.

Die Idee ist ja, dass wir alle bestehenden Formate (DCC,SX,loconet,can,..) in ein einheitliche Datenstruktur transferieren und dann ebenso diese beim Ansteuern eines in dieser Datenstrukturliste gespeicherten TFZ egal auf welchen Ausgangsbus ausgeben können.

Netter Nebeneffekt wäre dabei, das der 1z160HR zugleich ein BusFormattranslator wird.

Daher nochmal die Frage: Reichen die oben genannten 4 Werte aus, um in jedem potentiellen Datenformat sie dann entsprechend anzusteuern oder wären eventuell noch zusätzliche Hilfwerte hilfreich ?

LG

wassi

Hallo wassi,



Ich denke, das Gleisprotokoll muss mit rein -> also einen 5. Parameter. Denn, bei SX-Systemen gibt es in der Zentrale keine Lokdatenbank - hier wird über die SX2-Erweiterung im Busprotokoll das Gleisformat an die Zentrale gemeldet. Mit Gleisformat meine ich SX1, SX2 und DCC (mit samt seinen Fahrstufen und Funktionen).
Mehr zum Thema SX2:
http://www.muet-digirail.de/filemgmt_data/files/SX-2-Definition%5B1%5D.pdf
Bei RMX wird das Gleisformat in der Zentrale abgelegt, doch die RMX-Spec ist nicht öffentlich.


Viele Grüße
SX1-Norbert

Folks!
Wär's nicht einfacher wenn wir ein Modul (HW oder SW) bauen das die Tätigkeit der anderen Geräte puffert und dann vom Handregler bequem abgefragt werden kann?

An anderer Stelle hab' ich das schon einmal durchdiskutiert. Damals sind wir zur Erkenntnis gekommen, daß ein Handregler durchaus später, also nachdem schon viel Kommunikation stattgefunden hat, an den Bus angeschlossen werden kann. Der Handregler hat daher keine Chance das zu "wissen". Daher wäre eine Stelle die man befragen kann von Vorteil. Man denke nur daran daß man den HR abstöpselt 5 Meter weitergeht und neuerlich anstöpselt. Falls das in HW gelöst wird könnte diese Kiste auch als Funkbasisstation dienen.

Mein Hintergrund ist ZIMO belastet, daher staune ich immer wider das viele Plattformen aus Kostengründen so viel weggelassen haben. Das braucht man nicht zu kritisieren weil der Modellbahner immer billig haben will, Funktionalität ist selten ein Entscheidungsgrund, oder erst nachdem man Enttäuscht worden ist. In der ZIMO Welt ist es schon immer üblich gewesen alle Systemdaten in der Zentrale zu speichern. Das passiert auch Batterie gepuffert über Spielsitzungen hinweg. Ein Fahrpult kann immer die Zentrale befragen was über eine Adresse bekannt ist. Somit sind die Infos jeder Zeit vorhanden. Schon in den 1990'er waren da 256 Fahrzeugadressen die "gemerkt" wurden. Das reicht wohl auch für viele Vereine aus.
-AH-

Hallo Leute,



Ich hab jetzt nur kurz in das von Norbert verlinkte PDF zu SX2 reingeschaut.
Für mich schaut es so aus, dass das SX2-Protokoll doch im Grunde bereits das übergeordnete Protokoll ist ... siehe z.B. die SX2-Präambel.
Ich denke, da braucht man nix neues für erfinden ... ?!

Was Arnolds Modul betrifft, klingt das für mich schon stark nach einer Zentrale ... dafür dürfte nicht mehr viel fehlen.

Viele Grüße,
Arndt
... der sich auch einen schicken haptischen Touchregler ;)) wünscht !!!

Hi,

53@snorpser: hm wenn SX2 das nicht auseinander halten kann, dann muessen wir ihm halt diese Info mitschreiben.

Ich wollte eigentlich auch noch in das Busprotokoll mit aufnehmen auf welchem Bus es rein kam. Das wäre dann für das "Routing" wichtig, wenn man zwischen den Busen vermitteln will

55@arnibe: der Ausdruck Busprotokoll ist vielleicht etwas missverständlich von mir gewählt.
Es handelt sich hier nur um eine reine in der Software vorhanden "Busstruktur" zur Kommunikation zwischen den einzelnen Softwaremodulen (also dem eigentlichen Bedienteilfunktionen und den verschiedenen Businterface Routinen).

Im wesentlichen sind das also nur Bereiche im Speicher, wo die aktuellen Daten mitgeschrieben werden und entsprechenden Zugriffsfunktionen.

Das hat  mit SX2 nicht wirklich etwas zu tun.

Sie sollte so einfach wie möglich sein und nur um die unbedingt notwendigen Busspezifischen Zusatzinformationen erweitert werden.

arnold@54: hm das ist ein Problem. Bisher bin ich immer nur davon ausgegangen, das ein Handregler nur das kennen kann, was er selbst am Bus gehört hat.

Die Trennung in Basis und HR kann man ja später davon ableiten. Die Basis wüßte ja dann alles aus der Vorgeschicht seit Power-On und kann dieses dann an den/die HR weiterleiten.
Dann kann man dort auch das Speichern über einen Powerzyklus hinaus erledigen.

Im HR finde ich das gefährlich, es könnte ja während des umstöpselns eine Änderung auf dem Bus übertragen worden sein, die der HR natürlich dann nicht mitbekommen hat.

Kann einer was bezüglich eventuell notwendiger zuätzlicher Informationen für Loconet sagen ?

LG

wassi

Hallo Wassi,

die Beschreibung des SX2-Protokolls kann ich doch direkt auf dem Speicher abbilden, d.h. die Bits und Bytes in genau der Reihenfolge im Speicher ablegen, wie sie auch gesendet werden.
Nun sieht das SX2-Protokoll ja auch die notwendigen Datenrahmen für DCC, MM etc. bereits vor, somit würden diese ebenfalls im Speicher abgebildet werden.
Für einen SX2-Bus braucht man dann doch nur den Speicher "der Reihe nach absenden", während sich für die anderen Busse die Informationen daraus ableiten lassen.
Sehe ich das falsch ?

Gruß, Arndt

Hallo Arnibe,

wie weiter oben schon erwähnt, wollte ich zumindest den internen Softwareaufbau so unabhängig wie nur möglich von einem Gleis/realem BusProtokoll halten, um dadurch keine Variante zu bevorzugen.

Ein Speichern der Bits und Bytes im SX2 datenformat im Speicher halte ich nicht für sehr effektiv,
so muss ich zum Beispiel immer wenn die "GUI" einen Wert (z.Bsp. die aktuelle Fahrstufe) einer Lok benötigt erst einen SX2-zu-realem Fahrstufenkonverter anwerfen. Dieses wird nur einmal beim Empfang des entsprechenden SX2-Datenrahmens für alle anderen Funktionsmodule getan.
Bei der ständigen wiederholung wird nur auf Änderungen reagiert (und ein Trigger ausgelöst).

Ich finde eine einfache abstrahierte Datenstruktur erleichter doch sehr die Programmierung aller der darauf Zugriff nehmenden Funktionen.

So kann z.Bsp jemand ohne Kenntnis von SX2 an der Programmierung der entsprechenden CAN-Konverterfunktionen teilnehmen. Sonst muß sich ja jeder mit SX2 auseinandersetzen.

LG

wassi

Okay ... das ist ein Argument

Danke,
Arndt

Die Anwendung des LocoNets für Loks kreist um das slot management protocol. Ich nehme an, das bekommt man am besten mit der Verwendung von Bibiothekstutinen hin.

http://fremodcc.sourceforge.net/Loconet_d.html
-> http://fremodcc.sourceforge.net/loconet/loconet.ppt

http://embeddedloconet.sourceforge.net/

Gruß,
Harald.

Hi,

für alle die noch nach eine Möglichkeit zum Bezug des Eval-Boards für Privatpersonen suchen

http://shop.myavr.de/ARM-Produktlinie/STM32F429...php&artID=200116

LG

wassi

Hallo wassi,

wow, ist das Teil preiswert...! Vielen Dank für den Link!
Was soll eigentlich die Programmiersprache fürs sein? C? C++?


Viele Grüße
SX1-Norbert

Hallo Norbert,

erstmal reines C.

Hatte es auch mal testweise in diesem Projekt mit C++ versucht, bin aber dann beim Zusammenbinden mit den in reinem C geschriebenen Hardwareroutinen gescheitert  (gcc in CooCox ide).

LG

wassi

Hallo wassi,

C klingt gut
Ich mache mir auch mal paar Gedanken und poste das separat...


LG,
SX1-Norbert

Hi,

ich denke mit simplen C haben wir auch einen größeren Kreis an möglichen Entwicklern

Auch wenn C++ gerade bei der Definition des Interfaces zu den Busprotokollen auch seinen Reiz hätte.

Ich werde hoffentlich noch heute (sonst morgen) eine Definition und ein Beispiel für die Anbindungsfunktionen eines Busprotokolls an den 1z160HR ins git einstellen, damit wir da eine einheitlich Struktur rein bekommen

1. eine Funktion zum Schreiben des aktuellen TFZ auf den jeweiligen Bus
2. eine Funktion zum Melden einer gelesenen Aktion auf dem Bus zum Eintragen in die Busprotokoll Datenstruktur
3. eine Funktion zum Abarbeiten der Busprotokoll spezifischen Aufgaben ausserhalb der ISR (Timinginterval? Länge?)
4. eine Funktion zum Initialisern der Ports und der ISR
5. die ISR (wenn notwendig zum behandeln des Protokolls) sollte halt so kurz wie nur notwendig sein, der Rest in der regelmäßig aufgerufenen Abarbeitungsfunktion

LG

wassi

Hallo wassi,

wie wäre es, wenn die eigentliche Busbehandlung von einem separaten µC realisiert wird? Dieser könnte via SPI, I2C oder seriell angebunden sein. So könnte die Busbehandlung autark laufen und in festen Intervallen tauschen "HMI-µC" und "Bus-µC" die Daten aus.

Die Busanbindung an sich ist sowieso je nach Bus "speziell". Xpressnet (RS485) und CAN werden üblicher Weise über entsprechende Treiberbausteine angebunden. SX via Transistor und Komparator.  

VG,
SX1-Norbert

Hallo Norbert,

meinst Du das ist wirklich erforderlich ?
der f429 hat doch so ca Faktor 10 mehr speed wenn man ihn ausfährt (ich weiß hängt ganz von der Detailaufgabe ab) als so ein externer mega oder pic
Wir haben doch so ca 5-6  verschiedene busprotokolle, die meistens nie alle gleichzeitig Last erzeugen werden. Meistens haben wir wohl nie mehr als zwei externe Protokolle, die gleichzeitig aktiv benutzt werden.

Ein Multi-µC System hat natuerlich auch seinen Charme, verkompliziert jedoch den Aufbau.

LG
wassi

Also bei C steig ich aus Ich programmier doch nicht alles nochmal, was es in C++ schon aus der Schublade gibt. Zumal C++11 gerade für den Embedded-Bereich eine erhebliche Verbesserung des erzeugten Codes ermöglicht. Ich sag mal nur constexpr!

Wer noch gerne in C programmiert, weil er es eben halt kann, dem sei empfohlen alsbald mal die Füße zu heben und einen Sprung in die aktuelle Welt zu wagen

Gruß
Klaus

Vielleicht kann ich ja noch was beisteuern:
http://www.aca-modellbahn.de/ElektronikSchaltungen/FR_Artikel/Fahrtregler.html

basiert auf einem Atmel AVR Tiny

Schaltplan habe ich inzwischen überarbeitet, aber noch Update noch nicht online gestellt.
Bei Hardware Problemen bin ich gerne behilflich.

Mein Beitrag zum Bedieninterface:
Ein Poti ist immer gut. Drehencoder oder gar Touch Lösungen sind nicht das gelbe vom Ei !
Wer schon mal mit einem Poti geregelt hat, weiss wovon ich spreche.

Hi

Aca@69:

Du willst den 1z160HR auch für analog nehmen ? Okay interessante Idee. Da wirst Du dann jedoch andere Werte in der "LOK-DB" speichern wollen als bei den Digitalen Protokollen (Freq. Rampen,....)

Ich denke insgesamt wäre für einige Konfigurationen ein externer Speicher in Form einer SD-Karte gut (z.Bsp. auch Bilder/Icons für die Lokwiedererkennung, Langzeitgedächtnis, LOK-DB (Adressen, Format für lokalen Einsatz und Aufruf)

PS: Gegen einen fein aufgelösten Drehencoder kommt meiner Erfahrung nach keine Poti-Lösung an, ebenso (sieh oben) bezüglich der thematisierten Problematik Handover zwischen Bedienteilen.

LG

wassi

wassi@70:
Die Problematik mit der Synchronisation mehrerer Geber existiert natürlich.
Aber es gibt auch Motorpotis
Werden im professioniellen Audiobereich im Mischpult immer noch verwendet... die Haptik ist einfach besser als ein Tipp-Schirm.....

Ich habe zur Speicherung "meiner" Werte zwei Stück 32kByte EEPROMs genommen. Da passt allerhand rein.......
[Edit:
SD Karten kann man nur schwierig mit einem µC ohne Betriebssystem nutzen.
Und da ja eh die ganze Config in der Zentrale sein soll, tut's auch ein/mehrere EEPROMs.
Schreiben und Auslesen dann über PC.
\Edit]

"Mein" Bedienteil kommt im Normalfalle per I2C an die "Zentrale" und die dann an den PC.
Aber um nur mal eben etwas fahren zu lassen, geht es auch ohne PC.

Aber es ist auch möglich, den Analogregler via I2C von z.B. Rocrail steuern zu lassen... oder auch umgekehrt
Wenn man sich die OpenDCC Zentrale anschaut, so ist es durchaus möglich, damit auch Analogregler zu steuern zumindest, wenn diese per Bus (I2C oder SPI oder UART) angesprochen werden können.

Habe auch mal meinen "Systemplan" online gestellt:
http://www.aca-modellbahn.de/ElektronikSchaltungen/System/System.html

Es steht übrigens nirgendwo, dass man DCC oder SX oder was auch immer nicht über RS485 übertragen werden darf Nur im Protokoll ein Bitfeld vorsehen, das angibt welcher Typ von Daten gleich kommt.

Wenns zuviel Eigenwerbung ist, dann bitte etwas sagen

Hi,

habe gerade mal die USB_CDC Routinen  von Uwe.B. integriert und so erweitert,  dass jetzt printf auf die untere (Micro)-Usb  via ST Virtual Com Port geht.

Ist hilfreich beim Ascii-Debug

LG

wassi

Hi,

was haltet Ihr davon für die "Oberfläche" auf dem Touch die Stemwin (Seggers emwin für ST) zu verwenden ?

http://www.st.com/web/en/catalog/tools/PF259225

+ einfache und einigermaßen übsche GUI
- fixiert auf ST µC, Portierung auf andere nicht ohne Kosten möglich

LG

wassi

Hi,

habe lange Zeit nichts vom 1zu160HR hören gelassen,

die STemwin habe ich wieder fallen gelassen, war zwar hübsch und auch recht einfach zu verwenden, jedoch auch sehr Resourcen hungrig.

Heute mal wieder ein update ins git (siehe oben) gestellt.

LG

wassi

Hallo,

hat den schon jemand entdeckt?

http://www.esu.eu/produkte/digitale-steuerung/mobile-control-ii/

Gruß
Ralf

Hallo Ralf,
sehr interessant, ein schöner Spagat zwischen Touchbedienung und Haptik. Leider funktionierts nur mit der Ecos, die ist mir aber ein "bisschen" teuer :)

Viele Grüße
Carsten von 1001-digital

Hallo Carsten,

zunächst funktioniert es nur mit der Ecos, andere Hersteller/Entwickler sollen aber eigene Apps entwickeln können um das Teil in ihre Umgebung anbinden zu können.

Gruß
Ralf

Hallo Ralf,

bei einem Preis von ca. 300,00 € wird das aber auch bei Anpassungen an andere Umgebungen für viele keine Alternative werden. Mir ist es als Handregler auch zu  teuer.

Gruß Gerd

Hallo Gerd,

ich habe bislang keinen Preis gesehen, aber 300 € wäre natürlich schon eine Hausnummer (für einen Handregler). Andererseits wenn man die Preise für Smartphones von Apple, Samsung etc sieht, und die Hardware wird ja vermutlich ähnlich sein (nur dass die Stückzahl bei Esu im Vergleich lachhaft klein sein wird).

Gruß
Ralf

Hallo Ralf,

den Preis habe ich hier gefunden: http://www.digitale-modelleisenbahn.de/downloads/esu_neuheiten_2014.pdf .
Bei Smartphones gebe ich aber keine 300,00 € für einen Handregel aus, sondern habe eine alternative Nutzung für ein vorhandenes Gerät. Ich würde auch keine 300,00 € für ein Smartphone ausgeben, wenn ich damit ausschließlich die MoBa steuern wollte. Der Rest der Steuerung (Zentrale, Booster, etc.) kommen ja noch dazu!
Wer bereit ist so viel auszugeben, der bekommt nach der Herstellerbeschreibung wohl einen tollen Handregler.

Gruß Gerd

Hallo Gerd,

vielleicht kauft man ja bei ESU einen Handregler für die Modellbahn mit dem dann als Goody auch noch telefonieren kann.

Gruß
Ralf

Gruß Gerd

Hallo

genau so habe ich mir einen Handregler vorgestellt. 3 Meter Spiralkabel dran und fertig Brauche keinen Funk.

Gruß Michael

Hi,

der 1z160HR kann nun schon auf dem Xpressnet Bus mit lesen

Beim Schreiben zum XP-Bus bin ich mir noch nicht ganz sicher wie die Zuordnung eines Handreglers zu den 31 Transmissions-Windows ablaufen soll.

bei den meisten Implementierungen habe ich folgendes gefunden:

händisches Festlegen (SimpleMaus, MiniMaus) : was bei Kollision mit zweiten Regler gleicher Adresse?

Die Roco/Fl Multimaus hat hier eine Automatik (man kann eine default Adresse vorgeben, aber beim Auftreten eines Addr-Konfiktes sucht sie sich einen andere) Leider ist der Algorithmus hier nicht in der Anletung beschrieben.

Auch die Lenz Doku zum Xpressnet-Protokoll schweigt sich hier aus.

Ich könnte mir ein Art History über den letzten Zeitpunkt wann welcher Slot das letzte mal von anderen Teilnehmern benutzt wurde vorstellen. Bei Kollision würde ich dann automatisch den ältesten daraus nehmen.

Nach dem Wechsel müßte ich dann ein Loco operations mit "meinen" aktuellen Betriebsdaten (speed, richtung,..) an die Zentrale im neuen Slot senden, damit ich sie dann "übernehme" im neuen Slot.

LG

wassi

Ich höre von befreundeten Modulbahnern, dass diese Automatik an einer Lenzzentrale nicht notwendigerweise funktioniert. Könnte sein, dass sie sozusagen orginal gar nicht dazugehört? Dann könnte man ja lange bei Lenz nach einer Doku suchen.

Gruß,
Harald.

Hi,

also die Multimaus Automatik geht zumindest an der opendcc z1 und der org. fleischmann Boosterbox ohne Probleme

Lg

wassi