Digitalsysteme .... eine Gegenüberstellung/nl

Verwendung

Digitale systemen voor modelspoorwegen ... een vergelijking; maar geen vergelijkingen en waarderingen

Digitale systemen ... een vergelijking

Het juiste digitale systeem?

Uit de vele vragen en bijdragen van het forum: Railroad & Co, Freiwald Software (Egmating) heb ik geleerd dat veel modelspoorders die nieuw zijn in het digitale tijdperk of een ombouw / uitbreiding plannen, onzeker zijn over welk digitaal systeem en welke componenten "de juiste" zijn.

Verder heb ik de indruk gekregen dat er in bepaalde bedrijfssituaties problemen ontstaan die alleen zinvol kunnen worden opgelost door rekening te houden met de kennis van het/de digitale systeem/systemen.

Dit alles deed me denken aan mijn eigen tijd toen ik overstapte van het analoge systeem naar digitaal.

Deze vergelijking is bedoeld als aanvulling op de zuivere technische gegevens en feiten zoals gedefinieerd door de fabrikanten in hun gegevensbladen of in de normen.

Ik benadruk nadrukkelijk dat dit artikel niet bedoeld is als een vergelijking van "voor en tegen", noch is het bedoeld om welk systeem dan ook te waarderen.

De lezer moet deze informatie ter harte nemen en hopelijk met succes opnemen in zijn oplossingsproces.

Overwogen digitale systemen

Er zijn een aantal digitale systemen op de markt, maar ik zal alleen kijken naar de systemen die het meest vertegenwoordigd zijn op het bovengenoemde forum; deze omvatten ...

• DCC
• Märklin met zijn varianten
• Selectrix (SX)

Dit verslag gaat over de status van de systemen zoals ze (in mijn geval) in augustus 2011 waren. Latere ontwikkelingen moeten later worden toegevoegd.

Historisch overzicht

Voor zover ik weet en herinner, was Märklin de eerste onderneming die een "compleet" digitaal systeem voor modelspoorbanen op de markt bracht, dat bekend werd als "Motorola I".

De opvolgers Motorola II en mfx' volgden in de loop der jaren.

Märklin introduceerde zijn digitale systeem onder het marketingaspect: Twee draden zijn genoeg om de modelbaan te bedienen. Geen "draadwarboel" meer zoals bij analoge systemen.

Voor zover mogelijk werden de rails gebruikt als draden, ze vormen de verbinding tussen de commandopost en de respectievelijke decoders (centrale >> locomotief-/schakeldecoder). Voor de terugmelding (bezetmelding), die later werd toegevoegd met de pc-aansluiting, werd een extra aparte communicatielijn geïntroduceerd, de "s88-bus" (terugmelddecoder >> centrale).

De technische details van het Märklin systeem werden nooit officieel bekendgemaakt. Technisch geïnteresseerde gebruikers bepaalden de protocollen voor "Motorola I / II en mfx" "achterstevoren" (reverse-engineering) en konden zo zelfgebouwde producten realiseren.

-- Het bedrijf ESU uit Ulm, dat waarschijnlijk een beslissende rol heeft gespeeld in de ontwikkeling van "mfx", verkoopt een product met het "ECOS" controlecentrum, dat ook het "mfx" protocol kan uitvoeren; om redenen van bescherming wordt dit echter het "M4" protocol genoemd.

Onder deze randvoorwaarden kunnen de Märklin-systemen worden gecategoriseerd als "gesloten systemen".

Vanwege deze "compartimentering" ontwikkelde de accessoires-industrie (Lenz), waarschijnlijk in samenwerking met andere modelspoorfabrikanten", het digitale systeem "DCC", dat werd gestandaardiseerd en waarin alle technische gegevens "open" zijn en gratis kunnen worden ingezien.

Het bedrijf Trix, toen nog juridisch onafhankelijk, ontwikkelde samen met industriële ondersteuning het digitale systeem "Selectrix". Dit systeem is ook gestandaardiseerd en alle informatie / gegevens zijn openlijk beschikbaar. Ondertussen is het systeem verder ontwikkeld wat betreft extra locomotiefadressen / functies. Dit nieuwe Selectrix systeem is "upwardly compatible" met zijn voorganger en wordt aangeduid als Selectrix "SX II" (SX2). Het "originele" Selectrix systeem wordt in het volgende aangeduid als Selectrix (SX). Tegenwoordig wordt "SX I" (SX1) ook gebruikt in sommige literatuur om onderscheid te maken tussen de twee.

DCC en Selectrix kunnen worden omschreven als "open systemen" omdat - zoals al eerder vermeld - alle systeemgegevens openbaar worden gemaakt.

Specifieke ontwikkelingsachtergronden

Märklin met zijn systemen en DCC werden ontwikkeld met het oog op de "speelgoedindustrie", wat betekent dat alle vroegere knoppen, schakelaars en transformatorfuncties in een centrale moesten worden geïntegreerd. De randapparatuur, d.w.z. de decoders, moesten zo eenvoudig en dus zo goedkoop mogelijk zijn.

De verbinding met een pc werd eigenlijk pas later toegevoegd en was niet de focus van de eerste ontwikkelingen.

Deze twee systemen kunnen daarom worden gedefinieerd als "gecentraliseerde systemen".

