Samengevat: De 'MiNiDiGi' Centrale

[Han Zijlstra]

Keus zal voornamelijk gaan over de Global detector en de localdetector. Men wil er uiteindelijk een nmra norm van hebben ( ze zijn pas bezig vanaf 95 of zo:) dus de verschillen zullen uiteindelijk wel meevallen.
Tis nu even wachten wat de software boys er mee doen ( ben zeer benieuwd of koploper hier al iets over heeft) De truc van Esu om zijn terugmelder uit te rusten met 16 terugmelders waarvan 4 met Railcom lijkt me op dit moment de meest interressante. Met een beetje goede wil is zagen in de rails om melding mogelijk te maken straks zooo jaren 2000:)

[Jeroen van Tol]

Men wil er uiteindelijk een nmra norm van hebben ( ze zijn pas bezig vanaf 95 of zo:) dus de verschillen zullen uiteindelijk wel meevallen.

Dat geldt alleen voor RailCom. Digitrax heeft de hoop op nomering voor hun Transponder-systeem lang geleden opgegeven.

Met een beetje goede wil is zagen in de rails om melding mogelijk te maken straks zooo jaren 2000:)

Voor locatiebepaling zul je volgens mij nog steeds moeten zagen... Ook bij RailCom toch?

Het grappige is overigens dat de Digitrax variant blijkbaar al even in omloop is en dat ik daar nog niets over had gelezen. Daarentegen is de RailCom variant net wel/net niet op de markt maar lees je er overal al over...

En dat terwijl ik bij het vergelijken van de specs eerder voor Transponding van Digitrax zou kiezen... Volgens mij moeten die jongens meer aan marketing doen! 

[Wim Ros]

Jeroen, het RailCom verhaal is ook al heel wat jaren oud, waarschijnlijk net zo oud als het Transponder verhaal. Een slap aftreksel is MFX van Märklin (ESU).
Al met al een systeem met veel haken en ogen, en vooral nog steeds in de kinderschoenen.

Mvg
Wim.

[henk]

@Henk
Goeie vraag... Mijn woordkeus is misschien ook niet ideaal, want eigenlijk is het veel interessanter of er treinbesturingssoftware is die er iets mee doet...

Nou Jeroen, de vraag is of deze vorm van terugmelding de makers van treinbesturingssoftware voor de computer eigenlijk wel zoveel biedt. Paul Haagsma heb ik er nog nooit iets positief over horen zeggen.
Zoiets als Railcomm maakt stand alone automatisering met alleen een centrale wat gemakkelijker. Zoiets als Lissy, maar dan niet met infrarood.

[Han Zijlstra]

Voor locatiebepaling zul je volgens mij nog steeds moeten zagen... Ook bij RailCom toch?

Railcom geeft een aantal dingen door: o.a snelheid . samen met bv wissels die hun actuele wisselstand terug melden en de lengte van je baanstukken moeten je treinbesturingssysteem die info geven waar de lok zich bevindt.
Het Lissy gebeuren lijkt interressant totdat je uitgaat rekenen wat dat kost. ( onbetaalbaar)

Dan kun je nog beter met het RFID van littfinski werken wat overigens al samenwerkt met railroad & co.
 

[henk]

Dat moet je toch eens toelichten Han. De centrale/computer kan alleen iets met de snelheid en de lengte van de baanvakken in relatie tot een vast punt. Zo'n punt kan denk ik niet te ver weg liggen in verband met de betrouwbaarheid. Hoe worden die vaste punten dan doorgegeven?

Dit heeft overigens weinig met Railcomm te maken. De meeste computerprogramma's passen het door jou genoemde principe al toe. De centrale weet immers van zichzelf al hoe hard de locs rijden.

[Paul Haagsma]

Nou Jeroen, de vraag is of deze vorm van terugmelding de makers van treinbesturingssoftware voor de computer eigenlijk wel zoveel biedt. Paul Haagsma heb ik er nog nooit iets positief over horen zeggen.

Henk,

