[tibaum]

Hallo Joachim,

Zitat

---

Wenn die für den RFID Leser 54 € aufgerufen haben, muss ich kein schlechtes Gewissen haben

---

Was schätzt Du denn was Dein RFID Reader kosten wird?

Gruß
Timo

[joachimkr]

Ich hoffe, ich kriege das für 30 € hin.
Da der Schaltplan und das Fertigungsverfahren noch nicht klar ist, schätze ich.

[joachimkr]

Hallo liebe Mitleser,

Am 14.05. hatte ich mich mit dem aktuellen Vorgehen gemeldet.
Die ganze Zeit über habe ich nun mit dem vorhandenen Material von NXP und deren Application-Notes gekämpft, etliche Varianten ausprobiert.
Inzwischen bin ich weiter gekommen, nachdem ich meine Fehler erst gemacht, dann gesucht und beseitigt habe.
Das UID des RFIDs wird noch nicht gelesen, aber ich habe eine verifiziert funktionierende Initialisierung des Leserchips und die extrem kleine Software, von nur wenigen hundert Zeilen, erkennt ein anwesendes RFID. Sie scheitert aber noch beim Einlesen des UID, der langen Identifikationsnummer des RFID.
Ich habe den Quellcode der (wegen Umfangs nicht genutzten aber funktionierenden) Bibliothek inspiziert und gezielte Zeitsteuerungen gesehen, die mir noch fehlen.
Die Application-Notes schweigen sich darüber aus
Daher vermute ich dringend, dass nun eben nur noch das Timing stimmen muss, damit ich den UID auch noch bekomme.
Da nun aber endlich die erste RFID Interaktion funktioniert, bin ich zuversichtlich.

Viele Grüße
Joachim

[joachimkr]

Hallo liebe Mitleser,

Nur ein kurzes Update:
Heute habe ich das erste mal einen komplett korrekten UID aus dem RFID auslesen können.
Für diejenigen,die Hardware-nah programmieren:
Die Software der Bibliothek hat mir in die Suppe gespuckt; Im Hintergrund lief ein ungewollter Interrupt-Service noch parallel mit und zum zweiten hat diese Routine der Bibliothek die Hardware des Chips anschließend geblockt, so dass ich keine weiteren Interrupts mehr bekam.
Diese Bibliothek ist unfassbar komplex, deckt alle vorhandenen Chips von NXP und alle vorhandenen CPUs von NXP ab.
Daher haben die 3 Abstraktionsebenen übereinander gestapelt eingebaut, die ich alle nicht benötige und deren Größe ihren Einsatz für mich verhindert.
Ein weiterer Faktor ist, dass das Timing meiner Software für die Energie-Übertragung in den RFID und dessen Reaktion noch nicht auf meine Testumgebung abgestimmt ist. Die nächsten Schritte müssen in 'Realzeit' und mit dem Logic-Analyzer gemacht werden, um das Timing richtig einzustellen. Die Bibliothek wird nun Schritt für Schritt komplett auskommentiert, bis ich etwas Portables übrig behalte.

Für mich ist das Fortschritt - hat lange gedauert, auch weil von NXP nun leider keine Hilfe mehr kam, musste ich mich alleine durchbeißen.

Viele Grüße,
Joachim

[joachimkr]

Nochmal ein Update:
Inzwischen konnte ich mindestens die Geschwindigkeit der Originalbibliothek erreichen. Also 8 msec für den kompletten Durchlauf mit Einlesen des UID vom RFID.
Der Chip, von NXP führt ein interessantes, komplexes Eigenleben. Schade, dass in den Datenblättern keine wirklich lebensnahe Beschreibung enthalten ist, wie der arbeitet.

Aber das Entscheidende: ich habe den Quellcode in C, den ich für die Portierung auf den Bluetooth-Prozessor brauche.

[joachimkr]

Hallo liebe Mitleser,

Die Design-Entscheidung für den Prozessor ist gefallen, da der Quellcode nun sehr klein ist. Um Euch meinen Ansatz zu verdeutlichen, hier ein Bild des Prozessors. Er ist deutlich kleiner, als der RFID Lese-Chip:

Das Ding ist der graue Krümel links auf der Leiterplatte, 2 mal 3 mm klein, kein Ball-Grid, sondern auf der Fläche sind unterwärts 24 Pins, die per Reflow verlötet werden. Ich finde das schon recht abstrakt. Aber so ist die Technik eben inzwischen.

Viele Grüße
Joachim

[joachimkr]

Nur ein Update:

