OM32, OC32 and LichtOrgel

Posted by Leon van Perlo on 2011-12-18 18:43

Hans,

Ik vermoed dat het veroorzaakt wordt door stoorsignalen op de DCC bus waar de OC32 blijkbaar gevoeliger voor is dan sommige andere decoders. Je zult hier vooral last van hebben als je de DCC signalen aftapt achter de booster.

Theoretisch kun je die gevoeligheid voor storingen verminderen door het aanbrengen van een laagdoorlaatfilter. Dat kan door slechts 1 extra condensator aan te brengen tussen pin 1 van de DCC connector en pin 3 van de 6N137 (optocoupler). Bijgaande foto geeft aan waar die condensator moet zitten. De waarde dient 10nF..22nF te zijn en het type bij voorkeur een keramische multilayer.

Ik heb dit inmiddels getest en op de oscilloscoop geeft het het resultaat dat ik verwacht. Ik weet alleen niet of het in de praktijk ook het probleem vermindert of elimineert, want ik heb geen DCC baan die dergelijke stoorsignalen genereert.

Ik hoor graag of je in staat bent dit te testen.

Mvg,
Leon

Posted by Hans Kleton on 2011-12-18 20:49

Hoi Leon,

Ik ga eens kijken of ik zo'n condensatortje heb. Ik wist niet dat de baan zo stoorde, verdikkeme!
In de tussentijd heb ik wat testen gedaan met de plek waar ik de stroom vanaf haal voor de OC32, dit lijkt wel wat uit te maken. Direct vanaf de booster gaf een erg gelabberd resultaat, toen werd er zodra er 1 trein reed niets meer geschakeld.
Je hoort nog van me of het lukt met de condensator!

Groet,
Hans

Posted by Leon van Perlo on 2011-12-18 21:26

Hans,

Als je die condensator niet hebt stuur ik je er wel een.

De beste plek om je DCC signaal voor de OC32 af te tappen is voor de booster, maar dat moet dan wel kunnen.
Accessory paketten worden bij DCC niet herhaald, althans, voor zover ik uit de standaard kan lezen en ik het heb kunnen analyseren d.m.v. reverse engineering. Dat betekent m.i. dat het nooit volledig te garanderen is dat een pakket ontvangen wordt. Als het anders is hoor ik graag onderbouwd van een specialist hoe dat wel kan.

Mvg,
Leon

Posted by Hans Kleton on 2011-12-18 21:50

Hallo Leon,

Hier heb ik niets meer, wellicht dat er op werk nog wat is, al durf ik dat niet met 100% zekerheid te zeggen.
Mocht ik daar bot vangen, dan is opsturen een goede optie denk ik.

Net nog even direct aan de track uitgang van de Ecos aangesloten (baan los) Perfect reageren natuurlijk.
Hang ik de baan er weer aan, samen met de OC32 nog direct aan die uitgang, vergeet het maar. Ergens moet een mega stoorzender zitten.
In de afgelopen jaren is er heel wat aan gerommeld, ik denk dat ik er toch aan zal moeten om het uit te gaan zoeken.

Groet,
Hans

Posted by Hans Kleton on 2011-12-19 08:36

Leon,

Helaas, op werk niet de juiste kunnen vinden. Als je in de gelegenheid bent om er 1 op te sturen zou het geweldig zijn!

Gr,
Hans

Posted by Gerrit Schoenmaker on 2011-12-19 12:03

Beste Hans,

Heb hetzelfde probleem als jij dat de OC32 gekoppeld aan een ECoS centrale DCC opdrachten mist. Ben hierover al langere tijd in discussie met Leon. Wat ik constateer is het volgende:
Het missen van DCC opdrachten door de OC32 lijkt gerelateerd aan (en/en en niet en/of):
1. ECoS interface
2. Het hebben van zowel Sink als Source drivers op de OC32
3. Meer treinen tegelijk in bedrijf hebben

