Dcc Decoder werkt wel op LENZ maar niet op TWINCENTRE

[Nick1950]

Hallo allemaal,
Ik heb een DCC Decoder ontwikkeld voor wissels en seinen op basis van een AT89C2051.
Je kan het schema e.d. vinden op mijn site.

http://home.hccnet.nl/n.goes/

Omdat ik dit project niet voor mijzelf wilde houden heb ik het gepubliceerd via mijn website. Er zitten nogal wat uren ontwikkeling in dus ik dacht dit project voor andere digitale rijders beschikbaar te stellen.

Zelf werk ik met LENZ en en de DCC Decoder functioneert zonder mankeren.
Ook werkt hij goed met de Intellibox van Uhlenbrock.
Maar met het Twincentre van Fleischmann en de Multimaus van ROCO gaat het niet.

Ik vermoed dat er wellicht verschillen zijn binnne het DCC Format. Tolleranties in timing van de seriele data of zo....

Weet iemand van jullie wat hiervan de oorzaak kan zijn?

Groet Nico

[Hans Keulen]

Uiterst vreemd Nico. Ik neem aan dat je decoder voldoet aan de timing normen in de NEM670 '?
(zie www.morop.org)


D.w.z. :
1 bit is 58 microseconden plus of min 6 microseconden
0 bit is 100 microseconden. Decoder moet bit als nul herkennen tussen 90 en 10000 mikroseconden.

Ik heb even mijn IB en multimaus op de scope gezet. Daar zie ik geen meetbaar verschil.

hans

[piksov]

Leuk hoor die multi-protocol centrales, maar als je niet goed oplet, laat je je soms foppen.

Het is mij ook wel eens overkomen dat mijn decoders het niet doet ...

Wat blijkt dan? Dan heb ik weer een adres gekozen wat niet op het DCC formaat staat ingesteld maar op FMZ (in geval van mijn TWIN-CENTER)

Check even je formaat ....

TWIN-CENTER werkt goed samen met de OPENDCC decoders....

Guus

[Hans Keulen]

Guus,

Nivco geeft aan dat zijn decoder het doet op Lenz (= puur DCC) maar niet op Roco Multimaus (= puur DCC). Hij heeft dus niet alleen een instellingsprobleem.

Hans

[Dave van der Locht]

Zoals Guus aangaf kan inderdaad het multi-protocol gebeuren wel eens roet in 't eten gooien.

Ook is het uiterst belangrijk de specificaties van de NMRA exact in acht te nemen. Niet elke centrale stuurt exact het zelfde DCC signaal uit, daar zitten (zeer kleine) afwijkingen in. Waardoor je dus een bepaalde tolerantie moet inbakken in je decoder (zie NMRA specs).

Een dergelijk probleem heb ik zelf ook gehad met mijn zelfbouw decoders. Er zijn diverse oorzaken mogelijk, maar het begint i.i.g. met het 100% nauwkeurig in acht nemen van de NMRA specificaties en zeker weten dat je een DCC decoder aanstuurt vanuit de centrale.

Groetjes,
Dave

[piksov]

En dan is er nog gedoe met de dcc adressen op een ibox (tc is een afgeleide van de ibox)

Hoe het precies in elkaar steekt weet ik niet meer precies maar blijkbaar worden adressen soms verschoven. Blijkbaar is de dcc spec. hier anders te interpreteren.

Om dit zeker te weten zou ik het programmaatje ShowDCC downloaden (even googlen op showdcc). Met 3 weerstandjes en 2 diodes kun je dan je dcc signaal naar de microfoon ingang van je geluidskaart voeren. Met ShowDCC kun je dan precies zien welke info op de rails gezet wordt.

Adressen e.d. kun je dan controlleren.

(met dank aan Dave vd Locht die mij een tijdje geleden op dit tool wees)

[Nick1950]

Hallo beste mensen,

Hartelijk dank voor jullie reacties. Het is toch een specifiek terrein en dan toch al reacties.

Ik heb de NMRA specs tijdens het ontwikkelen wel aangehouden. Maar ik ga toch eens met de hardware aan de gang of dat ook werkelijk zo is.
Dat gedoe met multi-protocol heb ik ook wel voor ogen, maar ik ben er nooit bij als men de decoder na het bouwen uiteindelijk gaat testen.
Onlangs had ik aan iemand een door mij zelf gebouwde decoder opgestuurd om eerst maar eens te testen. Op een TC. Hij had al meerdere decoders in gebruik. Maar geen resultaat met mijn decoder.

Een week later stuur ik dezelfde decoder naar iemand met een IBox en alles werkt perfect.

Ik had ook het idee dat de TC en IBox uit dezelfde fabriek komen.


Ik heb zelf niet al die systemen in huis, dus kan het niet testen.
Als een van jullie mijn decoder eens willen testen, hou ik me aanbevolen.

Tot zover 
Nico
Have a nice day
 

[piksov]

ik heb een TWIN-CENTER en OPENDCC, ik wil wel e.e.a. voor je testen