Die neue Prozessorplattform erfordert eine Entwicklungsumgebung, eine Musterplatine und vor allem: Einarbeitung mit Verifikation aller Schritte.
Hier ist ein kleines Video, in dem der Prozessor, der Krümel, Ausgaben auf der seriellen Schnittstelle macht, sowie eine orangene LED blinken lässt. Zu sehen ist nur letzteres. Profan, könnte man denken. Ist es aber nicht.
Nur 2 Pins des Chips werden 'geopfert', genutzt.
Wichtig: Die Bluetooth-Schnittstelle ist zugleich in Betrieb und erreichbar!
[youtu-be]https://youtu.be/mzYgaFkT_hw[/youtu-be]
Viele Grüße,
Joachim

[joachimkr]

Da die Bluetooth Software gerade entsteht, habe ich die Spezifikation, ersten Beitrag, geringfügig überarbeitet.
Details erläutert.
N-Gleise habe ich ersteinmal rausgenommen. Aufgegeben habe ich das noch nicht.

[joachimkr]

Noch ein Update:
Die intensive Einarbeitung in die Konzepte von dem Prozessor und seiner Bibliotheken, sowie Normen von Bluetooth LE hat ein paar Früchte getragen, also Software ergeben.
Zwar weiß ich ja von allem das Grobe, aber im Detail liegt dann doch viel Arbeit.
Ich kann nun große Mengen von längeren, variierenden Botschaften, also z.B. RFID Informationen zuverlässig per Funk übertragen. Der Verkehr läuft mit Quittungen, in diesem Fall durch das Smartphone, dass ja normgerecht reagiert. Das Smartphone stellt die Verbindung her, errichtet den Datenkanal und empfängt dann, was mein Prozessor ihm so schickt.
Mein Mini-Prozessor ist extrem flexibel. So ganz nebenher hat er eine serielle Schnittstelle, die für mich nur einen Pin aus dem kleinen Pool von Pins benötigt. Wer sich für 'Embedded Software' interessiert, kann sich gern per PN bei mir melden, um mehr zu dem zu erfahren.
Der Konzentrator, also die Software für den Raspi, existiert ja noch nicht, so nutze ich das Smartphone und Norm-konforme Software als Instrument, um selbst möglichst kontrolliert konform zur Norm zu bleiben. Da bei Bluetooth der 'Server', hier der RFID Reader, alle Datenstrukturen festlegt, wird der Konzentrator auch erst begonnen, wenn der Reader 'steht'.
Diese Smartphone-Testsoftware jedenfalls, zeigt die einlaufenden Daten sehr flüssig an.
Das nächste größere Ziel ist die Inbetriebnahme der Schnittstelle zum NXP Lesechip. Dann kann ich echte Daten senden. Dafür sind einige Hürden zu nehmen...

Also bis bald auf diesem Kanal... Denn derzeit bin ich unerwartet frei - gut für's Projekt, schlecht für mein Konto.

Viele Grüße an die Leser,
Joachim

[joachimkr]

Sehr kurzes Update:
Die Integration hat begonnen. Die Software passt erwartungsgemäß in den Mini. Funktionieren tut aber bislang nur der Bluetooth Anteil, da die Schnittstelle SPI noch nicht aktiviert ist. Dafür ist der Bluetooth Anteil aber wirklich gut getestet und 'clean code'.

[joachimkr]

Kurze Zwischen-Information, eigentlich nicht der Rede wert...
Ich habe mir nun 3 Tage die Zähne ausgebissen, an dem Betrieb des SPI Interface des SoC von Dialog Semiconductor,
Je tiefer ich dort eindringe, um so mehr Respekt entsteht für deren Software.
Wirklich gut gemacht. Leider ist es wie oft, dass 'selbstverständliches' nicht erläutert wird. So auch diesmal.
Also, mir gelingt der Transfer von Daten, jetzt müssen sie nur noch korrekt sein, dann steht dem Rest der Portierung eigentlich nichts mehr im Wege.

Im Bild: gekoppelte Chips, per Drahtverbindung. Hinten der Bluetooth Prozessor, vorn der NFC Chip nebst seiner Testumgebung. Die muss nun ebenfalls noch mitspielen, also ihre Finger vom Chip lassen. Das tut sie scheinbar noch nicht ganz.

[joachimkr]

Ich kann nicht anders, freue mich gerade wie Bolle. Die Kommunikation zwischen den Boards und somit zwischen den Chips klappt nun. Eine wichtige Hardware-Hürde ist genommen. Ich konnte die blaue Platine so umbauen, dass deren Prozessor keinen Zugriff mehr auf das SPI Interface des RFID Lesers hat. In den folgenden Wochen kommt für die Software der zweite Durchgang, nun auf dem neuen Prozessor. Danach folgt das erste komplette Hardware-Design - welches aber weitgehend feststeht - und schließlich wird noch das Ganze aus einem SPI Flash ROM Boot-fähig gemacht und dann wahrscheinlich viel Feinschliff. Die Arbeit wird mir nicht ausgehen.