Beetje kort door de bocht maar het klopt wel wat jij zegt. Als een besturingsprogramma goed werkt kan het voor mij op slechts 1 plaats toegevoegde waarde hebben en dat is de plek waar een handmatig rangeerterrein eindigt en de trein meegegeven moet worden aan het automatisch rijden.
Echter met de handregelaar optie van mijn programma is dit ook niet echt meer een probleem.

Als op het koploperforum gebruikers mij echt kunnen overtuigen van de meer waarde van deze toevoeging wie weet komt het dan wel, maar vooralsnog laat ik deze toepassingen links liggen.

[fissy]

Ik denk deze vorm van terug melding is echt belangrijk, voor een grote baan.

Ik heb immers de idee, dat de mogelijkheden met een programma beperkt zijn als je een vaste volgorde in de omlopen hebt. Dan denk ik immers an TV kijken. Ik heb meer de Idee van spelen op de baan, een niet de baan (of de PC) spelt voor mij. Nu is dit niet echt de punt van het transponder, maar als je nu van dit volgorde afwijkt, door een fout, een actie van een "met club lede" of een ongeluk en een foute herstel van dit ongeluk. Ben ik zeker zo'n transponder systeem is toch een goede hulp. Bijzonders als iedere station een bestuurder heeft met een eigen PC, dan heb je echt zo'n systeem nodig,..

Groet

Bernd

[Paul Haagsma]

Hallo Bernd,

We wijken wel af van het oorspronkelijke onderwerp....

Je hebt wel gelijk met wat jij zegt, echter dat is niet mijn doelgroep. Mijn doelgroep is degene die lekker thuis met zijn treinen bezig is en dit graag geautomatiseerd wil doen. Koploper is gemaakt voor automatisch bedrijf!

Trouwens dit hoeft echt niet volgens een vast patroon te gaan. Hangt er echt vanaf hie je de software gebruikt. Ik denk dat meest gebruikte software producten beide mogelijkheden in zich hebben (vaste patronen of random gebeurtenissen).

Mvg,
Paul.

[fissy]

Je hebt gelijk, wij dalen af...

Ik dacht al, dat koploper niet voor dit bedoeld is...

@Jeroen, let op dit digitrax transponding werkt slechts met digitrax hardware en dan ook niet echt eenvoudig, maar als dit systeem werkt, werkt het goed...

Ik heb goede contacten met Zimo, se hebben ook een transponding-system noemt HLU, werkt ook niet met alle decoders :-|

Ik denk gebruiken van de code in de loconet specs is "envoudig" maar je hebt toch echt veel hardware voor nodig, kijk maar naar de handleiding van de BDL 168...

Groet

Bernd

[Albert.H0]

De eerste kandidaat voor een experimenteerprintje is gevonden

Volgend ideetje, voor afremmen/stoppen zonder PC?
Vandaag mijn Lenz LG100 remsignaalgenerator eens opengemaakt, zit een Philips chip in met een dikke streep erdoor. Wat nog leesbaar is is P87C515?  4A. Lijkt tot de 8-bit microcontrollers te horen. Kent alleen de stand stop, is een "broadcast"bit waar alle decoders op reageren, en niet remmen tot lage snelheid (geel sein). Zoiets zou toch op een intelligentere  manier met een PIC/Atmel kunnen, waarbij in stand "geel sein" alle snelheden boven een ingestelde waarde verlaagd worden naar een vaste waarde en snelheden die er al onder liggen ongewijzigd blijven, en bij stand "rood" alle snelheidsinformatie op 0 gezet wordt? Vraag is alleen of je dit met een sniffer oplost, dus systeem onafhankelijk op het DCC signaal, of op bus-niveau (xPressNet of LocoNet). Uitgang dan naar aparte booster(s).
Nadeel is dat je alle binnenkomende snelheidsinformatie moet bewerken. Bij uitbreiding met RailCom functionaliteit zou je dit kunnen beperken tot het gedetecteerde adres.

[Han Zijlstra]

@ Henk
Een wissel is een vast punt en kent twee posities. die doorgegeven worden aan de centrale.
Het baanvak daarachter kent een lengte x(en is ingegeven in besturingsprogramma), Lok ( = uitzendende decodere) komt voorbij meldpunt met snelheid y en de besturingssoftware rekent in no time uit waar de lok in het baanvak zich gaat bevinden.
Het is inderdaad niet allemaal nieuw het enige wat nieuw wordt is dat de communicatie twee richting wordt. Maw de besturingssoftware ( denkt) te weten waar een lok is maar krijgt nu de bevestiging van de lok zelf.