Een OC32 met alleen SINK drivers voor het aansturen van "USA Search light signals"doet in DCC mode prima zijn werk. Echter een OC32 uitgerust met 4 SINK drivers en 2 SOURCE drivers (de laatste voor het aansturen van 8 = 16 uitgangen Tortoise wisselmotoren) laat IN DCC aansturing steken vallen. De frequentie waarin fouten optreden is gerelateerd aan het aantal treinen dat tegelijk in bedrijf is. Ik heb een experiment gedaan waarin handmatig een wissel voortdurend werd omgezet terwijl een trein met samengestelde loks en 30 wagons (3 USA diesels gekoppeld) zijn rondjes draaide. Zodra de trein op een locatie in de baan kwam die extra trekkracht vereiste (in bijv. een bocht met 30 wagons) ging het mis en ging een direkt vanaf de ECoS centrale gegeven DCC opdracht voor de wisselomzetting de mist in.

Verder heb ik nog geprobeerd of de OC32 in DCC betrouwbaarder werkte door deze rechtstreeks op de programmeerspoor uitgang van de ECoS aan te sluiten. Dat bood wel enig soelaas maar toch kwamen de fouten nog steeds voor, zij het in een lagere frequentie. Ben er nog niet achter wat de stoorzender is. Commercieel verkrijgbare decoders blijken daarentegen geen last te hebben.Maar ik wil de OC32 vanwege zijn uitzonderlijke lage prijs per adres beslist niet kwijt. Waar vind je een decoder met de welhaast onbegrensde mogelijkheden van de OC32 die voor die prijs bijv. 16 wissels aanstuurt??????

Graag hoor ik of jij vergelijkbare ervaringen hebt, zodat we misschien er achter kunnen komen wat de oorzaak is van de storing (ECoS centrale????). In ieder geval ga ik het LOW PASS filter van Leon testen.

PS: De OC32 aangestuurd via de RS485 interface werkt feilloos. Maar dat vind ik geen optie, want dat betekent extra connecties tussen alle OC32 modules met twisted pair kabels en ook nog eens een RS485/USB verbinding met de computer. Dat houdt in dat een laptop nooit de vrijheid van alleen een WIFI verbinding met de ECoS centrale kan hebben omdat je altijd weer met die verdraaide RS485 kabel zit. Ik wil af van de ouderwetse seriele interface. DAT IS NIET MEER VAN DEZE TIJD.

Mvgr.
Gerrit Schoenmaker, Oldemarkt
Digitaal USA modelspoor aangestuurd met iTrain, BMD-16N-SD detectiemelders van Huib Maaskant en OC32 van Leon.

Posted by Hans Kleton on 2011-12-19 19:34

Hallo Gerrit,

Wat je omschrijft zijn inderdaad ook grotendeels mijn bevindingen.
OC32 is bij mij hetzelfde geconfigureerd, 4x sink, 2x source (uitgang 16-31)
Wanneer ik de programmeerspoor aansluiting gebruik, reageert de oc32 nergens op. Haal ik de TRACK aansluiting los, dan reageert hij weer wel via het programmeer spoor.
De baan is behoorlijk in electrische segmenten gebouwd, ik ga zolang ik nog geen condensator heb proberen om toch uit te sluiten of er vuiligheid op de baan gegenereerd wordt.

Qua prijs is de OC32 zeer zeker interessant, ik heb 9 LS150's onder de baan (6 aansluitingen) en langzamerhand gaan ze last van alzheimer krijgen lijkt het wel, dus als dit goed gaat zie ik nog een aantal oc32s komen.

Ben benieuwd naar jouw ervaringen met de condensator er bij!

Gr,
Hans

Posted by Hans Kleton on 2011-12-19 21:25

Een update met wel interessante bevindingen:

Ik heb de baan in segmenten los gehad van de boosters.
OC32 op programmeerspoor aansluiting van de Ecos gehad, met baan eraan deed hij niets.