Tijdens de ontwikkeling van Selectrix werd voor een compleet andere aanpak gekozen, waarschijnlijk vanwege de industriële ervaring met gedistribueerde systemen. In het Selectrix netwerk zouden de perifere componenten ook zoveel mogelijk "intelligentie" moeten hebben om een "gedistribueerd systeem" te kunnen bouwen. Deze aanpak vereiste ook een compleet ander communicatiesysteem (bussysteem). Met Selectrix kan elke busdeelnemer gegevens / informatie met elkaar uitwisselen; de enige beperking is hier met de locomotiefdecoders (tijdens het rijden).

Dit is niet mogelijk met de twee eerder genoemde systemen, waar er slechts één richting is van de commandopost naar de decoders (randapparatuur); (met uitzondering van de RailCom methode die momenteel op de markt komt met DCC > zie hieronder; evenals "mfx" hier is er een tegenovergestelde richting locomotief decoder > centrale). Met deze twee functies is de tegenovergestelde richting van communicatie echter alleen beperkt tot de locomotief decoder en is niet algemeen geldig zoals bij Selectrix (>> een groot en significant technisch systeemverschil).

Selectrix valt daarom in de categorie "gedecentraliseerde of gedistribueerde systemen".

En hun effecten

Uiteindelijk is het, rekening houdend met het bovenstaande, niet verwonderlijk dat zich compleet verschillende communicatiestructuren ontwikkelden, zowel aan de hardwarekant als aan de softwarekant in de vorm van protocollen.

Terwijl Selectrix het doet met één bussysteem en één protocoltype voor rijden, schakelen en seinen, vereisen DCC en Märklin elk twee bussystemen en protocoltypes; één voor rijden en schakelen en één voor seinen. SX2 vereist een tweede protocoltype voor communicatie met de locomotief decoder.

Als er handregelaars zijn of moeten worden geïntegreerd om de modelbaan te besturen, is er meestal een derde bus- en protocolsysteem nodig voor Märklin of DCC; Selectrix heeft daarentegen geen extra bussysteem nodig. Bij SX2 kunnen er vanwege de verschillende realisaties door de afzonderlijke fabrikanten ook extra interfaces en/of apparaten op de markt komen in de controlecentra, zodat de handregelaars / bedieningsingangen ook het SX2-protocol kunnen bedienen.

Opmerking: Een Selectrix handcontroller heeft slechts toegang tot één van de SX-bussen van het systeem tegelijk. Als andere SX-bussen moeten worden bediend, moet de handcontroller opnieuw worden aangesloten of omgeschakeld met een elektronische schakelaar.

Verschillende, openbaar gemaakte bussystemen / protocollen

DCC

 Dit protocol (zonder RailCom) is zo ontworpen dat men kan spreken van een "standaard deel" en 
 een "open deel (uitbreidingen)". Deze gekozen structuur maakt het voor de individuele fabrikanten relatief eenvoudig om specifieke 
 productuitbreidingen aan het systeem toe te voegen. 
 Dit resulteert in protocollen van verschillende lengtes en dus transmissietijden van verschillende lengtes.

Selectrix

 Het Selectrix (SX1) protocol, dat bestaat uit een "adresbyte" en een "functiebyte", heeft een star, vast kader. 
 Daarom is elke zendtijd hetzelfde en kan hieruit worden afgeleid hoe vaak elke busdeelnemer 
 binnen een gedefinieerde tijdsperiode wordt aangesproken binnen een bus.
 De flexibiliteit van dit bussysteem ligt in het feit dat het busprotocol (individuele bits) zelf niet wordt toegewezen aan een decoderfunctie.
 De functie van de individuele bit volgt uit de logische toewijzing ervan aan de / decoderfunctie / functies.
 Dit betekent dat hetzelfde bit kan worden geïnterpreteerd als schakeluitgang "S" voor de ene decoder en ingesteld als detectoringang "M" 
 voor de andere > de centrale evalueert dit dan.
 Ook hier kan hetzelfde bit deel uitmaken van een bitcombinatie die een specifiek bericht verzendt, bijv. snelheidsniveau, enz.

 Met de introductie van SX2 wordt een tweede protocol voor het aansturen van (momenteel alleen) de locomotief decoders toegevoegd.
 Het doel van SX2 is om het adres- en functiegebied uit te breiden (extra functies).  
 Aangezien de nieuwe locomotief decoders van Doehler & Haas, Munchen zo kunnen worden geprogrammeerd (geconfigureerd) om te werken als 
 Selectrix (1 / 2), DCC, Märklin - decoders,
 is er een preambule nodig die de decoder vóór elk nieuw protocol informeert voor welke bedrijfsmodus en dus voor 
 welk "locomotief decodertype" de volgende informatie bedoeld is.  
 De preambule wordt dan gevolgd door nog eens 5 bytes die het adres en alle functies bevatten.

 Deze langere verzendtijd vergeleken met SX1 betekent dat de vorige tijden voor een "refresh" niet langer geldig zijn.

 Een andere uitdaging is dat niet alle theoretisch mogelijke adressen van locomotieven voortdurend kunnen worden bijgewerkt.

 Het wordt duidelijk dat elke fabrikant van een centrale zijn eigen weg gaat in het realiseren hiervan. 
 Dit betekent ook een verschillend aantal gelijktijdig bestuurbare locomotieven op een modelbaan.

 De oude "SX1 locomotieven" (met hun oude adressen) kunnen samen met 
 nieuwe "SX2 locomotieven" op een systeem worden ingezet.

 In 2011 geeft één fabrikant aan dat er maximaal 16 SX2 locomotieven kunnen worden 
 ingezet naast de 103 SX1 locomotieven. 
 Een andere fabrikant staat de gelijktijdige inzet van 32 SX2 locomotieven toe.

 Weer een ander gebruikt een volledig aangepast railsignaal gebaseerd op SX op het spoor en 
 maakt gemengd bedrijf van SX1 en SX 2 locomotieven mogelijk, waarbij het maximum aantal locomotieven nog steeds 103 is.

 Een andere benadering is dat alleen de eenheden / tientallen / honderdtallen uit het getal van 4 cijfers worden gehaald.
 Dit betekent dat de locomotieven nog steeds kunnen worden gebruikt in SX1 mode, d.w.z. 103 locomotieven kunnen parallel worden gebruikt.

 Het valt nog te bezien welke varianten op de markt zullen worden geaccepteerd.

 Dit geldt voor de zogenaamde SX0-bus van een centrale. Tot nu toe werden de SX0 en SX1 bus 
 van een centrale altijd bediend met dezelfde snelheid en hetzelfde protocol. 
 Afhankelijk van de bovenstaande oplossing van de fabrikant zal dit in de toekomst waarschijnlijk niet meer het geval zijn.

 De gebruiker moet daarom ook nadenken over de aansluiting / functie van 
 alle andere decoders / handmatige besturingsapparaten, enz. op de andere SX-bussen 
 VOORDAT hij SX2 gebruikt en navraag doen bij de leveranciers.

