BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: Martin Hornis op 26 December 2019, 16:14:44
-
Beste forumlezers,
Hoe 'weet' een loc dat een adres in het DCC-protocol voor een loc bestemd is en niet voor een wissel met hetzelfde adres?
-
Daar is toch geen verschil tussen?
Bij het Motorola protocol wel, daar zijn de pulslengtes voor locs en wissels verschillend.
-
https://dccwiki.com/Digital_packet
Het komt er eigenlijk op neer dat een wissel decoder niks snapt van een loc decoder commando en hem dus negeert en loc decoder niks snapt van een wissel decoder commando.
Hij 'weet' het dus niet maar reageert alleen op wat hij begrijpt.
-
Erik, kan je ook aanwijzen waar dat staat in dat geschrift?
Van de site van de NMRA begrijp ik dat het verschil zit in het adresbereik. Adressen tot 127 zijn voor locs, adressen van 128 tot 256 voor wissels. De structuur van de inhoud is voor beide gelijk. Dus als je een wisseldecoder gaat aansturen als een locdecoder of andersom, dan gaan er volgens mij rare dingen gebeuren.
-
Het is mij zo uitgelegd en werkt in de praktijk. (maar ik kan het mis hebben er zullen best mensen zijn die het beter weten of beter kunnen uitleggen ;D)
Maar ik denk dat het kom door het volgende.
Instruction Bytes
The Instruction byte tells the device to set a function (light, bell, whistle, horn, coupler, etc.) on or off, to change to a specified speed step, to reverse direction, to emergency stop, etc. Systems using 14 or 28 speed steps only need one byte for the instructions. For 128 speed steps, two bytes are required. The structure of the bytes differs to indicate the speed steps used.
-
Eigenlijk ius het heel simpel. De decoder kijkt naar het adres in het commando. Als het eerste bit 0 is, dan is het een lokdecoder met een simpel adres (1-127), is het eerste bit 1 en het tweede bit 0, dan is het een wisseldecoder. Als het eerste bit 1 is en het tweede bit ook 1, dan is het een lokdecoder met lange adressen.
Groet Meino
-
Allen hartelijk bedankt. De link en de gegeven toelichtingen maken het voor mij duidelijk.
-
Van de site van de NMRA begrijp ik dat het verschil zit in het adresbereik. Adressen tot 127 zijn voor locs, adressen van 128 tot 256 voor wissels. De structuur van de inhoud is voor beide gelijk.
Dat is niet correct! Locdecoders hebben een adres bereik tot ver boven de 127, dmv zogenaamde “long adressen”. Wissels kunnen in DCC vanaf adres 1 gebruikt worden. Dus de adres range overlapt elkaar.
Het verschil zit in de inhoud van de pakketjes. Dus zoals Erik (in eenvoudige taal) al zei snapt een locdecoder “niets” van de wisselcommando’s en de wisseldecoders niets van de loc-commando’s.
-
Eigenlijk ius het heel simpel. De decoder kijkt naar het adres in het commando. Als het eerste bit 0 is, dan is het een lokdecoder met een simpel adres (1-127), is het eerste bit 1 en het tweede bit 0, dan is het een wisseldecoder. Als het eerste bit 1 is en het tweede bit ook 1, dan is het een lokdecoder met lange adressen.
Groet Meino
Dus ook dit is niet cerrect.
-
Dat is niet correct! Locdecoders hebben een adres bereik tot ver boven de 127, dmv zogenaamde “long adressen”. Wissels kunnen in DCC vanaf adres 1 gebruikt worden. Dus de adres range overlapt elkaar.
Dat zag ik toch in dit geschrift: https://nmra.org/sites/default/files/s-9.2.1_2012_07.pdf (https://nmra.org/sites/default/files/s-9.2.1_2012_07.pdf), onder A: Adress Partitions. Of begrijp ik dat verkeerd?
-
Hoi,
Ik heb indertijd begrepen dat er een signaal op de rails gezet wordt en een decoder denkt 'hee das voor mij' wat de decoder daar dan mee doet is, zijn opdrachten omzetten in acties. Dus wissel klapt, loc rijdt of lampje gaat uit/aan.
Net als Erik dus, snap ik het op deze manier.
Groet Ad
-
Ja, de decoder herkent aan het adres dat de boodschap voor hem bestemd is. Daarna volgt het commando waar de decoder aan moet voldoen. Net als wanneer iemand roept: hé Ad, dan weet je dat het bericht voor jou bestemd is, en als ze roepen: hé Klaas, dan is het voor mij.
Waar ik nou weer benieuwd naar ben, wat gebeurt er als je een loc een wisselcommando geeft, wat doet die decoder dan met het commando. Iemand al eens geprobeerd?
-
Dat gebeurt toch voortdurend op een digitale baan? De wisselcommando's worden toch net als de loc commando's via de rails doorgegeven? Als ik met een digitale loc rijdt en ik zet via de centrale een wissel om dan is dit toch precies wat er aan de orde is? De loc decoder "herkent" het signaal dan domweg niet (hoe dat technisch zit weet ik niet) en negeert het dus.
Groeten,
Bert
-
Ik bedoel: wat gebeurt er als je wisselcommando's stuurt en je geeft een locdecoder dat adres?
Dan gaat de locdecoder er naar luisteren omdat het adres klopt. Maar wat doet hij vervolgens met het commando?
-
Ik heb geen idee hoe een decoder zijn eigen adres precies "herkent" maar op mijn baan heb ik zowel loc adressen als wisseladressen beneden de honderd in gebruik. Als ik rijd met een loc die luistert naar zijn adres 5 en ik schakel de wissel die ook adres 5 heeft met mijn centrale dan reageert de loc daar niet op. Voor de gebruiker heet het kennelijk allebei adres 5 maar in het protocol zal dat dan dusdanig verschillend zijn dat een lok decoder een wisselcommando niet herkent en vice versa.
Groeten,
Bert
-
Ik doe even een poging 8) in J&J taal:
Adressen spelen in eerste instantie nog geen rol. Eerst wordt bepaald of een locomotief-opdracht verzonden moet worden of een opdracht voor een wissel. Pas daarna komt een adres in beeld. Het adres zit in het pakketje.
Een centrale zend een opdrachtpakket naar de rails. Dat doet hij in zo genaamde opdrachten pakketjes die zijn voor wissels anders zijn dan voor locomotieven . Alle wissels en locomotieven luisteren allemaal welke pakketjes er allemaal via de rails worden verzonden.
Komt er een pakketje voorbij waarop staat: "dit is een pakje voor een locomotief" dan zal een locomotief snel het pakketje open maken en kijken of het wel voor hem bestemd is. Staat in het pakket: Dit is een opdracht voor locomotief met adres 12. Dan denkt de locomotief met adres 10, hé dat ben ik niet :( en onderneemt geen actie. Een andere locomotief ziet dat pakketje ook langs komen en roept hé das voor mij :D want ik ben een locomotief met adres 12.
Snel wordt het pakket verder open gemaakt en wordt gekeken welke opdrachten hij moet uitvoeren.
Ook wissels zien deze pakketjes voorbij komen. Telkens als er een pakketje voorbij komt waarop staat "dit is een pakje voor een locomotief" dan zegt elke wissel doei, niet voor mij >:(. Pas als er een pakket met de tekst: "dit is een pakje voor een wissel" dan denkt het wissel even kijken wat er in zit ??? . Staat er in het pakket dit is een opdracht voor wissel 12 dan zegt wissel 10 jammer dat is niet voor mij >:(. Maar wissel 12 ziet het pakketje ook en denkt even lezen wat ik moet gaan doen, want ik ben wissel 12 :D.
Ik hoop dat ik een en ander hiermee wat verduidelijkt heb.
-
Ik hoop dat ik een en ander hiermee wat verduidelijkt heb.
Nee, voor mij wordt het alleen maar mistiger.
Wat is dan het verschil tussen b.v. adres 5 voor een locdecoder en adres 5 voor een wisseldecoder? Bij DCC is het eerste byte na de pre-amble toch gewoon het adres? In de beschrijvingen bij NMRA en Morop zie ik nergens waar in het bericht wordt aangegeven dat het voor een loc of voor een wissel is.
-
Klaas
in de NMRA norm wordt over adres reeksen gesproken, 0-127 voor loks met simpele adressen, 128-192 voor wisseldecoders enz. Maar je kunt er ook anders naar kijken, en de eerste 2-3 bits als indicator gebruiken, zoals ik het hier probeerde uit te leggen;
Eigenlijk ius het heel simpel. De decoder kijkt naar het adres in het commando. Als het eerste bit 0 is, dan is het een lokdecoder met een simpel adres (1-127), is het eerste bit 1 en het tweede bit 0, dan is het een wisseldecoder. Als het eerste bit 1 is en het tweede bit ook 1, dan is het een lokdecoder met lange adressen.
Het hangt dan gewoon van de programmeur af hoe hij daarmee omgaat.
Om het ingewikkeld te maken, moet je voor het echte adres dan ook nog kijken naar de bits uit het tweede byte dat volgt op het adress byte. Voor het echte adres van een wisseldecoder moet je er ook nog 5 bits uit het volgende byte er bij betrekken. Hoe dat adres geinterpreteerd wordt hangt van het type decoder af, Decoders met 4 functie uitgangen of een decoder met 1 functie uitgang, alhoewel dit meer een semantische exercitie is, dan dat het uitmaakt voor wat er in de 6+5bits staat, 511 + 4 functie uitgangen betekent 9 bits voor het adres en 2 bits voor de functie uitgang, is 11 bits. Voor decoders met 1 uitgang is de adres ruimte 2047, ook 11 bits.
Groet meino
-
Ik heb geen idee hoe een decoder zijn eigen adres precies "herkent"
Een decoder krijgt af fabriek default het adres 3, dat wordt, met alle andere CV waarden, opgeslagen in een eeprom in de decoder. Bij het configureren ('programmeren') van een decoder is dat te veranderen, het oude adres wordt dan overschreven.
... op mijn baan heb ik zowel locadressen als wisseladressen beneden de honderd in gebruik. Als ik rijd met een loc die luistert naar zijn adres 5 en ik schakel de wissel die ook adres 5 heeft met mijn centrale dan reageert de loc daar niet op.
Er zijn twee 'adresruimten', 1 voor (mobiele) locdecoders en 1 voor (stationaire) schakeldecoders (zie DCC Wiki (https://dccwiki.com/Accessory_Address) link). In beide adresruimten mag het adres '5' voorkomen. In het DCC pakketje zit in het adres informatie of het pakketje voor een loc- of schakeldecoder is. Iedere decoder 'weet' wat voor type decoder hij is en kijkt constant naar alle pakketjes die op de rails voorbijkomen. Alleen als er een pakketje voorbijkomt met zijn adres en zijn type dan zal hij het commando in de rest van het DCC pakketje uitvoeren.
Een locdecoder met adres 5 negeert een commando voor schakeldecoder met adres 5, en andersom ook.
Het is ook vrij zinloos om een schakeldecoder (voor b.v. een wissel) het commando 'verhoog snelheid' te laten uitvoeren.
-
Het is me nog steeds niet helder. Kan iemand een bitpatroon laten zien (nullen en enen) van een adres 5 voor een locdecoder en een adres 5 voor een wisseldecoder. En daarin aanwijzen welke bits cruciaal zijn voor het verschil.
-
https://dccwiki.com/Digital_packet
In deze link staat alles. Het gaat mij er alleen om hoe de eenvoudigste uitvoering is. Dus zoals het in het begin van het digitale tijdperk geregeld was. Heel eenvoudig. Adres 0 mocht niet. De adressen 1..127 zijn voor locs bestemd. De adressen voor accessoires (1..64) worden gecodeerd verzonden door er 127 bij op te tellen. Het zijn daardoor de adressen 128..191. Aangezien alles via een 8-bits-formaat wordt verzonden, houdt het dus in dat loc-adressen met een 0 begonnen. De reeks is dan 0000 0001 t/m 0111 1111. Voor accessoires is die reeks: 1000 0000 t/m 1011 1111. Dus een accessoire-adres begint met 10. Voor locs en accessoires met een hoger adres, is een andere adresindeling 'verzonnen'. Maar dat mag iedereen voor zichzelf gaan uitzoeken. Ik ben tevreden met het gegeven antwoord.
-
Kan iemand een bitpatroon laten zien (nullen en enen) van een adres 5 voor een locdecoder en een adres 5 voor een wisseldecoder.
Ja. Zie antwoord hier boven.
Locadres 5: 0000 0101. -> 3e bit van rechts -> 4. -> 1e bit van rechts -> 1. -> samen 5.
Wisseladres 5: 1000 0100 (127 + 5 = 132.-> 132 - 128 (-> meest linker bit) = 4 (-> 3e bit van rechts).
-
Hierbij de beschrijving van de DCC commando’s in ENEN en NULLEN:
https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf
Je moet er even de tijd voor nemen, maar dan heb je ook alles!
M.vr.gr. Marco
-
Hallo,
Misschien toch even iets recht zetten...
... Er zijn twee 'adresruimten', 1 voor (mobiele) locdecoders en 1 voor (stationaire) functiedecoders (zie DCC Wiki (https://dccwiki.com/Accessory_Address) link). In beide adresruimten mag het adres '5' voorkomen.
... Een locdecoder met adres 5 negeert een commando voor functiedecoder met adres 5, en andersom ook.
Het is ook vrij zinloos om een wisseldecoder het commando 'verhoog snelheid' te laten uitvoeren.
Hier wordt het woord functiedecoder gebruikt voor een "accessory decoder" (oftewel schakeldecoder), terwijl het woord functiedecoder normaal gebruikt wordt voor een "uitgeklede" locdecoder voor het schakelen van functies in rijdend materieel zonder motor...
http://wiki.modelspoorwijzer.net/index.php/Functiedecoder
De locdecoders en de z.g. functiedecoders maken wel degelijk gebruik van dezelfde adresruimte en luisteren naar dezelfde locadressen.
Een locdecoder met adres 5 negeert een commando voor functiedecoder met adres 5, en andersom ook.
Dus niet, zij luisteren beide naar loc-adres 5...
De "accessory decoders" (dus de schakeldecoders voor wissels en seinen) hebben hun eigen adresruimte, los van die van de loc- en functiedecoders.
Groeten,
Bert
-
Locadres 5: 0000 0101. -> 3e bit van rechts -> 4. -> 1e bit van rechts -> 1. -> samen 5.
Wisseladres 5: 1000 0100 (127 + 5 = 132.-> 132 - 128 (-> meest linker bit) = 4 (-> 3e bit van rechts).
Kijk, nu begint het me te dagen. Wisseladres 5 is dus helemaal niet adres 5, het is adres 132. (ik weet hoe binair tellen werkt)
-
... even iets rechtzetten...
Ik heb de benaming aangepast.
-
Klaas, dat heet kortsluiting ;)
-
Ik heb de benaming aangepast.
Ik heb het gezien... (y)
-
Kijk, nu begint het me te dagen. Wisseladres 5 is dus helemaal niet adres 5, het is adres 132. (ik weet hoe binair tellen werkt)
Bijna goed.
Maar helaas is de adressering van wisseldecoders een aan elkaar gebreid zootje. Ik ben eens in de code van de DCC bibliotheek voor een Arduino gedoken om te kijken hoe het adres uit de pakketjes gehaald wordt.
Het kan erg verwarrend zijn, door de manier waarop dit door de NMRA is vastgelegd. Het eerste probleem is dat de standaard 2 verschillende manieren van adresseren beschrijft; 511 basic decoders, ieder met 4 binaire uitgangen, of 2044 basic decoders met 1 binaire uitgang.
Maar kijken we nu naar de inhoud van het pakket voor een basic accessory decoder, dan bevat dat altijd een 9 bit base adres dat loopt van 1 tot 511. Maar dat zelfde pakket bevat ook een 2 bit sub address dat een van de 4 uitgangen aanstuurt, voor het gemak loopt dat van 0-3.
Ik weet niet hoe het in andere treinbesturings programma's is, maar binnen Koploper gebruik je de laatste methode van adressering (max 2044 adressen), Iedere uitgang heeft zijn eigen adres.
Hoe werkt dat in de praktijk. Wisseldecoder 1 wordt base adres 1, sub adres 0. Wisseldecoder 4 wordt base adres 1, sub adres 3. Wisseldecoder 5 wordt nu base adres 2, sub adres 0. Etc.
Hoe ziet nu een fysiek pakket er uit. Bijv Wisseldecoder 3, wisselstand afbuigend. Dat ziet er in Hexadecimaal nu als volgt uit 81FC (ik laat voor het gemak de preamble, tussenbits en error byte even weg)
In bit notatie is dat als volgt 1000 0001 1111 1100, 2 bytes.
Dat kunnen we nu als volgt opbreken:
10 2 bits die aangeven dat we een Accessory decoder (wissel decoder) adresseren
00 0001 6 bits voor het eerste deel van het base address, noem dit A1.
1 1 bit die aangeeft dat dit voor een Basic accessory decoder (9bit adres is)
111 3 bits voor het tweede deel van het base address. Noem dit A2. Het vreemde is dat dit deel van het adres geinverteerd is, een 0 is een 1 en een 1 is een 0 ???
Het complete base address wordt nu gemaakt uit A1 en A2 volgens de volgende formule; (~A2<<6)+A1
Dat resulteert hier in een base address van 1 ( ~(111) wordt 000 )
gaan we nu verder.
1 1 bit, geeft aan of een coil geactiveerd moet worden. (voorzover ik het kan volgen zet Koploper dit altijd op 1)
10 2 bits die het sub address bevatten, sub address is hier 2, dat is dus de 3e uitgang, samen met het base address 1 maakt dit decoder adres 3 ;D.
0 1 bit voor de richting van de wissel, 1 is rechtdoor, 0 is afbuigend (tenminste dat gebeurd bij mij met Koploper)
Het is misschien een wat lang verhaal geworden en alleen maar de beschrijving van een simpele wissel decoder, maar ik hoop dat het nu wat duidelijker is.
Groet Meino
-
1 1 bit die aangeeft dat dit voor een Basic accessory decoder (9bit adres is)
Als die 1 er niet staat, dan zijn er maar 64 adressen beschikbaar. En is het maar een 6-bits-adres.
-
Hoe werkt dat in de praktijk. Wisseldecoder 1 wordt base adres 1, sub adres 0. Wisseldecoder 4 wordt base adres 1, sub adres 3. Wisseldecoder 5 wordt nu base adres 2, sub adres 0. Etc.
Het Motorola protocol doet het op dezelfde manier, een basis adres met vier SUB adressen cq uitgangen. Een efficiënte manier om veel wisselnummers in een beperkt aantal adressen te coderen.
Beslist geen “een aan elkaar gebreid zooitje”, je moet alleen het “trucje” door hebben. Gelukkig wordt dit allemaal onder de tafel door je centrale geregeld. Alleen als je je eigen centrale gaat maken (zoals ik > 15 jaar geleden met MRdirect al deed) kan het een lastig te doorgronden probleem zijn.
M.vr.gr. Marco
-
bijkomend configuratievoordeel van de opsplitsing tussen base adres en subadres is dat je ook maar 1 basisadres per decoder moet instellen per 4 (8) uitgangen en geen 4 of 8. Het is maar hoe je kijkt naar basisadres, subadres en rood/groen keuze. Ook deze laatste is niet meer dan een onderdeel van de adressering om tot een enkele fysieke uitgang te komen. ( namelijke 1 spoel of lamp de je aan of uit kan zetten). Je kan probleemloos je eigen accessory decoder maken met 1 fysieke uitgang die je bvb dan inbouwt in de voet van je straatlantaarn. Voor elke straatlantaarn zal je dan het basis adres, subadres en kleur moeten instellen. Wel wat configuratiewerk maar optimaal configureerbaar en meeste flexibiliteit.
Mvg, Patrick
-
Als die 1 er niet staat, dan zijn er maar 64 adressen beschikbaar. En is het maar een 6-bits-adres.
Dag Martin
Volgens de DCC Wiki geeft dat aan dat het een Extended Accessory Decoder packet is met een 11 bit adres. Dit wordt gebruikt voor multi aspect (licht) seinen. Ik weet niet of dat veel ondersteund wordt.
Groet Meino
-
Multi-aspect is een andere benadering. Ik weet alleen dat het in de OC32 gebruikt kan worden en dat het door iTrain ondersteund wordt. Zelf laat ik het multi-aspect-signaal vanuit de PC (iTrain) niet via DCC verlopen, maar via RS485 naar de OC32's. Daarmee omzeil ik de centrale (Intellibox I).
-
DCC volgens de NMRA specs heeft een locomotief signaal twee Adressermodes, 7 en 14 bit:
7 bit. 0AAAAAAA adres 0 - 255
14bit. 11AAAAAA AAAAAAAA 0 - ??
Voor de base accessory decoder 6 bit
6 bit. 10AAAAAA adres O - 127 , dus 4*127 = 588 wisselNUMMERS.
-
14 bit -> ?? = 2^14 - 1 = 16.383.
6 bit -> 2^6 -1 = 63. dus 4*127 = 588 wisselNUMMERS
Dat vind ik vreemd, want 4*127 = 508. Je zou er de 3 bits in de 2e byte er bij kunnen nemen. Dan kom je uit op 2^9 = 512 nummers. Door de keuzebit in de 2e byte kun je beide mogelijkheden bij elkaar optellen: 64 + 512 = 576. Maar of dat zo werkt, weet ik niet. Als je nog meer adressen wil dan moet je een andere benadering toepassen.
-
7 bit. 0AAAAAAA adres 0 - 255
Sorry, maar 7 bits geeft 0-127, adres 0 wordt niet gebruikt, dus dat geeft maximaal 127 locs.
6 bit. 10AAAAAA adres O - 127 , dus 4*127 = 588 wisselNUMMERS.
Helaas ook niet correct, 6 bits geeft 0-63, ook hier wordt adres 0 niet gebruikt. Maar in het volgende databyte zitten ook nog 3 bits (bij een Basic Accessory Decoder packet), die aan het adres worden toegevoegd. Dat geeft 9 bits voor het base adres. Dus 1-511 als mogelijke base adressen. Dat resulteerd in 4*511 = 2044 decoder adressen. Bij een Extended Accessory Decoder pakket worden er 5 bits toegevoegd. Maar dat type pakket heeft geen subadressen, dus het aantal decoders is het zelfde.
Groet Meino
-
Dat geeft 9 bits voor het base adres. Dus 1-511 als mogelijke base adressen. Dat resulteerd in 4*511 = 2044 decoder adressen.
Het zijn in totaal 2048 decoderadressen die beschikbaar zijn: base-adres 0 kan ook gebruikt worden... dus 4*512 = 2048.
Meestal wordt base-adres 0 echter niet gebruikt (conform norm RCN-213) en resteren er 2044, alleen Fleischmann/Roco zijn de uitzondering in deze.
> http://normen.railcommunity.de/RCN-213.pdf
Aus Gründen der Kompatibilität zu existierenden Zentralen ist die erste angesprochene
Adresse 4 = 1000-0001 1111-D00R. Diese Adresse wird in Anwenderdialogen als
Adresse 1 dargestellt.
Vandaar de regelmatig tot verwarring leidende adresverschuiving van 4 adressen:
- Bij Roco/Fleischmann is bij wisselnummer 1 het "decoderadres" = 0 en zijn er in totaal 2048 "wisselnummers" bruikbaar
- Volgens RCN-213 is bij wisselnummer 1 het "decoderadres" = 4 en zijn er in totaal 2044 "wisselnummers" bruikbaar
In de Z21 Maintenance Software vind je dan ook de keuze voor de RCN-213 standaard terug:
(https://images.beneluxspoor.net/bnls/00_45.jpg) (https://images.beneluxspoor.net/bnls/00_45.jpg)
De "oude" MultiMuis "centrale" aan booster 10765 heeft deze optie niet en begint dus bij base-adres 0 voor "wisselnummer" 1.
Een via deze "centrale" ingestelde wisseldecoder heeft dus een adresverschuiving van 4 ten opzichte van de "standaard" RCN-213 centrales.
Ook de Digikeijs DR5000 Centrale heeft de mogelijkheid om te kiezen voor de "Fleischmann/Roco" adressering (Eerste wissel-module adres =0) of de standaard RCN-213 adressering (Eerste wissel-module adres =1):
(https://images.beneluxspoor.net/bnls/00_46.jpg) (https://images.beneluxspoor.net/bnls/00_46.jpg)
Met behulp van deze optie kun je van een werkende "MultiMuis + Booster 10765" baan (dus met base-adres 0) overschakelen naar een besturing onder de DR5000 zonder last te hebben van de "adresverschuiving" door te kiezen voor de waarde 0 voor het "Eerste wissel-module adres".
Groeten,
Bert
-
Ik heb er nog eens de NMRA specificaties op nagekeken, je hebt gelijk dat base adres 0 een geldig adres is voor een accessory decoder. Echter adres 127 is volgens de NMRA specs gereserveerd voor broadcasts. Dus blijven er nog steeds slechts 511 base adressen en 2044 decoder adressen over. Verder zie ik dat in Rocrail en Koploper adres 0 voor een decoder niet opgegeven kan/mag worden.
Wel weet ik dat Koploper in combinatie met de MDRRC-II Centrale als base adres het zelfde genereert als het adres dat in Koploper is geconfigureerd. Een wissel dat als 1 is geconfigureerd krijgt als base adres 1 en subadres 0, een wissel met een geconfigureerd adres 2 krijgt base adres 1 en sub adres 1, etc.
Hoe andere DCC centrales daar mee omgaan is nog weer een ander verhaal en dat weet ik dus niet
Groet Meino
-
Ik lees bij de NMRA dat adres 0 is gereserveerd voor de broadcast.
Intussen begin ik wel een idee te krijgen hoe het in elkaar zit. In ieder geval veel ingewikkelder dan in mijn idee nodig is. Als ze vanaf het begin twee bytes hadden gebruikt voor de adressen dan had je een paar miljoen adressen gehad waarin je zonder meer lange adressen kon kiezen zonder extra rompslomp.
Nog een ander punt wat eigenlijk buiten dit onderwerp ligt: De nullen en enen op de baan bestaan uit een negatieve en een positieve puls van gelijke lengte direct na elkaar. Dat hebben ze gedaan om de DC rest nul te maken waardoor het mogelijk was via zero-stretching een analoge loc te kunnen laten rijden. Dat bleek een fiasco, er zijn heel wat analoog gestuurde motortjes in rook opgegaan. Als ze dat idee hadden losgelaten was voor elke bit maar 1 puls nodig en was het protocol 2 keer zo snel geweest.
-
Hallo Meino,
Echter adres 127 is volgens de NMRA specs gereserveerd voor broadcasts.
Klopt. En dat levert bij sommige schakeldecoders dan ook weer problemen op. Zo wordt bijvoorbeeld bij geactiveerde "RailCom voor Accessory Decoders" met regelmatige tussenpozen een broadcast via een wisseladres uit de base-adresreeks 127 gedaan, waardoor schakeldecoders tijdens het programmeren van het wisseladres "van slag" kunnen raken: sommige schakeldecoders slaan dit adres op als "eerste wisseladres" en verlaten dan weer de programmeer-modus voordat de gebruiker het bedoelde wisseladres zelf heeft kunnen schakelen... Meestal verraad een regelmatig knipperend adresserings-ledje op de schakeldecoder dit probleem.
Dit probleem kan dan worden voorkomen door "RailCom voor Accessory Decoders" in de centrale (tijdelijk) uit te schakelen.
Ook zijn er centrales (bijvoorbeeld TAMS) die via specifieke wisseladressen Boosters "pollen" om te zien of de Booster nog "actief" aanwezig is. Ook deze vorm van broadcasting kan leiden tot dezelfde problemen bij het instellen van wisseladressen voor schakeldecoders.
Conclusie: ook al zijn er NMRA standaards, er zijn bij implementaties veel "eigen interpretaties" met soms verrassende neveneffecten...
Groeten.
Bert
-
Hallo Klaas,
Ik lees bij de NMRA dat adres 0 is gereserveerd voor de broadcast.
Hier lees ik wat anders:
> https://dccwiki.com/Accessory_Address
Address Range
You can have addresses from 1 to 2044. Each address location can control a pair of functions, usually either two solenoids for turnouts or two LEDs for signals.
Different manufacturers view this range in one of two ways:
1) 511 decoder addresses, each with 4 sub-addresses, or
2) 2044 individual output addresses
Not all command stations support all of the possible addresses in that range.
Special Addresses
The NMRA reserves addresses 2045 to 2048 for broadcasting to all accessory decoders.
Zijn er meerdere (verschillend te interpreteren?) NMRA specificaties?
Aanvulling:
Ik lees in dit document https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf het volgende:
Page 1:
A: Address Partitions
The first data byte of an Extended Packet Format packet contains the primary address. In order to allow for different types of decoders this primary address is subdivided into fixed partitions as follows.
Address 00000000 (0): Broadcast address
Addresses 00000001-01111111 (1-127)(inclusive): Multi-Function decoders with 7 bit addresses
Addresses 10000000-10111111 (128-191)(inclusive): Basic Accessory Decoders with 9 bit addresses and Extended Accessory Decoders with 11-bit addresses
Addresses 11000000-11100111 (192-231)(inclusive): Multi Function Decoders with 14 bit addresses
Addresses 11101000-11111110 (232-254)(inclusive): Reserved for Future Use
Address 11111111 (255): Idle Packet
Page 9:
If operations-mode acknowledgement is enabled, receipt of an extended accessory decoder packet must be
acknowledged with an operations-mode acknowledgement.
Broadcast Command for Accessory Decoders
Broadcast Command for Basic Accessory Decoders
The format for the broadcast instruction is:
{preamble} 0 10111111 0 1000CDDD 0 EEEEEEEE 1
This packet shall be executed by all accessory decoders. CDDD is defined as specified in the paragraph on Basic Accessory Decoder Packet Format.
Broadcast Command for Extended Accessory Decoders
The format for the broadcast instruction is:
{preamble} 0 10111111 0 00000111 0 000XXXXX 0 EEEEEEEE 1
All extended accessory decoders must execute this packet. XXXXX is defined as specified in the paragraph on Extended Accessory Decoder Packet Format.
NMRA maakt dus blijkbaar zelf al onderscheid in de specifieke toepassing van adressen voor loc-decoders en schakeldecoders...
Groeten,
Bert
-
https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf (https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf), bij Adress partitions
https://morop.org/downloads/nem/de/nem671_d.pdf (https://morop.org/downloads/nem/de/nem671_d.pdf), hfdst 4.1
Beide noemen adres 0 als broadcast adres.
127 is bij beide het laatste locadres.
PS: Bert was 4 seconden sneller.
-
Klaas,
Ik had ondertussen mijn eerdere antwoord wat aangevuld, zie onder Aanvulling.
Zit het verschil dan in "standaard Broadcasting" en "Broadcasting voor Accessory Decoders"?
Groeten,
Bert
-
Ik was nog niet aan page 9 toegekomen. ;) Blijkbaar zijn er 2 broadcast adressen, 1 voor locdecoders en 1 voor wisseldecoders. Maar adres 127 zit daar niet bij, dat is een gewoon locadres. Hoe ze daar bij DCC wiki aan komen weet ik ook niet. Ik ga er vanuit dat alles wat in tegenspraak is met NMRA of NEM niet waar is.
Voorlopig ben ik weer genoeg bijgepraat, ik ga weer eens kijken naar de besturing van mijn analoge baan. ;D
-
Ik ga ook weer even "analoog" verder, gewoon lekker solderen op een printje... 8)
-
Daarom noemde ik de adressering van wisseldecoders een aan elkaar gebreid zootje. Ook omdat diverse leveranciers weer hun eigen varianten hebben bedacht. Gelukkig heb ik met Koploper en MDRRC-II een combinatie waarvan ik weet hoe het zich gedraagt en kan ik voorzover nodig zelf in de code ingrijpen.
Groet Meino
-
... Als ze vanaf het begin twee bytes hadden gebruikt voor de adressen dan had je een paar miljoen adressen gehad waarin je zonder meer lange adressen kon kiezen zonder extra rompslomp.
Tja... Voortschrijdende techniek; kleiner, sneller, goedkoper... De eerste DOS pc's waren '8 bits' met een 16 bits brede databus waardoor je maar een beperkte geheugenruimte kon adresseren. Met kunstgrepen en memory managers werd dat aanvankelijk opgelost. Latere systemen waren 32 en nu ook 64 bits waardoor geheugenadressering geen probleem meer is, maar programma's zijn daardoor niet meer downward compatible .
Eigenlijk zou DCC opnieuw gedefinieerd moeten worden, met 16 bits adressen, dan ben je van een hoop ingewikkeld gedoe af.
-
Wat was er voor hardware beschikbaar in 1989-1992 om decoders te bouwen? Pc's draaide toen op intel 386, 16Mhz, unix systemen hadden vaak een motorola 68010, 1Mb geheugen, harde schijven van 20-80Mb waren al groot. Ik kan me nog goed de tijd herinneren (rond 1992) dat de eerste 1Gb schijven beschikbaar kwamen. DCC ontstond in een veel beperktere omgeving dan we nu voor normaal vinden. Welke fabrikant gaat nu nog investeren in een complete nieuwe opzet? Ik denk dat dat niet realistisch is. Kijk naar het Internet, we weten al ruim 25 jaar dat IP V4 op is en vervangen moet worden door IP V6, maar wie van ons is al een bewuste gebruiker van IP V6?
Groet Meino
-
Wet van de remmende voorsprong, daarom hebben ze in de VS nog steeds het NTSC systeem terwijl PAL technisch veel beter is. Het is te ingrijpend om over te stappen op een beter systeem.
-
Met een schone lei beginnen ter vervanging van DCC en Co heeft zeker zo zijn voordelen maar of de glazen bol van vandaag beter werkt dan die van 25 jaar geleden is zeer de vraag. Als je ziet dat men erin slaagt om gestaag verder te bouwen en de mogelijkheden te vergroten zonder dat je oude decoders in de vuilbak moet kieperen dan noem ik dat niet verkeerd. Als je vandaag een uitspraak moet doen welke voorzieningen een nieuw protocol moet hebben om vanaf heden binnen 25 jaar een feature efficient en schaalbaar te kunnen realiseren, dan is het antwoord toch even zoeken. 16 bit adressering, analoge locs niet ondersteunen , etc. zijn zeker te overwegen aanpassingen maar zijn enkel een antwoord op problemen die je tot op heden vastgesteld hebt. Dat is de easy part. Doe nu dezelfde oefening door 25 jaar vooruit te gaan in de tijd en terug te denken wat je dan anders zou willen. Dit geeft je een beeld van de eisen voor het nieuwe protocol van vandaag of morgen.
Mvg, Patrick
.
-
De oude decoders hoeven niet meteen in de vuilnisbak, een nieuw programma er op wat een protocol met 16 bits adressen leest, is genoeg. Functioneel blijft veel hetzelfde.
-
Moet de decoder wel programmeerbaar zijn. Blij dat ik destijds voor Selectrix gekozen heb. Zelfs de huidige uitbreiding naar SX2 is begrijpbaar en logisch.
Groet,
Gerard van der Sel.