[henk]

Han, ik snap wel dat een wissel een vast punt is, maar de centrale/computer zal toch moeten weten wanneer de trein om het even welk vast punt (een wissel lijkt me eigenlijk niet zo handig) passeert, wil hij kunnen gaan rekenen. Dat wordt toch stukjes rails isoleren.

[Karst Drenth]

...Dat wordt toch stukjes rails isoleren...

Hoi,

Ook van mij maar eens een bijdrage aan dit onderwerp

Dat klopt helemaal Henk.
RailCom is eigenlijk niets anders dan een middel om data van de loc naar een 'RailCom-detector' te sturen.

Er kan allerlei nuttige info verstuurd worden, b.v. of een wissel is omgegaan, hoe warm een decoder is, wat het actuele motor toerental is etc. etc. Hier praten we over de z.g. dynamische CV's.

Dit is een generiek mechanisme, dus zover de fantasie reikt, zover kun je gaan.

Om echter te weten WAAR een trein zich bevindt, heb je idd lokale RailCom detectors nodig. Deze luisteren dan alleen specifiek naar dat stuk je rails waarop ze zijn aangesloten.
In essentie niets anders dan de huidig bekende methode van stroom detectie, alleen nu met de zekerheid dat er niet alleen bekend is DAT er een trein ergens is, maar ook WELKE.

Overigens elimineer je hiermee de generieke mogelijkheden van feedback van uit de decoder om dynamisch voornoemde parameters op een centraal punt uit te lezen en dit aan b.v. een computersysteem door te geven.

Interessant zou het worden, als er op de decoder een lees-inrichting zou zijn die b.v. 'bakens' in het spoor zou kunnen lezen en dit via railcom zou kunnen doorgeven. Dan kan e.e.a. wel weer centraal.
^{( overigens kom je hier dan weer op het verhaal van een RFID lezer in de loc die RFID tags uitleest die in de baan liggen, vergelijk b.v. ERMTS )}

Een volgend probleem is het gebruik van boosters. Omdat RailCom alleen werkt in de stroomkring waarin zich de decoder opdat moment bevindt, zal in het geval van het gebruik van boosters, dus de RailCom info naar die betreffende booster met ingebouwde detector gaan.

Om naar Henk's opmerking terug te keren, puur als terugmelding kom je dan ook nog op het aspect kosten. In principe moet dan elke 'bezetmelder' als RailCom detector worden uitgevoerd. Deze signalen moeten dan b.v. via LocoNet ( of een ander bussysteem ) doorgegeven worden aan een centraal punt, b.v. een PC met besturingssoftware.

Kortom eens met Paul en Wim's opmerkingen, een goed werkend software systeem weet op de bezetmelder nauwkeurig WAAR een trein zich bevindt en heeft derhalve geen extra info nodig voor de positie bepaling. Wel zou het wellicht handig zijn om b.v. de actuele snelheid te weten voor b.v. het remmen. Maar zelfs dit is 'fraglich'.

In het geval wat Bernd beschrijft is e.e.a. wel degelijk zinvol. Je hebt het dan over meerdere onafhankelijke computersystemen, die bij binnenkomst van een loc in je controlegebied kunnen aangeven welke trein dat is.
Overigens heeft Uhlenbrock dat met z'n Lissy al aardig voor elkaar. De nieuwe IB's kunnen een loc automatisch op 1 van de regelaars zetten als die door Lissy gedetecteerd wordt.

Verder onthoud ik me van waarde oordelen over de zinvolheid van RailCom. Technisch is het aardig bedacht, wel redelijk gefreubelt overigens, dat de decoder stroom moet sturen door een kortgesloten centrale/booster uitgang !
Toepassingen zijn er ook voldoende, alleen denk ik dat je ze niet moet zoeken in het bereik van automatisch rijden en op bezetmelding lijkende systemen.