Märklin

 Aangezien er geen officiële gegevens / technische informatie over de Märklin protocollen beschikbaar zijn, 
 neem ik dit systeem hier niet op in de protocolbeschouwingen. 
 Lezers kunnen mogelijk meer informatie krijgen via de gegeven links.

Systeem- en communicatiestructuren

Rijden en schakelen

In deze (hier beschouwde) systemen zijn zowel de locomotiefdecoders als alle andere decoders voor het schakelen (displays) verbonden met de centrale via een 2-draads verbinding (bus) -- bijv. rail / spoor of draden / kabels.

Alle instellingscommando's van de centrale worden in gecodeerde vorm via deze bus verzonden.

De respectievelijke spanning en de digitale codering verschillen sterk tussen de twee systemen DCC en Märklin. Er zijn zelfs grote verschillen tussen Motorola I / II en mfx (M4).

Meer technische informatie over de bussen en hun protocollen is te vinden via de links (hieronder).

Aangezien de mij bekende decoders voor schakelen/weergeven op de markt een relatief eenvoudige structuur hebben, moet een commando worden gegeven om een uitgang te schakelen > uitgang "aan" en na een tijd t het commando > uitgang "uit". De tijd t wordt bepaald in de centrale. Dit betekent dat elke schakeling van een magnetisch artikel 2 busoverdrachten vereist plus tijdverwerking in de centrale.

Terugmelden

Deze functie werd pas noodzakelijk met de uitbreiding van de "PC-besturing", die in feite het "oog" is van het modelspoorbesturingsprogramma, in dit geval TrainController (TC).

Het principe van terugmelding is de detectie van een stroom die wordt geactiveerd door een voertuig dat zich in een bewakingsgebied (spoorsectie) bevindt.

DCC

  Bij DCC is de bezetmelding/herkenning gebaseerd op de zogenaamde "stroommeting".
  Hier wordt de volledige stroom van een sectie omgeleid via een bezetmelder (decoder).
  Als er stroom vloeit omdat een belasting (locomotief of wagon met verlichting of
  "weerstandsassen") zich op de spoorsectie bevindt, wordt dit herkend en via een
  eigen terugmeldbus met een eigen protocol naar s=de centrale.

  Opmerking:
  De "weerstandsassen" zijn parallel geschakelde weerstanden waarvan de totale weerstand
  aanzienlijk verminderd, wat leidt tot een hogere stroom.   
  Hiermee moet rekening worden gehouden bij het ontwerpen van de weerstandsassen / het configureren 
  van het systeem of de gevoeligheid van de bezetmelders.

Märklin

  Bij Märklin is de bezetmelding/detectie gebaseerd op het "massacontact". 
  Deze historische term is gebleven, hoewel je in een digitaal systeem niet meer van "massa" kunt spreken.
  De middenrail is verbonden met één uitgang van de centrale of booster, de andere met één van de twee buitenste rails.
  Als er een Märklin (of 3-railvoertuig) op de baan staat, verbinden de elektrisch geleidende assen 
  het spoor (de rail) dat verbonden is met de centrale / booster met het andere spoor 
  (terugmeldrail). Deze rail is verbonden met een decoderingang.
  Dit betekent dat dezelfde potentiaal aanwezig is op de ingang van de detector als op de centrale/booster.
  Er loopt nu een kleine stroom (mA) via een weerstand met hoge impedantie in de terugmelddecoder,
  omdat de terugmelddecoder een aansluiting moet hebben waarop het middengeleiderpotentiaal van de spoorsectie zich bevindt; 
  er moet dus een verbinding zijn met de centrale of booster.
  Uiteindelijk wordt hier ook een stroom gedetecteerd; in tegenstelling tot DCC is deze echter kleiner.  

