volgende »

[Noordwaarts]

Misschien kunnen de digitaal-experts alhier mij helpen met het volgende.

Als ik het goed begrepen heb, dan zend iedere van RailCom voorziene decoder zijn adres uit.
M.a.w.: de decoder maakt kenbaar: "Ik ben loc die-en-die en ik rijd nu met snelheid x".
Klopt dit?

Zo ja, dan zou het toch mogelijk moeten zijn om op basis daarvan locs en treinstellen voor seinen te laten afremmen?
Immers, een centrale weet dan dat loc die-en-die het spoor voor een rood tonend sein binnenrijdt en zou dan een rembevel naar die decoder kunnen sturen.
Klopt dit?

Zo ja, waarom bestaan er dan (nog) geen modules die op basis van dit principe werken?

mvg,
Gert

[Anne W]

Beste Gert,

Interessante vraag, maar voor je vraag na "zo ja" heb je in het stuk voor "zo ja" één mededeling van de decoder niet vermeld: "en ik ben nu daar en daar", tenminste als de decoder/railcom dat kan.

Groet, Anne W

[Noordwaarts]

Hallo Anne,

Geen idee of de decoder ook kan vertellen waar hij is. Het lijkt mij dat dat vooral afhankelijk is van hoe je je modelbaan inricht.
Je zult dan immers secties moeten aanbrengen en die van detectors voorzien. Als je dat doet, dan weet je centrale waar een loc met een decoder die meldt "ik ben loc Y en rijdt met snelheid X" zich bevindt.

De vraag is dan dus: kun je op basis daarvan locs en treinstellen laten afremmen voor een rood sein?

mvg,
Gert

[Dirk J]

BiDi (zoals de techniek heet) of RailCom (een naam die eigendom is van Lenz) kan nog maar heel weinig. Op dit moment is dat in het algemeen alleen het eigen loc adres zenden, vaak ook de eigen snelheid, en soms ook een antwoord op een POM opdracht. Zie hier voor de lijst met BiDi decoders en wat ze kunnen.
Lenz heeft inmiddels RailComPlus. Daar kan een decoder zichzelf aanmelden en tevens doorgeven welke functies beschikbaar zijn met welke eigenschappen.

In de eerste BiDi documenten vind je inderdaad dat er genoemd wordt "kunnen zenden waar de lok is". Dat is nog niet geïmplementeerd, en ook (nog) niet nuttig, omdat de decoder geen middel heeft om zijn locatie te bepalen. En wat je niet weet kun je ook niet vertellen.
Voordat BiDi/RailCom een dergelijk signaal kan uitzenden, zal er dus eerst iets bedacht en genormeerd moeten worden waardoor een decoder weet waar hij is. Daar zijn legio ideeën over, maar voorlopig zie ik die nog niet tot werkende producten leiden. Daar heb je ook pas wat aan wanneer RailCom zo volwassen is dat het te allen tijde betrouwbaar werkt. Met de huidige normeringen en technieken kun je dat alleen krijgen op een baan met slechts een booster en een beperkt aantal actieve RailCom decoders.

Kortom, het is leuk, maar er is nog een lange weg te gaan voordat het bruikbare realiteit is. En dan nog zul je zoals het er nu uitziet alles op je baan geschikt moeten maken voor RailCom(Plus). Dus moet je dan o.a. alle boosters en decoders vervangen... Lenz wil dat best wel leveren  

Conclusie: RailCom biedt op dit moment helemaal niets dat bruikbaar is om treinen te laten afremmen of stoppen voor een rood sein. Daarvoor kun echter je wel het ABC systeem gebruiken, mits je compatibele decoders toepast.

[Noordwaarts]

Hallo Dirk J,

Dank voor je antwoord en de link.

Het ABC-systeem van Lenz is me bekend, maar dat zou betekenen dat ik allerlei decoders (waaronder veel sounddecoders) zou moeten vervangen.
Dat gaat dus niet gebeuren. Voordeel van RailCom is dat in ieder geval ESU aparte RailCom-zendertjes biedt, die je kunt toevoegen aan locs waarin decoders zitten die die functionaliteit missen.