• TRACK losgekoppeld, en OC32 doet het.
• Track weer aangekoppeld, circuit voor wisseldecoders los, nog steeds niet.
• Andere (ESU) booster los, 2/3 van de baan is dan spanningsloos: geen werkende OC32
• Voeding naar een aantal bezetmelders los gehaald die op de interne ecosbooster zitten: werkende OC32
• Andere booster er ook weer bij, nog altijd een werkende OC32
• Bezetmelders die loswaren weer erbij: geen werkende OC32
• Lenz keerlus detector die opgenomen was in dat circuit: geen werkende OC32
• Een viertal bezetmelders (4x 16) losgelaten, overige weer aangesloten (qua bedrading kwam dit zo uit): werkende OC32
• Eentje weer aangesloten: werkende OC32
• Laatste weer aangesloten: geen werkende OC32

Probleem dus kunnen achterhalen!
Nu is het zo dat die melder die los is, de aller alleroudste is die ik heb.
Deze melder heb ik nu los (hele schaduwstation op 1 spoortje na stroomloos), en ik heb een trein nu rondjes rijden via dat spoortje.
OC32 blijft netjes werken, tenzij (!) er een rijdende trein gevoed wordt een van de drie overige bezetmelders die in het groepje van 4 hoort.
Dan heeft de OC32 er geen zin in. Staat de trein stil in een sectie gevoed door die melder, dan werkt de OC32 wel goed.

TL;DR, een aantal melders storen blijkbaar, 1tje volledig, 1 andere alleen als er iets rijdt in zijn deel.

Nou hoop ik eerlijk gezegd dat het met de condensator opgelost is, anders zal ik 4 nieuwe melders moeten aanschaffen ter vervanging. Dan wordt het toch weer wel een dure grap.
Melders die het probleem veroorzaken zijn printjes met diodes, weerstandje en optocoupler, gekoppeld aan een losse echte S88

Gerrit, ben jij in de gelegenheid om ook op deze manier je baan te analyseren?

Groet,
Hans

Posted by Gerrit Schoenmaker on 2011-12-20 00:19

Hans,

Ook nog even aan het nadenken geslagen. En een oplossing gevonden voor mijn DCC instabiliteits problemen met de OC32 gekoppeld aan de ECoS centrale van ESU.
Ik heb mijn OC32 toch maar weer aan de programtrack uitgang gekoppeld, maar nu via een rechtstreekse verbinding gemaakt van een netwerk CAT5 kabel. De DCC aansluiting bestaat nu feitelijk uit twee draden die elk weer bestaan uit twee draden afkomstig van verschillende twisted pairs. De DCC voedings draden draaien dus om elkaar heen en vormen zo een goed afgeschermd geheel. Op het moemnet dat ik dit schrijf draait de testmodule nu 3.5 uur achter elkaar zonder storingen. Maar het LOW PASS filter ga ik ook testen om de zaak bullet proof te krijgen.

Conclusie: De OC32 werkt betrouwbaar via DCC en de ECoS indien aangesloten via een goed afgeschermde kabel (bijv. CAT5, twisted pair) op de programmeerspooruitgang van de centrale.

