Moet modelspoor aan de NFC?

[MartinRT]

Dat is niet zo heel moeilijk. Wat je met ABC moet doen, en dit zit in die BM2 meen ik, is ABC pas inschakelen nadat de trein in zijn geheel al op de sectie is en niet daar voor.

Daarvoor heb je een buffersectie nodig die langer is dan je langste (duwende) trein. Pas wanneer het voorste rijtuig (die stroom afneemt) de sensor bereikt

Buffer en sensor zijn bij Lenz dus rijstuk en remstuk (vertaald). Beide behoren in zowel de BM2 als de BM3 tot 1 blok, als ik hier de juiste term gebruik.  En dan het is ook duidelijk dat de gehele trein in het blok (Lenz: rijstuk) moet zijn, want anders zou je een overbrugging krijgen tussen de 2 blokken.  Dus het voorgaande blok waar gewoon gereden wordt en het blok waarin geremd en gestopt moet worden. In andere onderwerpen lees ik vaker dat overbrugging bij digitaal (DCC) betekent, dat het algemene signaal boven het remsignaal of andere beïnvloeding gaat.  Zie ik dat zo correct ?

[bask185]

Wel leuk hoe we van NFC, zijn geeindigd op Wifi, ethernet, ABC, IR, barcodes en wat nog meer? 

[iljitsch]

Wel leuk hoe we van NFC, zijn geeindigd op Wifi, ethernet, ABC, IR, barcodes en wat nog meer? 

En dan was er ook nog het idee van RobGood even geleden om via een IR-led onder de trein signalen te versturen die een fotodiode in de baan dan kan ontvangen.

Zou mooi kunnen via een UART bijvoorbeeld na het passeren van een bepaalde combo van licht/donker gekleurde bielzen en ballast een seconde ofzo op 19200 bps wat info versturen.

Allereerst natuurlijk DCC-adres. Maar ook treinlengte, treintype, nog wat van dat soort dingen.

[Patrick Smout]

@Bas, even nog terugkomen op een statement van mij en jouw reactie.

Voor de PC software is er dan wel de uitdaging dat die exact dezelfde curve moet simuleren

Dat doen ze nu ook al? het verschil met jouw idee is dat je niet elk snelheidsstapje op de bus moet plempen.

Onderstaande uiteenzetting is op basis van ervaringen opgedaan met het schrijven van eigen PC software voor de besturing van mijn baan.

We gaan ervan uit dat we rijden met geijkte snelheden en je in de PC de exacte afgelegde afstand wil bijhouden. Stel dat een trein moet versnellen van 40km/u naar 100km/u. De PC software zal met vaste intervallen de modelsnelheid verhogen bepaald door de massavertraging. In realiteit gebruik ik zelf een S-curve maar dat doet hier even niet ter zake. Door de omzetting van berekende modelsnelheid naar decoderstappen a.d.h.v. de ijkingstabel zal de werkelijke snelheid van de trein op andere momenten aangepast worden dan in de PC. In feite krijg je een afronding van de snelheid naar beneden toe. Dit betekent dat een afgelegde weg die in de PC berekent zou worden op basis van de gewenste modelsnelheid niet overeenstemt met de werkelijk afgelegde weg door de trein ( In de PC is de afgelegde weg langer). In mijn PC software wordt dit opgelost door de afgelegde weg in de PC te berekenen op basis van de afgeronde modelsnelheid en niet op basis van de gewenste modelsnelheid. In praktijk zet de PC software de gewenste modelsnelheid om naar decoderstappen gebruikmakend van de ijkingstabel en die gaat dan via het commandstation naar de rijdende trein. In PC wordt de berekende decoderstap ook bmv een inverse bewerking met de ijkingstabel terug omgerekend naar de afgeronde modelsnelheid. Die afgeronde modelsnelheid wordt vervolgens gebruikt om de afgelegde weg te berekenen. De berekeningen voor de positie in een blok zijn 64bit ( long long). Eenheid voor de snelheid is nanometer per milliseconde (nm/ms).  Dit lijkt er allemaal wat over echter het is noodzakelijk omdat de snelheden en posities om de 50ms herberekend worden en je voldoende significante bits wil overhouden bij lage snelheden om afrondingsfouten te voorkomen. Op mijn baan haal ik op die manier mm nauwkeurigheid voor positiebepaling maar een correcte ijking blijft noodzakelijk en is de zwakke schakel.
Het voorbeeld is gegeven met versnellen maar ook bij een constante snelheid speelt de afronding mee.

[bask185]

