Hi allemaal,

zoals bekend heb ik een CS3. En sinds gister ook een BR 103 met Uhlenbrock Decoder, de standaard van Piko. Aangezien alle Piko spullen standaard op adres 3 komen en dit adres toevallig op dit moment al bezet is, wilde ik het anders veranderen. Zou met de CS3 moeten kunnen. Wat ik deed, deed ik, maar ik gooide de programmering overhoop. Reset dus en alle CV's, dit maal op de IB, terugzetten naar hun waarde van Piko. Zo gezegd, zo gedaan. Stukje proef gereden bij de IB, alles deed het, geen rare fratsen. Adres veranderd, nogmaals getest, alles in orde. Lok weer naar de CS3 toe. Lok aangemaakt, adres 103 (DCC) gegeven en ingevoerd. 28 rijstappen, net als de decoder als default doet. Zodra ik echter een commando richting lok stuur, bijvoorbeeld licht aan (stond nog aan van de IB en geen vernieuwd commando, dus vastgehouden), begint de verlichting onregelmatig te knipperen, alhoewel ik zo nu en dan meen enige regelmaat, namelijk een frequentie van 1 seconde, te herkennen. Dit gewoon tijdens stilstand, dus een contactprobleem is het niet. Ook tijdens het rijden is dit het geval. Het maakt hierbij niet uit of de lok op de hoofdbaan staat, of dat deze op op het programmeerspoor staat. Vermogen is volgens de meetapparatuur van het CS zelf voldoende.

Zet ik de lok weer in de IB controle, dan doet ie dat niet. In CV 100, het storingsregister, wordt niets aangetroffen. Het veranderen van de waarde in het CV dat de felheid van de verlichting regelt, haalt niets uit. De lok op adres 80 terugzetten en aanroepen in Motorola zorgt ervoor dat de lok zich weer netjes gedraagd zonder knipperen. Een tijdelijke oplossing, maar naar mijn idee geen permanenten oplossing. Goed, deze lok heeft dan geen tig functies, maar ik wil gewoon zeker weten dat ie het op DCC ook zonder morren doet en blijft doen.

De lok is dus goed, de decoder is goed, de stroomafname is goed, maar ergens in het communicatievat tussen CS3 en lok op DCC gaat het fout. Iemand die mij hiermee kan helpen?

Groet,
Laurent

De Piko lijkt alleen programeerbaar via de 6021-route.
Het is mij een aantal maanden geleden gelukt met een trucje i.c.m. twee MS2.

Het lijkt heel omslachtig, maar je moet eigenlijk een paar hulploks aanmaken, zodat je de stappen van de UB-decoder te laten reageren.
Ik ga nog even op zoek naar de juiste instructie.

John

Analoog herkenning uitzetten helpt wellicht?

Dank voor jullie antwoorden. Vanavond zag ik bij toeval dat de stuurstand van mijn Railjet, door mij voorzien van LoPi V4.0 multiprotocol decoder die voor functiedecoder speelt, hetzelfde doet als de stam in duwbedrijf wordt gebruikt (en hij dus wit moet tonen). En ook deze doet dat niet op de IB. Decoder gereset en opnieuw gemapt, zelfde verhaal. Ergo: Ik denk dat het probleem zit in het CS3. Ik heb waarschijnlijk geprobeerd in een of andere programmeerfunctie iets anders aan te roepen. Die ga ik dus zo back-uppen en dan maar eens resetten.

CV's uitlezen op het programmeerspoor wordt momenteel ook geweigerd.

EDIT: Het knipperen is na dubbel restoren verholpen. Eerst een back-up gemaakt van de huidige situatie, vervolgens een restore gedaan naar de laatste update. Toen was het weg. Stoute schoenen aan gedaan en de back-up van net weer teruggezet. Probleem kwam daarmee niet terug.

Bizar.

Laurent.

Het probleem met de uhlenbrock decoders heb ik ook af en toe met mijn IB.
En zoals Ben al aangaf heb ik helaas nog niet overal het analoge uitgezet.
Het knipperen komt voor als ik bv de ib met de rode knop uitheb gezet in een noodgeval om een botsing te voorkomen.
Ben namelijk nog met te veel dingen tegelijk bezig waardoor er wel helaas soms iets verkeerd kan gaan.
Maar na de herstart op de ib wil er soms een loc niet meer van zijn plek af , en staan dan in die modus dat het alleen met regelmaat knippert.
Na volledige herstart van de IB werkt het weer prima.
Met een ESU decoder heb ik hier nog nimmer last mee gehad.

Het heeft duidelijk met een afwijkend signaal te maken.

Mvg: Alex


Edit Frenkievee: merk Uhlenbrock aangepast, op het forum bij voorkeur de gewone merknaam gebruiken

Laurent,

Ik denk dat het aan je CS3 ligt, en wel aan het feit dat je van protocol gewisseld bent. Ik vermoed dat de CS3 beide protocollen nog uitstuurt, en de decoder daarop reageert.

Je zou nog eens dezelfde procedure kunnen herhalen (protocolwissel) waarbij je op het ene protocol het licht aan hebt staan en op het andere uit. Een herstart van de CS3 zou het dan in theorie op moeten lossen.

Erik

Hoi Erik,

dat denk ik ook. Ik heb gisteravond een backup gemaakt van de laatste situatie, een andere backup teruggezet en toen was het over. Toen voorzichtig geprobeerd de gemaakte backup ook weer terug te zetten en toen was het nog steeds over. Wat er dus precies aan de hand was, ik weet het niet. Het gekke is dat ik al eens herstart had met het CS. Zeker met de ESU decoder, was het al een paar keer gebeurt.

Hoi Alex,

Ik heb eigenlijk met Uhlenbrock nog nergens last van gehad. En de ESU was ook nieuw. Terwijl de Zimo in mijn RailJet, ook op adres 3, dus nergens last van had. En die bleef het ook doen na een herstart van het systeem. Ik had dus echt iets gewijzigd in het systeem of in de uitvoer vanuit het systeem Analoogherkenning uit zetten is wel een goede, ga ik eens doen bij het een en ander. En de Railjet ook op een ander adres gooien. Dat 3 wordt nu wel irritant.

Dank voor het meedenken.

Groet,
Laurent