Das heißt, in der Zentrale werkelt ein Programm, das die Teilnehmer entsprechend miteinander zuordnet und den Datenverkehr steuert.
Der Vorteil iegt darin, dass man neben den ZigBee-Modulen je nach ihrer vom Hersteller mitgegebenen Programmausstattung keine weitere Rechnerintelligenz auf der Teilnehmerseite braucht, um dort digitale Ausgänge zu setzen, analoge Spannungen und Eingänge zu lesen. So etwas ist dann relativ schnell gemacht und ins Laufen zu bringen. Der hauptsächliche Nachteil liegt darin, dass man wegen des Befehls- und Datenformats dann auf einen Hersteller festgelegt ist.
Im zweiten Fall arbeitet der Netzkoordinator für sich allein, denn in den Fahrzeugen und Handsteuergeräten sitzt jeweils zusätzliche Rechenleistung, die sich um die Datenaufbereitung und -verkehr kümmert. Z.B. weiß jeder Handregler schon von vornherein, welchem Fahrzeug er seine Daten zu schicken hat und es kann auch eine Tabelle für mehrere Loks dort abgelegt werden.
In dem Fall ist eine Zentrale nicht nötig und es können auch ZigBee-Module anderer Fabrikate in das Netz eingebunden werden. Er entspricht auch ziemlich dem WLAN-Betrieb.
Der Unterschied zu WLAN besteht aber weiterhin darin, dass im Netz eine Maschenstruktur herrscht, d. h. falls sich Absender und Adressat direkt 'sehen', gehen die Daten ohne Umweg dorthin. Nicht für den Adressaten bestimmte Daten werden an den nächsten Teilnehmer weitergeleitet und springen so über die verteilten ZigBee-Devides zum Ziel.
Statistik: Verfasst von ateshci — Do 18. Jun 2015, 11:49
]]>
ateshci hat geschrieben:Spaßeshalber sind von den 8 benutzten ( es sind noch 3 frei, ebenso die serielle Schnittstelle) Ausgängen des Empfängers 4 rastende Ausgänge (Beleuchtung ein/aus) und 4 Momentausgänge ( Ausgang so lange an, wie Taste gedrückt) im Programm eingestellt.
Konnte diese beliebige Zuordnung eigentlich WLANCROC oder WLAN-TL?
Hallo Heizer,Konnte diese beliebige Zuordnung eigentlich WLANCROC oder WLAN-TL?
geplant war vieles ... aber soweit ist das ursprüngliche WLANCROC-Projekt nicht mehr gekommen.
Nach meinem Kenntnisstand sind die Ausgänge bei WLAN-TL nur als rastend vorgegeben. Aktuelle Bedienungsanleitungen sind als Nichtkäufer weder vom Entwickler noch von Trainline zu bekommen. Angeblich steht die Anleitung im Netz. Die dem ausgelieferten WLAN-TL-Raspi beigelegte Anleitung ist allerdings eine andere. Eine Anfrage von mir bei Trainline bestätigte die nur rastenden Funktionsausgänge.
Viele Grüße
Holger
Statistik: Verfasst von gatzi — Do 18. Jun 2015, 01:40
]]>
Einlesen von Kippschalter und Tastern für Richtungsvorgabe und Funktionsauslösung. Spaßeshalber sind von den 8 benutzten ( es sind noch 3 frei, ebenso die serielle Schnittstelle) Ausgängen des Empfängers 4 rastende Ausgänge (Beleuchtung ein/aus) und 4 Momentausgänge ( Ausgang so lange an, wie Taste gedrückt) im Programm eingestellt.
Konnte diese beliebige Zuordnung eigentlich WLANCROC oder WLAN-TL?
Rückmeldung der Akkuspannung des Fahrzeugs auf ein per LAN-Kabel am Raspi angeschlossenes Tablet. Hier wird also parallel noch ein Netzwerk ( mit 2 Teilnehmern) unter Linux betrieben.
Statistik: Verfasst von ateshci — Do 18. Jun 2015, 00:03
]]>
Statistik: Verfasst von ateshci — Fr 12. Jun 2015, 23:11
]]>
Statistik: Verfasst von ateshci — Mo 8. Jun 2015, 00:36
]]>
Hallo Gartenbahntechniker,
einen Raspberry Pi lediglich zur WLan Steuerung eines Stepper Motors ist im Vergleich zu neueren WiFi-Modulen wie dem ESP8266
technisch und preislich nicht in jedem Fall sinnvoll.
Billiger und effektiver geht es so:
Michael
Statistik: Verfasst von Adler Nbg — Mi 25. Feb 2015, 18:10
]]>
anbei eine (noch nicht getestete!) Schaltungsskizze zur Messung von Back Emf an einem digitalen Eingangspin des Arduino:
Hier zeige ich die Digital-Pin Variante.
Für den Digital-Pin wirdeine kleine Schaltung mit Komparator bspw. LM393 benötigt, Materialkosten ca. 1,36 Euro zzgl. Lochstreifenplatine und Versandkosten
bei bspw. reichelt de.
Vorteil dieser Digital-Pin Schaltung: im Prinzip kann der gleiche Softwarealgorithmus wie beim TLE-Hall-Sensor am Digital-Pin angewendet werden.
Allerdings muß dabei die Schaltung für die gewünschten Motor-PWM-Frequenzbereiche saubere Signale liefern und entsprechend angepasst werden
(Das wäre zu testen).
Siehe dazu die Diskussion hier im Forum.
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — Mi 20. Aug 2014, 19:20
]]>
Die Kamera würde ich noch Direkt auf den Servo Packen, sondern auf ein Kugellager. Für die Ansteuerung gibt es dann zwei Möglichkeiten, die erste wäre über ein Gestänge/Bowdenzug, oder aber die zweite über Zahnräder.
Ich habe sowas mal mit einem Fotoapparat gemacht, der wurde auf ein Kugellagergelenk montiert, und das was sehr leicht drehbar, die gab es mal bei Ebay günstig, das war ein viereckiger Block wo es drinnen lag, und auf der oberen Platte war die Schraube für den Fotoapparat.
Grüsse
Statistik: Verfasst von Nobody — So 27. Jul 2014, 07:44
]]>
Damit hier auch wieder mal was weitergeht:
Zufällig ist mir die Software für die Steuerungskette Android-Tablet --((wlan))--> Raspberry Pi --[[i2c]]--> Microcontroller (Atmel ATMega) untergekommen, die ich im Weihnachtsurlaub erstellt hatte. Endlich ausprobiert - es läuft. Die Servos bewegen sich. Jetzt läuft es noch über Schieberegler, im Endeffekt dann aber einfach über die Position des Fingers im gestreamten Kamerabild.
Jetzt muss ich mir noch ansehen, wie ich die Kamera gut am Servo befestigen kann.
Ein paar Gedanken zum weiteren Projektverlauf:
Wenn man wie von Karl vorgeschlagen die Achs-Auslenkung per Poti misst, kann man ja leicht softwaremäßig konfigurierbar machen, ob die Kamera mitlenken soll, oder nicht. Das bleibt dann dem Benutzer überlassen.
Aufzeichnung und Stream sollte kein Problem sein, jedoch empfiehlt es sich, die Aufzeichnung auf der SD-Card im Raspi zu machen, statt die vollen Daten übers WLAN zu schieben. So kann man die volle HD-Qualität aufzeichnen und ggf. einen abgespeckten Stream zum Steuerungsgerät senden. Schließlich will man das Bild für die Steuerung ohne Verzögerung haben.
Mithilfe von node.js am Raspi (von Michael Feldmüller bereits getestet, glaube ich irgendwo gelesen zu haben) sollte auch eine Browser-Steuerung für i-Geräte möglich sein.
Schöne Grüße,
Michael
Statistik: Verfasst von michaelb — So 27. Jul 2014, 01:59
]]>
Danke für Dein positives Feedback. Ich habe irgendwann mit Fritzing Skizzen angefangen, weil diese recht anschaulich die mögliche Realisierung eines trockenen Schaltplans als Heimwerker-Bastelschaltung zeigen.
Das Löten nach Fritzingskizzen fällt mir leichter. Dabei stelle ich oft notwendige Änderungen fest, weil bspw. die
Größe der elektronischen Bauteile eine andere Anordnung erfordert oder die Lochstreifenplatine zum passenden Einbau in die Lok anders dimensioniert werden muß usw.
Diese Änderungen übertrage ich wiederum in die Fritzing-Skizze.
Klasse wird es dann, wenn man zu diesen veröffentlichten Skizzen konstruktive Kritik und Fragen bekommt,
denn dann wird das Ergebnis immer weiter verbessert.
Ich werde demnächst auch mal die größeren und kleinen Rückschläge in meinem Bautagebuch zum Taurus mit veröffentlichen. Aus Fehlern lernt man ja auch. Manche sind mit Abstand betrachtet recht lustig.
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — Sa 5. Jul 2014, 16:20
]]>
Ich möchte hier auch mal meinen Dank aussprechen. So tief wie Du und Rainer bin ich nicht in der Materie, aber mit dem was Du hier einstellst fällt es mir erheblich leichter der Sache zu Folgen. Ich finde es sehr interessant. Und die Grafiken sind der Hammer. Die werde ich zukünftig auch für meine Dokumentationen nutzen.
Danke, und mach bitte weiter, ich sauge das gerne auf, auch wenn es mit dem verstehen noch nicht so klappt.
Grüsse
Statistik: Verfasst von Nobody — Sa 5. Jul 2014, 13:47
]]>
ich stelle bewußt die Anwendungen separiert da, um mich später in meinem Bautagebuch zum Taurus beim Einbau
auf diese Darstellung zu weitergehenden Information beziehen zu können.
Die SuSi Schnittstelle ist recht gut dokumentiert:
http://www.nmra.org/standards/DCC/stand ... nglish.pdf
Ein Prograemmchen für den Arduino ist damit schnell geschrieben.
Die Herausforderung liegt im Zusammenspiel der Anwendungen (Programm-Module).
Konkret möchte ich alternativ zu dem Raspberry Pi ein "altes" Soundmodul mit SuSi Schnittstelle in meinem Projekt "recyceln".
Sobald ich damit weiter bin, stelle ich das Ergebnis hier gerne vor.
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — Do 3. Jul 2014, 17:59
]]>
vielen Dank für die umfangreichen RasPi-Zusammenstellungen. So wird es sicher für jederman verständlicher.
Die Darstellung mittels Fritzing ist sehr hilfreich und dient mir auch zur Doku meiner Aktivitäten. Denn wer kann sich
nach längerer Zeit schon an alle Details eines Lokumbaus erinnern.
Bei der SuSi-Schnittstelle würde mich interessieren, wofür Du sie einsetzt. Vielleicht kannst Du mal ein Beispiel einstellen.
LG aus Düsseldorf
Rainer
Statistik: Verfasst von Rainer — Mi 2. Jul 2014, 11:33
]]>
nachfolgend zeige ich eine einfache "SuSi-Schnittstelle" am Arduino und dem RasPi.
Die Schnittstelle stelle ich aus Anschauungsgründen einzeln vor.
Softwareveröffentlichung hier (in Vorbereitung):
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — Sa 28. Jun 2014, 13:54
]]>
hier findet Ihr nachfolgend eine Schaltskizze für eine "DCC-Leseschnittstelle" an einem Arduino und dem RasPi:
http://www.fairchildsemi.com/pf/6N/6N137.html
Auszug des Schaltungsprinzips des Optokopplers:
6N138 und HCLP0500. Diese sind um den Faktor 10 "langsamer" als
der 6N137, aber funktionieren auch.
Es folgt der Bau der Platine.
Zurechtschneiden einer Lochstreifenplatine mit Breite: 4 Streifen und Länge: 14 Loch:
Softwareveröffentlichung hier (in Vorbereitung):
Viele Grüße
Michael
Statistik: Verfasst von Adler Nbg — Sa 28. Jun 2014, 13:10
]]>