[joachimkr]

Hallo zusammen,

Kurzes Update: Nach Beseitigung von Kompatibilitätsproblemen an der SPI Schnittstelle habe ich mit dem zuvor erarbeiteten Quellcode jetzt quasi auf Anhieb das erste vollständige Ergebnis.
Hier ein Schnappschuss, der Code ist korrekt. Er läuft beliebig oft und beliebig lange durch. Auf der oben fotografierten Plattform, also dem Bluetooth SoC Chip, mit SPI an den NFC Leser gekoppelt. Also die bunten Drähte, von Platine zu Platine.

Übrigens: Die Geschwindigkeit des Krümel-Prozessors toppt den älteren, größeren NXP Prozessor. Die Erkennungsgeschwindigkeit ist geringfügig höher. Die derzeitige Version erkennt sogar 2 zugleich im Empfangsraum befindliche RFIDs - beide werden gemeldet.
In 6 Sekunden werden 1000 UIDs ermittelt.
Die Aussage, dass kein RFID da ist, kommt schneller, als die Aussage, welchen UID das RFID trägt. Also ist das Timing gut eingestellt.
Nun können die fertigen Funktionalitäten gekoppelt werden. Das ist ein wenig herausfordernd, da kein RTOS verwendet wird. Die Funktionalitäten müssen quasi unabhängig, also asynchron voneinander erhalten bleiben.

Viele Grüße, Joachim

[joachimkr]

Kleines Update:

Man kämpft mit 'Kleinigkeiten'.
Diesmal musste der gesamte Code für Bluetooth und der für den SmartCard Reader unter eine Haube. Das bedeutete insbesondere, dass die Nutzung der I/O Pins nun in die Bluetooth App aufgenommen worden musste. Klingt trivial, ist es aber nicht. Der CPU Krümel kann jede interne Funktion an jeden Pin mappen. Also jede interne Peripherie-Einheit, wie hier der SPI Controller und eine LED Ausgabe durften nicht in Konflikte mit den Bluetooth Funktionen geraten. Anschließend musste das Timing der SPI Transfers so abgewickelt werden, dass die Bluetooth 'Connection' nicht abgebrochen wird.
Jetzt klappt das. Es werden Daten transferiert, der NFC RFID wird korrekt gelesen und an den Bluetooth Partner übergeben. Ist kein RFID im Lesebereich, wird das erkannt und ein 'wildcard' zurückgegeben. Der Code ist integriert und hat eine Chance als Basis für die Gesamtapplikation. Es geht voran.

Viele Grüße,
Joachim

[joachimkr]

Update: Allmählich wird es immer realer.
Ich stelle hier 2 Videos ein. Das erste zeigt, mit welchem Tempo ein Leser Ergebnisse produzieren kan.
Das zweite zeigt, wie ein Empfänger diesem Strom darstellt.

Man muss davon ausgehen, dass die Darstellungen jeweils überflüssig sind und den Prozess bremsen!

[youtu-be]https://youtu.be/ikGAh4bcY-A[/youtu-be]
Und derweilen am Empfänger:

[youtu-be]https://youtu.be/89PxlmRiOCM[/youtu-be]

Es kommt auf die Zeile mit 'value' und 'Hex' an.
Die Tags unterscheiden sich nur ab der zweiten Stelle in 2 Bytes
Realzeit.
Das sieht echt gut aus, inzwischen.

Kein einziger Melder würde es erleben, unter realen Bedingungen so viel Rollmaterial zu sehen.

[joachimkr]

Hallo liebe Stummis,

Jetzt geht es in die Phase der Umsetzung in Hardware. Der Schaltplan steht, nur in wenigen Punkten muss ich den finalisieren.
Das Layout mache ich noch, aber die Fertigung der Platine und deren Bestückung sind ein Fremd-Prozess, Lohnarbeit. Die will bezahlt sein, so wie ich das Material kaufen muss.
Einige von Euch haben das Projekt aufmerksam verfolgt, sehr viele haben mitgelesen.
Nach meinem Eindruck können das 100 bis 200 Personen gewesen sein.
Jetzt muss ich planen und kann dabei alle Stummis berücksichtigen, die diese Technik mitverfolgen und vor allem, mitmachen wollen.
Vorab: ich bleibe solange am Ball, bis es bei jedem läuft.
Wer jetzt eine Menge deklariert, bekommt diese Menge und die werden funktionieren.
Wer also interessiert ist, schicke mir bitte eine PN, mit Name, Adresse, Rufnummer und Stückzahl. Und Direkt-Email.
Ich plane dann insgesamt die Vorserien und melde das Ergebnis zurück.
Rechnet mit einem Preis von 30 € pro Stück. Mehr werde ich selbst tragen. Verdienen werde ich nichts daran.
Anschließend müsst Ihr mir Zeit für die Umsetzung geben.
Während dieser Zeit schicke ich 'Rechnungen' raus, für eine Abschlagszahlung. Und natürlich halte ich Euch über den Stand auf dem Laufenden.
Es kommen dann auch die Beschreibungen, wie das alles in Betrieb genommen und integriert wird, bzw. mit welchen Optionen.
Jeder, der jetzt einsteigt, bekommt etwas für ihn nutzbares.
Ich werde also auf jeden individuell eingehen.
Ihr bekommt also auch Einfluss auf das Ergebnis.

