Stroomdetectie gecombineerd met RailCom detector?

[Jeroen van Tol]

Hallo allemaal,

Ik zit al een tijdje te piekeren over RailCom. Hoewel niet iedereen het eens is over het nut er van en ze bij de NMRA ook al jaren proberen te verzinnen hoe RailCom nou precies zou moeten werken is het voor mij toch een onderwerp wat me blijft interesseren.

Mijn voornaamste doel met RailCom was om te kunnen zien waar een trein daadwerkelijk is (bezetmelding met daarbij door welke trein), in tegenstelling tot waar een trein zou moeten zijn (bezetmelding in cominatie met treinbesturingssoftware). Inmiddels kun je wel een RailCom detector kopen/bouwen die dat kan, maar alle bezetmelders vervangen door RailCom detectoren is nogal een kostenpost. (Bezetmelding op basis van stroomdetectie kost een paar euro per sectie, een RailCom detector een paar tientjes!)

Na wat piekeren zit ik nu aan de volgende oplossing te denken. Ik heb begrepen dat wanneer je een opdracht stuurt naar een RailCom decoder, dat deze (en alleen deze) antwoord geeft in de cutout periode direct na de opdracht.
Tijdens de cutout periode staat er heel even geen spanning op de baan dus de bezetmelders op basis van stroomdetectie meten op dat moment geen van allen stroom. Behalve dan (volgens mij) die ene sectie waar een RailCom decoder antwoord aan het geven is.

Stel nu dat je voor de logica 'achter' de stroomdetectie (normaal gesproken shiftregisters volgens de s88 norm) gebruik maakt van een microcontroller (dergelijke oplossingen zijn er al). Dat is iets duurder dan normaal maar op 16 secties scheelt het niet heel veel. Je bent dan in staat om het DCC signaal te monitoren en steeds te bewaren aan welk decoderadres de laatste opdracht werd verstuurd. Tevens ben je dan in staat om de cutout periode te 'zien'. Wanneer je vervolgens tijdens de cutout periode een bezetmelding krijgt weet je dat het laatst bewaarde adres in de betreffende sectie zit. Kortom, je hebt dan 1 RailCom detector nodig per 16 stroomdetectie secties. En dan vallen de kosten wel mee.

Er is weliswaar (nog?) geen software die iets met deze informatie doet maar aangezien ik zelf software aan het bouwen ben wil ik wel eens weten of deze theorie haalbaar is. Mijn vraag is dan ook: Wat denken de goeroes op het gebied van bezetmelding en microcontrollers hier van? Kan het wat ik wil of zie ik zaken over het hoofd?

Alvast bedankt voor het meedenken!
Groet,
Jeroen.

[Karst Drenth]

Hoi Jeroen,

Best wel een haalbaar idee

Zeker als je de railcomdetector ook b.v. de s88 bus laat scannen...

Dus zoiets als een s88LocoNet adapter, die ook RailCom detecteerd en beide messages ( bezetmelding en lokadres per bezetmelding ) op de bus zet.

Er zullen overigens nog wel wat haakjes en oogjes aanzitten, omdat de cut-out maar enkele microseconden groot is. Je zult dus het wegvallen van de bezetmelding moeten detecteren, vervolgens RailCom moeten detecteren en die twee gegevens aan elkaar koppelen. Maar.... de meeste, huidige, RailCom geenabelde  decoders zenden 'unsollicited' hun adres al, waardoor er dus al een speciale RailCom message aan te pas moet komen om e.e.a. uit elkaar te kunnen houden....

Denk ze lekker verder, ik hou het in de gaten

Grtzz,

Karst

[Wim Ros]

Jeroen,

Volgens mij is deze discussie al eens eerder gevoerd. Ik zie het nut niet van te weten waar een lok is en in welke sectie op grond van RailCom.

Er is maar een plaats waar het enig nut heeft, en dat is aan het eind of het begin van een rangeerterrein wat buiten om de computer handmatig wordt aangestuurd.

Wat je vervolgens denk ik over het hoofd ziet is hoe krijg je de Railcom informatie vanaf  zeg het S88 schuifregister in de seriele poort van de computer.

Alle besturings programma's weten perfect waar een lok is en kunnen die ook perfect volgen.

Mvg
Wim.

[maartenvanderburgt]