Interessant verhaal  . Er zit een grotere resolutie in dan ik had verwacht. Die mm nauwkeurigheid klinkt bijna te mooi om waard te zijn. Niet dat ik je niet geloof hoor. Maar loop je in de praktijk niet tegen vertragingen aan van het gehele systeem van terugmeldbus naar computer naar dcc pakketjes?

Omtrent nauwkeurigheid en stoppen he. Ik neem aan dat het ook zo is dat de positie opnieuw wordt bijgesteld elke keer dat een trein een melder berijdt niet? Kan je dan voor het optrekken niet simpelweg volstaan door de optrek curve door te trein laten regelen en het afremmen wel direct te beinvloeden? Om toch wat ruimte op je bus te creeren? Als je al je je blokken voorziet van inrij melders kan je positie synchroniseren en dan tot de mm nauwkeurig afremmen.

Ander theoretisch vraagje. Die decoders kan je volgens mij voorzien van een zelf ingestelde optrek/rem curve met CV programmering. Zou het nut hebben om bijvoorbeeld je computer programma voor jou al die CV's te berekenen en te programmeren en dat je dan gebruik maakt van de standaard optrek/remvertraging? Bij nader inzien lijkt me dat 'vervelend' als je met regelmaat met verschillende rem/optrekcurves wilt werken. Dan heb je daar weer niks aan.


Bas

[Bahn-AG]

Patrick, je schrijft een heel lang verhaal op over de correctie van een "geijkte" waarde, maar feitelijk weet je nog steeds niet waar een trein zich daadwerkelijk bevind.
Andere (zwaardere) trein erachter en er klopt al niks meer van de correctie. Even doorslippen van de lok: weg theoretische afgelegde weg.
Berekeningen om de 50ms...zinloos als je melders 2 meter uit elkaar liggen. Alleen als de trein over de meetpunten komt weet je waar hij is.

Enige zinvolle is een gps systeem. Dan kan gelijk alles van bezetmelders, stopsectie e.d de prullenbak in.
Koppel gelijk je car-system, magnorail en noem maar op eraan en je kunt aanrijdingen, hulpdiensten, overwegen, taxis die reizigers ophalen als een trein aankomt (met vertraging ) en de rest eraan hangen.

[Patrick Smout]

Dag Bas,

posities worden idd bepaald relatief tov de start van een blok en op 0 gezet door de inkomstmelders. Vertragingen zijn er zeker en die introduceren een fout. Op zich niet erg als die fout maar constant is en voor alle treinen dezelfde. Je ziet ook afwijkingen voor een loc die bv langere tijd niet gereden heeft maar op zich valt dat allemaal wel mee. Materiaal moet allemaal wel goed rijden. Vandaar mijn idee in een eerdere post in dit draadje om de afgelegde te laten terugmelden door de decoder zelf. Op zich werkt mijn software niet anders dan andere PC software maar ik heb ondervonden dat bij het berekenen van de afgelegde weg toch wel wat extras komen die meegenomen moeten worden als zaken verhuizen naar de decoders.

[Patrick Smout]

Patrick, je schrijft een heel lang verhaal op over de correctie van een "geijkte" waarde, maar feitelijk weet je nog steeds niet waar een trein zich daadwerkelijk bevind.
Andere (zwaardere) trein erachter en er klopt al niks meer van de correctie. Even doorslippen van de lok: weg theoretische afgelegde weg.
Berekeningen om de 50ms...zinloos als je melders 2 meter uit elkaar liggen. Alleen als de trein over de meetpunten komt weet je waar hij is.

Enige zinvolle is een gps systeem….

Klopt, ik ken de absolute positie van mijn trein niet maar dat is ook niet het doel dat ik nastreef. Een oplossing is er voor een bepaald probleem en zelden is de oplossing generiek.
Ik rij met vaste treinsamenstellingen en ijk de snelheid van de treinen, geen locs. Mijn software is zeker niet perfect maar ik ben best tevreden over wat mogelijk is.
Ik hoor graag van jou welke tijd jij gebruikt in jouw zelfgeschreven software om de berekening te doen.   De term zinloos doet vermoeden dat jij ervaringsdeskundige bent?
Ik verneem ook graag welke technologie jij aanbeveelt voor een betere absolute positiebepaling. Ik help je even op weg door de afvallers op te noemen met onvoldoende nauwkeurigheid: GPS 20m, BLE AoA en UWB 10 cm best case, BT RSSI 5m. Je kan nog wat verfijnen door wat extra bakens te zetten maar de voortplantingssnelheid van radiogolven ligt nu eenmaal wetmatig vast. Wil je daar beter doen dan zal het op basis van licht worden met picoseconde meetresolutie om de ToF te bepalen. Komt ook met een prijs.

[iljitsch]

GPS modelleren. 