Geht also in Euch und schreibt mir. In zwei Wochen ist Deadline dafür.
Es geht los, dieser Würfel ist gefallen.

Viele Grüße, Joachim

[Lindilindwurm]

Hallo Joachim,

könntest du bitte nochmal kurz nennen, was du jetzt entwickelt hast und für welches modellbahnerische digitale Umfeld es kompatibel ist?

Vielen Dank und Grüße

Lindi

[joachimkr]

Zitat

---

Hallo Joachim,

könntest du bitte nochmal kurz nennen, was du jetzt entwickelt hast und für welches modellbahnerische digitale Umfeld es kompatibel ist?

Vielen Dank und Grüße
Lindi

---

Hallo Lindi,

Jetzt wird mir klar, dass diese Frage unbeantwortet war. Sorry und Danke für's nachfragen!

Der eigentliche Melder ist in meinem Musteraufbau funktionsfähig entwickelt. Der ist ja die immer gleiche Grundlage.
Der Konzentrator auf der Basis von einem Raspi, funktioniert ebenfalls grundlegend, er nimmt die Meldungen entgegen.
Die von mir bereits geplanten Übergabe-Schnittstellen sind weniger anspruchsvoll, aber noch nicht fertig entwickelt.
Da kommen jetzt diejenigen ins Spiel, die sich bei mir als Interessenten registrieren lassen. Bei jedem werde ich die Umsetzung ggf. neu beleuchten, prüfen, wie das am besten geht.
Bereits näher beleuchtet und vorgesehen sind die folgenden:

RocRail: Übergabe direkt per Netzwerk-Protokoll
CS2 und CS3: Übergabe per Netzwerk, durch die Spiegelung von CAN Protokoll der Märklin CS.
Z21: Übergabe per Netzwerk, durch die LocoNet Spiegelung der Roco Z21.

S88: Der Konzentrator gibt per Hardware eine ggf. sehr große Kette von Meldern, vielleicht 64, an einem Interface aus. Dies ist die Rückfall-Lösung. Die Lösung wird nur entwickelt, wenn notwendig. S88 Schnittstellen sind etwas langsamer, wegen ihres Taktsignals.

Schwerpunkt, erster Ansatz, ist immer die jeweils vorhandene Netzwerk-Schnittstelle der Steuerung. Die Übertragung geht schnell und das Ereignis steht in der Steuerung direkt an. Somit reagiert sie auch schnell.

Also: Wer von dieser Liste abweichende Bedingungen hat, nennt sie mir und ich suche eine Lösung. Das ist die Substanz der Einladung!

Wer zufällig eine gute Dokumentation der Loconet Schnittstelle hat, kann sie mir zur Verfügung stellen.

Viele Grüße,
Joachim

[joachimkr]

Nachtrag: Loconet erfordert eine Platine für den Raspi. Aber es wäre relativ problemlos, die zu entwickeln. Eine saubere Spezifikation und Schaltungbeispiele habe ich. Natürlich reduzieren reine S88 oder Loconet Lösungen die Funktionalität auf die Besetztmeldung. Die Ableitung von speziellen Besetztmeldungen für bestimmte RFIDs ist aber genauso möglich. Die Ableitung eines Fehlercodes bei Waggonverlust geht auch, bei S88 jedoch nicht, da müsste man improvisieren.

Gefühlt hat sich die Zahl der Zugriffe auf den Thread deutlich erhöht. Pro Tag mehrere hundert - überlegt nicht zu lange, ob /wie Ihr einsteigt. Dass es funktionieren wird, habe ich ja versprochen.

[joachimkr]