Ik zie het nut niet van te weten waar een lok is en in welke sectie op grond van RailCom.

Dan zet binnen welk huidig systeem maar eens een lok of meerdere op de baan. Of haal er een of meer van de baan af.
Dan weet je meteen waarom Railcom zoveel handiger is, want de lok meldt zichzelf aan (of af door niet meer te melden). Die hoef je dus niet meer in te geven via je computerprogramma, samen met de positie waar die neergezet is. Of je hoeft hem niet meer te verwijderen uit je systeem.

Kortom: uitermate handig en in dit tijdperk van automatisering een zeer bruikbare logische stap vooruit. Met de tijd meegaan dus, over een paar jaar bestaat er niks anders meer en zijn alle huidige programma's verouderd.

Maarten

[Wim Ros]

Dan lees je dus niet wat ik al in mijn vorige bericht geschreven heb.

Wim.

[Wim Romijn]

over een paar jaar bestaat er niks anders meer en zijn alle huidige programma's verouderd

Zoiets heb ik 20 jaar geleden, of nog langer, ook wel eens gehoord, nog niet over railcom, maar over andere programma's. Dat heet marketing, laat die jongens ook een droom hebben.

[Wim Ros]

Hi,

En er is een nog veel groter probleem, je hebt decoders nodig die de RailCom informatie kunnen uitzenden. Dat is misschien een leuke optie als je nieuw begint met de hobby, maar niet als je daar al een tijdje mee bezig bent en een niet nader te noemen aantal decoders in bedrijf hebt. Of je moet een apart zendertje monteren.

Maar goed, bij het aanmelden op de baan daar kan ik me nog wel iets bij voorstellen dat kan automatisch. Maar automatisch afmelden bij het systeem of bij de software daar kan ik nog niets mee.

Ik wil best mee met de tijd, alleen moet het wel zoden aan de dijk zetten en goedkoper zijn dan het systeem wat er nu gebruikt wordt.

Zolang de aanbieders er zelf nog niet uit zijn, zal ik er geen geld aan uitgeven.

Marklin heeft MFX
Fleischmann/Uhlenbrock hebben Traincontroller/Lissy
Digitrax heeft Transponders

En nu Lenz met RailCom.

En allemaal niet compatibel met elkaar.  

Maar goed laat Jeroen maar een systeem bedenken dat aan de eisen van het Railcom systeem voldoet, dus geen standalone oplossing is, en waar men dus iets aan heeft, bij alle RailCom systemen.

Mvg
Wim.

[henk]

Ik denk eigenlijk dat Jeroen niet zit te wachten op de volgende discussie over nut en onnut van RailCom. Ik denk ook niet dat dat nieuwe argumenten gaat opleveren. 

[maartenvanderburgt]

Dan lees je dus niet wat ik al in mijn vorige bericht geschreven heb.

Dat geloof je toch zelf niet. Ik lees in ieder geval iets wat niet juist of niet volledig is, zoals:
"Alle besturings programma's weten perfect waar een lok is en kunnen die ook perfect volgen."
Dat klopt grotendeels, maar dan vergeet je er wel bij te zeggen, dat dat pas gebeurt nadat je de lok en de plaats waar die staat eerst hebt moeten ingeven in je systeem. En dat hoeft bij Railcom dus niet. En een huidig besturingsprogramma weet al helemaal geen raad met "verdwenen" lok's.

Dat je verder het nut ergens niet van ziet lees ik ook en dat nut zie ik dus wel.

Dan een inhoudelijker reactie van jou waar ik wel wat mee kan.

"Maar automatisch afmelden bij het systeem of bij de software daar kan ik nog niets mee."
Heel simpel. Wanneer een lok van de baan genomen wordt, komt er geen Railcom-signaal meer op dat baanvak en ziet het (toekomstige) programma dat er geen lok meer aanwezig is. Dit staat los van eventuele bezetmelding (bijv. door wagons).

"Zolang de aanbieders er zelf nog niet uit zijn, zal ik er geen geld aan uitgeven."

Marklin heeft MFX,  klopt, maar dat is geen DCC. Overigens wel ongeveer dezelfde werking als Railcom
Fleischmann/Uhlenbrock hebben Traincontroller/Lissy  met hetzelfde probleem. Er wordt pas iets gedetecteerd als op een bepaalde plaats iets gebeurt (een trein passeert een detector)
Digitrax heeft Transponders idem als hierboven, maar met een ander systeem