Patrick: zou het tellen van dwarsliggers niet een mooie aanvulling op het systeem dat jij gebruikt zijn?

Dit is ook niet perfect want bij wissels en dergelijke kan je een aaneengesloten stuk plastic of een aantal dwarsliggers op niet-standaard afstanden hebben. Maar dat levert steeds dezelfde fout op dus daar kan je rekening mee houden.

(Bv. er zit een ontkoppelaar over 10 dwarsliggers dus je bent ~ 5 cm verder dan de bielzenteller denkt, maar dan stel je gewoon in dat je 5 cm eerder stopt.)

Update: een optische computermuis ziet de afstand die-ie aflegt zelfs zonder een duidelijk patroon als dwarsliggers/ballast. Dus je zou een muis in kunnen bouwen...

[bask185]

Als je dat werkend krijg, zou dat geen slecht idee zijn. Ik betwijfel alleen of je dat voor elke baan werkend kan krijgen. Als je bielzen diep in het ballast liggen, kan je geen afstand meer meten.

Die marklinisten zouden misschien puko's kunnen tellen.

Bas

[iljitsch]

Als je dat werkend krijg, zou dat geen slecht idee zijn. Ik betwijfel alleen of je dat voor elke baan werkend kan krijgen. Als je bielzen diep in het ballast liggen, kan je geen afstand meer meten.

Nee, het bielzen tellen kan geen oplossing zijn die zonder aanpassingen op willekeurig elke baan toepasbaar is.