Es tauchen Fragen auf, die ich offenbar offen gelassen habe.
Ich versuche, die hier sinngemäß zu kolportieten und zu beantworten:
Welches Gleismaterial wird bei C-Gleis vorausgesetzt?
Mir ist momentan egal, ob es die 172 oder 188 mm Gleise sind, sie sollen nur gerade sein. Ein Bogen ist für Spulen, die da rein müssen, Mist. Jedenfalls prinzipiell. Ich schließe nicht aus, dass es trotzdem geht. Aber die Geraden sind optimal.

Da die Spule eine gewisse Länge braucht und die Platine ebenso, die Platine nicht über der Spule liegen darf, braucht man eine gewisse Strecke. Die Platine beinhaltet ja ein Masse-Plane. Das ist eine Spule mit Kurzschluss, da würde das Feld für NFC zusammenbrechen, wenn die Platine über der Spule montiert würde.
Ich denke, kürzer als 100mm kriegt man es nicht hin.

Später kann man mal Versuche machen, Kurvenstücke mit Spule auszustatten, aber es gibt in Kurven immer das weitere Problem, dass die Montage der RFIDs dann nicht mehr so simpel zentrisch hinzukriegen ist, ähnlich einer Schleifer-Montage. Es gibt Radien, wo es problemlos gehen sollte: Die Gegenbögen der schlanken Weichen.

Frage: Was braucht man denn noch alles, außer dem NFC Reader, dem Melder? Außer dem RASPI4 als Konzentrator?
Antworten:
Die Meldungen kommen vom Konzentrator über das Netzwerk, direkt an Rocrail oder die CS2, CS3, Z21 - jedenfalls das, was steuert.
15m Distanz in mehreren, aneinander grenzenden Räumen ist grenzwertig, innerhalb von 'nassem' Mauerwerk. Da könnten 2 RASPIs tatsächlich besser sein. Ich habe hinter einer 2. Mauer Grenzen beobachtet. Feuchtigkeit im Mauerwerk ist die beste Abschirmung
Da haben es die Verwender der Spuren 1 und G im Freien besser.
Inbetriebnahme:
Was zur Inbetriebnahme abläuft ist: Der RASPI sucht zu Beginn nach bestimmten Partnern. Die merkt er sich dann und meldet sich dort an. Dann erteilt man händisch jedem Melder eine Nummer, die zu der der Steuerung korrespondiert.
Da die Melder nur einen Partner zur Zeit akzepzieren, kann man bei der ersten Inbetriebnahme einfach versuchen, die Räume zu trennen, nacheinander mit Gleissignal zu versorgen. Ist die Gruppe konfiguriert, kommt die zweite. Theoretisch kann man Melder von A nach B ummelden. Solange er logisch die gleiche Nummer bekommt, sieht Rocrail oder CS, Z21 keinen Unterschied.
Sind RASPI und Melder verbunden, kommt kein zweiter RASPI an diesen Melder heran.
Man muss aber ja eine klare Zuordnung machen, also einmal bestimmen, welcher Melder wo im Gleisplan sitzt. Das ist Arbeit in und mit Rocrail. Oder der CS, oder Z21 - dort, wo gesteuert wird!
Jeder Melder hat einen eindeutigen Namen. Der steht drauf, unten, und man tut gut daran, diese Nummer erstmal eindeutig zu dokumentieren, wo der verbaut ist. Im Konzentrator vergibt man einfach aufsteigende Zahlen an diese langen Namen und das war's dort. Dann wird der Melder mit seiner laufenden Nummer bei Rocrail o.ä. eingetragen.
Das war's bei Rocrail, oder anderer Gleissteuerung. Jedenfalls erfassungstechnisch. Die Automatik muss dann auf dieser Grundlage aufbauen.. Jedenfalls kann ich mir nicht vorstellen, dass man mit S88 Technik zeitlich im Aufwand auch nur in die Nähe kommt, der Aufwand ist viel größer, bei S88, als hier.
Gleise trennen, Kabel anlöten, verlegen, Stromversorgung holen, Signal-Kanal zur Zentrale verlegen, dabei die Netzstruktur beachten und die nicht änderbaren Nummern korrekt eintragen.
Die 30 €:
Ich kann für die 30 € zunächst nur die Platine machen. Und verspreche eben die Nutzbarkeit. Bleibe solange (Support) dran, bis das Ganze läuft.
Das Gleis anzufertigen, ist momentan fertigungstechnisch noch nicht final geklärt. Das sind überwiegend Bearbeitungskosten, sowie die Einlage von der Spule und Austausch der Puko Streifen aus Eisen gegen NE Metall. Es gibt passende, fast fertige Puko-Streifen..
Wenn ich das selber mache, was ich zu Anfang auf jeden Fall tue, kann ich ca. 4-6 Stück pro Stunde schaffen. Eine Anleitung werde ich machen, aber auch nach Anlieferung von Gleisen, diese ausrüsten.
C-Gleise, ob Märklin oder Trix oder Roco geschottertes Gleis.
Weiteres Material:
Pro überwachtem Zug muss mindestens ein RFID verbaut sein. Dazu habe ich passende Klebebänder, von 3M. Der Chip braucht 8*8 mm und ist von Murata. Der kostet in Kleinstückzahl etwa 2.50 €/Stück. Der ist speziell, in Dickschichttechnik und deswegen klein und trotzdem gut. Wenn Du am Zugende noch ein RFID spendierst, wird erkannt, falls der Zug sich trennt.
Sind weitere dazwischen, wird das Ganze zugleich zum Achszähler.
Jeder Triebteil mit einer angesteuerten Adresse sollte ein RFID bekommen. Das sehe ich als Grundausstattung. Wendezüge haben mindestens 2 Stück.
Software-Updates:
Die Updates der Melder erfordern, dass ich die an einen Programmierer anschließe. Solange, bis ich Updates per OTA (Bluetooth) beherrsche. Das ist theoretisch möglich, aber ich zweifle, ob sich die Entwicklung rentiert:
Funktional wurde der Melder konzeptionell so stark entlastet, dass ich damit kaum rechne. Der RASPI ist komplexer, da ist das wahrscheinlicher. Updates sind dann Downloads.
Der RASPI bekommt von mir SDHC Karten.
Auch dafür gibt es dann eine Anleitung. Nur der 4er RASPI reicht aus. Die alten sind zu langsam. Die Meldungen sind zeitkritisch.

