BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: kar op 12 mei 2020, 15:21:00
-
Beste allemaal,
Introductie
Stukje bij beetje ben ik bezig een modelbaan op te bouwen, bestaande uit een schaduwstation, een lange hellingbaan en een zichtdeel met een bescheiden baanplan. De boel wordt aangestuurd middels de Digikeijs DR5000, een booster DR5033 voor het zichtdeel en tbv het automatisch kunnen rijden maak ik gebruik van Rocrail. Zowel het schaduwstation als het station in het zichtdeel zijn een kopstation, zodat ik feitelijk heen en weer pendel met treinstellen. Van rondrijden of een keerlus is geen sprake.
Het schaduwstation en de lange helling zijn al een tijdje af en hebben in een proefbedrijf probleemloos gedraaid (melders, rijwegen, alles ok). Inmiddels heb ik het eerste spoor van het zichtdeel van prik voorzien. Na de helling volgt de overgang naar het stuk spoor in het zichtdeel dat door de booster van spanning wordt voorzien, uiteraard zijn beide railstaven bij deze overgang geïsoleerd. Wanneer ik met de standaard Digikeijs regelaar een locomotief over deze overgang laat rijden verloopt alles soepel. Met Rocrail zijn de extra rijwegen gecreëerd voor het nieuwe blok in het zichtdeel. So far so good (y).
Probleem
Bij het testrijden pendelt een trein braaf van het schaduwstation naar het zichtdeel boven en weer terug naar beneden. Dit gaat een tijdje goed, maar op enig moment blijft de trein na het terugkeren en stoppen in het schaduwstation op het kopspoor staan en wordt het kermis op de baan: verlichting van de trein gaat flikkeren, van een trein op het spoor ernaast draait de verlichting om (front naar rear) en bij het bedienen van geluidsfuncties worden er meerdere toeters en bellen tegelijk aangezet. Met andere woorden: ik heb sterk de indruk dat het digitale signaal verstoort wordt, alleen kan ik er de vinger niet op leggen waarom… ???
Vraag
Wie herkent een soortgelijk probleem waarbij het na enig moment kermis wordt op de baan met flikkerende lampjes, et cetera? En enig idee waar ik het probleem moet zoeken? Bedrading heb ik al nagelopen, voltageverschil tussen booster en centrale lijkt ok en kortsluiting lijkt het niet te zijn want dan schakelt de centrale zich normaal uit. Ik heb nog gezocht of er in de DR5033 booster of in Rocrail nog speciaal iets ingesteld moet worden om met elkaar te kunnen omgaan, maar ik heb geen aanwijzing in die richting gevonden. Daarnaast is het überhaupt maar de vraag of de toegevoegde booster onderdeel is van het probleem :-\
Henk
-
Zo te lezen zullen er niet veel treinen tegelijk rijden, waarom dan uberhaupt een booster ?
grtz rob
-
Hoi Rob,
Ik verwacht dat er uiteindelijk in het zichtdeel zo'n 5 a 6 treinen gelijktijdig in beweging kunnen zijn (incl. binnenverlichting). Op de helling naar boven en naar beneden zijn er ieder twee blokken waar zich treinen kunnen bevinden. Tevens worden wissels geschakeld mbv voeding uit de centrale en zijn er nog wat seinen in aantocht (hoewel die seinen niet zoveel verbruiken). Dat was mijn overweging om een booster te plaatsen die het treinverkeer in het zichtdeel voor z'n rekening neemt.
Henk
-
Moet makkelijk kunnen met alleen de dr5000, om te troubleshooten zou ik sowieso die booster even loskoppelen en kijken wat er dan gebeurt,
grtz rob
-
Is er een terugmeldschakeling met ingangen op de twee verschillende stroomkringen (DR5000 en booster)?
-
Moet makkelijk kunnen met alleen de dr5000, om te troubleshooten zou ik sowieso die booster even loskoppelen en kijken wat er dan gebeurt,
Dat is inderdaad goed om als vervolgstap te proberen. Ik lees overigens wisselende verhalen over het aantal treinen dat bij gelijktijdig rijden met 1 centrale/booster toe kan. Soms lees je '10 treinen op één centrale kan makkelijk' terwijl elders wordt gerekend met 0,5A per trein waardoor je bij een centrale die 3A kan leveren op maximaal zes treinen uitkomt.
Ik wil nog niet op de zaken vooruitlopen, maar als inderdaad blijkt dat alle treinen toe kunnen met de DR5000 dan zou ik kunnen overwegen de booster er voor de treinenloop uit te halen.
Is er een terugmeldschakeling met ingangen op de twee verschillende stroomkringen (DR5000 en booster)?
Ik maak gebruik van de DR4088LN terugmelders. De melders zijn via LN kabels verbonden met de LocoNet T poort op de centrale, ze maken daarbij geen kring: ze zijn steeds doorgekoppeld aan de volgende DR4088LN. De stroomvoorziening voor de meldpunten zelf komt -afhankelijk van de sectie- uit de centrale of uit de booster. De booster is via LN gekoppeld aan de LocoNet B poort op de centrale. Ik hanteer een zuivere scheiding van DR4088LN melders die uitsluitend gebruikt worden in de secties van de centrale en melders die uitsluitend gebruikt worden in de secties van de booster.
-
Hoi Henk,
Treedt het probleem steeds op dezelfde plek op? Dus als een loc op een specifieke plaats in het schaduwstation staat?
Ik denk dat het vooral een kwestie van uitsluiten wordt:
- Maak je gebruik van acties in Rocrail? schakel deze uit.
- Verwijder alle treinen van de baan, op 1 na en ga hiermee testrijden.
- Verwijder de booster en ga testen. Als dit het probleem niet oplost, naar de volgende stap.
- Sluit je melder(s) aan op een andere module, wijzig het adres in Rocrail en opnieuw testen.
Succes,
Albert.
-
Waarom de wissel voeden met de voeding van de centrale? Misschien zit hier de probleem.
-
Dank, ik heb weer een aantal aanknopingspunten om verder op onderzoek te gaan. Ik zal eerst het probleem nog een aantal keer proberen te simuleren om vast te stellen of het steeds op dezelfde plek is - ik meen dat het in ieder geval op twee verschillende sporen in het schaduwstation ontstond en ook nog eens door twee verschillende treinen.
De ironie is dat ik op de plek waar de verstoring ontstond in het schaduwstation ook mijn enige Digikeijs DR4088 S88N terugmelder gebruik, direct gekoppeld aan een DR4088LN (het bekende startsetje). Op advies heb ik voor de overige modules steeds gekozen voor de LN variant. Die S88 module zit pal naast de DR4088LN en heeft verder nooit enige storing gegeven. Toch sluit ik op voorhand niets uit.
Afijn, ik heb huiswerk :angel:
Henk
-
Vanavond nog een klein testje gedaan. Eén trein herhaaldelijk laten rijden van het schaduwstation (gevoed door de centrale) naar het zichtdeel (gevoed door de booster) v.v.. Geen vuiltje aan de lucht. De booster laat geen blauw lampje branden, met andere woorden er is geen sprake van omgekeerde polariteit.
Wanneer ik daarna een tweede trein plaats in het blok van het booster-deel dan licht het blauwe lampje wel op en ontstaat vlot daarna een storing: het was weer kermis met in dit geval geel/rood knipperende frontverlichting van een mat'64...
In de volgende stap wil ik de booster zoals hierboven al werd geadviseerd (tijdelijk) wegnemen en sluit ik alles op de centrale aan om te zien of dat het probleem oplost. Desalniettemin wilde ik dit bericht met deze ervaring plaatsen omdat het genoemde jullie wellicht verder op ideeën brengt.
-
Vandaag tijdelijk de booster eruit gehaald. Eerste trein laten rijden: geen probleem. Tweede erbij: gaat ook goed. Derde trein (Plan U, Artitec) erbij en het probleem doet zich helaas weer voor. Het probleem lijkt daarmee niet gerelateerd te zijn aan de booster. De Plan U was gisteren overigens ook betrokken toen de problemen ontstonden... Nu heb ik de Plan U van de baan gehaald, de boel opnieuw opgestart en alles draait al ruim een uur als een zonnetje. Inmiddels rijden vier treinen probleemloos rond.
De komende dagen zal ik de treinen nog een poosje laten proefrijden om te zien of het probleem niet terugkomt.
Gesteld dat het de Plan U zou zijn die de storing veroorzaakt dan begrijp ik niet waarom de andere treinen reageren op een verstoring van het digitale signaal, zelfs wanneer de trein op het moment dat het probleem zich voordoet van de baan wordt genomen. De verstoring bij de andere treinen bleef totdat ik de baan heb uit- en aangeschakeld. Heeft iemand ervaring met zo'n vaag scenario?
-
Nee, maar bij mijn weten is de stroomafname van de plan U van voor tot achter doorgekoppeld. Dan zou het probleem kunnen worden uitgelokt door te lang contact tussen de uitgang van de centrale en de boosteruitgang. Is het probleem overigens nog steeds gek.
-
Gesteld dat het de Plan U zou zijn die de storing veroorzaakt dan begrijp ik niet waarom de andere treinen reageren op een verstoring van het digitale signaal, zelfs wanneer de trein op het moment dat het probleem zich voordoet van de baan wordt genomen. De verstoring bij de andere treinen bleef totdat ik de baan heb uit- en aangeschakeld. Heeft iemand ervaring met zo'n vaag scenario?
Geen ervaring mee maar als de Plan U een verstoring van het digitale signaal veroorzaakt kan het zijn dat de decoders in de andere treinen een vervormd signaal binnen krijgen die ze niet snappen en daardoor ook van slag raken.
Dat verklaart namelijk waarom ze het weer normaal reageren als de baan is uit en weer ingeschakeld.
-
Is het een plan U met ESU Loksound? Ik heb eerder gelezen dat er bepaalde ESU Loksound decoders roet in het eten gooien. De oorzaak zou het ontbreken van een ontstoorcondensatortje over de interne voedingsspanning van de decoder zijn. Volgens mij heeft die Plan U een 21MTC connector en zowel de plus als de gnd zitten op die connector. Daar zou een condensatortje over moeten. Maar wellicht weet iemand hier het draadje te vinden waar dat ooit beschreven is.
Succes Frits
-
Ja, het betreft inderdaad een Plan U met loksound. Toevalligerwijs de overige 3 treinen die momenteel op de baan staan ook, dus die reageren er wellicht op maar lokken het probleem niet uit.
Ben benieuwd of iemand verwijzingen heeft naar dit loksound decoder probleem - uiteraard ga ik zelf ook op zoek.
Dank voor de aanwijzing. Dit type storingen is flink irritant wanneer je zo’n beetje door alle logica heen bent...
-
Ik dacht: dat topic is zo gevonden. Dus in de zoekbalk vul ik in: plan u loksound.
Komt er een melding: elk woord moet minstens 2 tekens lang zijn. Dat schiet dus niet op. Even een andere zoekterm bedenken.
-
Waarom de wissel voeden met de voeding van de centrale? Misschien zit hier de probleem.
Ik ga hier ook voor. Zorg voor een aparte sterke voeding voor de wissels. Korte stroompieken kunnen nu een oorzaak zijn.
-
Dit wil ik nog proberen, een paar wissels schakelen nu nog middels voeding vanuit de centrale. Die kan ik nog afkoppelen en op een separate voedingsbron zetten.
-
in de zoekbalk vul ik in: plan u loksound
Zoek met Google naar "plan u loksound site:beneluxspoor.net", dat werkt beter.
-
Volgens mij is dit de link (https://forum.beneluxspoor.net/index.php?topic=66140.60) naar het bewuste draadje over een storende Loksounddecoder
Gr. Frits
-
Dank, ik ga er induiken.
Overigens herinnerde iemand mij ook aan de eerdere problemen met knipperende binnenverlichting van de Plan U - die zijn toen bij mijn weten opgelost via de instructie (https://www.artitec.nl/index.php/component/zoo/category/plan-u) van Artitec.
-
Inmiddels het draadje doorgelezen. Tsjonge, de kenmerken van het probleem lijken wel heel erg overeen te komen...
Nu kom ik qua het aansluiten van de baan een behoorlijk eind, maar dingetjes solderen op een printplaat in een trein is even andere koek. Weet niet of ik daar zelf uit kom.
Even een ongelofelijke dummy vraag: de oplossing die Artitec eerder adviseerde voor het verlichtingsprobleem (zie boven), zou dat wel of of niet dit probleem moeten verhelpen? Of dekt dit bijvoorbeeld niet de storingen vanuit de motor of het hele treinstel af?
Nb: Plan U inmiddels opengemaakt en die oplossing van de Artitec website zat er al in.
-
Het knipperen van de verlichting is volgens mij een issue van de Artitec print.
Om de storende spikes van de decoder te verhelpen moet je een condensatortje van 100nF a 1uF over de plus en min zetten van de decoder voeding.
(https://images.beneluxspoor.net/bnls/ESU-Loksound-21MTC.jpg) (https://images.beneluxspoor.net/bnls/ESU-Loksound-21MTC.jpg)
De condensator komt tussen pin 20, GND en pin 16, U+. Je kan ook tussen pin 20, GND en pin 12, VCC proberen.
Succes Frits
-
Korte update:
1) ik heb het circuit van de baanspanning en wisselaansturing nu volledig gescheiden. De booster gebruik ik momenteel voor het schakelen van wissels en daar kan in ik de toekomst seinen en weet-ik-veel-wat nog op aansluiten.
2) ik heb vandaag een dappere poging gedaan om een condensator aan te sluiten op de decoder, technisch lukte dat. Echter zowel op pin 16 als pin 12 (icm pin 20) bood het geen soelaas voor het probleem. Ik denk dat er echt iets grondig mis is met (de decoder van) deze Plan U. Ik ga contact opnemen met Artitec hierover. Worst case zet ik er een gewone decoder in en dan maar geen sound.
Op de site van Artitec zag ik overigens dat er inmiddels een LocSound v5 bestaat, o.a. met het geluid van de Plan U. Weet iemand of de problemen met de LocSound v4 spikes in de v5 verholpen zijn?
Bedankt voor alle hulp tot op heden.
Henk
-
Ik heb een aantal ESU sound decoders V4 en ook V5 en ook in Artitecs en ook in plan U maar herken je probleem niet. Ik vermoed dat je decoder idd defect is. Je kunt hem nog eens proberen in een andere loc en kijken of het probleem mee verhuisd. Dan weet je het zeker.
-
Hoi kar,
Ik heb dit probleem helaas met de LS4 meerdere malen zien gebeuren, op verschillende banen.
Ik heb het echter niet in deze mate gezien zoals je het beschrijft.
Even mijn ervaring van het het probleem:
Je kunt de lok op de baan zetten en dan licht (of andere functies), en het geluid aanzetten. Tot dan geen probleem. Het begint pas als de lok begint te rijden. Vanaf dat moment kunnen er wissels niet meer geschakeld worden en of andere lok's kunnen niet meer reageren op commando's. De lok met de LS4 blijft wel gewoon rijden en reageert op commando's. De andere loks met courante ESU en Zimo decoders blijven normaal rijden. Loks met oude Lens decoders reageren niet meer op commando's.
De oorzaak is het ontbreken van een ontstoorcondensator op de LS4. Daardoor wordt de schakelpuls van de motorsturing niet onderdrukt en komt het op de rails, met alle gevolgen van dien.
Dan ben je afhankelijk van de andere decoders hoe deze om kunnen gaan met stoorimpulsen op het DCC signaal.
De problemen van de knipperende verlichting in de Plan U werden ook veroorzaakt door de stoorimpuls. In de Plan U zit een spanningsomvormer-ic op de printplaat (voor de binnenverlichting) en die gaat oscilleren n.a.v. de stuurimpuls.
In beide gevallen is de oplossing een ontstoorcondensator monteren tussen de U+ en de GND (niet op de VCC en GND).
Bij de Plan U kan dat eenvoudig op de printplaat en anders met een smd-condensator op de powerpack aansluiting van de decoder. Slechts 1 van de 2 is nodig.
Toch dan de vraag, blijft de Plan U normaal rijden en reageren op commando's als alles begint te knipperen?
Los van dit alles, de Plan U bij Artitec aanbieden, ze hebben een goede service.
mvg spock
PS: Een Plan U zonder geluid kan ECHT niet. ;D
-
PS: Een Plan U zonder geluid kan ECHT niet. ;D
Hi spock,
Met die ps toverde je een brede glimlach op m'n gezicht, je hebt daarin natuurlijk helemaal gelijk :D
Goed, nieuwe dag, nieuwe kansen. Houd je vast, want het neemt mijns inziens een bizarre wending aan.
Toch dan de vraag, blijft de Plan U normaal rijden en reageren op commando's als alles begint te knipperen?
Ik wilde dit scenario nog eens testen. In tegenstelling tot eerdere testen heb ik ditmaal rocrail niet gebruikt en heb mij beperkt tot de software van digikeijs. De volgorde was nu anders: meestal zet ik eerst het treinstel op de baan om daarna met de regelaar het adres in te toetsen. Ditmaal draaide ik het om: ik selecteerde het adres (128) en......... gelijk KERMIS op de baan :-X ??? :o. Het treinstel stond nog niet op de baan en kon deze verstoring dus onmogelijk veroorzaken. In plaats van de hulpdiensten te bellen heb ik (na het herstarten) de Plan U op het programmeerspoor gezet en het locnummer 3 gegeven. Geluid doet het nu normaal, ook bij het rijden en bij deze korte test was er geen impact op de overige treinen op de baan.
Dit maakt de situatie mogelijk dus compleet anders. Daarom de volgende vragen:
- zit het nummer 128 toevallig in zo'n reeks van nummers 'die je beter niet kunt gebruiken'? Op internet zag ik zojuist dat nr 99-128 soms problemen kan opleveren?
- als dit zo is, zijn er nog meer de nummers die ik beter zou kunnen vermijden?
- als nummer 128 beter niet gebruikt wordt, geldt dit dan zowel voor loc adressen als voor wisseladressen, als voor melder-adressen?
- los van bovenstaande: enig idee wat in de digikeijs centrale al die fouten kan triggeren bij het alleen maar selecteren van het nummer 128 in de software en hoe ik dat zou kunnen vermijden (behalve nr 128 in te geven natuurlijk...)?
Wat een klucht dit...
Henk
-
Hallo Henk,
Het is nu wel duidelijk dat het niks het de ontstoorcondensator te maken heeft.
Ik vermoed dat het iets met protocollen en adressen te maken heeft.
De LS4 en LS5 zijn multiprotocol decoders. Standaard staan alle protocollen geactiveerd op de decoder.
Wil je svp het volgende proberen:
Op de decoder alle protocollen uitschakelen behalve DCC.
Vervolgens de Plan U weer adres 128 geven, maar dan wel volgens de lange adressen methode (CV 29/17/18), NIET de korte.
mvg spock
-
Dat is dan nog wel even een karweitje, want dat zou ik dan moeten doen bij alle treinen waar een LS/LP in zit. Ook een soundloze trein stond vanmiddag namelijk dapper mee te knipperen nadat ik adres 128 had ingegeven.
Moet ik het zo zien dat bepaalde protocollen bij bepaalde adressen ‘andere’ signalen uitsturen? Als het zo is dat ik wellicht bepaalde adressen beter niet kan gebruiken dan is dat eenvoudiger dan van alle esu decoders de protocollen aan te passen.
Neemt niet weg dat ik dit scenario voor de huidige treinen op de baan wel ga uittesten zodat we ervan kunnen leren en het probleem kunnen isoleren.
Nogmaals dank voor alle hulp tot op heden.
-
Heb je dit NMRA DCC adressen (https://dccwiki.com/Address_Range) al eens gelezen?
Adress 128 is niet geldig voor een kort loc adres, die lopen van 1-127
Groet Meino
-
Om het nog leuker te maken: in de documentatie van de LS4 staat dat een kort adres van 1 -127 mag zijn met als kanttekening dat sommige centrales alleen de adressen 1-99 kunnen uitsturen (in de korte adressen).
@henk: wil je eens de volgende test doen: zowel de plan U als de knipperende LP4 beide voorzien van een lang adres boven de 128 bv 1128 en 1130( en laat de protocollen maar aan staan).
Mvg spock
-
Kort / lang: ik meen dat dat met een DR5000 automatisch gaat. Je stelt in wat het hoogste "korte" adres is (127) en programmeer je een adres daarboven (128 en hoger) dan is dit automatisch "lang". Geen omkijken naar CV17/18/29.
(https://abload.de/img/naamloosr2j1l.png) (https://abload.de/image.php?img=naamloosr2j1l.png)
Gr, Ben.
-
Hallo,
Kort / lang: ik meen dat dat met een DR5000 automatisch gaat.
Dat is inderdaad zo. Tenminste als je het loc-adres programmeert zoals Ben hierboven aangeeft: via het veld Adres...
Doe je het rechtstreeks via CV1 dan zal dit niet gebeuren... ::)
Ik vraag mij af hoe Henk/kar het lok-adres programmeert. Als hij dat rechtstreeks doet via CV1 en daar de waarde 128 in zet dan werkt dat niet...
Dan heeft de lok volgens CV29 een kort adres, echter met een ongeldig adres (128) in CV1...
Ik wilde dit scenario nog eens testen. In tegenstelling tot eerdere testen heb ik ditmaal rocrail niet gebruikt en heb mij beperkt tot de software van digikeijs. De volgorde was nu anders: meestal zet ik eerst het treinstel op de baan om daarna met de regelaar het adres in te toetsen. Ditmaal draaide ik het om: ik selecteerde het adres (128) en......... gelijk KERMIS op de baan :-X ??? :o. Het treinstel stond nog niet op de baan en kon deze verstoring dus onmogelijk veroorzaken. In plaats van de hulpdiensten te bellen heb ik (na het herstarten) de Plan U op het programmeerspoor gezet en het locnummer 3 gegeven. Geluid doet het nu normaal, ook bij het rijden en bij deze korte test was er geen impact op de overige treinen op de baan.
Vragen aan @Henk/kar:
- Hoe programmeer jij het adres van je loc? "Gewoon" op het programmeerspoor via CV1?
- Zo ja, doe je dat ook voor adres 128?
- Welke waarde staat bij jou in de DR5000 software in het onderstaande scherm achter "Laatste 'korte' loc-adres?
(https://images.beneluxspoor.net/bnls/00_00_AA_22.jpg) (https://images.beneluxspoor.net/bnls/00_00_AA_22.jpg)
Verder is het zo dat als je via de ene centrale/software een loc-adres 100 t/m 127 als "kort" adres in de loc programmeert (dus in CV1) en de loc vervolgens aanstuurt vanuit een centrale die de locadressen vanaf 100 aanstuurt als "lang" adres de als "kort" geprogrammeerde locs niet reageren op de aansturing via "lange" adressen 100 t/m 127...
De aansturing vanuit de centrale voor korte en lange adressen is namelijk verschillend...
Groeten,
Bert
-
Dat is allemaal waar, als de centrale automatisch omschakelt van basic adressen naar extended adressen (lang loc adres), dan is het enige wat dan zou kunnen gebeuren is dat die ene loc niet reageert. In dit geval slaat echter alles wat op de baan staat op tilt. Voor mij lijkt dat er op dat er een vorm van broadcast bericht wordt uitgezonden waar alles op moet reageren. Dat zou inderdaad kunnen omdat bij adres 128 het eerste bit op 1 staat en de overige 7 bits (het echte korte adres) op 0 staat, wat inderdaad het broadcast adres is.
Dus is het misschien een configuratie probleem in de centrale?
Groet Meino
-
@henk: wil je eens de volgende test doen: zowel de plan U als de knipperende LP4 beide voorzien van een lang adres boven de 128 bv 1128 en 1130( en laat de protocollen maar aan staan).
@spock: wil ik nog wel doen, maar ik denk dat dit geen oplossing geeft. Het probleem lijkt te ontstaan bij het intoetsen van het nummer 128 op de centrale. Bij 127 en 129 gebeurde er niets. 1128 zal dan ook wel goed gaan. Ik heb ook een ander treinstel op de baan staan met een lang viercijferig nummer dat gewoon keurig reageert op de centrale maar meeflipt wanneer ik het getal 128 intoets.
Vraag aan @Henk/kar:
- Hoe programmeer jij het adres van je loc? "Gewoon" op het programmeerspoor via CV1?
- Zo ja, doe je dat ook voor adres 128?
@Bert: ik had voordat ik de DR5000 ging gebruiken een Lenz centrale (incl. upgrade naar v3.6 die dus lange adressen ondersteunde). Eerlijkheidshalve weet ik niet meer wanneer ik deze Plan U heb geprogrammeerd en of dat met de Lenz centrale was of met de Digikeijs DR5000. Tegenwoordig gebruik ik altijd de Digikeijs centrale middels het scherm dat Ben heeft getoond.
In dit geval slaat echter alles wat op de baan staat op tilt. Voor mij lijkt dat er op dat er een vorm van broadcast bericht wordt uitgezonden waar alles op moet reageren. Dat zou inderdaad kunnen omdat bij adres 128 het eerste bit op 1 staat en de overige 7 bits (het echte korte adres) op 0 staat, wat inderdaad het broadcast adres is.
Dus is het misschien een configuratie probleem in de centrale?
Heb ik dan echt die ene naald in de hooiberg weten te vinden? ;-).
N.a.v. bovenstaande reacties (die ik trouwens allemaal zeer waardeer) zit ik zelf op de koers van Meino - hoewel ik bitter weinig van zo'n broadcast bericht weet. Het lijkt erop dat de centrale de boel vanaf dit specifieke adres ontregelt. Wel ongemakkelijk: alsof er een rode knop in de kamer hangt waar je niet op mag drukken maar waar je wel langs komt. Ergo: als het nummer 128 een no-go nummer is zou ik het liever ook niet in kunnen toetsen op de centrale...
Henk
-
Henk,
.. Ergo: als het nummer 128 een no-go nummer is zou ik het liever ook niet in kunnen toetsen op de centrale...
Het "nummer" 128 als loc-adres is geen no-go nummer, bij mij op de DR5000 werkt dit zonder problemen...
... Het probleem lijkt te ontstaan bij het intoetsen van het nummer 128 op de centrale. Bij 127 en 129 gebeurde er niets. 1128 zal dan ook wel goed gaan. Ik heb ook een ander treinstel op de baan staan met een lang viercijferig nummer dat gewoon keurig reageert op de centrale maar meeflipt wanneer ik het getal 128 intoets.
In welk DR5000 scherm en in welk veld toets jij het getal 128 in? Kun je hier daarvan een schermprintje plaatsen?
Groeten,
Bert
-
In welk DR5000 scherm en in welk veld toets jij het getal 128 in? Kun je hier daarvan een schermprintje plaatsen?
Beste Bert,
Ik doet dit via dit scherm:
(https://images.beneluxspoor.net/bnls/digikeijs.jpg)
(via 'control go-stop' en dan 'rijden!')
Henk
-
Hoi Henk,
Bert heeft een scherm getoond met "laatste korte adres".
Welke waarde wordt bij jou getoond?
Mvg spock
-
Henk,
Ik doet dit via dit scherm:
Ook dat werkt bij mij zonder problemen...
Welke twee Firmware versies worden bij jou getoond in het DR5000 USB-scherm?
(https://images.beneluxspoor.net/bnls/00_00_AA_23.jpg) (https://images.beneluxspoor.net/bnls/00_00_AA_23.jpg)
Groeten,
Bert
-
- Welke waarde staat bij jou in de DR5000 software in het onderstaande scherm achter "Laatste 'korte' loc-adres?
Beste spock en Bert,
Ik zag zojuist inderdaad dat ik die vraag nog niet had beantwoord. Als waarde staat daar '126'.
Firmware zal ik morgen even checken.
Henk
-
Hallo Henk,
Ik zag zojuist inderdaad dat ik die vraag nog niet had beantwoord. Als waarde staat daar '126'.
Ook met de (wat onlogische waarde) 126 kan ik bij mij op de DR5000 zonder enig probleem de waarde 128 ingeven op het door jou getoonde scherm...
Firmware zal ik morgen even checken.
Dan wachten we dat gegeven nog even af... ;)
Groeten en tot morgen,
Bert
-
Herstel van mijn eerdere bericht: het laatste 'korte' loc-adres staat op 88 in de DR5000. Toen ik gisteren keek zat ik met de laptop op de bank ipv met het kabeltje gekoppeld aan de centrale.
De huidige firmware staat op v1.5.4. In tegenstelling tot het screenshot van Bert staat bij mij als laatste beschikbare versie ook 1.5.4 ipv 1.5.5. Gezien het serienummer van de DR5000 vermoed ik ook dat ik een iets ouder exemplaar heb - geen idee of dat er verband mee kan houden.
Het omzetten van een LP naar DCC only als test moet ik nog doen.
-
Hallo Henk,
Voordat je allerlei andere dingen gaat proberen zou ik eerst de DR5000 software en firmware upgraden naar versie 1.5.5, dat is de recentste versie.
Daartoe eerst vanaf deze site de software downloaden:
> https://support.digikeijs.com/hc/en-us/articles/360001203338-DR5000-ADJ-Manuals-Downloads (onderaan: EXE - Software/Firmware Version 1.5.5)
Vervolgens de software installeren op PC en daarna de de DR5000 met firmware V1.5.5 updaten.
In de handleiding vind je de daartoe benodigde instructies.
Nog een vraag: gebruik je na het intoetsen van loc-adres in het DR5000 "Rijden" scherm het scroll-wieltje op de muis om de snelheid van de loc te regelen?
- Zo ja, dan dien je na het intoetsen van het adres eerst het veld "Locadres" te verlaten voordat je met het wieltje gaat scrollen, anders ga je via het wieltje scrollen tussen de locadressen in het veld "Locadres", waardoor elke keer het volgende (tussen)adres geselecteerd en geactiveerd wordt...
Groeten,
Bert
-
Upgraden kan geen kwaad maar lost het probleem niet op, 1.55 is een fix voor een Daisy.
Ik zou ook maar even resetten naar fabrieksinstellingen en de DR5000 opnieuw configureren. Daarmee is het klaar en kun je testen.
Gr, Ben.
-
Hallo,
Upgraden kan geen kwaad maar lost het probleem niet op, 1.55 is een fix voor een Daisy.
Klopt, maar dan werken (en testen) we wel allemaal met een versie de gelijk is en officiëel ondersteund wordt, juist omdat Henk een "bug" in de DR5000 software/firmware vermoedt...
Groeten,
Bert
-
Ik zet de vlag alvast klaar, maar hang 'm nog net niet uit - eerst nog even doortesten ;)
Vandaag tussendoor het volgende gedaan n.a.v. de suggesties:
- firmware upgrade naar v.1.5.5 --> probleem was hiermee niet verholpen, maar de centrale is in ieder geval bijgewerkt
- DR5000 teruggezet naar fabrieksinstellingen en... het probleem lijkt weg.
Bij het selecteren van adres 128 geen kermis deze ronde. De Plan U heb ik vervolgens middels het Digikeijs schermpje via het adres veld weer van nummer 128 voorzien en de geluiden werden goed afgespeeld zonder daarbij de overige treinen te beïnvloeden. Het lijkt erop dat de reset dus heeft geholpen.
In de komende dagen zal ik bij gelegenheid nog eens vaker testen en ik zal de Plan U ook mee laten rijden op de baan om te zien of het probleem wegblijft of weer terugkomt. Dan kan de vlag uit - het is/was namelijk een knap frustrerende verstoring. Het is lastig om het probleem te isoleren en om te begrijpen wat de fout heeft veroorzaakt.
Nog wel de eerder gestelde vraag: het is toch ok om overlap te hebben met wisseladressen, melderadressen en locadressen? Ergo, adres 201 zou bijvoorbeeld toch mogen voorkomen als wisselnummer èn als meldernummer èn als locnummer?
Ik heb al eerder gezegd dat ik blij ben met alle hulp, maar doe dat nu opnieuw: veel dank voor het meedenken!
-
het is toch ok om overlap te hebben met wisseladressen, melderadressen en locadressen? Ergo, adres 201 zou bijvoorbeeld toch mogen voorkomen als wisselnummer èn als meldernummer èn als locnummer?
Jazeker, dat kan/mag.
-
Het lijkt op een overlap, bijv lokadres 12 en wisseladres 12. In werkelijkheid wordt dat wisseladres 12 verhoogt met een vaste waarde, zodat op de DCC bus ze altijd uniek zijn. Daarom kun je wisseladressen probleemloos laten overlappen met lokadressen.
Het zelfde vraag je ook met betrekking tot de melderadressen. Voor zover ik dat weet gaan die niet over DCC, Ik denk dat dat LocoNet of S88 nummers zijn. Die staan dus los van de DCC adressen.
Groet Meino
-
Hallo Henk,
Fijn dat het probleem opgelost lijkt...
Nog even ter controle: Staan op jouw DR5000 USB scherm nu ook beide Firmware versies op 1.5.5?
(https://images.beneluxspoor.net/bnls/00_00_AA_23.jpg) (https://images.beneluxspoor.net/bnls/00_00_AA_23.jpg)
Groeten,
Bert
-
Dank voor de bevestiging mbt de nummers, dan hoef ik mij daar geen zorgen over te maken.
@Bert: beide waarden geven nu v1.5.5 aan, dus de firmware upgrade lijkt geslaagd.
-
Het lijkt op een overlap, bijv lokadres 12 en wisseladres 12. In werkelijkheid wordt dat wisseladres 12 verhoogt met een vaste waarde, zodat op de DCC bus ze altijd uniek zijn. Daarom kun je wisseladressen probleemloos laten overlappen met lokadressen.
Het DCC protocol kent verschillende soorten adressen:
7bit = Korte adressen voor Lok decoders
9bit = voor wissel decoders
11bit = extended accessory (geen idee of dat gebruikt wordt)
14bit = Lange adressen voor lok decoders
Het is zelf zo dat je in theorie de ene Lok kort adres 1 Kan geven en een andere lang adres 1, em ze dan dus beide appart Kan aansturen.
In de praktijk werkt dit vaak niet omdat de meeste centrales werken met een drempel waarde van 100 of 126 Als grens of een adres kort of Lang is.
Reinder
-
Je hebt gelijk en niet gelijk. Een DCC pakket is opgebouwd uit een aantal bytes (8bit). Allleen het eerste byte van 8 bits bepaald het type adres en is eigenlijk het enige adres byte. Als bit0 (MSB) 0 is, dan zijn de volgende 7 bits het adres van een basic locdecoder. Dus de inhoud van het adres byte loopt dan van 1-127. Is bit0 == 1 en bit2 == 0, dan is zijn er 6 bits voor het adres van een wisseldecoder en de data byte(s) die volgen bevatten dan de rest van het decoder adres. Dus de inhoud van het adresbyte loopt dan van 128-191. Als laatste de inhoud van het adres byte 192-231, geeft aan dat er een lok decoder met een lang adres wordt aan gesproken.
Dus het hangt er maar vanaf of je de variabele preamble, van 1 tot 4 bits tot het adres rekent of niet. Ik doe dat wel, zo wordt het n.l. ook in de NMRA standaard verwoord.
Groet Meino
-
Ik weet niet of het al geopperd is, maar is het een idee om een andere centrale te proberen. Voor de test?
Wellicht heeft iemand in je omgeving een IB of een Z21? Anders heb ik wel een Z21 te leen even.
Als ik de problemen zo lees kan het best een centrale ding zijn. Net als met de EcoS bijvoorbeeld waarbij je vaak fluctuering kunt waarnemen in de verlichting.....
Just shooting
-
Da's toch pas zinvol als het probleem weer terug komt? Wat ik begrijp is dat het opgelost is.
Gr, Ben.
-
Dan heb ik die memo over het hoofd gezien.
Negeer mijn post dan maar even tot het probleem er weer is.
-
...Als bit0 (MSB) 0 is, dan zijn de volgende 7 bits het adres van een basic locdecoder. Dus de inhoud van het adres byte loopt dan van 1-127.
Is bit0 == 1 en bit2 == 0, dan is zijn er 6 bits voor het adres van een wisseldecoder en de data byte(s) die volgen bevatten dan de rest van het decoder adres. Dus de inhoud van het adresbyte loopt dan van 128-191. Als laatste de inhoud van het adres byte 192-231, geeft aan dat er een lok decoder met een lang adres wordt aan gesproken....
Oeps Meino...
Graag wel even de algemeen gangbare conventie aanhouden dat Bit-0 het LSB (Least Significant Bit) is en niet het MSB (Most Significant Bit). ;) ( Lenz heeft al voldoende verwarring gezaaid, door het MSB Bit 1 te noemen :'( )
Dus:
...Als bit7 (MSB) 0 is, dan zijn de volgende 7 bits het adres van een basic locdecoder. Dus de inhoud van het adres byte loopt dan van 1-127.
Is bit7 == 1 en bit6 == 0, dan is zijn er 6 bits voor het adres van een wisseldecoder en de data byte(s) die volgen bevatten dan de rest van het decoder adres. Dus de inhoud van het adresbyte loopt dan van 128-191. Als laatste de inhoud van het adres byte 192-231, geeft aan dat er een lok decoder met een lang adres wordt aan gesproken....
...Dus het hangt er maar vanaf of je de variabele preamble, van 1 tot 4 bits tot het adres rekent of niet.
Ook hier weer: Pre-Amble betekent in DCC termen echt iets anders... De preamble-bits zijn z.g. "1" bits die vóór een DCC Pakket gestuurd worden door de centrale, met het doel de ontvanger in de decoder te synchroniseren.
Grtzz,
Karst
-
Dag Karst
Omdat er altijd verwarring is over de volgorde waarin je de bits benoemd worden, gebruik ik (als C,C++ Javaan) wat ik gewend ben. Ik gebruik dus de volgorde zoals je ook een index in een array gebruikt, dat begint met 0 voor het eerste element. Dus voor mij is het eerste bit bit0. Verder een byte heeft op de platforms waar wij meestal op werken 8 bits. Maar in deze volgorde, heeft bit0 de hoogste waarde, die is 128, vandaar MSB.
Dit komt overeen met wat in de NMRA norm beschreven wordt over de DCC adresruimte. Een stukje uit de DCCWiki
"The first address range defined is 1 through 127. This is the Primary Address. It is a one byte (eight bit) address which in Hexadecimal (see Binary) can have the value of 0116 to 7F16 (1 to 127 in decimal) − hence it is called a Two Digit Address. Other terms used for the Primary address are the Short, Baseline or 7−bit Address. It is called a 7−bit address because the first (most significant) bit in the first byte of a DCC packet is always a zero when it is addressing a multifunction decoder in primary address mode. The MSB of this byte can be used for other purposes. "
Dat Lenz dat bit1 noemt komt omdat er een andere stroming in de IT is (Cobol, Fortran etc) waarbij het eerste element in een array index 1 heeft.
Het gebruik van het woord preamble door mij komt, omdat dat in mijn vak in een veel ruimere betekenis gebruikt wordt.
Groet Meino
-
Omdat er altijd verwarring is over de volgorde waarin je de bits benoemd worden, gebruik ik (als C,C++ Javaan) wat ik gewend ben.
Het gebruik van het woord preamble door mij komt, omdat dat in mijn vak in een veel ruimere betekenis gebruikt wordt.
Heerlijk toch zo'n discussie, ik zal hier maar niet gaan vermelden waaraan ik gewend ben...
Dan wordt de verwarring nog groter... 8)
Eén ding is echter zeker: Adressen voor "loc"-decoders en adressen voor "wissel"-decoders staan echt helemaal los van elkaar, net zoals huisnummer 302 in de stationsstraat niet hetzelfde adres is als huisnummer 302 in de stationsdwarsstraat... ;)
De centrale zorgt wel voor de juiste "verpakking"...
Groeten,
Bert
-
Omdat er altijd verwarring is over de volgorde waarin je de bits benoemd worden, gebruik ik (als C,C++ Javaan) wat ik gewend ben. Ik gebruik dus de volgorde zoals je ook een index in een array gebruikt, dat begint met 0 voor het eerste element. Dus voor mij is het eerste bit bit0.
Logisch... en naar mijn mening correct (idem hier als C,C++, Java, C# estd. 1988) ;)
Maar...
...Verder een byte heeft op de platforms waar wij meestal op werken 8 bits. Maar in deze volgorde, heeft bit0 de hoogste waarde, die is 128, vandaar MSB. ......
Als jij die opvatting hebt, vraag ik me echt af hoe je met microcontrollers kunt werken... daar heeft bit 0 toch echt de waarde 20 = 1, bit 1 21 = 2, bit 2 22 = 4, etc.
(https://images.beneluxspoor.net/bnls/MSBLSB.png) (https://images.beneluxspoor.net/bnls/MSBLSB.png)
Maar goed, ieder z'n eigen idee is ook goed ::) ::) ::) is iig handig voor communicatie onderling :)
Anyway, dit helpt de topic-starter allemaal niets. Ik vermoed, dat zijn DR5000 gewoon "van de leg" was, zeker gezien hij 88 als waarde in "het hoogste korte adres" had staan. De Factory-reset heeft het probleem verholpen. En mits er niet meer aan "het hoogste korte adres" gefriemeld wordt, zal dat ook zo blijven. :)
Grtzz,
Karst
P.S. de NMRA DCC norm beschrijft een pakket als bit-stream. En benoemt de bits naar volgorde van ontvangst. En definieert daarbij dat het eerste bit (bit0 dus ;) ) dat binnenkomt, de hoogste waarde heeft... In die zin dus het MSB. Dus in dat licht bezien zijn je opmerkingen nog niet eens zo heel fout ;)
-
Dag Karst
Ik heb gedurende mijn hele werkzame leven in de IT nooit te maken gehad met de software voor micro controllers. Ik heb me beziggehouden met ander soort problemen (UNIX systeem drivers, Document verwerking, traffic control, web services, CORBA, SOAP, data modellen etc) .Uiteindelijk is dit gewoon wat we gewend zijn.
Iets valt me wel op in alle onderlinge discussies, dat mijn denkwijze niet overeenstemt met de aanpak van velen die zich met Arduino's en PIC's bezig houden hier op het forum. Voor mij is een IT probleem in eerste instantie een probleem op meta nivo. Voor mij is in de oplossing in eerste instantie de hardware niet echt relevant. Natuurlijk speelt die wel een rol, maar meer om kaders te plaatsen. Pas als ik het probleem uitgewerkt heb (in OO) kijk ik pas hoe dat uitgerold zou kunnen worden. Ik merk echter, door de vele discussies, dat dat niet de standaard aanpak is, zoals die door velen hier wordt gehanteerd, daar draait alles om de specifieke hardware, en vanuit dat startpunt wordt een probleem aangepakt waarbij gelijk code wordt geproduceerd voordat IMHO het probleem zelf is doorgrond.
Overigens denk ik dat deze discussie voor de meeste lezers niet erg interessant is dus laten we die maar als beeindigd beschouwen.
Groet Meino
-
Anyway, dit helpt de topic-starter allemaal niets. Ik vermoed, dat zijn DR5000 gewoon "van de leg" was, zeker gezien hij 88 als waarde in "het hoogste korte adres" had staan. De Factory-reset heeft het probleem verholpen. En mits er niet meer aan "het hoogste korte adres" gefriemeld wordt, zal dat ook zo blijven. :)
Hoi Karst en alle anderen,
De topic-starter weet nu in ieder geval dat hij zich over deze adressen geen zorgen hoeft te maken :). Net nog even gekeken naar het "het hoogste korte adres" en die staat na de reset weer op 99. Overigens kan ik mij niet herinneren, laat staan er redenen voor verzinnen waarom hier ooit aan 'gefriemeld' is en hoe deze op 88 is gekomen. Ook de betreffende trein met het nummer 128 heeft in het verleden normaal gereden op de baan. Wat het probleem uiteindelijk veroorzaakt heeft dat de DR5000 van de leg was: geen idee. Inmiddels draait de boel al een paar dagen zonder problemen en kijk ik met veel plezier naar de afwisseling van treinen die op het zichtdeel van de baan verschijnen. De verdere bouw kan nu beginnen.
Henk
-
Beste spock en Bert,
Ik zag zojuist inderdaad dat ik die vraag nog niet had beantwoord. Als waarde staat daar '126'.
Henk
Ik help een kennis met een vergelijkbaar probleem.
Volgens de handleiding van de DR5000 zou 126 de standaard waarde moeten zijn. Dat betekent dus dat adres 127 en hoger als 'lang' adres wordt behandeld.
Henk,
Ik lees hier dat je DR5000 na de reset op 99 staat. Dat komt me dan vreemd over. Wat is nu correct?
Groeten,
Albert.
-
... Als jij die opvatting hebt, vraag ik me echt af hoe je met microcontrollers kunt werken... daar heeft bit 0 toch echt de waarde 20 = 1, bit 1 21 = 2, bit 2 22 = 4, etc.
FWIW, ik heb in het eerste jaar computerkunde, in 1985, ook geleerd dat bits van rechts naar links genummerd worden, beginnend bij 0 (nul).
-
Ik lees hier dat je DR5000 na de reset op 99 staat. Dat komt me dan vreemd over. Wat is nu correct?
Beste Albert,
Wat correct is weet ik niet, wel dat de centrale na de reset 99 als laatste ‘korte’ loc-adres gebruikt. Heb het zojuist nog even nagekeken en hij staat nog steeds op 99 (heb hier ook niet meer bij gezeten).
Misschien dat Karst jou hierover uitsluitsel kan geven?
Sinds de harde reset heeft bij mij alles een tijd lang uitstekend gefunctioneerd. Vorige week had ik een probleem waarbij de centrale niet meer wilde inschakelen. Zowel qua software als met de fysieke knoppen niet. Uiteindelijk bood alleen een harde reset uitkomst en sindsdien draait het weer goed. Oorzaak: geen idee.
Henk
nb: in het screenshot van Bert -eerder in dit draadje- zie ik ook het getal 99 staan als laatste korte adres
-
Hoi Henk,
Bedankt voor je reactie.
Volgens de NMRA standaard:
'Bits 0-6 contain an address with a value between 1 and 127'.
Bron: https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.1_electrical_standards_2020.pdf (https://www.nmra.org/sites/default/files/standards/sandrp/pdf/s-9.1_electrical_standards_2020.pdf)
Als ik dan kijk naar de DR5000 is zowel 99 als 126 niet de juiste waarde, dit zou 127 moeten zijn. Ik lees je topic nog even door om te kijken of dit aan de orde is geweest.
Groeten,
Albert.
-
Maak het niet te ingewikkeld zou ik zeggen Albert. "Het hoogste korte adres is 126" mag je ook lezen als "het laagste lange adres is 127".
Verder is het handig even een back-up te maken van de instellingen van het werkend systeem, dat kun je dan weer inlezen als je een reset hebt moeten doen.
Gr, Ben.
-
Maak het niet te ingewikkeld zou ik zeggen Albert. "Het hoogste korte adres is 126" mag je ook lezen als "het laagste lange adres is 127".
Hoi Ben,
Ik hoop het juist duidelijk te maken. Wat je schrijft klopt namelijk niet. Het hoogste korte adres is 127 (NMRA) en het laagste lange adres is dus 128.
Bedankt voor de tip over de backup, die neem ik mee.
Groeten,
Albert.
-
(y)