ja, ich bin gerne bereit, zu unterstützen.
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — Di 9. Sep 2014, 09:41
]]>
Zum Thema Wiki:
Ich würden die Verwaltung des Wikis übernehmen (vermutlich zusammen mit Michael Feldmüller, wenn ich da falsch liege, bitte protestieren..). Füllen und bearbeiten würde ich alle interessierten Forums-Mitglieder lassen, die sich darum bemühen - es soll ja Team-Arbeit entstehen. Der Einfachheit halber also Berechtigung auf Anforderung, da die Anzahl der Füll-Willigen ohnehin überschaubar sein dürfte. Probleme mit Spam gäbe es dann auch nicht.
Im Wiki kann dann neben WLANcroc und WLAN-Zukunft natürlich auch die restliche Gartenbahntechnik übersichtlich dokumentiert werden, daher würde ich als Namen "Gartenbahntechnik Wiki" vorschlagen.
Ich kann jedenfalls Dokuwiki empfehlen. Das System und die Installation sind "relativ" einfach.
https://www.dokuwiki.org/de:dokuwiki
Eine weitere Alternative gäbe es noch: dass man die die Dokumentation auf GitHub macht. Das ist grundsätzlich eine Versionsverwaltung (nicht nur) für Software und bietet auch Wiki-Funktionalität. Das würde unter einer Gartenbahntechnik-"Organisation" laufen, wo auch die Zusammenarbeit/Berechtigungen gemanagt werden können. Die Wiki-Funktionalität habe ich hier getestet.
Vorteil: du hättest keine Arbeit/Belastung mit der Installation/Administration
Nachteil: es ist dann natürlich komplett unabhängig vom Gartenbahntechnik-Forum und würde nicht unter dessen Internet-Adresse laufen. Man könnte nur per Link aufs Forum und die Diskussionen verweisen.
Zum Forum:
Die ungenützten Forums-Gruppen hast du ja schon entfernt. Einige der Unterteilungen könnte man noch zusammenfassen:
Die 3 Gruppen zu einer einzigen zusammenziehen:
- Vorstellung des Projektes Wlan
- Aktueller Stand
- Generelles Konzept – Visionen und Ideen für die Zukunft
"WLANcroc – Steuerung über Android mit grafischer Benutzeroberfläche" -> in "Alles rund um die Software" integrieren
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Di 9. Sep 2014, 00:13
]]>
So, nun habe ich mir das alles nochmal durchgelesen, warum, ich hatte Karl nach dem ersten Teil des Projektes gesagt das ich pausieren muss, da ich beruflich mehr als stark eingespannt war, und mein Hobby und die Gartenbahn brach gelegen haben. Daher war hier auch nicht viel passiert. Es wird nun langsam etwas ruhiger, aber es ist immer noch knackig, und wird es auch noch dieses Jahr so bleiben.
Daher habe ich das Projekt nur leicht verfolgt. Ich hatte Karl mitgeteilt das ich das WLANcrocprojekt etwas zusammen schrumpfen wollte und zusammenfassen da es nicht weiter ging, aber wie es scheint ändert sich das. Soll es unter dem Namen weiter gehen, oder unter einem eigenem Projekt?
Zum Thema Wiki, das bin ich gerne bereit einzurichten, muss mich da aber erst reinRbeiten, Vorschläge nehme ich gerne an, und es muss Ein oder mehrere Personen geben die es füllen und bearbeiten dürfen.
Wenn also Interesse daran besteht, werde ich es auf den Servern einrichten.
In wie weit ich helfen kann, keine Ahnung, programmieren kann ich nicht, im Basteln kenne ich mich was aus, und testen/nachbauen würde gehen, aber nur in begrenztem Masse, da ich immer noch beruflich stark eingespannt bin.
Ich fände es gut wenn das Projekt einen Abschluss finden würde.
Grüße
Philipp
Statistik: Verfasst von Nobody — Sa 6. Sep 2014, 10:17
]]>
Für die Diskussion zur Software (-Erstellung) habe ich einen eigenen Thread angelegt:
Open Source Lok-Software für WLANcroc - Diskussion
Schöne Grüße,
MichaelB
Statistik: Verfasst von michaelb — Mo 18. Aug 2014, 00:40
]]>
michaelb hat geschrieben:Wenn wir für die Software so etwas wie GitHub verwenden, können ja auch mehrere Leute an einer Software arbeiten und die Übersichtlichkeit bleibt trotzdem gewahrt. „Open Source“ soll es ja sowieso werden.
Hallo Zusammen,für die vorgestellten RasPi-Projekte werde ich die Software entsprechend demnächst hier online stellen.
(Die anderen Verzeichnisse werden meine Android App und die (von mir bevorzugte) Internet-Browser basierte Steuerungsoberfläche enthalten).
Da ich keine kommerziellen Absichten hege (Hobby bleibt Hobby
), stelle ich diese unter die MIT-Lizenz (= Alles erlaubt, nur freundliche Nennung der Ideenlieferanten, keine Haftung für Fehler...).
Und dann geht es an das gegenseitige Verbessern.
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — So 17. Aug 2014, 13:29
]]>
]]>
natürlich bin ich weiter dabei, allerdings kann ich bei der ganzen Programmiererei nicht unbedingt helfen, da dies absolut nicht meine Sache ist. Deshalb vielen Dank dass die aktiven hier versuchen zu retten was zu retten ist.
Um so mehr ko.... es mich an, das der "godfather of wlan" die Welt missioniert und uns hier hängen lässt! Sorry, aber ich bin ideswegen richtig angefressen!
Dennoch würde ich versuchen weiter zu helfen wo es meine Möglichkeiten ebend zulassen.
Viele Grüße Hp1
Statistik: Verfasst von Hp1 — So 17. Aug 2014, 08:39
]]>
ateshci hat geschrieben:So wie ich es verstehe, ist der ARM allerdings ausschließlich für's Handhaben des Protokolls zuständig und soll den eigentlichen Steuerprozessor so weit entlasten, dass die Anwendung mit dem kleinstmöglichen Prozessor auskommt.
Hallo Heizer!Nur kurz Folgendes:
"The CC3100 is a standalone WiFi module and is more or less a hugely upgraded CC3000. [..]
The CC3200 is what’s really cool. It contains everything the CC3100 has, but also includes a second, completely separate ARM Cortex-M4 to run user code on. So, instead of having to implement a WiFi module and MCU on your board, you get both in 64-Pin QFN package!" [hier gefunden] oder bei TI selbst.
Bisher gibt's nur das vollgepackte LaunchPad zu Evaluierungszwecken, aber ein passendes, schmales Breakout-Board mit dem Chip könnte mir schon gefallen.. Würde ich mein tägliches hackaday.com aufmerksamer lesen, hätte ich das alles schon gewußt
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — So 17. Aug 2014, 00:08
]]>
Statistik: Verfasst von ateshci — Sa 16. Aug 2014, 21:29
]]>
Neben der Pinbelegung solle in der Doku auch eine durchgängig einheitliche Verwendung der Kabelfarben angestrebt werden. Das muss nicht normgerecht (nach welcher Norm?) sein, aber bitte im Projekt bzw. der Projektdoku durchgängig. Ausgangspunkt dazu könnte die damals schon beschworene Steuerleitung mit 31 (?) Adern (lies Kabelfarben) sein.
Ein zweiter Aspekt ist die Verwendung von farbkodierten Flachbandkabeln (z.B. bei den 10-poligen Steckverbindungen). Dieses setzt natürlich die Verwendung dieser Steckverbindungen voraus (wie z.B. ich sie verwende). Andere, die lieber die Kabel direkt an der Platine anlöten, werden dadurch aber nicht von der Nutzung dieses Farbschemas abgehalten !
@ Heizer:
dass der RasPi einen WLAN-Stick braucht, ist mir schon klar. Mein Posting hätte besser heißen müssen "WLAN-Stick mit angehängtem RasPi zur Konfiguration des WLAN-Zuganges". Mit der Wiznet-Komnfiguration hatte ich damals, soweit ich mich erinnere, keine Probleme (nun bin ich darin auch nicht unbedingt ein DAU). Allerdings habe ich noch nie die Firmware aktualisiert, da meine seit dem ersten Teil in der WLANKrok-Krabbelkiste liegen.
Schöne Grüße
johannes
Statistik: Verfasst von Pirat-Kapitan — Sa 16. Aug 2014, 18:18
]]>
Rein als Datenschleuse, solange man nicht vom MC aus rumkonfigurieren will, kann man ja jederzeit ein anderes WLAN-Modul mit serieller Anbindung verwenden.
Kürzlich habe ich beim Stöbern im Netz einen Vergleich verschiedener WLAN-Module gefunden.
Das TI CC3000 ist mir in letzter Zeit öfter untergekommen. Bei zB. Adafruit und Sparkfun gibt es ein Modul mit uFL Connector.
Es gibt bei TI auch noch CC3100 und CC3200, die man nebenbei anscheinend auch noch als MC verwenden kann.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Sa 16. Aug 2014, 14:50
]]>
Statistik: Verfasst von ateshci — Sa 16. Aug 2014, 10:48
]]>
Erstes Ziel muss natürlich sein, die "WLANcroc Phase 1" Funktionalität zu erreichen, soweit sie schon läuft bzw. durch die Küsters-Module vorgegeben ist. Es soll niemand die Angst bekommen, dass wir jetzt nur mehr vom Raspi und Billig-Boards schwärmen und die WLANcroc-Hardware umsonst gekauft wurde. Dem ist keinesfalls so! Die Komponenten sind immer noch ihr Geld wert und werden alle eingesetzt. Das modulare Konzept kommt voll zum Tragen (wie Karl immer gepredigt hat)! Wir wären aber schlecht beraten, wenn wir nicht gleich modernere Elemente einbinden würden, wo es leicht möglich ist bzw. gleich darauf achten, dass wir uns für zukünftige Erweiterungen nichts verbauen.
So zB. das "Big-Little" Konzept (Name von ARM geborgt), wo ein mächtigeres Linux-Board kleine Mikrocontroller steuert (über I2C, aber auch über UART möglich), welche die zeitkritischen Aufgaben übernehmen. Es gibt viele wirklich günstige Arduino-Clone Boards (Arduino Pro Mini oder Arduino Nano), die sich ausgezeichnet verwenden lassen. Das Wiznet bei Bedarf durch ein Raspi zu ersetzen, sollte daher eher früher als später möglich sein.
Mit bedingter Kompilierung und Hardware-Definitionen lassen sich die gängigen Atmel-Chips leicht abdecken. Die gängigen Bibliotheken machen es ja vor.
Wenn wir für die Software so etwas wie GitHub verwenden, können ja auch mehrere Leute an einer Software arbeiten und die Übersichtlichkeit bleibt trotzdem gewahrt. „Open Source“ soll es ja sowieso werden.
@Gatzi:
Da bin ich ganz bei dir. Dass wir sauber getrennt Dokumentationen zu jedem Thema in Reinschrift benötigen, ist aus unserer bisherigen Projekterfahrung klar. Ich finde aber, man sollte dabei Diskussion und Dokumentation auseinanderhalten. Die Diskussion steht am Anfang. Wenn man dann sieht, wohin es läuft, sollte sich die Diskussion in Threads zu den einzelnen Themen aufspalten. Aber Diskussionen werden immer mehr oder weniger chaotisch und unübersichtlich sein. Außerdem muss ja auch ein wenig Spass dabei erlaubt sein - schließlich ist das ein Hobby. Sobald dann bei einem Thema ersichtlich ist, dass die zu behandelnden Details halbwegs definiert wurden, sollte sich jemand an die Ausarbeitung der Dokumentation (in einem eigenen Thread) machen. Diskutiert wird im zugehörigen Diskussionsthread, auch über die Dokus, die ja im weiteren Verlauf noch geändert oder erweitert werden können. In der Dokumentation wird NICHT diskutiert (ggf. dann etwaige Postings verschieben bzw. umkopieren und löschen, wenn sich das irgendwie einrichten läßt). Die Dokus könnte man im Thread-Titel mit dem Prefix "DOKU:" oä. kennzeichnen.
Eine andere (bessere) Möglichkeit wäre, die Dokus in einem Wiki anzulegen. Ich weiß nicht, ob sich Philipp damit anfreunden könnte, noch DokuWiki oder eine ähnliche Software auf seinem Server zu installieren? Es würde sich aber lohnen. Ich habe leider keine praktikable Lösung gefunden, wie man DokuWiki und phpBB user-mäßig unter einen Hut bringen könnte, ohne dass man sich jeweils ein weiteres Mal anmelden müsste. Es gibt zwar teilweise Lösungen für eine gemeinsame User-Verwaltung, aber das sind üble Hacks, die dann meist mit dem nächsten Update schon nicht mehr funktionieren und nicht offiziell unterstützt werden. So etwas macht nur graue Haare.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — Sa 16. Aug 2014, 02:13
]]>
Das gemacht, kann die Arbeitsgruppe z.B. die nächste wünschenswerte Funktionserweiterung wie I²C und Servos angehen.
So kann man die Source mit entsprechenden Compilierschaltern versehen auf einer Menge (erst mal ATMEL-) Plattformen zum Laufen bringen.
Statistik: Verfasst von ateshci — Fr 15. Aug 2014, 21:29
]]>
was mir auffällt: Es deutet sich dasselbe Problem an, dass das alte Projekt letztlich kaum mehr verständlich gemacht hat:
Vieles passiert in einem Thread.
Das wird dann zu unübersichtlich.
Ich schlage vor, verschiedene Aspekte auf verschiedene Themen zu verteilen. (Im Grunde gehört mein Post auch in einen anderen Thread).
Dringend getrennt halten sollte man die verschiedenen Baugruppen untereinander (Überlappungen gibt es natürlich und sind unvermeidlich), Anleitungen und vor allem die Diskussionen.
Diskussion ja, auf jeden Fall, sind ja erst der Treibstoff, der den Wagen/die Lok ins Rollen bringt, aber die eigentliche Anleitung, das Kochrezept, sollte unter einer eigenen Überschrift zu finden sein, ebenso die Beschreibung der einzelnen Module. Das erleichtert das Auffinden mehr als jegliche Suchfunktion.
-----
Weiterhin sollten wir kurz abstecken, wie vorgegangen werden soll:
z.B. die Diskussionen um das Lastenheft könnten einerseits geführt werden, das Lastenheft selbst und seine Anpassungen aber getrennt dargestellt werden.
Vielleicht wäre auch ratsam, einmal zusammenzufassen, nach Modulen, was vorhanden ist, welche Vor- und Nachteile und ggf. welche "Zukunftsaussichten" sie haben. Daraus ergibt sich später an Diskussion was ggf. dazukäme oder etwas ersetzen kann/muss.
Kurzfristiges Ziel dürfte aus meiner Sicht sein, die vorhandene Technik zu nutzen.
Reizvoll finde ich auf jeden Fall, wenn die Software portiert werden kann, um kleinere oder günstigere MCs zu nutzen, je nach Modellanforderungen auch einzelne Module (Hard- und Software), denn nicht jede Funktion muss in jedem Modell vorgehalten werden. Das könnte der Baugröße, den Kosten und letztlich der weiteren Verbreitung dienlich sein.
Denn, wenn alles gut läuft, will man sicherlich nicht nur die "dicken Brummer" mit WLAN ausrüsten.
-----
Viele Grüße
Holger
Statistik: Verfasst von gatzi — Fr 15. Aug 2014, 19:01
]]>