Was ist mit 2-poligem Gleismateriall ohne Schotterbett:
Ich werde ein verleihbares Werkzeug anfertigen für DC Gleise. Die Schwellen werden damit passend eingefräst, die Spule eingelegt und über eine kurze Distanz wird durch die Platte das Spulenkabel geführt. Die Platine wird unten angeschraubt. Die Spule muss verbaut werden, wie sie ist! Abschließend kann verschottert werden. Antenne ist unsichtbar. So wie überall.
K-Gleise:
Das ist noch in Arbeit. Spezifikation folgt später!
Da ich selbst nur K-Gleise auf der eigenen Anlage habe, könnt Ihr sicher sein, dass ich das hinkriege!
Was passiert nach Gleisspannungs-Abschaltung:
Der RASPI behält ja seinen Strom und nach ~ 100msec sind alle Verbindungen weg, die Melder sind ohne Connection und der Konzentrator wartet auf das 'Advertising' der Melder, dass die starten, sobald Strom da ist.
Bekommen die Gleise wieder Strom, verbinden sich der RASPI in jedem 'Advertising'-Intervall mit einigen der Melder. Nach ca. 10 Sekunden hat er ca. 100 Stück wieder verbunden.
Also: Wenige Sekunden, dann kann es weitergehen.

[joachimkr]

Liebe Mit-Foristen,

es ergab sich eine Frage, die ich hier wiedergeben und beantworten will:

Was ist mit der Zukunftssicherheit der Lösung, was passiert in der Folge einer ersten Serie ?

Der geplante Ablauf ist dieser:
Ich sammle verbindliche Bestellungen, also eine Gesamtstückzahl für eine erste Serie. Diese wird gefertigt und dann zu Meldern bei mir komplettiert. Ich liefere dann funktionsfähiges Material aus. Getestet.
In der Folge werde ich die Auslieferungen betreuen, bis es bei jedem integriert ist.
Dann folgen weitere Serien, die ich ebenfalls vorher erfragen werde.
Hoffentlich mit in Summe der Bestellungen steigender Stückzahl.

Mancher wird ungern alles auf eine Karte setzen, zuviel investieren. Ist also daran interessiert, in der Folge weitere Bestellungen mit mir abzuwickeln. Hierzu folgendes Versprechen: Wer in den ersten 2 Runden mitmacht, kann in der Folge solange nachbestellen, wie er möchte. Der Zeitabstand zwischen Lieferungen kann einige Monate werden. Also auch nicht zu vorsichtig da rangehen.
Es ist jedoch nicht sinnvoll, dass diese Bestellungen immer gerade aus 2 Stück bestehen. Das macht die Sache 'unhandlich' und unnötig aufwändig.
Nehmt Euch etwas vor, einen Bauabschnitt, von dem Ihr etwas habt.
Besser ist, mir mitzuteilen, wieviele Melder am Ende insgesamt bestellt werden könnten, sowie die belastbare Zahl, die in der ersten Runde bestellt wird. Der Zeitraum, den man braucht, um die letzten Melder zu verbauen, wird nicht 'umgehend' sein, das lässt sich leicht denken. Auch kostet der Einstieg Einarbeitung und die Ideen werden sich weiterentwickeln.