Maar een oplossing die de sensor van een optische muis gebruikt (zoals deze, zo'n 2 euro) zou dat wel moeten kunnen.

Alleen interface is SPI. Ik kan nergens vinden dat DCC locdecoders dat protocol kunnen spreken op hun aux-pinnen.

Dit zou toch wel een mooie oplossing zijn want dan kan je op iedere baan de echt gereden afstand (en dus snelheid) zo uitlezen zonder verdere ingewikkelde truuks.

En de hardware is in principe een 19x19 pixel camera dus wellicht zijn hier nog meer leuke dingen mee te doen. Komen we toch weer terug bij zaken als streepjescodes. 

[bask185]

(zoals deze, zo'n 2 euro) zou dat wel moeten kunnen.

Misschien, maar zoiets moet echt eerst getest worden. Ik weet niet of die sensor ook goed omgaat met de verscheidene ballaste modelspoorbanen en betrouwbare waardes uitspuugt. Ik heb soms al ruzie met mijn muis op werk omdat mijn buro soms wel en soms niet te shiny is.

Ik kan nergens vinden dat DCC locdecoders dat protocol kunnen spreken op hun aux-pinnen

Nee dat klopt, dat is een obstakel. Veel van de aangedragen ideeen hier zijn ook niet toepasbaar op de standaard esu decoder zonder een nieuw ontwerp. Zo'n IR led daarentegen hoef je niet eens aan de decoder te hangen. Daar kan je zelf een print voor fabrieken. (zou wel makkelijk zijn als de decoder zoiets zou kunnen  )

Ik snap ook niet waarom ze zoiets gemaakt hebben als een SUSI bus.. aangezien men al I2C uitgevonden heeft. Zal met hardware wel makkelijker geweest zijn.

Bas

[iljitsch]

Ik denk dat niet detecteren van beweging met een optische-muissensor bij modelspoor geen probleem zal zijn. Wat je nodig hebt is ofwel een zekere mate van kleurverschil ofwel een zekere mate van reliëf om zo'n muissensor te laten werken. De LED die erbij hoort schijnt met een grote hoek het oppervlak onder de sensor aan waardoor ieder beetje reliëf voor een zichtbaar patroon zorgt dat de optische sensor kan gebruiken om de verplaatsing te meten.

Als ik me niet vergis zit in dwarsliggers vaak wel wat reliëf om ze op hout te laten lijken, en in ballast zeker. Dat is voor zover mij bekend nooit éénkleurig superglad materiaal.

Daarnaast rijdt een trein met een relatief constante snelheid, dus als de sensor dan ineens kort stilstand rapporteert kan je de afgelegde afstand aan de hand van de eerdere en latere snelheid en de tijdperiode interpoleren.

Enige probleem zou kunnen zijn de afstand die veel groter is dan bij een muis. Maar dat kan je met een geschikte lens compenseren. Alleen kan de afstand variëren naar gelang het type spoor en of de ruimte tussen de dwarsliggers opgevuld is met een vorm van ballast of niet. (Hier zijn wat mogelijkheden met bijvoorbeeld een tilt-lens omdat we toch alleen geïnteresseerd zijn in beweging in één richting.)

Uiteraard allemaal dingen die uitgeprobeerd moeten worden.

Maar stel dat dit werkt en het mogelijk is om in de toekomst locs zonder veel meerkosten uit te rusten met een sensor die de afgelegde afstand redelijk precies (+/- 2% ofzo?) kan rapporteren.

Dan heb je ineens nieuwe mogelijkheden zoals een loc zeggen "stop na 80 cm". Ook hoef je in software niet meer moeilijk te doen met het ijken van de snelheden van treinen: je kan de trein instrueren met een bepaalde snelheid te rijden. De trein kan aan de hand van de feedback van de sensor nu het benodigde motorvermogen leveren om vrij precies met een bepaalde snelheid te rijden. (Ongeacht het aantal wagons.)

En je kan de locs gewoon hun eigen acceleratie/deceleratie-curves laten gebruiken. Wat telt is hoeveel afstand ze afleggen, niet wat de precieze snelheid op welk moment was.

Met een IR-sensor langs de baan kan je bepalen hoe lang een trein is, door op het moment van activeren de centimeterteller uit te lezen en dan weer op het moment van deactiveren van de sensor.

Ook kan je stukken baan opmeten door er gewoon overheen te rijden.

Wat ik voor me zie is dat je nog steeds een aantal terugmelders nodig hebt omdat 100% vertrouwen op de muissensor natuurlijk na verloop van tijd lastig wordt (of het na 2 meter of 200 meter is), maar als je alleen treinen hebt die deze sensors aan boord hebben kan je voor de normale blokbeveiliging gebruikmaken van de afstandsdetectie in plaats van blokdetectie.

Ofwel door van de decoder terug te horen hoeveel afstand-ie afgelegd heeft via RailCom, ofwel door de loc te instrueren te stoppen na bepaalde afstanden. En dan als blokken vrijkomen de stopafstand en/of maximale snelheid aanpassen terwijl de trein nog rijdt.

De terugmelders hoef je alleen neer te zetten op plekken waar alle treinen na enige tijd wel een keer langs komen. Dan kan je de afstandsteller herinitialiseren om te zorgen dat foutieve metingen zich niet opstapelen.

Even terug naar NFC of RFID: ik blijf het huidige systeem van terugmelders die weer een aparte bus gebruiken erg suboptimaal vinden. Ik zou daar graag vanaf willen maar de functionaliteit behouden. Er zijn allemaal dingen te bedenken waardoor de loc detecteert waar-ie rijdt en dit dan terugmeldt via RailCom. (NFC/RFID, streepjescodes, ABC.) Maar ik ben bang dat de voordelen hiervan onvoldoende zijn om dit van de grond te krijgen. Vooral ook omdat huidige bouwers van grote banen hier weinig direct voordeel van hebben.

Optische afstandssensors en dan veel minder terugmelders maar wel grotere precisie is een mooie combo: minder hoge kosten en bedradingsellende voor nieuwe banen (en minder instellingen in de software), maar bestaande banen hebben ook voordeel van de grotere precisie.

Update: wat je met dit systeem ook relatief makkelijk zou kunnen doen is een computer laten bepalen hoeveel afstand de trein mag afleggen en met welke maximale snelheid (op basis van blokbeveiliging of gewoon vanwege einde spoor) en dan de daadwerkelijke snelheid (beperkt tot het maximum) met de hand laten besturen via iets anders dan de computer.

(Wellicht is deze functionaliteit nu ook al mogelijk met programma's als iTrain, Koploper en/of RocRail, maar mijn indruk is dat als je het programma blokbeveiliging laat doen je dan eigenlijk gedwongen bent de snelheid van je trein ook via dit programma aan te sturen.)

[reinderlf]

Om nog even een variatie toe te voegen, ik heb eens een test gedaan met een QR code onder de wagons,15x15mm. Camera ($2 webcam) onder de baan, en 2 SMD led voor de velichting. Het werkt, maar je moet heel langzaam rijden, niet ideaal. Beter Zou zijn Om een camera te gebruiken met waarbij je autofocus uit Kan zetten, dat gooide best wel roet in het eten omdat de camera steeds probeer te focuses op de passerende wagons, koppelingen etc.

Dat IR LISSY systeem van uhlenbrock werkt opzich goed, heb ik een paar tests mee gedaan Om er achter te komen hoe de LocoNet berichten in elkaar zitten zodat ik in Traintastic kon inbouwen. Losse zenders zijn iets van 17eur, nog best aan de prijs. Het nieuwe type heeft overigens ook railcom. Je stelt het adres in en nog een 2bit category. De ontvangers kun je wel helemaal programeren met opdrachten die Dan via LocoNet trein snelheid aanpassen wissels schakelen etc.