Ik begrijp uit jouw verhaal dat RailCom nog niiet kan vertellen waar een loc zich bevindt. Maar als het dan wordt opgelost zoals ik voorstelde, met detectors die een sectie monitoren?
Dan weet je toch per sectie welke loc zich ergens bevindt? Feitelijk is dit toch wat ESU al doet met haar EcoSDetector RC?
Zie: http://www.esu.eu/en/products/digital-control/ecosdetector/ecosdetector-rc/

In zo'n sectie (baanvak, stationsspoor, zijspoor, of wat je maar wilt) weet je centrale dan toch welke loc er zich bevindt? Dan zou de centrale die loc toch kunnen laten afremmen voor een rood tonend sein? Of zie ik het allemaal te simpel?

mvg,
Gert

[Dirk J]

In dat geval is het niet de RailCom decoder die vertelt waar hij is, maar alleen wie hij is. De bezetmelder zonder RailCom is een eenvoudig dom ding: bij 2-rail is het in essentie een paar diodes en een transistor, bij 3-rail zelfs dat niet. In het geval van RailCom met de door jou genoemde ESU module wordt de bezetmelder een slim ding. Hij kan van de RailCom decoder de identiteit ontvangen, en dan dat gegeven met de locatie (namelijk het id van de sectie waarop de RailCom decoder zich bevindt) doorgeven aan de ECOS. De ECOS krijgt dus twee gegevens: (1) loc die-en-die bevindt zich in (2) sectie-zus-en-zo. Het eerste komt van de locdecoder en wordt door de intelligente bezetmelder doorgegeven, die er het tweede aan toevoegt.

Vervolgens moet je op de ECOS de te ondernemen acties programmeren. De ECOS kan dan bijvoorbeeld spoorbomen sluiten. Aangezien de ECOS weet welke secties bezet zijn, zou hij dan ook een trein voor een bezette sectie moeten kunnen laten stoppen.

Hoe dan ook heb je aan de slimme ESU bezetmelder alleen wat als je ook een ECOS hebt, (of een CS met ESU software) totdat er andere compatibele centrales komen.

Groeten, Dirk

[Noordwaarts]

Dank voor je reactie Dirk.

Dan zou het met RailCom i.c.m. EcoSDetector RC dus toch moeten kunnen.
Als dat werkt, dan zou je dus geen systeem als Lissy (met aparte zendertjes onder je locs en ontvangers tussen de rails) meer nodig hebben.

Ik zag vandaag dit op de site van ESU: http://www.esu.eu/support/tipps-tricks/ecos/firmware-400-installieren/
Geheel onderaan die pagina staat "Die neue Software 4.0.0. ist nun die stabile Basis für mehr Erweiterungen, die im Laufe des Jahres 2014 erscheinen werden. Lassen Sie sich überraschen!"

Misschien is die verrassing wel wat ik hier beschreef: afremmen voor stoptonende seinen d.m.v. RailCom en geschikte detectors.
Zou mooi zijn!

mvg,
Gert

[Dirk J]

Inderdaad Gert. Ik verwacht van RailCom met de huidige ontwikkelingen meer dan van Lissy, waar het nut mij overigens geheel van ontgaat. Wat de EsuDetector doet is indertijd niet voorzien toen het concept BiDi/RailCom gelanceerd werd, en strikt genomen is het meer dan alleen een uitbreiding of implementatie van het protocol. RailCom decoders zouden zèlf hun locatie uitzenden, en dat principe hebben ESU/Lenz hiermee losgelaten. Volgens BiDi/RailCom zouden lokdecoders rechtstreeks terug praten naar de centrale; in dit concept praat een lokdecoder tegen een intelligente bezetmelder, die op zijn beurt met de centrale praat. Zo werkt voortschrijdend inzicht... Je kunt dan de vraag stellen of dit nog zuiver RailCom is (volgens de oorspronkelijke normen: nee) maar dat vind ik persoonlijk geen interessante discussie.

In mijn ogen is de slimme bezetmelder wel een van de meest realistische manieren om het probleem van het lokaliseren op te lossen. Ook zie ik meer mogelijkheden voor alternatieve aanbieders van soortgelijke functionaliteit dan bij Lissy. En alles bij elkaar betekent het in mijn ogen dat dit een begaanbare nieuwe weg kan blijken te zijn.

Kijk je op dit moment naar de markt voor centrales, dan is voor velen de z21/Z21 een heel aantrekkelijk ding, en een behoorlijke bedreiging voor de ECOS. ESU heeft met deze uitwerking van RailComPlus iets in handen dat daar goed tegenwicht aan kan bieden.