Ihr könnt alles bei mir beziehen. Das bündelt die Bestellungen. Ich werde an bestellten RFIDs, an Gleisumbauten, Spulen und Klebebändern nichts verdienen. Mein Interesse ist jetzt vorrangig, das Projekt durchzuziehen, mit soviel Stückzahl, wie möglich. Jeden werde ich individuell betreuen. Je mehr Bauteile ich liefere, desto wahrscheinlicher ist, dass es funktioniert.
Wenn etwas gewünscht wird, das nicht machbar ist, werde ich das kundtun.

Die Zukunft wird dann - so hoffe ich - so aussehen, dass die Melder ihren Preis halten oder verringern, dass die Technik mit jedem Projekt weiter reift, besser wird. Ich denke für mich selbst ziemlich langfristig und auch nachhaltig. Meine eigene Anlage werde auch ich nicht an allen Ecken zugleich bearbeiten. Der mentale Ursprung der Gesamtidee war vor etwa einem Jahr, dass ich absolut nicht geneigt war, mein 11qm Gleisbett, dass in 6 Jahren 2 Umbau-Iterationen und einen Umzug bekommen hat, nun komplett zu zerschneiden flaster: um mühselig alles wieder (mit Rückmeldung) heil zu machen. Die K-Gleise sind in der Beziehung nicht so tolerant, wie andere Gleise. Außerdem hasse ich, über Kopf zu arbeiten. Also musste eine 'minimalinvasive' Lösung her . Die hat sich nun schon fast verselbständigt.

Liebe Grüße,
Joachim

[joachimkr]

Überarbeitet am 21.11.2021

Hallo Ihr,

ich möchte hier beginnen, einen Katalog von Vorteilen und neuen Szenarien erstellen, damit jeder weiß, was er damit anstellen kann. Wenn nicht jetzt, dann in Zukunft.
Da dieses System keine Steuerung ersetzt, sondern nur neue Informationen liefert, ist dies ein konjunktiver Katalog!
Das ist Absicht. Denn es lesen gewiss auch Modellbahn-Hersteller mit, die dann unter Umständen Konsequenzen ziehen müssten.
Was ich nicht beschreibe ist, wozu Besetztmelder gut sind; Aber: Wir wollen automatisieren!

- Das System erfasst alle RFIDs des Zuges. Trennt sich dieser unabsichtlich auf, löst es einen Alarm aus, notfalls eine Abschaltung. Kollisionen von schnellen Zügen mit stehenden Waggons sind teuer und ärgerlich. Von denen sollen so viele wie möglich vermieden werden.
- Das System bringt neben der 'Besetzt' Information den Ort und die Lok/Triebwagen oder auch Waggons zusammen, jedes für sich eindeutig identifiziert. Daraus ergeben sich neue Möglichkeiten:
1. Der Konzentrator kann dazu gebracht werden, einer bestimmten Lok an einem bestimmten Melder einen 'Kontakt' zuzuordnen, den es physikalisch nicht gibt. Simples Szenario: Eine bestimmte Lok fährt ein, sie braucht ein bestimmtes Gleis, die Weiche wird also passend umgelegt. Oder 20 nacheinander. Was immer Eure Steuerung hergibt! Die Möglichkeiten sind nicht begrenzt.
2. Die Steuerung könnte die Bremsung im Bahnhofsvor- und -Einlauf individuell vornehmen. Sowas ist in RocRail bereits im Prinzip angelegt.
3. Eine Soundsteuerung könnte ohne großartige Interpolation die Geräusche der Züge nahezu perfekt an eine 'Quadrophonie' Anlage abgeben. Wenn sie es gut macht, für alle, auch wenn es 20 zugleich sind.
4. In Modulanlagen mit erheblicher Ausdehnung wäre es möglich, die ankommende Lok zur Übernahme auf den lokal zugeordneten Handregler anzubieten. Tastendruck, die Lok und ihre Geschwindigkeit sind übernommen. Auf Mobilgerät, Station, PC, was immer.
Diese Funktion könnte man generalisieren: Wenn eine neue Lok aus der Vitrine genommen wird und plötzlich neu erscheint, könnte man ähnlich reagieren.
5. Rangierbereiche können im Konzentrator definiert werden. Dies erlaubt, dort frei zu fahren und Züge zu ändern. Wenn der Zug den Rangierbereich verlässt, lernt das System automatisch den neuen Zug an und verwirft den alten anhand der RFIDs. Rangierbereiche sind im Konzentrator definiert, definierbar. Das geht also immer, mit allen Steuerungen.
6. Der Konzentrator läuft eigentlich immer hinzulernend, autonom und automatisch. Was er nicht wissen kann, muss man konfigurieren. Was der Konzentrator in Zukunft selbst an neuen Informationen liefern könnte, ist mir solange egal, bis einer mit einer tollen Idee um die Ecke kommt.
Tatsache ist, er empängt per Bluetooth und verfügt über einen Netzwerkanschluss, oder mit Zusatzausrüstung auch CAN oder auch BiDiB.
7. Die Wechselstromer haben kein Railcom. Jetzt gibt es aber auch für sie einen schnellen, breiten Datenkanal - die Lok und wenn man möchte, jeder Waggon ist augenblicklich bekannt. Die Erkennung der Information (des RFID) im System ist so schnell, wie ein S88 System braucht, die Besetztmeldung intern nur zu erzeugen. Alle Folge-Datenpfade sind viel schneller.
8. Im Prinzip ist es möglich, auch H0-Autos auf ihren Fahrstraßen mit den RFIDs auszustatten, denn das RFID ist so klein, dass es unsichtbar passt. Ich kenne die Faller Fahrstraßen mit selbst eingelegten Stahldrähten, aber nur aus der Ferne. Faller hat mit Ultraschall und Satelliten-Modellen innerhalb von 80 msec ein Fahrzeug ungefähr geortet und auf die bekannte Straße gemappt. Mittels meiner Reader-Platine ließe sich an jeder Einbau-Position Energie in das Fahrzeug bringen.
9. Mit Einbezug von Entkupplungsgleisen: Es lassen sich auch Rangierbahnhöfe automatisieren, um z.B. Züge in einer Weichenharfe aufzuteilen, abzurollen und neu zusammenstellen.
10. In Bahnhöfen kann man Kurswagen-Abläufe nachbilden
11. Jeder Waggon, jede Lok lässt sich beliebig erfundenen Gruppen zuordnen: Zum Beispiel Güterzug, Personenzug, Schnellfahrzug.
Jeder der 3 Gruppen ordnet man am Bahnhof andere Gleise und Geschwindigkeiten zu.
12. Bei Hinterlegung der Fahrzeuglänge zum RFID kann man unterschiedliche Zuglängen unterschiedlich behandeln, oder ein Gewicht assoziieren und Geschwindigkeit oder Geräusche anpassen.

