decoders reageren niet op signaal van DR5000

[Karst Drenth]

Yep

[olifant58]

Hallo allemaal,

Even een update:
Ik heb inmiddels de DR5000 op 19V dc gezet.
Daarnaast heb ik een aparte verdeellijn gemaakt om de decoders te voeden met 15V dc.

Wat blijkt: Het werkt. Het was nog wel een item om alle aansluitingen dezelfde polarisatie te geven, anders werkte het niet.
Iedereen bedankt voor jullie meedenken en tips.
Toch wel leuk de discussie over Railcom en de technische achtergronden. Ik heb weer bijgeleerd 

Tot slot een spoorse groet,
Fred

[VvKan]

Zo worden we allemaal wat wijzer 

Maar begrijp ik het uit jouw woorden goed, dat het met name de polarisatie van de aansluitdraden betrof ?  Oftewel het inmiddels welbekende probleem met RailCom ?

[olifant58]

@ Veroniek:
Met de polarisatie bedoel ik dat alle draden vanuit de dr5000 op de zelfde wijze aangesloten op de DCC aansluiting en de voeding alle +en op de zelfde plek op de power aansluiting in de decoders moeten.

Doe je dat niet, dan doen de de decoders het niet.
Toen ik daar achter was, was het fluitje van een cent. Alle decoders reageren nu perfect op de commando's vanuit de app van Digikeijs op de pc.

Groet Fred

[Klaas Zondervan]

Ik denk idd ook om de reden die Veroniek noemt: Compatibility.

Overigens wordt er momenteel binnen de europese fabrikantengroep "RailCommunity.org" driftig nagedacht over de zin en onzin van het huidige DCC protocol.
Met name het "dubbel" verzenden van elk bit ( om de boel symmetrisch te houden ) staat ter discussie

Dat bedoel ik. Het idee van pulssymmetrie zou je overboord kunnen zetten. Elk bit enkel verzenden. De decoder kijkt dan alleen nog maar naar de pulslengte, ongeacht de polariteit.
Het voordeel is dat het protocol twee keer zo snel wordt. Het nadeel is dat de huidige decoders het niet meer snappen.
Je krijgt dan feitelijk een nieuw protocol.

[VvKan]

Doe je dat niet, dan doen de de decoders het niet.

En als je nou de DCC aansluiting op alle decoders omwisselt (als test), wat gebeurt er dan ?
Als de decoders wel met RailCom kunnen omgaan zou dat geen verschil mogen maken.  Als het niet meer werkt, ziedaar de oorzaak.

Overigens vind ik het een vreemde zaak.  Ik kan zelf de decoders hier aansluiten zoals ik wil.  Afgezien van het RailCom gedeelte geldt dat ook voor de externe voeding met wisselspanning.  Maakt niks uit.   Behalve in heel specifieke situaties, omdat (bij de Lenz LS150 in ieder geval) 1 pool van de wisselstroom rechtstreeks is doorverbonden met de gemeenschappelijke uitgang. Wil je dan dus iets bedienen wat aan de andere kant ook die pool heeft, dan gebeurt er dus niks.  Even 1 draadje omwisselen, klaar.

[spock]

Dus toch railcom

Mvg spock

[olifant58]

Sorry Veroniek,

Ik heb het uitgeprobeerd:

Als ik op 1 decoder twee draadjes ( het DCC signaal) omwissel, dan weigeren alle decoders dienst.

Zet ik ze weer op de wijze, zoals de andere aangesloten zijn, doen ze allemaal weer goed.

Ra, ra politiepet?
Misschien kunnen de techneuten hier op het forum dit verklaren?

Maar, met alle respect! Ik hou me voortaan gewoon aan de regel: op alle decoders op dezelfde manier aansluiten.

Groet Fred

[Patrick Smout]

Dat bedoel ik. Het idee van pulssymmetrie zou je overboord kunnen zetten. Elk bit enkel verzenden. De decoder kijkt dan alleen nog maar naar de pulslengte, ongeacht de polariteit.
Het voordeel is dat het protocol twee keer zo snel wordt. Het nadeel is dat de huidige decoders het niet meer snappen.
Je krijgt dan feitelijk een nieuw protocol.

En als de compatibiliteit op.de schop gaat kan je ook ineens de bitrate met een faxtor x opschroeven. Huidige microcontrollers kunnen daar nu prima mee overweg en korte bursts hebben meer kans om ongeschonden overgedragen te worden.
De bitencoding en bitrate hebben wel een invloed op de radiated emissie wat dus een aandachtspunt is als je daar aan gaat sleutelen.

[Klaas Zondervan]

En als de compatibiliteit op.de schop gaat kan je ook ineens de bitrate met een faxtor x opschroeven.

De microcontrollers kunnen daar wel mee overweg, maar kan het netwerk dat ook? Ik heb metingen gedaan met een blokgolf van 20 kHz, en op een paar meter van de bron en met belastingen op diverse plekken begint het signaal behoorlijk te vervormen. Het is dan lang niet meer zo'n strakke blokgolf die je op de plaatjes ziet.
Dus hoe ver zou je kunnen gaan zonder dat de blokgolf zo is vervormd dat de decoders het niet meer snappen?

[Patrick Smout]

Zou inderdaad best kunnen dat er ook aan boosters gesleuteld moet worden. Het feit dat de steile flanken uit de blokgolf zijn is op zich positief voor de uitstraling maar idd. moet het signaal nog herkenbaar zijn. Met een aangepaste eindtrap die voldoende stroom kan leveren om de buscapaciteit te overwinnen tijdens het schakelen zal het signaal er beter uitzien echter minder goed voor de uitstraling.
Geen idee hoe mijn lenz boosters het doen. Ik zal er bij gelegenheid eens op meten

[Karst Drenth]

Daar zit ook 1 van de problemen, maar ook bij de microcontrollers. Als je een DCC2.0 wilt introduceren, zul je ook een modus moeten bedenken waarbij je dus binnen DCC multiprotocol wordt.
Nu kunnen moderen microcontrollers wel met een (iets) hogere bit-rate overweg, maar de oudere zullen continue in de stress schieten als ze veel sneller dan een 58us puls aangeboden krijgen.

En... tegenwoordige H-bruggen met een beetje vermogen, kappen er ook vanaf zo'n 20 kHz mee.

Dus voldoende stof om goed over na te denken
Grtzz,
Karst

[Patrick Smout]

Over de schakelfrequentie van de H bruggen maak ik me niet zoveel zorgen maar alles komt natuurlijk met zijn prijs  .
Tot een nieuwe standaard voor een 2.0 komen lijkt me dan nog de grootste uitdaging. Wat neem je wel/niet mee iin dergelijk verhaal, hoe compatibel willen we blijven. Dat gaat m.i. ook de nodige doorlooptijd kosten ( in intussen worden de microcontrollers sneller en de H-bruggen beter en goedkoper  )