Voor mensen die geheel geautomatiseerd willen rijden, bijvoorbeeld met Koploper, zie ik geen echte meerwaarde in RailCom. Ja, een lok kan zich automatisch aanmelden, maar als je de kennis hebt om een dergelijk pakket te programmeren (want dat is het "vullen" van het pakket in mijn ogen wel) is dat een functionaliteit waar je zeker niet met verlangen naar uitkijkt. Bovendien zou de software dan dit soort terugmelding moeten gaan ondersteunen. Dat is een flinke operatie die bij de huidige stand van zaken geen duidelijke meerwaarde heeft, en die ik daarom ook niet verwacht.

Echter, als je meer handmatig wilt kunnen rijden maar wel met gedeeltelijke automatisering, zoals bijvoorbeeld een digitale implementatie van blokbeveiliging, dan biedt BiDi/RailComPlus perspectief. Ik volg het dan ook met grote belangstelling!

Groeten, Dirk

[Noordwaarts]

Precies Dirk. Dat is nu juist wat ik voor ogen heb: handmatig rijden maar met gedeeltelijke automatisering.

De z21/Z21 zal zeker een lastige concurrent blijken te zijn voor de EcoS.
Sinds kort (update 4.0.0) heeft de EcoS echter een VCN-mogelijkheid aan boord. M.a.w.: je kunt met een tablet de besturing van de EcoS overnemen.

Uhlenbrock blijft qua interface toch wel heel erg achter. Het lijkt me technisch gezien een degelijk systeem, maar dat ieniemini display en die enorme trits fysieke knoppen: niet meer van deze tijd. Wordt de hoogste tijd dat Uhlenbrock met een nieuw jasje komt.

mvg,
Gert

[Dirk J]

Helemaal mee eens Gert, en ook mijn insteek.

Terzijde: afkortingen zijn altijd lastig... Het is Virtual Network Computing = VNC.

Groeten, Dirk

[Noordwaarts]

Oeps, je hebt gelijk. VNC inderdaad.   

mvg,
Gert

[Blausee-Mitholz]

Railcom is mooi maar je moet ook iets hebben voor plaatsbepaling.
Tot zover is weet is dat er (nog) niet met Railcom.
Met lissy heb je een opnemer in de baan dus plaatsbepaling.

Houd wel even rekening mee dat als je zou willen Loconet niet samen gaat met Railcom bij de ECoS. (Dit staat ook duidelijk aangegeven bij de handleiding van de LNC voor de ECoS)

Ik heb de LNC. Maar de Railcom stond bij mij al uit want die gebruikte ik toch al niet.
Loconet met de ECoS doet het prima bij mij 

Mvg, Johan

[Dirk J]

Johan, dat was tot voor kort inderdaad een van de problemen.
Maar RailCom kan tegenwoordig wel met plaatsbepaling werken mits je bezetmelders gebruikt die Railcom ondersteunen. Er is er inmiddels een die dat doet, de ESU Detector RC.

Het wachten is nu op een nuttige toepassing hiervan. We hopen dat de nieuwe software voor de ECoS dat gaat bieden. 

[Blausee-Mitholz]

Dan heb je dus toch bezetmelders nodig dus zie ik het voordeel er niet van in. (En dat zijn niet de goedkoopste bezetmelders van ESU.......)

Mvg, Johan

[Dirk J]

Daar kan ik een heel eind in meekomen. Hierboven hebben we een uitgebreide discussie gehad over het nut van Railcom.

Net als alle andere plaatsbepalende systemen: het heeft pas nut als je een toepassing hebt (centrale of programma) die daardoor iets kan wat nu niet kan, of iets veel makkelijker maakt dan het nu is. Programma's als koploper werken uitstekend zonder loc-herkenning, en hebben aan detectie middels bezetmelders voldoende.

Dat "iets wat nu nog niet kan" moet nog komen. En dan kunnen we pas echt beoordelen wat nut en rendement is.

Een van de mooie dingen van Railcom: ieder mag er voor ontwikkelen en producten op de markt brengen. Het lijkt me dat het daarom een kwestie van tijd is en dan wordt Railcom vanzelf nuttig en steeds betaalbaarder.