[Nick1950]

Beste Piksov,

Als je wilt testen stel ik dat zeer op prijs.
Ik heb ook even je website bekeken. Leuk project dat OPEN DCC.

Stuur me je adres en dan zal ik volgende week een exemplaar opsturen.

Groetjes Nico

[piksov]

Gevonden!!!

bron: http://www.opendcc.de/modell/opendcc/opendcc_sw.html


Beispiel 2: Weichenansteuerung per DCC
Es wird ein Befehl mit 3 Byte geschickt:
Preamble Startbit  Adressbyte 10AAAAAA
         Startbit  Datenbyte  1AAA1BBR
         Startbit  Prüfsumme
         Stopbit

Dabei bedeutet im Adressbyte AAAAAA [A5 .. A0] und im Datenbyte AAA [A8 .. A6], wobei die Adressen A8 bis A6 invertiert übertragen werden. BB ist die lokale Adresse am Decoder (0,1,2,3), R ist das Outputbit, d.h. welche Spule aktiviert werden soll. In der Zentrale wird nun z.B. aus der von PC übermittelten Adressen wie folgt das DCC-Telegramm zusammengebaut:
   Adressbyte = 0x80 + (adresse & 0x3F);
   Datenbyte  = 0x80 + (adresse / 0x40) ^ 0x07) * 0x10;
   Prüfsumme  = Adressbyte ^ Datenbyte;

Die Adresse 0 ist als Broadcast reserviert, so dass die erste Weichengruppe bei Adresse 1 liegt. Leider gibt es bei den PC-Protokollen der einzelen Zentralen kleine, aber störende Unterschiede im Adressbereich und in der Interpretation des Outputbits sowie des Activatebits (im obigen Beispiel die 1).

Uhlenbrock (Intellibox) beschreibt wie folgt (und überträgt auch so):
'r' (red = thrown) and ('r' may also be spec'd as '0')
'g' (green = closed) and ('r' may also be spec'd as '1')
Der Adressbereich in der PC Schnittstelle beginnt dagegen entgegen der Dokumentation bei 1. Das heißt, der erste Decoder liegt auf Adressen 1 ... 4; Die Intellibox sendet auch nie den Abschaltbefehl auf das Gleis, auch wenn dieser vom PC aus angefordert wird.

Lenz beschreibt das Richtungsbit als D2 mit folgendem Text:
D2: D2 = 0 bedeutet Ausgang 1 der Weiche gewählt.
     D2 = 1 bedeutet Ausgang 2 der Weiche gewählt.

Allerdings läßt es sich nirgends rausfinden, was Ausgang 1 oder 2 bedeutet. An Hand eines Logfiles scheint rot und grün vertauscht zu sein. OpenDCC bildet diese Invertierung (abschaltbar) durch eine CV nach.
Dafür beginnen die Weichenadressen bei Lenz bei der Adresse 0 und den Abschaltbefehl gibt es.

[Wim Ros]

En wat wil je hier nu precies mee zeggen??
Want volgens mij staan hier een paar halve waarheden in.

Mvg
Wim.

[Hans Keulen]

Piksov,

Ik snap, net als Wim, niet wat je hiermee wil zeggen. Nog afgezien van de aard van analyse.
Nico geeft aan dat zijn decoders WEL werken op Lenz en IB (die hier worden vergeleken) en NIET op TC (IB kloon met andere firmware) en Roco Multimaus (puur DCC).

Hans

P.S. Nico, als je een multimaus wil hebben om te testen dan valt dat te regelen.

[Nick1950]

Hans,

dat is een geweldig aanbod. Daar wil ik graag gebruik van maken.

Wat Piksov wil zeggen is dat de adressen met 1 verschoven zijn.

Nico

Overigens dank aan allen voor jullie reacties en medewerking.

[Wim Ros]

De wisseladressen zijn niet met 1 verschoven.

Wissel nummer 1 op mijn LS100 is bediend met de IB als mijn wisselnummer 1 op mijn Lenz Set.

Wat daar staat te lezen is wat je via een software programma moet uitzenden via het P50Xa of P50Xb interface protocol, maar dat is heel iets anders dan het uiteindelijke protocol wat de IB of de TC op de rails zet.

De Intellibox en het Twin-Center zijn aan elkaar gelijk, dus als je decoder wel op de Intellibox werkt, dan werlkt hij ook op het Twin-Center, er is namelijk geen enkel verschil.

Bij de Multi-Maus daar integen zijn de wisseladressen wel verschoven en wel met een factor 4, dus dat het daar niet werkt kan kloppen, maar alleen omdat je het verkeerde wisseladres zend.
Als dat juist is zal ook de Multi-Maus werken met jouw decoder.

Mvg
Wim.

[Nick1950]

Wim,

Dat zou betekenen dat als ik bijvoorbeeld de groep wissels 5,6,7,8 wil aansturen ik op de multimaus wissel nummer 1,2,3,4 of 9,10,11,12 moet gebruiken???

Verschuiven omhoog of naar beneden???

Nico