De twee verschillende benaderingen hebben ook geleid tot verschillende decodertypes op de markt, die elk via verschillende bussystemen verbonden zijn met de centrale.

Terwijl bij Märklin de "S88"-bus moet worden gebruikt, hangt het bij DCC af van wat de betreffende centrale als terugmeldbus levert.

Identificatie van locomotief-/voertuigadressen

DCC

 Met het gestandaardiseerde RailCom-systeemonderdeel brengt de DCC-gemeenschap momenteel een 
 feedbacksysteem op de markt, dat niet alleen het decoderadres van de locomotief doorgeeft, 
 maar ook nog uitgebreidere 
 andere informatie biedt, zoals het snel programmeren van locomotieven overal op de modelbaan, 
 detectie van vervuilde sporen en informatie over gekoppelde wagons (toekomst).
 Onder OpenDCC vindt de lezer een uitgebreide verhandeling hierover.

 In principe is de oplossing gebaseerd op de volgende procedure:
 De baanspanning wordt momenteel met regelmatige, zeer korte tussenpozen geschakeld, zodat 
 een "blokspanning" wordt gecreëerd. Er wordt een korte vertraging ingevoegd in dit omschakelmoment,
 Dit schakelt de baan korte tijd uit door de centrale / booster > spanningsloos.
 Een locomotiefdecoder kan nu binnen deze tijdspanne een bericht verzenden via de rails,
 dat vervolgens moet worden geregistreerd en geanalyseerd door de centrale.
 De locomotiefdecoder gebruikt een kleine condensator
 op de decoder als energiebron voor de transmissie.

 Opmerking:
 Als de baanspanning na de korte vertraging weer wordt toegepast, laadt de condensator weer op.
 De condensatoren van alle locomotieven op de modelbaan zijn elektrisch parallel geschakeld,
 zodat er een aanzienlijke laadstroom kan ontstaan aan het einde van de terugmelding. 
 Hiermee moet rekening worden gehouden bij het ontwerp van de booster.

 De tijdslots voor Railcom worden gehaald uit de bestaande synchronisatiebits, de snelheid van de 
 gegevensoverdracht naar de locomotief blijft ongewijzigd. 
 Omdat de locomotief de ontvangst van een bericht met Railcom bevestigt, kan de centrale 
 de profylactische herhaling achterwege laten en zo een hogere verwerkingscapaciteit 
 bereiken en nauwkeuriger stoppen mogelijk maken.

Märklin

 Märklin heeft met mfx (M4) een terugmeldsysteem geïntroduceerd. Dit heeft echter 
 een heel andere functie dan het systeem dat onder DCC werd geïntroduceerd en het systeem dat nog
 onder Selectrix moet worden geïntroduceerd.
 Bij Märklin worden de locomotieven bij het op de rails plaatsen automatisch
 aangemeld bij de centrale met het adres van hun locomotiefdecoder. 
 De centrale kent een "modelspoorlocomotiefadres" toe aan dit locomotiefdecoderadres.
 Er is dus geen identificatie plaats via de locatie van het voertuig (de locomotief) op het systeem.

Gedecentraliseerde systemen

In dit artikel wordt alleen het Selectrix-systeem besproken.

In principe is de baan via twee lijnen verbonden met de centrale of een booster. Net als bij de andere twee systemen worden deze lijnen gebruikt om de locomotiefdecoder en de locomotiefmotor van stroom te voorzien en data via de bus door te geven. Net als bij DCC wordt de polariteit ook in zeer korte tijdspannes omgeschakeld om een "blokspanning" te genereren. Het protocol is echter anders dan bij DCC en Märklin.

Boosters zijn verbonden met het controlecentrum via de zogenaamde PX-bus. Via deze bus wordt het zendsignaal van de centrale naar de boosters gestuurd. De boosters passen het dan toe op de baanspanning binnen hun voedingsbereik.

Rijden, schakelen en terugmelden

Vanuit het gezichtspunt van de centrale maakt het spoor deel uit van de SX 0 bus. En een locomotiefdecoder (rijden) kan alleen worden aangesloten op een SX 0-bus!!

Alle andere SX decoders (schakelen, terugmelden) kunnen worden aangesloten op de centrale via een van de twee SX 0 of SX 1 bussen. Beide bussen hebben een volledig identieke structuur --- bij gebruik van SX1; bij SX2 kunnen er verschillen zijn afhankelijk van de oplossing van de fabrikant (zie hierboven !!).

De logische circuits van de decoders worden ook via deze bussen gevoed !!!, terwijl spanningen voor het schakelen enz. apart aan de decoder moeten worden geleverd.

In tegenstelling tot DCC en Märklin is er een groot verschil bij het schakelen. Als er bijvoorbeeld een wissel geschakeld moet worden met SX, stuurt de centrale alleen een bericht naar de decoder met de inhoud > wissel schakelen en de wisselstand. De decoder neemt het inschakelen van het magneetartikel (spoel) over en observeert de inschakelduur (stroomduur) en schakelt het magneetartikel vervolgens weer uit. Vanuit het oogpunt van de centrale is dit een vermindering van 50% busbelasting per schakelhandeling en een aanzienlijke vermindering van de tijdsduur (inschakelduur van het magneetartikel).