"En nu Lenz met RailCom."toch al een hele tijd hoor

"En allemaal niet compatibel met elkaar."
 en dat is inderdaad een heel cruciaal punt, waardoor het nog niet goed van de grond komt. De modeltreinindustrie werkt nog steeds meer naast/tegen elkaar dan met elkaar. Over enige tijd zijn alle Europese DCC-producenten bij elkaar (misschien al geweest) om Railcom beter vast te leggen dan wat met DCC gebeurd is. Dan zal er dus een soort Railcom-standaard ontstaan, waaraan iedere fabrikant zich dient te houden die Railcom als mogelijkheid in zijn systeem en decoders wil hebben. Aangezien Lenz het ontwikkeld heeft zal die wel de houder van de naam blijven, maar het vrijgeven voor algemeen gebruik, zoals nu ook al een aantal merken Railcom hebben. Dan kunnen ook de diverse merken programma's aangepast worden op de werking met Railcom

Maarten

[maartenvanderburgt]

Ik denk eigenlijk dat Jeroen niet zit te wachten op de volgende discussie over nut en onnut van RailCom. Ik denk ook niet dat dat nieuwe argumenten gaat opleveren. 

Jeroen vraagt zelf om mee te denken. Daar komt een reactie op, waarin getwijfeld wordt aan het nut. Juist dat nut benadruk ik, temeer daar Jeroen blijkbaar voorop wil lopen door zelf te programmeren. Dan moet je wel het in mijn ogen grootste nut duidelijk hebben. De keuze of hij dat wil gebruiken en hoe is aan hem.

Maarten.

[henk]

Jeroen heeft een innovatieve gedachte aangaande RailCom en stelt daarover een technische vraag. Tot nu toe is Karst de enige die op zijn vraag ingaat.
Over nut en noodzaak heeft Jeroen vast wel nagedacht. Al was het alleen maar omdat alle vragen die hij tot nu toe op het forum over Railcom heeft gesteld onmiddelijk tot dezelfde discussie tussen dezelfde personen (ik ook, waar blijft Han) met precies dezelfde argumenten hebben geleid.

[Jeroen van Tol]

De discussie over het al dan niet zinvol zijn is inderdaad al gevoerd en probeer ik hier ook te vermijden. Met een beetje zoeken staan alle voors en tegens al ergens besproken. Liever niet in dit draadje dus. (Niet omdat ik er niet blij ben met alle mogelijke informatie maar meer omdat het in andere topics thuis hoort en we er daar naar hartelust over kunnen praten)
 
@Karst
Het probleem van 'unsollicited' adresmeldingen hangt als het goed is af van hoe je de decoder programmeert. Je kunt dat volgens mij uitzetten door een juiste CV programmering. (Mits de 'onofficiele standaarden' door decoderfabrikaten aangehouden worden )