Grtzz,

Karst

[Jeroen van Tol]

@Wim
Je hebt (weer eens) gelijk. Het is inderdaad allemaal rond dezelfde tijd begonnen. (Heb het nog even opgezocht) Alleen is Digitrax uit de DCC-werkgroep gestapt omdat men gezamenlijk geen oplossing kon bedenken waarbij het aanpassen van bestaande apparatuur niet nodig zou zijn. (Bijvoorbeeld de aanpassing voor de cut-out)
Na een zelfstandige doorontwikkeling vond Digitrax een of twee jaar later wel een oplossing. En zo te zien is het zelfs al een tijdje op de markt. Dan moeten er toch mensen te vinden zijn die er ervaring mee hebben...

@Henk
Ik denk dat Han bedoelt dat je een blok (tussen twee wissels) niet meer in stukken hoeft te hakken omdat je met RailCom 'zeker' weet wat de trein wel of niet aan opdrachten heeft uitgevoerd en je dus ook preciezer uit kunt rekenen waar de trein zou moeten zijn.
Zoals jij zegt afleiden vanaf de pc kan ook maar dan weet je niet zeker of een opdracht ook echt door de decoder is uitgevoerd dus is het minder precies.
Al met al dus nog steeds de rails in blokken verdelen, alleen mogelijk niet meer in start-, rij en stopsecties. Het zal denk ik nog wel even duren voordat er een systeem ligt dat zó precies de locatie kan bepalen, maar dat is inderdaad de dag dat we de opmerking maken die Han hier schetst.  

@Paul
Ik ben met je eens dat het niet 'noodzakelijk' is. Maar het is op zijn minst 'handig'. Het is makkelijker om een trein willekeurig op de baan te kunnen zetten en dat de software hem automatisch met locatie en al registreert dan dat je die informatie handmatig aan de software moet vertellen. (Vooral na een pc-crash erg prettig)

Zoals jij en Bernd al aangeven is het pas 'noodzakelijk' wanneer je met heel veel vrijheid handmatig wil rijden. Kortom, wanneer je zoveel vrijheid hebt dat er wel eens (al dan niet per ongeluk) twee treinen in hetzelfde blok kunnen belanden. Dat 'zie' je alleen met zoiets als RailCom.
Omdat ik het speel-element heel erg belangrijk vind mik ik op een systeem waarbij je kunt aangeven of je die vrijheid wel of niet moet krijgen.

Ik vergelijk het met de parkeerhulp op een auto. Niet noodzakelijk, wel een toevoeging op het rijgemak, en heel af en toe behoed het je voor een stomme fout door een hoop lawaai te maken. Maar... hij trapt nog steeds niet op de rem voor je, en er hangt een prijskaartje aan.  

@Albert
Leuk om te lezen dat er meer mensen zijn het niet kunnen laten om een 'kastje' open te trekken en uit te zoeken wat het nou eigenlijk doet.
Heel erg leerzaam en dé manier om er achter te komen of er soms tekortkomingen in zitten die verbeterd kunnen worden.
Nu ben ik juist van de software, dus hardware die zelfstandig beslissingen neemt probeer ik zoveel mogelijk te vermijden. Maar dat is ieder voor zich natuurlijk want het kan net zo goed werken.
De sniffer bouw ik overigens puur om later de zelfbouw centrale te kunnen testen. Niet om functioneel toe te passen in het gebruik van de baan.

@Karst
Je was me voor dus ik dacht dat ik mijn verhaal wel weer weg kon gooien... Maar het valt mee. 
Vanwege die kortsluiting (en cut-out apparatuur) en de LocoNet aansluiting viel mijn oog op de digitrax variant als zijnde een 'betere' oplossing. Ik zou dat alleen wel eens gestaafd willen zien met ervaringen van gebruikers. En het prijskaartje is natuurlijk ook knudde.

Prijstechnisch wil je zelf een print kunnen maken welke bi-directionele communicatie en bezetmelding combineert waarbij de vraag is of je de  aloude 'stroomdetectie' dan nog wel nodig hebt. Communiceren lukt immers alleen als er een decoder is om mee te praten.


Groet,
Jeroen.