Het principe van terugmelden is hetzelfde als bij DCC, namelijk een meting van de totale stroom in het terugmeldtraject. In dit geval is de terugmelddecode aangesloten op een van de SX-bussen en verbonden met de centrale.

Echter, als Märklinisten - zoals ikzelf - SX willen gebruiken, dan is de "Märklin variant" ook voor hen beschikbaar vanwege de 3-draads rails. Zoals te zien is onder Märklin, kan er een verbinding worden gemaakt van de "terugmeldrail" naar de SX terugmeld ingang. De gebruiker moet echter zelf een weerstand van bijvoorbeeld 10 k Ohm in deze aansluiting steken. Een "massacontact"-melding werkt dan zoals hierboven beschreven.

Configuratie notitie voor SX bezetmelder

 Houd rekening met het volgende bij het configureren van bezetmelders van de SX
 (verbinding met de SX-bus van een centrale):
 Bezetmelders ZONDER opto-couplers die het spoorpotentiaal scheiden van het potentiaal 
 van de bezetmelder, moeten' worden aangesloten op de centrale 
 waarop ook de spoorvoeding is aangesloten.
 Bezetmelders MIT opto-couplers kunnen ook worden aangesloten op de SX-bussen van de 
 andere centrales.
 Der TC-Forumsbeitrag : 

http://www.freiwald.com/forum/viewtopic.php?f=8&t=14071&hilit=sx+optokoppler+besetztmelder
 geeft een picturale voorstelling van de "elektrische uitleg".
 Voor gedetailleerde vragen kunt u per e-mail contact opnemen met de auteur.

Selectrix II --- en de nieuwe locomotief adressering

Met de introductie van SX II is de eerdere "tekortkoming" van "slechts 100 locomotiefadressen" opgeheven. Er kunnen nu ongeveer 10.000 adressen worden toegewezen aan locomotiefdecoders; meer dan genoeg. Bovendien zijn er extra uitgangen op de locomotiefdecoder voor het schakelen van locomotieffuncties.

Maar hoe kan het oude principe van ongeveer gelijke cycli worden gehandhaafd in decodercommunicatie??

Strikt genomen helemaal niet, omdat de protocoloverdracht aanzienlijk langer duurt dan met SX1. In tegenstelling tot SX1 specificeert de systeemaanpak bovendien niet langer een vast aantal locomotiefadressen, maar worden deze gedefinieerd door de fabrikant van een centrale -- 10.000 is waarschijnlijk een illusie en zelfs 100, zoals bij SX1, ligt ver buiten het bekende "verversingskader".

Na wat onderzoek kwam ik tot de conclusie dat met SX2 alleen het railsignaal als zodanig "gestandaardiseerd" is, maar dat de daadwerkelijke realisatie van SX2, voor zover het de gebruiker interesseert, wordt overgelaten aan de individuele fabrikanten van de centrales.

Als gevolg daarvan bepalen deze ook hoeveel locomotieven tegelijkertijd actief mogen zijn op het systeem onder SX2. Deze bepaling van het maximum aantal resulteert dan in een maximum tijdsbestek voor het SX2 verversingsgedeelte. De hele verversingscyclus bestaat dan, voor zover ik weet, uit het eerder bekende SX1 verversingsgedeelte en het respectievelijke nieuwe SX2 verversingsgedeelte.

Hierbij moet worden opgemerkt dat het verversingsaandeel van SX2 in de loop van de tijd fluctueert binnen het minimum/maximum aantal "actieve" SX2-locomotieven, d.w.z. het is afhankelijk van de belasting.

Hieruit kan echter meteen worden afgeleid dat er een strategie nodig is waarbij locomotieven als "actief" of "passief" worden geclassificeerd en waarbij in elk geval een flexibele hergroepering plaatsvindt. Bovendien moet in elk geval worden gedefinieerd hoe de "passieve" status op de modelbaan merkbaar is voor de gebruiker.

Het maximum aantal "actieve" locomotieven heeft twee tegengestelde effecten. Als hun aantal laag is, dan is de hele verversingscyclus korter (meer herhalingen bijv. per sec of min), maar de frequentie van hergroeperen en dus de inspanning in de bediening of in de "wachttijd" neemt toe. Bij een hoger aantal is dit gedrag omgekeerd.

Een andere overweging is het hogere aantal bytes dat moet worden verzonden in vergelijking met SX1. Het hogere aantal resulteert meestal ook in een hogere foutmarge in de transmissie, wat snelle herhaling weer wenselijker maakt.

Een ander gevolg van deze "vrijheid" is dat de interface van de centrale <> PC van fabrikant tot fabrikant verschilt. Het valt nog te bezien hoe de afzonderlijke fabrikanten van besturingsprogramma's voor modelspoorwegen, zoals TC, hierop zullen reageren.