Wat de bezetmelders met terugmelding betreft, ik gebruik die van Huib Maaskant (S88 met netwerkinterface, zie http://www.floodland.nl/aim/). Deze werken hier storingsvrij en zijn verbonden door CAT5 kabels. Deze terugmelddecoders hebben een geintegreerde bezetmelding (stroomdetectie). Elke melder heeft 16 uitgangen die apart gevoed kunnen worden. Prima en goedkoop alternatief voor vele toch wel dure commerciele melders die vaak maar een functie hebben: detectie of terugmelding! In principe heb je voor je baan aan de OC32 en deze melders genoeg om alles aan te sturen (wissels, seinen, overwegen, relais, servo's, lichtreclames, etc.)

== INTERMEZZO =
Proefbaan bestaat uit een aantal modules van 60 cm breed en 1.60 m lang aan elkaar gekoppeld tot een grote ovaal van 6 x 1.6 m. Alles bedoeld om mijzelf wegwijs te maken in modelbouwers land. Als beginner moest ik mij orienteren en een keuze maken welk DCC-systeem ik zou aanschaffen. Dat het digitaal moest stond wel vast. Uiteindelijk gekozen voor de ECoS vanwege netwerk interface. Wat software betreft heb ik gekozen voor iTrain, omdat het geschreven is in JAVA en zowel in Server- als clientmode kan draaien. iTrain draait hier op verschillende laptops onder het besturingssysteem eComStation (moderne OS/2 van IBM, zie www.ecomstation.com). Alles wordt gevoed vanuit de standaard ECoS centrale. Dus geen extra losse boosters. Op de totale lengte van het spoor (ca 40 meter) geen stroom problemen geconstateerd bij het draaien met 6 locomotieven allen voorzien van geluidsdecoders. Al het rijdend materieel en scenery is uit de VS afkomstig (Atlas, Bachmann, Paragon/2, Proto 2000, Walthers, MTH, Athearn, Broadway Limited, KATO, BLMA, Woodland, etc.). Rails is USA track code 83 van PECO. Wisselaandrijving door de Tortoise wisselmotor van Circuitron
======

Posted by Hans Kleton on 2011-12-20 15:59

Hoi,

Vanavond of morgenavond ga ik verder.
Kan wel melden, dat de melders die GEEN storing veroorzaken, het de melders van Huub en Wim Ros zijn (4x Huub, 2x Wim). Op de melders van Huub zitten diode bruggen, op die van Wim gelijkrichters. Beide werken dus goed.
De diodes die ik op de print van Huub heb gezet, zijn hetzelfde als die op de eigenbouw printjes die dus wel een storing geven. (1N4001 zo uit mijn hoofd) Nou ben ik erg geneigd om te gaan twijfelen aan de kwaliteit van die op strokenprint gemaakte melders. Blijkbaar stoort daar het een en ander.
Hopelijk helpt het filter, dat is even wachten op het condensatortje.

Gr,
Hans

Posted by Hans Kleton on 2011-12-24 11:17

Hoi Leon,

Vandaag de condensatortjes ontvangen, dank!
Meteen ééntje aangesloten zoals op jouw foto.(zie super slechte foto) en getest.
OC32 reageert nu totaal niet meer op DCC , ook niet als hij het enige apparaat is wat op de centrale is aangesloten.
Condensator weer verwijdert van de print, en wel weer reageren, zij het op dezelfde manier als voorheen.
Komende dagen ga ik maar verder met uitsluiten en uitzoeken wat er nou exact stoort.

Groet, en fijne kerstdagen!

Posted by Leon van Perlo on 2011-12-24 13:51

Hans,

Dan weet ik niet wat er bij jou anders is.
Bij mij werkt het, zowel met Intellibox, op de Loconet uitgang, de booster uitgang en de "gleis" uitgang als met een SPROGII, zelfs met een nog grotere condensator.
Ik begreep trouwens van Gerrit dat het bij hem ook werkt met condensator.

Mvg,
Leon

Posted by Hans Kleton on 2011-12-24 17:45

Leon,

Ik heb net de andere condensator aangesloten, nu werkt het weer wel!
Nog helemaal opgelost is het niet, er is wel een aanzienlijke verbetering merkbaar.
De 100% mis is er niet meer, ik denk dat dat nu minder dan 25% (misschien zelfs

Posted by Leon van Perlo on 2011-12-24 19:50

Hans,

Ik geloof er eerlijk gezegd niet zo in dat de ene condensator wel werkt en de andere niet. Het is een passief component en en de waarde is slechts een richtlijn, dus het wil er bij mij niet in dat dat zelfs maar bij benadering kritisch is.
Als het zo is dat het in het ene geval "toevallig" wel werkt en in het andere "toevallig" niet, dan ben ik toch echt geneigd te denken dat er iets anders aan de hand is.

Mvg,
Leon

Posted by Hans Kleton on 2011-12-24 20:33

Dat ben ik helemaal met je eens!
Morgen weer een dag, wellicht dat ik ze nog even omwissel.

Posted by Gerrit Schoenmaker on 2011-12-26 12:39

Beste Hans & Leon,

Hier Oldemarkt en mijn bevindingen met de OC32 en de ECoS na aanbrengen van het condensator filter op de DCC ingang van de OC32. Twee waarden voor condensators (keramische multilayer) getest: 10 en 22 nF. DCC signaal heel grof gewoon afgetapt van de track om de test wat kritischer te maken.
Bij de waarde van 10 ging het toch af en toe nog mis, met een waarde van 22 heb ik geen DCC missers meer geconstateerd (3 uur onafgebroken rijden met 6 treinen). Wanneer ik de OC32 met een afgeschermde kabel rechtstreeks op de program trak uitgang aansluit voldoet 10 nF waarschijnlijk prima of is zelfs helemaal geen filter nodig.
Maar ik vind het prima zo, de waarde van 22 nF voldoet dus in "the worsed case" en maakt in mijn geval de OC32 inzetbaar ongeacht de wijze waarop ik hem/haar aansluit (vrouwelijk lijkt mij op wel op z'n plaats omdat ze nogal gevoelig blijkt te zijn).

Prettig uiteinde en een goed begin gewenst.

Mvgr.
Gerrit Schoenmaker

Oh ja, Leon bedankt voor het opsturen van de condensators.

Posted by Hans Kleton on 2011-12-26 15:09

Beste Leon en Gerrit,

Mooi dat het nu weg is!
Hier heb ik nog wel wat problemen helaas, en ben weer wat verder met uitzoeken. Mijn verdenking van de bezetmelders is niet correct geweest. Toevalligheid wil dat de interne booster van de Ecos alleen die melders heeft, en de extra esu booster de nieuwe melders.
Sluit ik de OC32 aan op die extra booster, verhuist het probleem vrolijk mee.

In het kort (storing betekend nu: af en toe een mis):

• OC32 aangesloten op booster1, en trein rijden in booster1 deel: storing. Trein rijdt in booster 2 deel, geen storing.
• OC32 aangesloten op booster2, en trein rijden in booster2 deel: storing. Trein rijdt in booster 1 deel, geen storing.
• OC32 aangesloten op booster1, volledige baan op booster2: geen storing.
• OC32 aangesloten op booster2, volledige baan op booster1: geen storing.
• OC32 aangesloten op programmeeruitgang met UTP, af en toe een mis wanneer er in interne booster deel gereden wordt.

Ik heb ook nog m'n delta booster geprobeerd als enige booster voor de oc32, maar dat werkt helemaal niet, oc32 geeft niet thuis.
De deltabooster wordt aangesloten op de track-out, en boost dat. En dus vermoedelijk het stukje waar de OC32 op hikt wordt ook versterkt.

Het missen van de opdrachten is met de condensator bijna helemaal weg, maar nog net niet helemaal om een 100% werking te garanderen.
De overige wisseldecoders (14 stuks, mix van LS150 en LDT's) hebben nergens last van.

Groet,
Hans

Posted by Leon van Perlo on 2011-12-26 23:50

Hallo Hans,

Mijn stelling in het algemeen is dat accessory decoders nooit betrouwbaar kunnen werken als je ze aansluit na een booster. De motivatie daarachter is dat het nooit te garanderen is dat er geen kortsluiting op de rails optreedt. Kortsluiting = signaal weg en als de centrale op dat moment een DCC accessory commando stuurt wordt dat niet ontvangen, welke error correctie je ook toepast. Aangezien accessory commando's niet herhaald worden werkt dit m.i. per definitie onbetrouwbaar.

Wellicht is de DCC fouttolerantie in de OC32 nog wat verder te verbeteren en ik zal daar komende tijd nog wel eens induiken, maar heel eerlijk gezegd geef ik daar op dit moment niet de prioriteit aan.
Wat je zelf nog zou kunnen proberen is de capaciteit van de filtercondensator nog eens verdubbelen. Dat kan simpel door er 2 parallel te zetten (je hebt er 2, dus dat zou moeten lukken).

Ongeacht of dat beter werkt is mijn advies is om een voldoende betrouwbare bron van DCC signalen te kiezen.

Overigens ben ik wel erg benieuwd waarom je eerder met condensator helemaal geen respons meer kreeg.

Mvg,
Leon