@Wim
Ik ben van plan om vanaf de detectieprint meteen naar LocoNet te communiceren en de hele s88 achterwege te laten. Zeg maar zoiets als jullie S88LN op elke detectieprint in plaats van de schuifregisters. Ik heb immers al een microcontroller nodig om RailCom uit te lezen dus kan die ook meteen de LocoNet communicatie voor zijn rekening nemen.
Ik denk alleen dat er (nog?) geen LocoNet bericht is gedefinieerd waarin ik deze info kwijt kan, wat zoveel betekent dat ik daar zelf een bericht voor zou moeten verzinnen. Qua compatibiliteit misschien niet zo mooi maar ik begeef me toch al op een vlak waar nog nauwelijks iets voor te krijgen is dus kan dat er ook wel bij. (En het is eventueel nog aan te passen mocht zo'n bericht er ooit wel komen of stiekum toch al bestaan ) Op de PC aangekomen (Middels de door jouw geleverde LocoNet->(RS232)PC interface) kan mijn treinbesturingssoftware het bericht eenvoudig oppakken.

Het doel is om tegen vergelijkbare kosten als de huidige bezetmelding (en daarmee hebben Karst en Wim de lat behoorlijk hoog gelegd met hun scherp geprijsde artikelen ) een RailCom detector er 'gratis' bij te krijgen. Dat zal niet helemaal lukken maar ik wil het verschil zo klein mogelijk proberen te houden. En ja, het zal inderdaad voor toekomstige starters pas interessant worden want vervangen is duur en er is ook nog geen software die de info op pakt. (Mijn software is waarschijnlijk pas leuk voor de eerstvolgende generatie want heel ver ben ik nog niet )

[Wim Ros]

Jeroen,

Als je het via loconet laat verlopen, dan is het geen RailCom meer, maar is het Lissy/Com of Transponder/Com. En die zijn wel gedefineerd in het LocoNet-Protocol. Daar hoef je zelf geen wiel voor uit te vinden.

Je hebt dan alleen een vertaalslag nodig van RailCom naar LocoNet. En heb je dus in feite een nieuw systeem, wat nergens meer mee compatibel is. Als dat is wat je wil prima.

Mvg
Wim.

[Jeroen van Tol]

@Wim
Daar heb je een verdraaid goed punt waar ik totaal niet over nagedacht had!

Wel een leuk dilemma. De techniek van Transponding vind ik persoonlijk niet zo mooi vanwege o.a. die lompe magneet. Vandaar mijn keuze voor de RailCom techniek. Voor het mooie zou het dan een XpressNet oplossing moeten worden. Maar qua 'bus' vind ik de werking van LocoNet dan weer mooier dan die van XpressNet...

Voor mij persoonlijk speelt het probleem inderdaad niet omdat de 'logica' van mijn centrale in de PC zit en de centrale(hardware) en boosters fysiek gescheiden zijn van de rest. Ik kan zelfs (in theorie) alle mogelijke bussoorten tegelijk met de PC verbinden en het met elkaar laten werken.

Voor anderen zouden er dus eigenlijk twee varianten moeten komen, waarbij je natuurlijk wel altijd gebonden bent aan de voorwaarden voor RailCom (cutout, decoders, enz.):
Eén 'standaard variant' voor XpressNet, waarbij RailCom gewoon als RailCom wordt gecommuniceerd.
En een tweede variant waarbij RailCom berichten 'vertaald' worden naar vergelijkbare Transponder of Lissy berichten (indien mogelijk, anders kan het alleen met 'passende' zelfbouw centrales) en deze over LocoNet communiceert.

De tweede is wat ik eigenlijk aan het doen was maar Wim heeft een terecht punt. Ik ga eens uitzoeken of je eenvoudig RailCom kunt vertalen naar Transponder of Lissy berichten (oftewel, komt de functionaliteit enigszins overeen?). Kan dat niet dan heeft de tweede variant voor weinig mensen nut en ga ik met de eerste verder. Anders hou ik me bij de tweede (en kan wellicht iemand anders het nabouwen voor XpressNet).

*** edit
Wel een vreemd idee eigenlijk: Mijn centrale geeft dan RailCom opdrachten aan decoders, vervolgens ontvangt de treinbesturingssoftware Transponder/Lissy antwoorden, en tot slot geeft deze Transponder opdrachten welke door de centrale weer vertaald moeten worden naar RailCom opdrachten voor op de baan.
Ik verzin weer wat  
***

*** edit2
En door deze eerste edit wordt me ineens duidelijk dat de tweede variant niet eens gaat werken zonder een centrale die daar mee om kan gaan.
Ik ga dus verder met variant 1. Bedankt voor de oplettendheid Wim!
***

[Jeroen van Tol]

Ik loop meteen tegen het eerste probleem aan: Geen documentatie te vinden over RailCom berichtspecificaties, waarschijnlijk omdat het nog niet 'uitgekristalliseerd' is. Berichtspecificaties over Transponding zijn er als het goed is wel maar ik kan ze niet vinden... Zo wordt het erg lastig om iets te maken wat ergens compatible mee is.

Een variant voor XpressNet maken kan op dit moment alleen door zelf verzonnen berichten te gebruiken (binnen de al wel gereserveerde range, zoals OpenDCC ook doet) en ze dan 'ooit' om te zetten naar officiele berichten.

Voor mijn eigen baan kies ik dan toch liever voor LocoNet. Een XpressNet variant bekijk ik nog wel eens op het moment dat de berichten wel bekend zijn.

Wanneer iemand overigens uitgebreide specs heeft over LocoNet (dus meer dan het 'personal edition' verhaal van Lenz) dan hou ik me aanbevolen!