Motorregelung, Schaltausgänge, I²C-Bus und App für's Wischfon.
Das Ganze muss dann den Teilnehmern so zur Verfügung gestellt werden, dass sie es mit einem Bootloader in ihre AT2561-MC-Platine hineinbekommen.
Bei der Apperstellung plädiere ich heftigst für Mintoris-Basic ( koste zwar auch noch einmaligl ca. 7.-€ Lizenz ), aber da laufen die Apps wenigstens und es ist ( jedenfalls für mich ) wesentlich verständlicher, wie ein Befehl samt Parameter aufgebaut sein muss.
Die 'Stromfresserei' des WIZNet ist mit 1,5W zwar recht hoch, aber mit einem 3,3V-Schaltnetzteil aus einer 4S-LiPo-Bordversorgung (~15V ) sind das primär auch nur noch ~120mA. Aber wesentlich ist, dass man ohne Änderung z.B. genauso gut ein WiFly RX170 hinhängen kann und es läuft alles wie gewohnt.
Statistik: Verfasst von ateshci — Mi 28. Jan 2015, 11:25
]]>
ich bin grundsätzlich nicht auf eine Hardware festgelegt. Rapsi und Wiznet sind Stromfresser. Da schon vorhanden, würde ich das Wiznet vorziehen.
Ziel für mich aber ist eine kleine, Strom sparende Bauweise, die gerne für die jeweilge Aufgabe optimiert sein kann. Nur der unendlichen Möglichkeiten wegen würde ich nicht überall einen Schuhkarton einbauen wollen/müssen, der mir innerhalb von Minuten den Akku leer lutscht. Wenn die Elektronik soviel Strom verbraucht wie der Motor selbst, sollte solch eine WLAN-Lösung eher stationär betrieben werden.
Viele Grüße
Holger
Statistik: Verfasst von gatzi — Mo 26. Jan 2015, 22:12
]]>
als erstes die Projekthardware fertig zum Einsatz bringen und dabei wahlweise Wiznet oder RasPi als Funkempfangsmodul verwenden (aus wenn der RasPi eine Spatzenkanone ist). Damit kommen wir denjenigen entgegen, die die vorhandene Hardware einschließlich des Wiznet "aufbrauchen" wollen. Ich kann durchaus nachvollziehen, dass Einige ihr teures Wiznetmodul nicht ohne weiteres entsorgen wollen, solange es noch funktioniert.
Bei Michael ist es etwas anders, er hat kein funktiontüchtiges Wiznet mehr und bei mir, gut ich würde aus Bequemlichkeit lieber RasPi aus meinem Bestand als Wiznet (ebenfalls aus meinem Bestand) nehmen.
Für die Dokumentation könnte ich mir aber auch vorstellen, die "Musterlösung" (auch) mit dem Wiznet aufzubauen.
Die von Dir bereits aufgezeigte Alternative (andere WLAN-Hardware) würde ich persönlich lieber erst als spätere Idee vertiefen. Ich gebe zu, in meine WLAN-Loks paßt immer noch mindestens ein RasPi. Das sind vielleicht andere Voraussetzungen als bei Dir, weil ich mit Schwerpunkt immer noch (und auch weiterhin) DCC oder 40MHz fahre.
Schöne Grüße
johannes
Statistik: Verfasst von Pirat-Kapitan — Mo 26. Jan 2015, 17:46
]]>
Und dann als zweites: Soll das nun auch auf den Raspi als Koordinator mit seinem recht großen Platzbedarf gesetzt werden? Nach meiner Meinung ist das Ding, wenn man nicht gleich unbedingt Videostreaming von der Lok und direkte Sprachein/ausgabe samt Mikrofon und Lautsprecher installiert, eigentlich eine Spatzenkanone. Zum direkten Regeln des Motors ist er unbrauchbar und zum Inkrementalgeberauswerten reicht auch ein AT-µC ( der dann gleich auch noch die Motorregelung und einiges mehr kann )
Statistik: Verfasst von ateshci — Mo 26. Jan 2015, 13:19
]]>
Bei der Doku bin ich gerne behilflich, ich habe ja auch schon die zu Wiznet-Teil zusammengestellt. Das würde in meinem Falle wieder PDF werden, da ich HTML immer noch nicht kann und ich meine eigene Doku nach wie vor in Word 2003 schreibe.
Mit meinen zwei Projekt-Teilesätzen kann ich einen für die beispielhafte Doku verwenden und mich am anderen "austoben".
Schöne Grüße
johannes
Statistik: Verfasst von Pirat-Kapitan — Mo 26. Jan 2015, 11:10
]]>
ateshci hat geschrieben:Konsequenz ist gefordert - entweder Ihr haut das Zeugs in die Tonne ( glaubt doch bloß nicht an den Weihnachtsmann, aber der nimmt ja auch nichts zurück ), oder wir tun uns zusammen und retten das Ganze.
Da ich nicht (mehr) an den Weihnachtsmann glaube, bin ich natürlich weiterhin dabei. Von technischer Seite geht es mir wie HP1. Zielgerichtete Fragen und Kommentare kann ich beisteuern.Viele Grüße
Holger
Statistik: Verfasst von gatzi — So 25. Jan 2015, 22:33
]]>
Ein Statusbericht von mir:
Ich habe über Weihnachten meine alte Lok-Software soweit an die WLANCROC-Hardware angepasst, dass es rudimentär laufen sollte. Gelaufen ist es dann nicht, weil die beiden Wiznet-Module wieder mal nur Probleme gemacht haben. Ich kann sie jetzt selbst über das Raspi nicht mehr ansprechen (was bisher immer gut geklappt hat). In dem ganzen Ärger habe ich auch noch mal das 3,3V Modul mit 5V versorgt. Wobei das noch das beste Ergebnis brachte, denn danach kam ich auf ein "Redboot"-Prompt des Wiznet-Moduls, das ist sozusagen die Ebene unter der Wiznet-Firmware. Praktisch bedeutet das, dass ich keine einsatzfähigen Wiznet-Module mehr habe (und mir ganz sicher auch keine mehr anschaffen werde).
Somit werde ich nur mehr mit Raspis weitermachen. Ich habe deshalb an der Raspi-Software weitergearbeitet, dann aber nicht mehr viel Zeit dafür gehabt, sodass es noch nicht ganz fertig ist.
Das Wiznet-Fiasko an sich ist aber kein Beinbruch, da das Raspi bei mir genau wie das Wiznet seriell mit dem Mikrocontroller verbunden wird und somit beide Lösungen verwendet werden können. Im Fall des Raspi wird die serielle Schnittstelle mit dem Bootloader verwendet, sodass auch die Updates über diesen Weg ohne Umkonfiguration laufen können.
Natürlich sind auch in der Loksoftware noch ein paar Bugs, die noch ausgemerzt werden müssen. Aber das wird sich relativ schnell ergeben, sobald die Steuerung über das Raspi läuft.
Wenn die beiden Software-Komponenten halbwegs laufen, werde ich alles (ATMega-Firmware, Raspi-Software und Android-Steuerung) auf Github hochstellen, damit auch andere das begutachten, weiterverwenden oder verbessern können.
Für die Nicht-Techniker kann dann gemeinsam eine Anleitung für eine praktikable Standard-Lösung erarbeitet und dokumentiert werden.
So sieht jedenfalls mein Plan aus. "Original"-WLANcroc ist, was mich betrifft, gestorben.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — So 25. Jan 2015, 22:04
]]>
Somit kann ich leider lediglich Ideen und Wünsche liefern.
Viele Grüße vom Hauptsignal
Statistik: Verfasst von Hp1 — So 25. Jan 2015, 20:58
]]>
Ihr könnt natürlich auch weiter einem gewissen Herrn hinterherheulen...
Statistik: Verfasst von ateshci — So 25. Jan 2015, 18:22
]]>
Vielen Dank für die rege Beteiligung. Das macht richtig Freude und bringt uns ordentlich weiter!
Auch wenn ich nicht auf alle angesprochenen Details sofort eingehen kann, werde ich alles in Bezug auf die Lok-Programmierung durchdenken und dann wieder zusammenfassen.
Ein weiter wichtiger Schritt ist noch notwendig: wir müssen noch definieren, wie die grundlegende "Hardware-Umgebung" in der Lok aussehen soll, in der die Projekt-Module, allen voran Mikrocontroller und WLAN-Modul, sicher und stabil arbeiten können. Ich werde dazu einen Thread im Hardware-Bereich anlegen: Hardware-Umgebung in der WLAN-Lok - Diskussion.
Mit dieser "Hardware-Umgebung" muss die Lok-Software zusammenarbeiten, wenn es zB. um Notstop, Akkuversorgung, Spannungsüberwachung, "analog fahren" usw. geht. Ohne das können wir die grundlegenden Anfoderungen an die Lok-Software nicht vollständig definieren.
@Heizer: keine Ahnung, was da los ist, ich kann auch meine Beiträge hier wie gewohnt ändern.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Do 21. Aug 2014, 23:45
]]>
Bei niedriger EMK ist die Flußspannung der Dioden eigentlich zu berücksichtigen. Also nochmal:
( Ergänzung: Wechsel von FF auf Chrome half in meinem Fall )
Statistik: Verfasst von ateshci — Do 21. Aug 2014, 20:29
]]>
]]>
ich würde nur einen Notfall/Stop-Befehl an die Lok geben, in der dann ein Wert hinterlegt ist, wie sie reagieren soll.
Wenn man die ohnehin hinterlegte Beschleunigungs-/Verzögerungskurve zum Notfallbremsen hinzuzieht, brächte man nur einen Faktor/Stellwert, der ggf. diese Verzögerungszeit reduziert. Dieser Wert wäre beliebig wählbar, so dass der Bremsweg bis auf "sofort Stopp" verkürzt werden kann. Default-Wert könnte dann z.B. 1/3 "Normalbremsweg" sein.
So kann jeder seine Loks individuell anpassen, was nicht unwichtig ist bei schweren Selbstbauten aus Metall oder Loks, die oft vor lange Züge gespannt sind.
Ein echtes "Power Off" ist beim Funkfahren ohnehin etwas aufwändiger, da die Loks über permanenten Schienenstrom (mit/ohne Puffer) oder Akku gespeist werden. Dazu müsste in der Lok extra ein Relais installiert werden, dass die Stromzufuhr abklemmt.
Viele Grüße
Holger
Statistik: Verfasst von gatzi — Do 21. Aug 2014, 15:51
]]>
@ Holger:
bei meinem Digitalsystem gibt es (neben dem Anhalten per Fahrregler) 2 Modi, um die Lok im Notfall zu stoppen:
1. Zentrale sendet an alle Loks / nur die Lok des Fahrreglers das Kommando Fahrstufe 0 sofort. (Notstopp).
2. Zentrale schaltet auf kommando den Strom ab. (Power OFF) Dann fahren gepufferte Loks gemütlich weiter, bei mir durchaus 1,5m und mehr. Dieses Stromabschalten ist also nicht zwingend zielführend, wenn in einer Gefahrensituation die Lok schnell zum Stand kommen soll.
Praxis: LGB-Lok (RhB 644) als Sololok, Gewicht ca. 7 kg
Anhalten aus voller Fahrt über Fahrregler (von 99% blitzartig auf 0%) ca. 6,5m (hohe eingestellte Verzögerung)
Anhalten mit Notstopp ca. 0,5m
Power OFF ohne Pufferung kann ich an dieser Lok nicht testen.
Wenn ich das richtig in Erinnerung habe, wird bei Notstopp der Befehl "Fahrstufe 1" an den Decoder gesendet, worauf der Decoder ohne die einprogrammierte Bremsverzögerung anhält.
Also wären m.E. 2 Modi zu berücksichtigen:
- normales Anhalten / Abbremsen mit eingestellter Verzögerung
- Nothalt-Anhalten via extra / gesondertem Kommando ohne eingestellte Verzögerung.
Mein Funkhandregler kann noch eine 3. Alternative:
zuerst wird Nothalt an alle Loks gesendet und dann, wenn ich innerhalb von 4 Sekunden die Nothalttaste ein zweites Mal bettätige, wird das Power OFF Kommando gesendet. In diesem Falle hat ja die Lok schon den Befehl zum Anhalten bekommen, so dass eine Weiterfahrt aus der Pufferung nicht mehr erfolgt.
Schöne Grüße
Johannes
Statistik: Verfasst von Pirat-Kapitan — Do 21. Aug 2014, 14:48
]]>
@all
Nach dem Durchlesen des verlinkten Threads aus dem amerikanischen Forum veranstalten die das doch nur, weil der ARM7 keinen A/D-Wandler besitzt. Es ist und bleibt eine "Von hinten durch die Brust ins Auge"-Lösung, wenn man die Gegen-EMK nicht messen kann und auf extrem langsame Umdrehungen aus ist.
Ausserdem muss auch da die Brücke zur Messung abgeschaltet werden mit den gleichen Potentialproblemen.
Statistik: Verfasst von ateshci — Do 21. Aug 2014, 12:59
]]>