Voorbeeld

 Eén fabrikant is van plan om 12 SX2 locomotieven tegelijk te ondersteunen,
 terwijl een andere fabrikant al ondersteuning biedt voor 32 SX2 locomotieven.  
 In beide gevallen is de bovenstaande "passief" zo gedefinieerd dat snelheidsniveau 0 
 aanwezig moet zijn EN ALLE extra functies en ALLE locomotiefverlichting zijn uitgeschakeld.
 Dit betekent dat de gebruiker - handmatig of via de pc - deze constellatie tot stand moet brengen.
 Als de "gelijktijdigheidslimiet" wordt bereikt, betekent dit bijvoorbeeld dat een locomotief 
 op donker moet worden geschakeld terwijl hij in het station wacht, zodat een andere kan rijden.
 Zo'n aanpak lijkt onrealistisch, vooral als je zulke krachtige
 modelspoorbesturingsprogramma's als TC gebruikt.

Identificatie van locomotief-/voertuigadressen

Deze identificatiemethode is een beetje "lastig".

Net als bij DCC verandert het spoorpotentiaal op de rails ook bij SX. Dit resulteert in een klein spanningsverschil - terwijl dit bij DCC veel groter moet zijn!

In deze korte fase ontlaadt een kleine condensator op de locomotiefdecoder zich via de rails en de op de rail aangesloten detectoringang en vandaar naar de booster/centrale en terug naar de rails > locomotief.

De resulterende kleine stroom (ongeveer 1-2 mA voor SX I; ongeveer 5 mA voor SX II) wordt herkend en geëvalueerd door de detector.

Hoe werkt nu de toekenning aan het adres van de locomotiefdecoder?

De condensatorontlading vindt plaats tijdens het verzenden van informatie naar locomotief xyz. De "intelligente" SX-detector registreert (onthoudt) in elk geval het verzonden locomotiefadres. Als er nu onmiddellijk een condensatorontlading volgt in de waarnemingssectie (signalering), kan hij het adres van de locomotief toewijzen aan deze sectie, wat bijvoorbeeld overeenkomt met een blok in TC (TrainController).

Tip: Als SX-identificatie wordt gebruikt, moeten alle lampen / LED's in de locomotief en wagon aan één kant worden aangesloten via een snel schakelende siliciumdiode volgens de SX-specificatie. Deze diode voorkomt "kruisstromen" die zouden optreden tijdens de ontlading van de condensator en dan zou er geen zuivere detectie kunnen plaatsvinden. Als Märklinisten SX en de bijbehorende detectoren gebruiken (zie hierboven), dan moet er ook een diode in serie met de weerstand worden aangesloten om zulke redenen.

Ook hier worden de locomotief EN de locatie herkend bij het op de rails plaatsen. Een vergelijking met DCC laat zien dat het DCC terugmeldsysteem veel geavanceerder is dan dat van SX.

LET OP: Bovenstaande geldt momenteel alleen voor SX1 locomotieven; locomotieven met de nieuwe "multi-protocol decoders" blijken dit nog niet te ondersteunen. Hetzelfde geldt ook voor de zogenaamde "intelligente" bezetmelders.

ALGEMEEN: De moderne PC modelspoorbesturingsprogramma's van tegenwoordig, zoals TC, hebben een dergelijke identificatie niet nodig voor het lopende bedrijf van de modelbaan. Dergelijke systemen kunnen echter nuttig zijn als treinbewegingen handmatig - zonder PC-programma - moeten worden uitgevoerd in gebieden die moeilijk te zien zijn (bijv. schaduwstations).

Multi-protocol centrales en decoders

Er komen steeds meer multiprotocol decoders en centrales op de markt, in de eerste plaats als marketinginstrument voor fabrikanten, maar ook als instrument in de "verdelings slag" van marktaandelen.

In zeer weinig gevallen zullen particuliere modelspoorders (afgezien van clubs) een groot aantal en verscheidenheid aan modelspoorbanen (locomotieven) bezitten. Zelfs als dit hier en daar het geval zou zijn, zou een decoderombouw ook een goed alternatief zijn voor een "multiprotocol modelbaan".

Werken met meerdere systemen (protocollen) op één systeem is niet onproblematisch en vereist altijd "meervoudige kennis" van de gebruiker bij het instellen, bedienen en onderhouden van zijn systeem.

Vanuit technisch oogpunt moet worden opgemerkt dat er altijd tijdvertragingen zijn bij het "omschakelen" van de protocollen -- vergeleken met een enkel protocol systeem. De omschakeling in de spoorvoeding (klok, codering) moet worden uitgevoerd of herkend door de centrale/decoder. In "gecentraliseerde systemen" hebben niet alleen de locomotiefdecoders last van dergelijke timingproblemen, maar ook ALLE schakeldecoders die op de bus (centrale) zijn aangesloten.

Hoewel de individuele tijden slechts in het µs / ms bereik liggen, kunnen ze bij elkaar optellen. De mix van locomotieven en hun huidige gebruik is hier ook een belangrijke factor.