Ich mache jetzt Pause. Dieser Beitrag wird laufend erweitert und ist deswegen ausgehend von der Spezifikation in Beitrag 1 verlinkt.
Ihr dürft selber Vorschläge einreichen, was Ihr gerne hättet. Wenn ich das für machbar halte, füge ich es ein. Wenn nicht, dann begründe ich das.

Nur zu!
P.S. die Spezifikation ist geändert worden.

[joachimkr]

Liebe Mitleser,

Eine Idee zur Kostenreduktion ist hinzugekommen: Das Rückmeldegleis wird um simple Belegungsmeldungen ergänzt, ohne RFID und somit ohne Fahrzeug-Information. Aber nur eine kleine Gruppe, um die Vergrößerung der Platine und potentielle Wärme-Generierung zu vermeiden.
Also ich denke an 1 RFID Leser, kombiniert mit 3 konventionellen Belegtmeldern.
Da meine Technik grundsätzlich DC und AC, H0, 1, 0 und G Spuren abdeckt, soll das auch so bleiben. Also es dürfen bei AC Gleisen elektrisch verbundene Gleisräder drüberlaufen, oder bei DC Gleisen ein Widerstand oder Verbraucher zwischen den Gleisrädern sitzen. Tritt bei DC ein Kurzschluss auf, wird dieser gemeldet. Der Melder gibt dann die diesem Abschnitt zugeordnete Nummer an den Konzentrator weiter. Das Know-How und ein Schaltplan dafür dafür liegt bei mir schon vor.
Die Bauelemente des konventionellen Melders kann man optional bei der Fertigung unbestückt lassen.
Die Funktionsweise des RFID Systems ändert sich nicht.

Viele Grüße,
Joachim

[DG-300]

Hallo Joachim,

ich denke das ist eine gute Idee, ich verstehe nur nicht warum gleich drei?
Mann kann doch maximal 1 Belegt Meldung auf dem Gleis gebrauchen.

[joachimkr]

Hallo Björn,

die 3 anderen sind auch für andere Gleise, von denen ja oft viele parallel laufen. Viele Foristen, die mit mir kommunizieren haben ja bereits Teile automatisiert, da ist dies einfach eine Ergänzung. Die dort lokale Verdrahtung machen ja nur die, die 'fest' aufbauen.
Für mich ist diese Ergänzung einfach ein Mittel, Kosten beim Anwender zu sparen.

Viele Grüße,
Joachim