BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: iljitsch op 02 May 2023, 16:33:10
-
Nog steeds niet één modeltreintje gekocht maar toch al weer flink wat weken bezig met nadenken over deze hobby. En dan lijkt het er toch op dat met de hedendaagse technieken er een hoop meer mogelijk is dan wat we nu in gebruik hebben.
Een interessante relatief recente techniek is NFC. Hiermee kan je op korte afstand een kleine hoeveelheid data uitlezen van iets zo simpel als een sticker van 22 mm doorsnee van 1 euro.
Je zou dus zo'n sticker onder iedere locomotief en wagon kunnen plakken en dan met een NFC-lezer in het spoor precies zien wat er op welk moment langs komt rijden. Of het nou een digitale of analoge loc is of een stroomloze wagon.
Je zou zo zelfs een baan in kunnen richten dat als er zich alleen digitale locs binnen een bepaald gebied bevinden eea digitaal gevoed wordt maar zodra een analoge loc binnenkomt de voeding omschakelt naar analoog.*
Of omgekeerd: NFC-stickers op de rijbaan en een NFC-lezer gekoppeld aan de decoder van een locomotief. Die locomotief kan dan instructies krijgen over snelheid, stoppen of keren, of om via RialCom terug te melden dat-ie een bepaald stuk spoor passeert.
Er zijn wat goedkope USB NFC-lezers van een paar tientjes. Maar volgens mij als je ze kan integreren in een bestaand systeem nemen de kosten relatief snel af, en het kan allemaal ook flink klein. In elk geval passend voor H0, met misschien wat verhoging tussen het spoor of verlaging van de buik van een loc/wagon voor de juiste afstand. N is waarschijnlijk nog een uitdaging met materieel van 19 mm breed en de kleinste (na 10 seconden zoeken met Google) NFC-stickers 22 mm diameter.
* Sowieso lijkt het mij tijd voor een update van DCC die werkt op basis van PWM bij gelijkblijvende polarisatie, wat geen problemen voor analoge locs oplevert, zodat digitaal en analoog beter kunnen samenleven.
-
Zelf op je eigen baan lekker met NFC klussen: niets houd je tegen. Loks detecteren kan met DCC ook al wel. Wagens en rijtuigen zonder decoders: daar zou meerwaarde kunnen zitten qua automatische administratie (mocht je dat willen).
Tijd voor een update van DCC: lijkt me lastig, voor zoiets moet je "iedereen" meekrijgen. Of het moet backwards-compatible te maken zijn. Een nieuw systeem als je er nieuwe apparatuur en nieuwe loks/decoders voor nodig hebt: da's nogal een stap.
Waar ik eerder heil in zie is om naast DCC een nieuw soort aansturing te verzinnen. Zeg maar "loks via wifi aansturen". En dan nog wel de standaard DCC voeding via de rails gebruiken. Dan kan gelijk de bestaande DCC door blijven pruttelen.
(Zelf blijf ik nog wel even met m'n eenvoudige multimaus rijden :) )
Reinout
-
@Reinout,
Zoiets schijnt Hornby uitgebracht te hebben. Maar dan via Bluetooth.
Zie: https://uk.hornby.com/hm7000
Gr, Hans
-
Bij McKinley Railway hebben ze RFID verregaand toegepast, zie bijv. https://www.youtube.com/watch?v=DXXYqRamxng
Groeten, Jos
-
Bluetooth heeft wel wat, maar ik denk niet dat het de ultieme oplossing is. Bijvoorbeeld, die Hornby-decoder kan maar met één apparaat tegelijk gekoppeld zijn. Een soort centrale in het midden die meerdere locs plus baanonderdelen aanstuurt en meerdere bestuurders toestaat is toch wel handig.
Ik zou dan liever gaan voor iets gebaseerd op Matter en vergelijkbare technieken voor huisautomatisering. Dat gebruikt al een zeer efficiënt draadloos protocol dat zeker in de toekomst breed beschikbaar zal zijn.
Zoals ik het zie is aansturing van wissels en seinen relatief volwassen: dat kan gewoon met apparaten die naar DCC luisteren. Maar terugmelden van baanbezetting is een veel zwakker punt. Hierbij kan je niet alleen DCC gebruiken, maar heb je nog een extra protocol zoals LocoNet nodig en de hardware die dat toegankelijk maakt naar een computer of soortgelijk.
Dus ofwel een loc die NFC-tags op de baan detecteert en via DCC/RailCom terugrapporteert ofwel een NFC-lezer op het spoor die NFC-tags onder locs/wagons detecteert zou toegevoegde waarde kunnen hebben.
-
Er zijn er die aan een analoge trafo en wat schakelaars genoeg hebben.
Anderen redden zich met een multimaus, en een slaaf of wat.
Ken er ook die hun spulletjes aansturen met een Ecos.
Of met de laptop.
Misschien verstandig eerst eens wat te bouwen, zodat je weet waar je precies behoefte aan hebt. Het aantal mogelijkheden is momenteel namelijk al onoverzichtelijk groot.
Dromen is goed.
Dromen verwezenlijken is beter.
Hup, bouwen! ;)
Hendrik Jan
-
En er zijn er ook die het leuk vinden om met opwind-treinen te rijden (waarbij Märklin trouwens een slecht figuur slaat):
https://youtu.be/T7SQBi8pp10 (https://youtu.be/T7SQBi8pp10)
https://www.youtube.com/v/T7SQBi8pp10
Groet
Fred
-
NFC heeft als voordeel tov een 'normale' melder dat je behalve weet dat er een trein is, ook welke trein dat is.
Als je rijdt met een programma heb je daar weinig aan omdat het programma bijhoudt waar wie is.
Dat kan je echter ook met Railcom terugmelders. Met railcom kan de trein je ook nog vertellen met welke snelheid hij rijdt. Ik snap tot op de dag van vandaag nog steeds niet wat je moet met die informatie omdat je dat toch al weet. Je zet immers met je eigen duim de snelheid.. maar goed nfc..
Het enige voordeel wat Nfc biedt, is dat je geen zaagsnedes hoeft te zetten in je rails. Dus in dat opzicht zou het wel iets van toegevoegde waarde hebben. Ik weet niet hoe de prijs zich zou verhouden tussen nfc en een railcom melder. Geen van beiden zal goedkoop zijn.
En het andere al genoemde voordeel is dat je elke wagon een nfc sticker kan geven. Losse wagon detectie is vrij uniek. Hoewel het wel leuk klinkt, kan ik zo niet bedenken wat ik er mee zou willen ???
Het zou wel gaaf zijn als je in een programma een wagon kan slepen van A naar B en het programma automatisch de sik stuurt om het te doen :police:
Bas
-
Nfc denk ik lastig omdat er tijd nodig is eerst om de chip powerup, dan komt er een heel circus van datauitwisseling opgang om de chip te indentificeren en daarna pas iets doen... bij albert hein duurt het ook minstens een 2 tal seconden... dan is die trein al een meter verder...zelf heb ik fantasieen over ir reflectie die de 'vingerafdruk' van een passerende trein 'leert'. Iedere trein zal zijn eigen patroon van reflectie hebben... wie weet mischien ga ik daar wel eens mee stoeien...
Rob
-
Misschien off-topic, misschien niet maar ::)
Ik vond dat camera systeem van Faller ook wel interessant, die stond weer in Ontrax. Ze hadden drie camera's verkleed als satelliet boven een auto baan gehangen die al die auto's kon tracken en bijsturen.
Het zou lastig zijn voor schaduwstations natuurlijk, maar wie weet voor in het zicht zou het wel leuk kunnen zijn. Dan kan je ook nog precies zien hoever de sik nog moet rijden om aan te koppelen. Je kan dan waarschijnlijk alleen geen onderscheid maken als wagons teveel op elkaar lijken.
Hackerstore (https://hackerstore.nl/Artikel/420) verkoopt ook een camera met beeldherkenning die je dingen kan inleren. Ik heb hem nooit gekocht vanwege het prijskaartje, maar aan de video's te zien, zag het er veel belovend uit voor in de modeltreinwereld.
Mvg,
Bas
-
Volgens mij is dat faller met gps schitteren mooi maar erg duur..en ik denk niet te doen voor zelfbouw...
-
Barcodes, fotocel, Arduino? ...
-
Ik vond dat camera systeem van Faller ook wel interessant, die stond weer in Ontrax. Ze hadden drie camera's verkleed als satelliet boven een auto baan gehangen die al die auto's kon tracken en bijsturen.
Dan ben jij de enige die dat gezien heeft. ::)
Als je goed opgelet had, had je geweten dat het niet met camera's werkt maar met ultrasoon. Niets verkleed dus.
Daarom hebben de auto's helaas nog zo'n opvallende gat in de daken om de ontvanger/zender contact te laten maken met de satellieten.
Ze zijn wel bezig om dat te verbeteren naar minder opvallend maar vindt het niet echt mooi.
En het nadeel dat er altijd "zicht" op de satellieten moet zien voor een betrouwbare werking
-
Ik zag een camera beeld van boven af met bewegende auto's en een vakje er om heen ingevuld door een computer. En dacht zodoende: 'hey wat leuk, een camera systeem'. Nou snap ik wel waarom er drie satellieten boven hingen. Ultrasoon zou ik zelf nooit aan beginnen. Ik zou voor die toepassing iets van een pulserende IR led pakken oid, maar voor wagons gaat dat nooit werken als je geen elektronica wilt inbouwen. + locatie bepaling wordt zo ook lastig.
Om een loc te tracken is dat misschien wel interessant. Elke loc laat je dan met de IR led een unieke reeks (ID) flashen (zoals de knoppen op een IR afstandsbediening) die ontvangers naast, boven of onder! de baan kunnen opvangen. Een IR ledje onder een loc moet niet zo'n probleem zijn.
Niets verkleed dus.
Die ontvangers leken ook op echte satellieten met zonnepanelen en al. Ze waren niet super gedetailleerd verder, maar wel aangekleed... tenzij die dingen zo uit de doos komen :-X Dan is het gwn ontwerp.
Bas
-
Er zijn er die aan een analoge trafo en wat schakelaars genoeg hebben.
Hier heb je er een. Nou ja, iets ingewikkelder.
Als je rijdt met een programma heb je daar weinig aan omdat het programma bijhoudt waar wie is.
Verslikt zo'n programma zich nooit? Dan is zo'n NFC misschien een middel om het weer in de pas te krijgen.
-
Bluetooth heeft wel wat, maar ik denk niet dat het de ultieme oplossing is…..
…..
Ik zou dan liever gaan voor iets gebaseerd op Matter en vergelijkbare technieken voor huisautomatisering. Dat gebruikt al een zeer efficiënt draadloos protocol dat zeker in de toekomst breed beschikbaar zal zijn.
Matter maakt gebruik van IPV6 en een beetje implementatie vereist zo een footprint van 1MByte Flash. Best wel pittig voor een decodertje. Erg efficient kun je m.i. matter niet noemen. Mbt Bluetooth, er is ook zoiets als Bluetooth Mesh.
-
Verslikt zo'n programma zich nooit?
Ja dat doen ze... soms wilt een wissel niet om... schade. We hebben ook wel eens een melder die dan ophoudt met werken... Zelf bedienende blokmodules for the win. :police:
Ik had begrepen dat je met railcom melders een noodstop kon uitvoeren als een trein ten onverwachts op een verkeerde railcom terugmelder beland.
-
Ja oké, maar een noodstop is niet hetzelfde als herstel van de treinposities.
-
Dat kan ook met railcom melders volgens mij. Ik heb het alleen nog nooit gezien in een filmpje ofzo. Maar het schijnt dat in iTrain een trein zichzelf in een blok kan plaatsen.
-
Ik ben op 23-11-2021 dit draadje begonnen, Automatische treinherkenning, https://forum.beneluxspoor.net/index.php?topic=100568.msg3222267619#msg3222267619
Beetje het zelfde idee als wat de topic starter voor ogen heeft.
De insteek was om (goederen) wagons vanaf een rangeerterrein te laten inlezen in i-Train. Hiermee kan de treinlengte min of meer automatisch herkend worden
Groet
Henk
-
Ik zat nog even na te denken, en een nog simpelere manier om kleine beetjes informatie over te dragen tussen spoor en materieel is met streepjescodes. Die zou je dus op de onderkant van je treinen kunnen plakken en dan met een fotodiode in het spoor uitlezen. (Waarschijnlijk een infrarode LED erbij om de onderkant van de trein te verlichten.)
Dit zal waarschijnlijk beter werken met treinen op snelheid. En bonus: als je weet hoe groot de barcode is kan je aan de snelheid waarmee je 'm leest de snelheid van de trein aflezen. En de richting natuurliijk.
De barcode kan info over de lengte van de trein of wagon bevatten zodat je veel makkelijker aan de slag kan zonder al deze info handmatig in een computer in te voeren.
Omgekeerd kan natuurlijk ook, met een streepjescode op het spoor en een lezer in de trein. Zou lijkt me met 1 pinnetje op de decoder moeten kunnen. Alleen streepjescodes op het spoor staat weer wat minder mooi... Wat je zou kunnen doen is de dwarsliggers te beschilderen met twee soorten verf die in zichtbaar licht dezelfde kleur hebben maar infrarood in verschillende mate reflecteren. Wel worden je codes erg kort met minimaal een dwarsligger per bit.
Maar toch is naar mijn mening een manier waardoor de decoder in de loc blokken kan detecteren en dan via RailCom terugmelden wel zeer wenselijk, omdat je dan aan de slag kan met blokbesturing zonder allerlei extra hardware en bedrading.
En je zou ook dingen kunnen doen als een maximumsnelheid aangeven, een (tijdelijke) stop, en dan ofwel in dezelfde richting verder of rijrichting omkeren en verder rijden.
-
Streepjescodes onder de wagens is al eens gedaan. Ik weet niet meer waar ik dat heb gezien.
-
In een hele oude Railhobby. Artikel over een Franse baan. Was behoorlijk vooruitstrevend toen.
Artikel heette: 'Hoe een eigenzinnig iemand een Franse tik opliep '. Jaar weet ik niet meer
-
Streepjescodes onder de wagens is al eens gedaan. Ik weet niet meer waar ik dat heb gezien.
Holtermann Elektronik schijnt zoiets te hebben. De website is echter "under construction". Via de Beneluxspoor encyclopie gevonden.
Ik vraag me echter af wat je niet met al deze dingen wilt. Eigenlijk kun je dan net zo goed een softwareprogramma gebruiken die dit alles biedt, en nog geavanceerder. Met Koploper, iTrain of RocRail kom je een heel eind.
En voor alles geldt: Wat door mensen is gemaakt, is per definitie feilbaar.
Hartelijke groet,
Joop
-
Technisch allemaal mogelijk, en je kunt een leuke hobby hebben aan het ontwikkelen van een dergelijk systeem.
Maar ik denk niet dat er een grote markt is om huidige systemen te vervangen.
Er zijn altijd wel een paar actuele projecten die proberen al-dan-niet bestaande problemen in het automatiseren van modeltreinen op te lossen.
Veel lopen stuk door te grote complexiteit of door een gebrek aan markt.
Er zullen niet veel mensen met je idee aan de haal gaan en een systeem maken dat je nu voor ogen hebt.
Gewoon wat treinen en een eenvoudige centrale kopen. Dan kun je daarmee spelen en kijken hoe je verder gaat/ wil gaan.
Groet,
Tjalling
-
Matter maakt gebruik van IPV6 en een beetje implementatie vereist zo een footprint van 1MByte Flash. Best wel pittig voor een decodertje. Erg efficient kun je m.i. matter niet noemen.
Een voorbeeld van een SoC die dit goed zou kunnen is de Nordic SM nRF52840 (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Fkeyfeatures_html5.html) en die heeft inderdaad 1 MB flash aan boord. Te krijgen voor minder dan een tientje. De TI CC1352R (https://www.ti.com/product/CC1352R?utm_source=google&utm_medium=cpc&utm_campaign=epd-con-null-prodfolderdynamic-cpc-pf-google-wwe_int&utm_content=prodfolddynamic&ds_k=DYNAMIC+SEARCH+ADS&DCM=yes&gclid=CjwKCAjwjMiiBhA4EiwAZe6jQ6IkosN4RUon76g20TxXHpM97VI8T-HVMmI02PkOHR4e0zEemacAbhoCkb8QAvD_BwE&gclsrc=aw.ds) kan ook Matter/Thread aan met 352 kB flash en 80 kB RAM. Daarvoor kan ik geen prijs vinden. Thread gebruikt inderdaad 6LowPAN, een voor dit soort dingen geoptimaliseerde versie van IPv6.
Als dat te zwaar is kan je doen wat bijvoorbeeld Hue doet, waar de hub the Matter regelt en met de lampen en dergelijke praat met het simpelere ZigBee. Hue spullen heb je al voor zo'n 20 euro dus de kosten van de draadloze aansturing moeten meevallen.
Ik zou het prachtig vinden als ik locs en wissels had met allemaal een eigen draadloze decoder dus geen aparte DCC-centrale nodig, gewoon voeding op de rails en de rest gebeurt draadloos. Ook geen aparte kabels voor wisselaansturing en dergelijke, of bij je 9e wissel weer een extra signaaldecoder.
Extra voordeel is dat je dan analoog en digitaal door elkaar kan laten rijden op dezelfde baan.
-
inderdaad 1 MB flash aan boord. Te krijgen voor minder dan een tientje.
Mijn atmega's hebben 32kB flash en ik krijg er alles mee gedaan oh en ze kosten een kwart. In de goede oude tijd waren ze nog 40 cent :'(
.. simpelere ZigBee. Hue spullen heb je al voor zo'n 20 euro dus de kosten van de draadloze aansturing moeten meevallen.
zigbee's zijn leuk, alleen veels te duur om ze ergens voor te gebruiken. Een wemos D1 mini met ESP chip kost rond de ~€2,00 en dan heb je wifi en ook iets van 1MB flash.
gewoon voeding op de rails en de rest gebeurt draadloos.
Je vergeet 1 klein detail. Als je DCC decoders gebruikt, kan je die ook voeden met DCC. Dan heb je 2 draden waarover je stroom en informatie gaat. Je kan prima onder een analoge baan een DCC bus hangen om wissels en seinen mee te schakelen. Die 2 draden voor stroom moet je toch trekken, waarom dan niet meteen informatie mee sturen?
dus geen aparte DCC-centrale nodig
Dat kunnen kleine dingetjes zijn hoor ;)
Extra voordeel is dat je dan analoog en digitaal door elkaar kan laten rijden op dezelfde baan.
Ik ontwerp mijn decoders, melders en schakelpaneel spul om die reden met loconet. Een loconet ding kan direct met een andere loconet ding praten zonder tussenkomst van een centrale. Zo kan je ook analoog rijden en toch gebruik maken van een makkelijk plug en play bus systeem. In plaats van een centrale komt er dan ergens een loconet power supply ergens in de bus.
Mvg,
Bas
-
Dat kan je echter ook met Railcom terugmelders. Met railcom kan de trein je ook nog vertellen met welke snelheid hij rijdt. Ik snap tot op de dag van vandaag nog steeds niet wat je moet met die informatie omdat je dat toch al weet. Je zet immers met je eigen duim de snelheid.. maar goed nfc..
Is dat niet misschien iets voor de toekomst? Dat er dan waarheidsgetrouwer afgeremd wordt omdat de centrale weet hoe hard de trein rijdt?
Bij handmatig rijden zie ik het nut van Railcom überhaupt niet namelijk, maar ik ben dan ook ouderwetsch (en m'n baan is klein) waardoor ik al dat extra digitale spul niet snel nodig zal hebben.
Nfc denk ik lastig omdat er tijd nodig is eerst om de chip powerup, dan komt er een heel circus van datauitwisseling opgang om de chip te indentificeren en daarna pas iets doen...
Het hangt er ook wel vanaf welke tag je kiest, want die zijn er in allerlei snelheden en klasses kwa geheugenruimte.
Waar de ene toepassing een trage lopende band is waar een lezer voldoende tijd zal hebben om in enkele seconden te lezen, razen in een ander proces objecten met flinke snelheid voorbij en moet de uitleessnelheid veel hoger liggen.
Laten we zeggen dat we in modelspoorland aan 1024 unieke nummers (UID's) voldoende hebben, das 10 bit. Dat is, als je elk rijdend ding van een tag voorziet, dan ook het enige wat je hoeft te weten: meer data is onnodig, want een rijrichting kun je er toch niet inprogrammeren (ja, het kan wel, maar er is niets wat dat garandeert en je moet die rijrichting telkens opnieuw in de tag programmeren als je de rijrichting wijzigt).
Bij een onbeveiligde tag is het overbrengen van het UID razendsnel voor elkaar: er hoeft geen authenticatie of versleuteling plaats te vinden, dus die relatief extreem lange tijd ben je al kwijt.
Het enige wat rest is uitlees-afstand en daar zou het moeilijk kunnen worden, omdat ik gok dat menig tag op een metaalrijke plaats gemonteerd wordt, wat uitlezen kan bemoeilijken. Als je daar minder tot geen last van wil hebben, kun je speciale(re) tags aanschaffen die daarvoor geoptimaliseerd zijn en omdat je dan in een specialistischer tak van RFID-werk terecht komt, worden de tags ook duurder.
bij albert hein duurt het ook minstens een 2 tal seconden...
Hoogstwaarschijnlijk is die dan ook niet onbeveiligd, maar vindt er authenticatie plaats. Authenticatie duurt van zo'n beetje het hele proces, het langste, omdat beide apparaten (als het goede authenticatie betreft) elkaar uitdagen en rekensommen op elkaar afvuren, puur om zeker te weten dat de AH-kaart een AH-kaart is en de lezer in de winkel echt de lezer in de winkel.
Dat soort processen heb je in modeltreinland gewoon niet nodig. Het is dat of gewoon slechte techniek van de AH waar ze mee weg komen omdat mensen toch wel bij ze blijven komen winkelen. Het is hetzelfde in het OV: sinds daar de bankpassen ook gebruikt kunnen worden, zijn de lezers van Connexxion echt gruwelijk sloom geworden, terwijl ze daarvoor razendsnel waren.
Ik zat nog even na te denken, en een nog simpelere manier om kleine beetjes informatie over te dragen tussen spoor en materieel is met streepjescodes. Die zou je dus op de onderkant van je treinen kunnen plakken en dan met een fotodiode in het spoor uitlezen. (Waarschijnlijk een infrarode LED erbij om de onderkant van de trein te verlichten.)
Dit zal waarschijnlijk beter werken met treinen op snelheid. En bonus: als je weet hoe groot de barcode is kan je aan de snelheid waarmee je 'm leest de snelheid van de trein aflezen. En de richting natuurliijk.
Die infrarode LED ga je zeker nodig hebben om nog onderscheid te kunnen maken tussen streepjes en wit. Grote kans dat je dan ook een ander materiaal, beter in IR-reflectie, moet hebben voor goede streepjescodes.
Het lezen zou ik niet op snelheid baseren, maar gewoon op een totaalreflectie: laat de ontvanger maar gewoon 60 keer per seconde (of iets dergelijks) volledige monsters nemen. Veel barcodescanners werken al jaren met een globale scanner en niet meer met een zwiepende laser (ze zijn er nog wel, maar worden zeldzaam vanwege hun kwetsbaarheid en traagheid). Een LED belicht in 1 keer de code, die vervolgens door een speciale sensor in 1 keer gelezen wordt.
De richting kun je zelfs uit het lezen van de code afleiden: als de code een startbit bezit, weet de lezer meteen of hij de code van links naar rechts binnenkrijgt of andersom, en draait - indien noodzakelijk - meteen zijn resultaat om kwa volgorde. Het enige wat je zelf nog moet doen is dan zorgen dat de lok eerst ergens 'aangemeld' is waardoor het systeem weet of de lok met het startbit naar voren of naar achteren rijdt, anders weet de lezer nog niets ;)
De barcode kan info over de lengte van de trein of wagon bevatten zodat je veel makkelijker aan de slag kan zonder al deze info handmatig in een computer in te voeren.
Mwah... dat kán, maar trein-lengte info in een barcode samenvatten vereist zeer veel unieke barcodes die je dan ook zelf onder de lok moet plakken: immers, elk nummer heeft z'n eigen lengte (vergelijk de zelf-weegschalen in supermarkten waar 4 bananen een andere streepjescode oplevert dan 5 en dergelijke)
-
Ok, bask185 heeft een goed punt dat draadloos niet ontzettend nodig is omdat DCC ook goed werkt. En dank ook voor de inzichten van Menno.
Dan hier wat ik heb zitten bedenken voor streepjescode-achtig spoor dat locs kunnen uitlezen terwijl ze er overheen rijden. 8)
Normaliter heeft modelspoor bielzen / dwarsliggers, met daartussen iets dat een andere kleur heeft. Laten we voor het gemak uitgaan van donkere bielzen en lichtgekleurd ballast. Als je daar overheen rijdt met een fotodiode die naar beneden kijkt zie je dus afwisselend licht/donker. Nu kunnen we tussen twee bielzen het ballast wat donkerder maken.
Laten we nu zeggen dat lichtgekleurd ballast een 0 is, en donkerder ballast een 1. En de donkere bielzen geven aan waar een 0 of een 1 begint/eindigt. Dan kunnen we bijvoorbeeld de volgende codes maken. Spatie is een dwarsligger, x een databit:
0 1 0 x x x x 1 1 0
Of, als we meer data hebben:
0 1 0 x x x x 0 1 x x x x 1 1 0
En nog meer:
0 1 0 x x x x 0 1 x x x x 0 1 x x x x 1 1 0
Dus van links naar rechts weet je dat er 4 databits komen na een 0 1 0. Dan ofwel een 1 die aangeeft dat het feest voorbij is, of een 0 en daarna een 1 en nog 4 databits.
In de andere richting weet je dat er 4 databits komen, dan een 0 als het klaar is of een 1 en dan een 0 en nog 4 databits. Wel even de bits omdraaien omdat je ze in omgekeerde volgorde gelezen hebt!
Met 4 bits heb je 16 codes. Een stuk of 4 kan je besteden aan verkorte blokaanduidingen (A, B, C, D). Dat is voldoende om te weten in welke richting een trein door een wissel gegaan is als-ie dat via RailCom terugmeldt.
Daarnaast kan de trein de bielzien die-ie ziet tellen en weet je dus vrij precies hoe ver-ie is en hoe hard-ie rijdt.
Je kan de trein dan ook vertellen "na X bielzen stoppen". En dan de locdecoder vertellen hoeveel bielsafstanden hij lang is voor en na de fotodiode. Zo kan-ie superprecies aan het eind van een perron stoppen.
Dit kan je dan combineren met ABC, zodat de trein dankzij het ABC-signaal weet wanneer-ie weer mag gaan rijden. Of gewoon na een door de streepjescode voorgeschreven haltertijd. De streepjescode geeft ook aan of de trein doorrijdt of in de omgekeerde richting terug vertrekt.
Spoorstreepjescode kan ook baanvaksnelheden aangeven.
Ik geloof dat bij N spoor je zo'n twee bielzen per cm hebt. Met 4 databits + 6 voor overhead is dat 5 cm. 8 bits = 8 cm en 12 bits = 11 cm. Dan moet je steeds een cm of 4 overslaan voor je de volgende code kan plaatsen.
Ik zie het helemaal zitten!
Dus maar eens zien of ik een wagon kan uitrusten met een Arduino, een fotodiode en een klein schermpje dat laat zien wat-ie van het spoor uitgelezen heeft.
Voor een IR fotodiode is meestal licht gewoon licht en donker gewoon donker maar als je dit serieus wilt gaan doen wil je naar ballast dat er optisch hetzelfde uitziet maar in IR wel verschillend is om zo de code door te kunnen geven.
-
Iljitsch, dat brengt mij weer op een idee. De loc heeft naar onderen gericht een ir tx diode hierop niet een constante maar de diode geeft een code .. snelheid mag enorm hoog, twee of drie bytes is voldoende om in die code de indentificatie van die loc te stoppen en misschien nog veel meer. Op gezette punten in de baan een rx diode tussen de bielzen... en voila we weten waar welke lok is... rob
-
Dat doen ze bij het DCCar systeem al jaren, werkt goed.
Mvg spock
-
Uhlenbrock heeft iets dergelijks voor treinen ontwikkeld genaamd Lissy.
Ik heb ook nog ergens EditsPro locdecoders waar een ir-diode op kan worden aangesloten. Werkt uiteraard alleen met de EditsPro centrale en bijbehorende software.
Het kan allemaal en is vast leuk om te ontwikkelen.
-
….
Daarnaast kan de trein de bielzien die-ie ziet tellen en weet je dus vrij precies hoe ver-ie is en hoe hard-ie rijdt.
….
Wat ook kan. Meet de omwentelingen die de motor maakt met een hallsensor o.i.d. Geeft je een perfecte indicatie van afgelegde weg en snelheid. Voor DC motoren met koolborstels kan je de snelheid ook meten adhv commutator spikes. Stuur info terug via Railcom en je weet de positie in een blok.
Ander idee: Bij meerdere rijdende treinen is de DCC BUS altijd druk bezet met het versturen van herhalingsdrachten. Daarnaast komen nog de opdrachten voor het vertragen en versnellen. Je zou de DCC BUS behoorlijk kunnen ontlasten met een nieuwe DCC opdracht die gewenste nieuwe snelheid en massavertragingsimulatie doorgeeft aan de decoder. Versnellen of vertragen doet de loc dan zelfstandig. Voor de PC software is er dan wel de uitdaging dat die exact dezelfde curve moet simuleren om de positie in het blok bij te houden. Vereist ook dat de snelheidsijking ook gekend is door de decoder.
-
Misschien is dit interessant: Using RFID on modelrailroads (https://www.starfishrail.co.uk/)
Groet Meino
-
Ik zie het helemaal zitten!
Aan de slag dan en laat maar eens zien of je complexe treinbewegingen zoals afkoppelen, omlopen, rangeren, lokwissel, een goederen sleep splitsen, etc. kunt realiseren door dwarsliggers te tellen. O ja, en klinkers tellen bij straatspoor....?
Ik lees het met belangstelling want de techniek gaat voort maar ik denk gelijk: wat kan het mij brengen wat ik nu niet kan?
Gr, Ben.
-
Bij meerdere rijdende treinen is de DCC BUS altijd druk bezet met het versturen van herhalingsdrachten
Iets wat met Railcom moet kunnen, is dat decoders hun pakketten bevestigen. Als ze na het eerste pakket het bericht vatten, hoeft de centrale niet nog 19x hetzelfde bericht te sturen. Dat zou wat moeten schelen. Ik zou nog de bit lengtes halveren.
Op een pakket met acceleratie waardes te sturen, vind ik ook wel een goede.
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.
dat brengt mij weer op een idee. De loc heeft naar onderen gericht een ir tx diode hierop niet een constante maar de diode geeft een code
Volgens mij had ik al dips op dat idee :P Dan moet het vast een goed idee zijn ;)
Om een loc te tracken is dat misschien wel interessant. Elke loc laat je dan met de IR led een unieke reeks (ID) flashen (zoals de knoppen op een IR afstandsbediening) die ontvangers naast, boven of onder! de baan kunnen opvangen.
Ik had ook nog bedacht om een nabijheids sensor oid op een rangeer lok te plaatsen. De lok kan dan autonoom afremmen en aankoppelen.
Zelfs als we het kunnen he om volautomatisch wagonnen weg te rangeren, zijnde met barcodes, IR, NFC, RFID, whatever. Wie zou dat eigenlijk willen? Dat is toch het leukste om zelf te doen ;)?
bas
-
Je kan al dat andere 'gedoe' beschouwen als een 'ander' deel van de hobby, naast het 'met treintjes spelen' :) :)
-
Of treintjes als een manier om thuis met elektronica bezig te zijn. Versterkers bouwen begint na een tijdje misschien ook wel te vervelen ;)
-
Bij McKinley Railway hebben ze RFID verregaand toegepast, zie bijv. https://www.youtube.com/watch?v=DXXYqRamxng
Op de modelspoorbeurs in Southampton eind januari stonden ze met een demobaantje en heb ik (met Sven) een tijdje met ze staan praten. Ze gebruiken RFID vooral om te weten waar materieel op de baan staat, met name omdat ze als club nogal wat materieel hebben. Het materieel stond al in een database dus dat was relatief eenvoudig aan elkaar te koppelen. De RFID oplossing is ontstaan uit de wens om te weten waar materieel op de baan staat zonder alles te moeten voorzien van decoders. RFID chips zijn goedkoop en ze hebben een producent gevonden die er de lol van in zag en wat onderdelen wilde produceren.
Opvallend was dat ze verder op DCC gebied heel erg Europees gericht waren. Er stond naast de RFID-demo ook een DCC-demobaan met ESU onderdelen.
Zelfs als we het kunnen het om volautomatisch wagonnen weg te rangeren, zijnde met barcodes, IR, NFC, RFID, whatever. Wie zou dat eigenlijk willen? Dat is toch het leukste om zelf te doen ;)?
De bovengenoemde club gebruikt het systeem ook om rangeeropdrachten te controleren. Een loc mag pas weg bij een station als wagon A, B en C op het juiste spoor zijn gezet. Dus handmatig rangeren met een digitale controle. Op die manier kun je ook een nieuw aspect aan het gebruik van RFID toevoegen.
-
Ik had ook nog bedacht om een nabijheids sensor oid op een rangeer lok te plaatsen. De lok kan dan autonoom afremmen en aankoppelen.
Zelfs als we het kunnen he om volautomatisch wagonnen weg te rangeren, zijnde met barcodes, IR, NFC, RFID, whatever. Wie zou dat eigenlijk willen? Dat is toch het leukste om zelf te doen ;)?
Tja, de grote vraag is natuurlijk wat een bepaalde modelspoorbaander leuk vindt en wat niet. Als we het even beperken tot het rijden, want het bouwen is nog veel ingewikkelder:
Getrouw de echte wereld nadoen is moeilijk omdat je vanaf boven / opzij een relatief kleine baan, of een relatief klein stuk van een grotere baan overziet. Het rijden van een vooraf vastgelegde route is dus eigenlijk direct saai, en ook moeilijk realistisch te doen omdat zelfs als je de seinen kan zien het zien van de borden/seinen met snelheidsbeperkingen heel erg lastig wordt.
Wat leuk kan zijn is rangeren met goederen. Dat kan op een relatief korte baan die ook niet diep hoeft te zijn omdat alle sporen min of meer parallel kunnen liggen. Ook heb je aan één of twee locs waarschijnlijk genoeg.
Bij een wat langere baan met meerdere bestemming waartussen treinen rijden (kan bij vracht, min of meer verplicht bij passagierstreinen) is één trein natuurlijk snel saai. Aan de andere kant is alles automatisch door een computer laten doen ook saai. ??? (Totdat het echt een heel grote baan wordt waarbij allerlei dingen zich geautomatiseerd afwisselen.)
Dus: wat is een redelijke tussenvorm voor de berijders van een niet heel kleine, maar zeker niet erg grote baan?
Dat kan je dan op twee manieren aanvliegen:
- Een simpel systeem uitbreiden met automatisering om de saaie dingen eruit te halen
- Een computergestuurd systeem uitbreiden met handmatige opties... om de saaie dingen eruit te halen ;)
Nadeel van de eerste optie is dat als je langzaan allerlei dingen toevoegt je op een gegeven moment met een onontwarbare kluwen kan komen te zitten en wellicht onnodig geld uitgeeft.
Nadeel van de tweede optie is dat je gelijk flink geld uit moet geven en veel tijd moet spenderen en het resultaat wellicht tegenvalt.
Met dat alles in het achterhoofd en een aantal sessies met iTrain is mijn conclusie dat baanvakbescherming met terugmelders voor mij waarschijnlijk aanzienlijk teveel van het goede is. Wellicht is het wel een optie om zo'n programma te gebruiken om de wissels en seinen aan te sturen door in één klik een rijweg in te stellen. Of met de z21 app.
Wat ik in elk geval wil doen is automatische remming met ABC-schakelingen toepassen. Zo kan ik een trein naar een station sturen en stopt-ie daar automatisch en hoef ik dus niet de trein handmatig netjes te laten stoppen. In plaats daarvan kan ik mijn aandacht dan op een andere trein richten voordat die eerste stilstaat.
Bij een kopstation bouw je zo'n schakeling gewoon permanent in 8), bij een station langs de vrije baan kan je een sein neerzetten en de status van de ABC aan het sein koppelen. Of het sein overslaan en de ABC koppelen aan een stroomvoerende wissel. Dus als de wissel goed staat mag de trein rijden, als-ie verkeerd staat niet.
Dan nog een enkel sein + ABC waar zich belangrijke conflicten kunnen voordoen. In het geval van het baanplan dat ik eerder postte voor de kruising waarmee je van de buitenlus de binnenlus op kan om bij de keerlus, kopstaion en opstel/rangeersporen te komen.
Maar dus wel "handmatig" opletten dat als er een trein voor een sein staat te wachten een andere trein 'm vanachter ramt, bij gebrek aan baanvakbescherming.
Ik ben benieuwd naar andere zienswijzen. 8)
Nog even over streepjescodes enzo: in bovenstaand systeem zou je die mooi in kunnen gebruiken om een trein netjes aan het eind van een perron te laten stoppen doordat de code de stopafstand kan doorgeven en de trein dan weet hoe lang-ie voor en achter de streepjescodelezer is.
Met ABC zit je het het probleem dat een getrokken trein het ABC-signaal relatief laat moet zien, maar een geduwde trein veel eerder om met al die wagons voor de loc op de goede plek te stoppen. Hoe lossen anderen dit op?
-
Met ABC zit je het het probleem dat een getrokken trein het ABC-signaal relatief laat moet zien, maar een geduwde trein veel eerder om met al die wagons voor de loc op de goede plek te stoppen. Hoe lossen anderen dit op?
Omdat ik op mijn voorlopig vrij kleine baan ook wat wil gaan "ontwikkelen" (lees: ontdekken hoe iets werkt) heb ik het ABC systeem een beetje bestudeerd. Uit de gegevens van de Lenz onderdelen begrijp ik, dat een geduwde trein geen enkel probleem heeft om op tijd te stoppen, als de eerste wagon (dus een stuurstand of zo) maar stroom afneemt. Dan stopt de hele trein precies hetzelfde alsof de lokomotief voorop rijdt.
Ik heb mijn centrale nog niet binnen dus ik kan nog geen bevestiging geven uit de praktijk. Maar misschien kan iemand anders dat wel ?
-
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 En de ABC module op 'onveilig' staat pas dan wordt ABC ingeschakeld. Zo krijg je dan een grotendeels gelijke remweg of je nu trekt of duwt,
(https://images.beneluxspoor.net/bnls_2023/deleteme-6454ca30c4716.png) (https://images.beneluxspoor.net/bnls_2023/deleteme-6454ca30c4716.png)
Ik heb hiervoor een tweetal zelfbedienende blokmodules op de tekentafel, eentje met en eentje zonder buffer. Die BM2 zijn leuk, maar echts veels te duur voor wat het is.
Tja, de grote vraag is natuurlijk wat een bepaalde modelspoorbaander leuk vindt en wat niet
True, sommige zijn helemaal weg van iTrain en volautomatisch rijden. Mij verveelt dat in 3 minuten. Ik deel verder je mening over hoe je baan wilt aansturen. ABC voor kopsporen en bloksystemen en de rest: Zelf doen.
Daarbij vind ik het dan wel een beetje leuk dat sommige dingen wel automatisch kunnen. Ik heb zelf ooit met een arduino een soort logger ding gemaakt. Die hang je aan de XpressNet bus en die neemt dan op wat jij doet met je multimaus die dat dan later kan afspelen. Zo kan je dus wel automatisch omlopen zonder bezetmelders. (of dat goed werkt, is dan vraag 2 ;) ). Ja en een sik die je richting wagons kan sturen maar wel zichzelf kan laten afremmen aankoppelen, vind ik dan wel ook wel geinig klinken. Nodig heb je het niet natuurlijk.
Mijn ideale manier van treinbaan besturen zou zijn het handmatig stellen van rijwegen en seinen ed. En dat de treinen dan grotendeels zelfstandig over de blokmodules kunnen rijden. Ik vind het leuk als je dan een uitrijsein op groen zet, dat de trein dan uit zichzelf gaat rijden.
Ik denk dat ik voor mezelf ook niks zou hebben aan unieke wagon detectie. Ik zou het leuk vinden om zoiets te ontwerpen, maar om te gebruiken... meh ik rangeer zelf wel ;D
Bas
-
MartinRT en bask185:
Ja, inderdaad als je via een spoorbezetterugmelder de ABC inschakelt dan ben je van dit probleem af. Maar dat is weer extra spul. Wat ik in gedachten heb voor die kopstationsporen is gewoon een sectie spoor permanent aan een ABC-schakeling te zetten. Dan ben je met vijf dioden klaar. Sterker nog, volgens mij kan ik dan allevier de sporen op één zo'n schakeling aansluiten. Ben je voor hooguit een euro klaar. 8)
En dan bij twee sporen de ABC aan het begin van het spoor in laten gaan en bij de andere twee sporen meer naar het eind. Wel even opletten dat je de getrokken treinen en geduwde treinen naar de juiste sporen stuurt.
Terugmelders met stroomdetectie ("current detection") zijn relatief ingewikkeld begrijp ik, maar wellicht dat er iets simpelers te fabrieken is met een IR-sensor die dan de ABC inschakelt. Dan kan je de voorkant van iedere trein detecteren, of-ie nu stroom afneemt of niet.
Het schijnt dat er mensen aan dit forum deelnemen die goed zijn met electronica, wellicht een kleine business opportunity? ;)
-
Zo kan je dus wel automatisch omlopen zonder bezetmelders.
Wat natuurlijk niks te maken heeft met het echte spoor, waar dit een zeeer handmatige procedure is. Dit is een filmpje (https://www.youtube.com/watch?v=tuUEQvYOylk) wat ik ooit maakte op spoor 1 van Den Haag HS toen dat het begin/eind was van de beneluxtrein, en de loc dus moest omlopen.
(Bij gebrek aan ICR-stuurstandrijtuigen op schaal N ben ik wel gedwongen de mogelijkheid tot overlopen op te nemen in mijn baanplan...)
Ik denk dat ik voor mezelf ook niks zou hebben aan unieke wagon detectie. Ik zou het leuk vinden om zoiets te ontwerpen, maar om te gebruiken...
Toen ik aan iTrain begon leek me dit een vrij belangrijk iets maar dat programma houdt gewoon bij hoe de wissels staan, welke kant welke trein op rijdt en welke bezetmelders er dan activeren. Zo weet-ie dus eigenlijk altijd welke trein waar is.
Lijkt me wel handig voor hele grote banen waar heel veel verschillende treinen rijden. Zeker als bijvoorbeeld bij een modelspoorvereniging mensen zelf wat meenemen om eens op de clubbaan te laten rijden. Als je dan automatisch leert welke DCC-adressen waar de baan op komen maakt dat alles wel makkelijker, lijkt me.
Maar in het algemeen natuurlijk geen slechte zaak dat als je een trein op de baan zet je die automatisch op het scherm ziet verschijnen in plaats van dat met de hand in te moeten voeren. Bespaart wat gedoe, maar moet dus zelf geen nieuw gedoe toevoegen anders heb je er weinig aan...
-
Dan kan je de voorkant van iedere trein detecteren, of-ie nu stroom afneemt of niet.
De simpele oplossing is dus om te zorgen dat de voorkant altijd stroom afneemt. Zo moeilijk is dat niet.
-
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 ?
-
Wel leuk hoe we van NFC, zijn geeindigd op Wifi, ethernet, ABC, IR, barcodes en wat nog meer? ;D
-
Wel leuk hoe we van NFC, zijn geeindigd op Wifi, ethernet, ABC, IR, barcodes en wat nog meer? ;D
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.
-
@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.
-
Interessant verhaal :police:. 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
-
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 :angel:) en de rest eraan hangen.
-
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, 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.
-
GPS modelleren. (y)
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...
-
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. ;D
Bas
-
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 (https://www.espruino.com/ADNS5050), 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. 8)
-
(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 :angel:)
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
-
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.)
-
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.