Opmerking: De locomotiefdecoders die Doehler & Haas momenteel aanbiedt, worden bij de eerste ingebruikname ingesteld op een van de mogelijke baanformaten (DCC, Märklin, Selectrix (1/2), afhankelijk van de gebruikte centrale. Ze werken dan uitsluitend in deze bedrijfsmodus op de modelbaan.

Gebruik op modelspoorbanen

Laboratorium v.s. baan

Het lijdt geen twijfel dat deze multiprotocolsystemen perfect werken in de laboratoria van de individuele fabrikanten.

Op de verschillende banen, vooral op middelgrote en in combinatie met besturingsprogramma's voor pc's zoals TC, kunnen er tijdgerelateerde problemen optreden bij het verwerken van de besturingscommando's/detectoropvragingen.

Dit is met name het geval wanneer gecentraliseerde systemen zoals DCC en Märklin met totaal verschillende signale/busprotocollen samen worden gebruikt als een multiprotocolsysteem.

Voorbeeld schakelen

Taak: Het schakelen van een wissel vanuit TC.

Oplossing: Märklin / DCC

TC stuurt een bericht via de PC <> centrale om wissel x naar positie r te schakelen.

De centrale moet deze boodschap opnemen en opsplitsen in drie acties ..

1. Bericht naar bijbehorende wisseldecoder sturen met de inhoud Uitgang (= wissel x) inschakelen (stroom > spoel magneetartikel)
2. Stel een tijd in voor de inschakeltijd van de spoel en vraag wanneer deze is verstreken
3. Bericht verzenden naar bijbehorende wisseldecoder met de inhoud om uitgang (= wissel x) uit te schakelen (geen stroom > spoel van magneetartikel)

TC mag gedurende deze periode GEEN verdere bijv. schakelcommando's naar de centrale sturen. Dit betekent dat een overeenkomstige "wachttijd" moet worden ingevoerd in TC, die langer moet zijn dan de periode die is ingesteld onder 2) plus reserve.

Deze reserve is in de praktijk nodig, omdat kan worden aangenomen dat een bustransmissie moet worden herhaald vanwege fouten.

Er kunnen ook andere activiteiten "ertussen komen".

Oplossing: Selectrix - TC stuurt een bericht via de PC <> centrale bus om wissel x naar stand r te schakelen.

De centrale moet dit bericht opnemen en afbreken in een actie ...

1. Bericht naar bijbehorende wisseldecoder sturen met de inhoud om uitgang (= wissel x) naar positie r te schakelen.

De SX wisseldecoder ontvangt dit bericht en splitst het op in de acties ....

1. Uitgang inschakelen (= schakelaar x) (stroom > magneetspoel)
2. Tijd instellen voor duur van inschakelen spoel en vragen wanneer deze is verstreken
3. Uitgang uitschakelen (= schakelaar x) (geen stroom > magneetspoel)

TC mag geen wissels meer sturen zolang de centrale bezet is. Vergeleken met de vorige systeemaanpak is deze opdracht echter veel korter.

Dit betekent dat er slechts een zeer korte "wachttijd" is in TC. TC kan daarom acties (bijv. schakelpunten) in een veel hoger tempo uitvoeren, omdat het gebruik van zowel de centrale als de systeembussen per actie veel lager is.

Aantal snelheidsniveau in de locomotief decoder Systeembelasting

Dit voorbeeld is gelijkelijk van toepassing op alle 3 de beschouwde systemen en bekijkt het probleem alleen kwalitatief.

• Taak:

Een locomotief moet worden afgeremd van de rijsnelheid Vg tot de kruipsnelheid Vk binnen een rembereik van bijvoorbeeld L = 30 cm, zodat de locomotief onmiddellijk kan stoppen wanneer hij het stoppunt bereikt.

• Gegeven:

Locomotief A met 128 snelheidsniveaus Locomotief B met 31 snelheidsniveaus Computerbesturingsprogramma - TrainController (TC) Centrale van het betreffende systeem, via een seriële interface aangesloten op de pc.

• Weergave voor locomotief A:

Nadat is vastgesteld dat het rembereik is bereikt, berekent TC aan de hand van Vg en de lengte L, de doelsnelheid Vk en het aantal rijstappen van de locomotief hoe vaak een rijstapverlaging naar de centrale moet worden gestuurd. Deze overweging resulteert ook in de optimale tijdsverdeling.

Laten we voor deze analyse aannemen dat er 100 snelheidsniveaus moeten worden geschakeld.

TC stuurt dus 100 berichten naar de centrale, die deze informatie "vertaalt" in het juiste dataformaat / protocol en stuurt ook minstens 100 berichten naar de locomotief decoder. Als de spoorverbinding slecht is, zijn het er meestal meer.

• Weergave voor locomotief B:

De eerste paragraaf over locomotief A is net zo goed van toepassing op locomotief B.

Laten we echter aannemen dat er 25 snelheidsniveas moeten worden geschakeld.

De derde paragraaf van locomotief A is ook van toepassing op locomotief B; er worden echter maar 25 berichten verzonden.

• Resultaat van de "spel"

-- en dit geldt voor zowel remmen als accelereren --

Locomotief A heeft 4 keer meer commando-overdrachten nodig dan locomotief B. Het systeem wordt daarom veel zwaarder belast. TC houdt echter rekening met deze belasting en vermindert het aantal snelheidsstappen dat naar locomotief A wordt gestuurd voor grote veranderingen. Met TC krijg je ongeveer vergelijkbaar gedrag bij scherpe veranderingen, maar bij lange remhellingen worden de fijne gradaties voor loc A gebruikt. Of het menselijk oog een significant verschil kan detecteren in de "normale" werking van het systeem is iets dat iedereen zelf moet uitzoeken.

Er kan echter worden aangenomen dat tijdsknelpunten als gevolg van het bovenstaande effect zeer merkbaar zijn als er veel treinbewegingen tegelijkertijd plaatsvinden.

Voorbeeld >> Rijden / Multiprotocollen

Als er met verschillende protocollen wordt gereden, zoals al het geval is bij Märklin wanneer Motorola I / II en mfx (M4) worden gebruikt, dan moet de centrale zowel de het railsignaal als het protocol volledig wijzigen. Dit alles kost tijd. Dit is zeker geen probleem bij handmatige bediening van twee locomotieven, maar bij bijvoorbeeld TC en 15 locomotieven kan het dat wel zijn (waarbij de cijfers alleen bedoeld zijn om de verschillen te illustreren en geen absolute waarden weergeven).

Hetzelfde geldt als de locomotiefdecoder met meerdere protocollen kan worden gebruikt. Hij moet dan de juiste "voorselectie" maken. Dit kost ook tijd.

In al deze gevallen -- zoals blijkt uit de vele vragen in het TC-forum -- kunnen problemen zich voordoen onder zeer uiteenlopende omstandigheden; ze hoeven zich echter niet noodzakelijkerwijs voor te doen.

Naast de langere transmissietijd van het protocol heeft de werking met SX2 ook een eerder ongunstig tijdseffect door het locomotiefbeheer (locomotieven actief / passief instellen). Gebruikers van SX2-systemen moeten hier rekening mee houden.

Interactie met het TrainController (TC) softwareprogramma

TC kan werken met een groot aantal centrales, zoals de wereldwijde distributie laat zien, en de verscheidenheid aan instellingsopties betekent dat sommige tijdgerelateerde problemen ook kunnen worden "omzeild".

Hoe en wanneer SX2 zal worden geïmplementeerd door TC zal waarschijnlijk pas op zijn vroegst in de loop van volgend jaar duidelijk worden.

Als functies niet werken zoals verwacht, laat het TC Forum zien dat het knelpunt meestal te vinden is in de hardware en bij de systeemleveranciers.

Bronnen voor meer informatie

De onderstaande links zijn bedoeld om de lezer de gelegenheid te geven zich verder in dit onderwerp te verdiepen, in het bijzonder om "dieper in te gaan" op de verschillende technieken.

--Uitsluiting

 Aangezien noch ik als auteur van deze tekst noch de aanbieder van het 
 TC Wiki-platform enige controle hebben over de inhoud achter de 
 links - zoals bekend verandert deze in de loop der tijd - is de 
 lezer/gebruiker volledig verantwoordelijk voor het gebruik van de links.
 Claims voor schadevergoeding, ongeacht de reden en aan wie, worden automatisch
 uitgesloten door de lezer / gebruiker door te klikken op de links.
 Volgens de uitspraak van het OLG Hamburg distantieer ik mij (en ook de
 exploitant van dit platform) van de inhoud van de gelinkte pagina's,
 inclusief de daaropvolgende pagina's.

• Gegevensformaten (Märklin - DDC - Selectrix - enz.)

 http://www.digital-bahn.de/info_begriffe/protokoll.htm

• Multiprotocol - centrales / decoders

 http://www.digital-bahn.de/info_kompo/zentrale_multi.htm
 

• DCC

 http://www.opendcc.de/index.html
 http://www.lokodex.de/mo/m_digital_dccprot01.htm
 http://www.steinhartw.de

• Märklin

 http://de.wikipedia.org/wiki/M%C3%A4rklin_Systems
 http://www.stayathome.ch
 http://www.suter-meggen.ch/maerklin/digital/mfx_decoder/index.htm
 http://www.alice-dsl.net/mue473/index.htm

• Selectrix

 http://www.steinhartw.de
 http://www.steinhartw.de/D&H%20Lokadressen/D&H%20Lokadressen%20Erfassung.htm
 http://de.wikipedia.org/wiki/Selectrix
 http://www.frank-keil.de/selectrix_/selectrix_.html
 http://www.uwe-magnus.de
 http://www.1zu160.net/digital/selectrix.php
 http://doehler-haass.de/cms
 http://doehler-haass.de/cms/media/pdf/FCC_Interface_Doku.pdf
        (Het protocol op de rails kan ook worden afgeleid uit dit document !!!)

• Meer specifieke informatie over de afzonderlijke producten is te vinden op de

 respectieve homepages van de fabrikanten/distributeurs:
 Om redenen van neutraliteit worden hier geen links gegeven.

Conclusie

Ik hoop dat deze vergelijking degenen die overstappen van ANALOG naar DIGITAL wat basishulp geeft bij het kiezen van "UW digitale systeem" en alle andere lezers wat suggesties voor het ontwerpen van hun modelspoorbaan. Bovendien kan deze informatie ook helpen bij het vinden van een oplossing in geval van problemen.

Weblinks

• TC-wiki: Vergelijkingstabel digitale centrales

--Jens Mohr 09:40, 17. Jul. 2011 (UTC) († 2023)

bearbeitet:Wohlmannstetter (Diskussion) 18:36, 10. Mär. 2021 (CET), Uslex (Diskussion) 14:35, 12. Feb. 2024 (UTC), Uslex (Diskussion) 10:42, 24. Aug. 2024 (CEST)