BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: Nullem op 03 september 2018, 15:30:02
-
Even een vraag van een absolute digibeet aan de specialisten hier:
Ik heb de adressen van mijn wisselaandrijvingen geprogrammeerd met een IB II. Onder de IB II doen de wissels het allemaal perfect. Nu wil ik de IB II voor een ander projectje inzetten: deze heb ik dus ontkoppeld van de baan en daarvoor in de plaats de (oude) IB neergezet. Tot mijn verbazing schakelt er geen wissel meer. Adressen zouden toch, net als in een locomotief, in de wisseldecoder moeten vastliggen? Het gaat om digitale Cobalt aandrijvingen, de IB (softwareversie 1.500) staat keurig op DCC (net als de IB II). Of vergis ik me en moet ik daadwerkelijk alle wissels opnieuw programmeren??
Dank voor jullie hulp, Frans
-
Adressen zitten inderdaad in de decoder. Waar jij door gebeten wordt is waarschijnlijk het protocol. Let op, dit kun je op twee plekken instellen. Algemeen, wat gebruikt wordt voor nieuwe adressen, maar ook per adres. Je kunt algemeen dus wel op DCC hebben staan maar het adres nog steeds als MM aansturen. Even controleren of je op de oude werkelijk DCC gebruikte op alle adressen en of je IB dat ook doet.
Timo
-
Ha Timo,
Dank voor je reactie. Ik ben in ieder geval al blij dat ik het basisprincipe van adressen toch goed begrepen heb. Ik heb het nagekeken, maar zowel de algemene instelling als de instellingen per adres staan op DCC. Ik zie het displaytje op de IB keurig bewegen, maar er schakelt geen wissel. Als ik de IB II terughang werkt alles weer perfect. Het blijft dus vooralsnog een raadsel.
Groet! Frans
-
Beetje domme vraag misschien, maar is die IB niet gewoon stuk? Bestuur je er ook treinen mee, en doen die het wel?
-
Treinen rijden met beide boxen perfect, da's het merkwaardige. Maar hij kan natuurlijk altijd nog een beetje stuk zijn: Daarom wilde ik eerst de kenners hier horen, zodat ik niets over het hoofd zie.
Ik kan eens proberen of zo'n digitale Cobalt wel een adres laat instellen via de IB, op dezelfde manier als bij de IB II. Als hij dat niet doet lijkt er toch iets mis te zijn; als hij dat wel doet heb ik een ander probleem, vrees ik.....
-
Hoi Frans,
De basis heb je inderdaad goed ;) Maar welk van de twee heb je nu gecontroleerd? Want dit kan je (volgens mij) in beide instellen.
Timo
-
@ Timo, bedankt weer voor je reactie.
Ik heb zowel de algemene instellingen (handboek 3.5 pag. 37) als de enkele instellingen (3.5.2, pag. 38) ingesteld op DCC en gecontroleerd. Alles zou dus DCC moeten zijn.
Daarnaast heb ik een testje gedaan:
Een Cobalt motor heb ik met de IB II op adres 1 geprogrammeerd. Die werkt daarna zoals verwacht als een tiet op de IB II. Vervolgens aangesloten op de IB: dan ik kan de knoppen van adres 1 indrukken wat ik wil, er gebeurt niets.
Als volgende stap heb ik dezelfde motor op exact dezelfde wijze geprogrammeerd met de IB, nu op adres 2. Vervolgens kan ik adres 2 intikken wat ik wil, er gebeurt niets. Sluit ik de motor weer aan op de IB II, dan wordt adres 2 niet herkend en werkt de motor nog steeds uitstekend op adres 1.
Ik begin me dus zo langzamerhand af te vragen of Klaas niet gelijk heeft: zou er iets mis kunnen zijn met de keyboard mode? (Loks rijden namelijk wel.) Ik hoor graag of jullie het met me eens zijn, of dat ik nog andere zaken kan testen.
Groet! Frans
-
Bij het programmeren: Op het hoofdspoor of aan het programmeerspoor? Maar het is wel gek dat je een decoder niet zowel op de IB als IBII direct via het adres kan benaderen. Defect denk ik zo niet. Zeker niet als je treintjes op alle twee de boxen rijden. Dan zit er signaal op de baan.
Groet Ronald.
-
Hoi Frans,
Wat ik met beide bedoel is beide centrales ;) Ik krijg namelijk sterk het vermoeden dat de IB niet op DCC staat. Dat zou ook verklaren waarom de decoder ook geen nieuw adres aan neemt.
Ander, minder voor de hand liggend, zou de schakeltijd kunnen zijn. Misschien vind de Cobalt een hele korte puls geen bekrachtiging. Maar dat lijkt me wat ver gezocht, zou eerder zeggen dat het protocol op de IB niet op DCC staat.
Timo
-
Ha Timo,
Beide centrales staan zowel voor de treinen als de wissels op DCC ingesteld. Bij de IB II werkt alles probleemloos.
In de IB zie ik overal waar dat zichtbaar is (dus ook bij de wisselinstellingen) het sterretje achter DCC staan. (Voor de loks is dat DCC28.) Nergens staat een tekst Motorola of zo. De schakeltijd (die op 10 msec. stond) heb ik ook al hoger gezet, maar dat heeft geen effect. Ook heb ik een reset van de wisselinstellingen doorgevoerd, zonder resultaat. Kortom, ik weet het even niet meer. Misschien moet ik Uhlenbrock maar eens een mailtje sturen?
Groet! Frans
-
Hoe hoog staat de pulstijd nu?
-
Hoi Frans,
Even wat "gekke" vragen:
- Je gaat naar keyboard mode met de [mode]-toets?
- Adres stel je in (via de [menu]-toets) en je zet hem niet op 0 (wat weer gekke dingen doet).
- General type staat op DCC? ([menu] [mode] => Accessory (decoder) setting => General type => DCC => [enter])
- Single type voor laten we zeggen, adres 1, staat op DCC? ([menu] [mode] => Accessory (decoder) setting => Single type => 1 => DCC => [enter])
- Hoe heb je de decoder aan de centrale aangesloten? Ook de optie om hem eens direct op de uitgang aan te sluiten?
Timo
-
@Henk:
pulstijd staat standaard op 10 msec., ik heb 50, 100 en 500 msec. geprobeerd.
@Timo,
Ik heb inderdaad alles gedaan wat je beschrijft: van 0...TAB ben ik afgebleven. Het boven beschreven experiment met de Cobalt motor is rechtstreeks aan de centrale uitgevoerd.
Groet! Frans
-
Mm, dan hebben we het meeste wel uitgesloten denk ik :-\
Heb je toevallig nog een (DCC) decoder van een ander merk liggen?
Timo
-
ik weet nog een onderzoeksmethode. Neem een koptelefoon en sluit die aan op de digitale spanning. Niet rechtstreeks, want dan blaas je de koptelefoon op, maar met een serieweerstand van 10k of zoiets. Daarmee kan je het digitale signaal horen. In rust is dat een eentonig steeds herhalend riedeltje. Dus even niks aansturen en een poosje luisteren om aan de "melodie" te wennen. Stuur dan het wissel aan en luister of er iets (kortstondig) verandert. Zo kan je bepalen of je IB de boodschap daadwerkelijk uitzendt.
-
Het idee van Klaas is te leuk en te origineel om niet te proberen, dus dat ga ik zeker nog eens doen......
Maar voorlopig helpt de suggestie van Timo weer iets verder. Ik had nog een oude Lenz LS110 liggen en heb daar een Peco spoeltje aangehangen: wie schetst mijn verbazing toen bleek dat dit ding probleemloos werkt op de IB (en natuurlijk ook op de IB II).
Dus: Lenz werkt op allebei, Cobalt vertikt het op de IB. Het lijkt er op of Cobalt niet als DCC herkend wordt op de IB.
Grote vraag: wat nu?
Groet! Frans
-
Weet je zeker dat je op de track-uitgang zit en niet op de programmeerspoor-uitgang?
En zou je de twee voedings-aansluitingen op de cobalt eens om kunnen wisselen? Ik heb vaker decoders gehad die niet werkten toen de aansluitingen verwisseld waren...
-
Ha Erik,
Ik zit 100% zeker niet op het programmeerspoor en de voedingsaansluitingen zijn ook al eens gewisseld, dus daar zit de oorzaak zeker niet.
Groet! Frans
-
Volgens mij is het nu tijd om het trucje van Klaas te proberen. Er zijn namelijk twee mogelijkheden:
1. De IB verzendt geen opdracht. In dat geval hoor je de verandering niet waar Klaas het over heeft. Probleem zit dan ergens in de IB.
2. De IB verzendt wel een opdracht want je kunt de verandering horen, maar de Cobalt reageert niet.
Dat laatste levert weer twee mogelijkheden op, namelijk dat de IB niet het juiste commando met het juiste adres verstuurt, of dat hij dat wel goed doet maar dat er een onnauwkeurigheid in het DCC signaal zit waar de Cobalt niet tegen kan en de Lenz wel.
-
Dirk, lees even reactie #15. Frans heeft het met een andere decoder met wisselspoel geprobeerd en dat werkt wel. De centrale zendt dus het goede commando uit. Blijft er volgens mij nog maar 1 optie over: de Cobalt is te kritisch op de timing van de pulsen.
Niettemin is het altijd leuk om met een koptelefoon naar de digitale "muziek" te luisteren. Misschien heb je in de oertijd wel eens meegemaakt dat er computerprogramma's via de radio werden uitgezonden. Ik dacht dat dat in Hobbyscoop was. Zo klinkt de digitale spanning ook ongeveer.
-
Klaas, dat is precies wat ik verwacht. Overigens vertelt Frans niet of hij de Lenz en de Cobalt op hetzelfde adres heeft aangestuurd. En ik heb teveel bijzonders meegemaakt om wat dan ook aan te nemen ;D
-
@Dirk:
Zowel de Lenz als de Cobalt(s) getest op adres 1 en adres 5 op de IB en op de IB II: dus ja.
Wat ik me begin af te vragen is of het probleem in de (nogal verouderde) software van de IB kan zitten: die is nog zo'n beetje uit het jaar kruik heb ik de indruk. Uhlenbrock schijnt een upgrade CD van 29 euro te verkopen: zou het zinvol zijn deze upgrade uit te voeren en dan nog eens te testen? Of hoef ik daar niets van te verwachten?
Ik zal in ieder geval een mailtje sturen naar Cobalt en Uhlenbrock of zij het probleem herkennen: op het internet heb ik er nog niets over gevonden.
Groet! Frans
-
Wellicht iemand in de buurt met een centrale die je ook kan helpen?
-
inmiddels de eerste antwoorden van zowel Uhlenbrock als DCC Concepts (van de Cobalt motoren) binnen. Ik moet zeggen: van beide perfecte service, zulke snelle reacties binnen één dag. Jammer genoeg lossen ze het probleem (nog) niet op. Maar we houden vol!
Uhlenbrock:
Dann könnten eventuell etwas mehr Preambel Bits im DCC-Paket bei der IB-1 helfen. Stellen Sie dazu die Sonderoption 904 = 32 oder 34 oder 36 oder 38 oder max. 40. Also immer nur in Zweierschritten erhöhen.Der Wert 28 ist Werkseinstellung.
Ik heb ze allemaal geprobeerd en het heeft geen effect. Benieuwd wat het antwoord van Uhlenbrock hierop gaat worden.
DCC Concepts:
I think it might be the way that some earlier DCC systems ex europe count accessory numbers. They use an earlier approach that also accommodated Marklin Motorola. There will be an offset of 4. See this Z21 PDF - the problem is probably exactly the same. https://www.dccconcepts.com/manual/an-alert-regarding-roco-z21-accessory-addressing-problems/ (https://www.dccconcepts.com/manual/an-alert-regarding-roco-z21-accessory-addressing-problems/).
Ik moet zeggen dat het verhaal al wat complexer wordt voor mij, maar volgens mij zit daar niet de oplossing in. Als ik het verhaal goed begrijp zit er een verschil in adresnummers. Aangezien mijn wissels doorgenummerd zijn van 1 tot en met 25, zou ik dus steeds andere wissels dan bedoeld moeten zien bewegen en er beweegt niets. Bovendien verschillen de adressen van Lenz wisseldecoders tussen de IB II en de IB niet. Ik zal dit terug melden aan de firma.
Een ervaringsdeskundige uit Eindhoven vermoedt dat het probleem wel eens zou kunnen zitten in de stabiliteit van het uitgestuurde digitale signaal: die stabiliteit schijnt bij de IB beduidend minder te zijn dan bij de latere IB II. Mogelijk dat de decoder van Cobalt daar (te) gevoelig voor is. Dan heeft een software update dus in ieder geval geen zin.
Wordt vervolgd, ik blijf benieuwd naar ideeën hier....
-
Hoi,
Lees dit verhaal eens: Mijn Intellibox 2 heeft GEEN symmetrisch dcc-signaal!! (https://forum.beneluxspoor.net/index.php?topic=66777.0). Gaat ook over de Cobalt-wisselaandrijvingen. Dus heb je al eens de draadjes omgewisseld?
Groet Ronald.
-
Heren!
Inmiddels contact gehad met Uhlenbrock: fantastisch snelle reacties, hoewel helaas geen oplossing.
Op hun verzoek heb ik de volgende zaken uitgeprobeerd:
Wat Ronald al suggereerde: draadjes omwisselen
Verder de preambel bits gevarieerd;
De faselengte van de 1 bits gevarieerd;
De faselengte van de 0 bits gevarieerd;
Het aantal bits aan het einde van een DCC-pakket gevarieerd.
Op de IB betreft het hier de 'sonderoptionen' 903 t/m 906.
Alle tests hadden geen effect: nog steeds geen reactie van de Cobalts. Uhlenbrock heeft aangegeven dat ze hiermee aan het eind van hun latijn zijn, ze kunnen me niet verder helpen.
Van Dccconcepts heb ik nog geen recente reactie teruggehad, maar daar verwacht ik eerlijk gezegd niet heel veel van.
Samenvattend:
Ik zou verwachten dat de IB en de IB II een identiek digitaal signaal uitsturen....
Lenz decoders werken perfect met beide apparaten....
Cobalt wisselmotoren werken perfect met de IB II, in het geheel niet met de IB.
Ik ben bang dat we er niet uit gaan komen. Timo of Klaas nog een idee???..... :-\
Groet! Frans
-
Het enige idee wat ik heb is dat je met een oscilloscoop het signaal gaat analyseren. Maar dan moet je wel zo'n ding hebben en er mee kunnen werken.
ik bedenk nu nog iets, maar dat heb je misschien al geprobeerd. Stuurt de IB ook andere protocollen uit, Motorola of zo? Het zou kunnen dat de Cobalt daar niet tegen kan.
-
En je weet zeker dat de knoppen op de IB voor het veronderstelde adres van de schakeldecoder geprogrammeerd zijn. Ik heb alleen een IB2 maar veronderstel dat het principe hetzelfde is dus dat je een magneetartikel adres aan een knop moet toewijzen.
-
Jean-Paul, even teruglezen dan zie je dat Frans het met een andere decoder en andere wisselaandrijving heeft geprobeerd en die werkt wel op beide IB's.
-
Oeps, op een of andere manier was ik er in geslaagd een deel van de conversatie te missen....
-
Ik weet niet of je er wat aanhebt, maar ik gebruik een aantal Arduino's voor DCC, en een van de voorbeeld sketches bij de DCC bibliotheek was een DCC monitor. Die dumpt alle DCC commandos op de seriele monitor. Misschien een Arduino optuigen als DCC monitor?
Groet Meino
-
@Klaas: interessante gedachte. Voor de zekerheid heb ik alles nog even gecontroleerd, maar zowel voor de locs als de overige digitaal aan te sturen apparatuur staat echt alles op DCC, zowel bij de algemene als de individuele adressen.
Overigens zoek ik het nu vooral in de IB (omdat de IB II het wel goed doet), maar het probleem kan natuurlijk ook liggen in de Cobalts zelf: ik heb daarvan inmiddels meldingen gekregen van 'ongebruikelijke bewegingen' in digitale omgevingen. In die zin zou het signaal van beide centrales een vergelijking waard zijn.
@Meino: voor mij als digibeet is dit een graadje boven mijn niveau. Maar ik ga het wel aan mijn zoon voorleggen, die zou er wat mee moeten kunnen.
Groet! Frans
-
Hallo Frans,
Het zou ook nog aan de combinatie van Cobalt en IB1 kunnen liggen. Een paar jaar geleden geprobeerd Cobalts aan de praat te krijgen achter een IB1 en/of een TC. Dat was een ramp. De ene Cobalt werkte min of meer, de andere totaal niet. We zijn er toen snel weer vanaf gestapt.
Waar we toen niet naar gekeken hebben is de pulslengte voor aansturing van wisseldecoders in het TC / de IB. Die staat vrij kort (50 cq 100 ms). Misschien helpt het nog om die te verlengen.
-
Dag Frans
Je zoon kan op deze site https://rudysmodelrailway.wordpress.com/2015/10/23/dcc-sniffer-packet-analyser-with-arduino/ (https://rudysmodelrailway.wordpress.com/2015/10/23/dcc-sniffer-packet-analyser-with-arduino/) wel het een en ander vinden. Belangrijk, er moet ook een klein interface bordje gemaakt worden met een opto coupler. Dat is makkelijk op een stukje stripboard te maken, het schema kun je ook van deze site halen. Overigens heb ik daar ook nog wel een jpegje van.
Groet Meino
-
Meino, kan die DCC sniffer ook de pulslengtes laten zien? Dat zie ik niet zo gauw. Want daar zit volgens mij het probleem. Frans heeft al geconstateerd dat het uitgezonden commando goed is, want een andere decoder reageert er wel op. Dus de volgorde van nullen en enen is wel goed, maar de pulslengtes worden door de cobalt niet herkend.
-
Klaas, niet direct, maar het is wel zo dat de pulsen binnen de pulslengtes zoals die door de NMRA zijn vastgelegd moeten liggen om een 0 of een 1 te krijgen. Maar er is wel iets anders wat een rol zou kunnen spelen, n.l. spikes in het DCC signaal, Ik weet dat omdat in eerste instantie mijn Arduino DCC implentatie soms problemen had met het ontvangen van commando's. Dit trad op als bepaalde locs op de baan reden, die waarschijnlijk storing veroorzaken. Ik heb gemerkt dat sommige locdecoders daar ook last van hebben. Bijv de goedkope Lais decoders, en ook Uhlenbrock kan daar last van hebben. Tams bijvoorbeeld niet. Dat zie je doordat soms de loc niet gelijk op een snelheids verandering reageerd, maar dat vertraagd doet. Overigens loc commando's worden continue verstuurd door de centrale, dus een loc zal op een gegeven moment gaan reageren. Maar de commando's voor wissel decoders hoeft dat niet. Mijn Centrale (MDRRC II) herhaalt deze commando's 5x, maar sommige centrales herhalen ook deze commando's constant.
Groet Meino
-
Vervelend :-\ Maar aan de offset ligt het in ieder geval niet. Je stuurt immers een wissel commando om het adres in te stellen. Of jij dat nu wissel 1 noemt en de decoder dat op slaat als wissel 44 maakt niet uit. Als hij daarna maar op hetzelfde commando werkt. Is anders als je een wissel via CV programmeren of dip switches etc een adres geeft.
En waar het probleem zit, tja. Een van de twee lijkt zich niet aan de specificaties te houden. Zou je inderdaad met de oscilloscoop of logic analyzer aan de gang moeten. Maar mijn gevoel zegt eerder dat de Cobalt te kritisch is :police:
Overigens, je zegt dat je helemaal geen MM uit zend. Maar ik meen te hebben gezien dat de standaard refresh stack bij de IB juist op MM stond. Zou je nog naar kunnen kijken.
En misschien een gekke vraag, maar ook al eens de IB gewoon helemaal terug gezet naar fabrieksinstellingen?
Timo
-
Maar er is wel iets anders wat een rol zou kunnen spelen, n.l. spikes in het DCC signaal,
Dat is ook nog een mogelijkheid. Om dat te weten zal je er toch met een scoop naar moeten kijken.
Anderzijds is het wel zo dat andere decoders daar geen last van blijken te hebben. Dus je kan ook stellen dat de Cobalt te kritisch is. (wat al eerder werd gesuggereerd).
-
Ik heb er nog eens over nagedacht. Ik ben bang dat storing op het DCC signaal niet het probleem is, omdat de IB het wel doet en de IBII niet. Ik neem aan dat beide gebruik maken van de zelfde physieke verbinding naar de Cobalts.
Maar iets anders, ik zit net nog even op DCCWiki het een en ander te lezen over de adressering van wisseldecoders. Dat kan op 2 manieren, met een zogenaamd "Decoder address". Het decoder adres is dan 9 bits, dus 512 decoders, en iedere decoder heeft 4 output paren die afzonderlijk aangestuurd kunnen worden. Of de decoder werkt met een "Output address" van 11 bits, dus 2048 decoders, en ieder adres stuur 1 ouput paar aan. Zou het kunnen dat de Cobalts alleen een "Output address" herkent, terwijl de IBII zo geconfigureerd is dat hij het "Decoder address" formaat gebruikt ipv een "Output address" formaat? Ik kan me voorstellen dat andere decoders zo slim zijn om op beide adres formaten te reageren.
Groet Meino
-
Hoi Meino,
Denk niet dat het daar mee te maken heeft. Ik heb het Extended Accessory Decoder Control Packet Format eigenlijk nooit gezien.
En dat is ook niet wat de DCCwiki bedoelt. Dat is, zoals de DCCwiki ook zegt, gewoon op twee manieren naar hetzelfde beestje kijken.
Different manufacturers view this range in one of two ways:
Of je kijk er naar dat het een 9-bit decoder adres met 2-bit sub-adres (maakt 11-bit). Of je kijkt er gewoon naar als één 11-bit adres. Alleen een extra hak in functie, op de bus staat hetzelfde.
Het effect is dat het ene merk spreekt van decoder met adres 2 en uitgang(paar) C/3 waar het andere merk dat gewoon adres 7 noemt. Heeft met er meer te maken dat de makers van de standaard het logisch leek om decoders met 8 uitgangen (dus 4 uitgangparen) te hebben, zonder ingewikkelde dingen als functiemapping etc.
Timo
-
Timo dat begrijp ik, maar het gaat er om wat de IB en de IBII doen. Een decoder adres 3 in Output formaat is hetzelfde als base adres 0, 4e output paar in Decoder formaat. Dus als de IB's verschillende formaten hanteren kan het makkelijk dat de adressen niet meer matchen met wat de Cobalts verwachten. De andere decoder die het wel deed op de IBII, is die ook met de IBII geprogrammeerd?
Groet Meino
-
Ja maar een decoder in programmeerstand verwacht niet adres x, maar gewoon een adres die het vervolgens over neemt. Het canvas aan de Cobalt kant is dan nog blank. En of de centrale die nu weer geeft als adres 2C en de Cobalt deze op slaat als adres 7 is dan niet van belang.
Timo
-
Ja dat is duidelijk, maar wat als hij geprogrammeerd is terwijl de centrale Output formaat adressen heeft gebruikt en je probeert nu dat zelfde adres (als het base adres) te gebruiken op een centrale die Decoder formaat adressen gebruikt? Bijvoorbeeld op de Centrale die Output formaat gebruikt is de decode met adres 7 geprogrammeerd. Als je dit adres nu gebruikt op een centrale die in Decoder formaat werkt, gebruikt die als base adres 7, maar dat wordt dan in de eerste 9 bits geplaatst, dus de decoder ziet dat als adres 28 en doet dus niets met dit commando.
Groet Meino
-
Meino, ik denk dat je het te ver zoekt.
Maar Frans zou het kunnen testen door de Cobalt te programmeren met de IB, en dan kijken of de combinatie dan wel werkt.
-
Klaas, waarschijnlijk heb je gelijk, maar het is een taai probleem en als een outsider denk ik misschien aan te vreemde scenario's. Daar komt bij dat ik zelf de IB's niet ken, dus kijk ik naar protocol fouten of zaken waar ik zelf ooit tegen aan gelopen ben, zoals spikes. Overigens heb ik er zelf ook aan zitten denken, wat gebeurd er als je een Cobalt opnieuw programmeert met de IB die niet werkt.
Groet Meino
-
Heren!
Leerzame discussie!
@ Meino: programmeren met de IB had ik al geprobeerd; zie reactie #6. Nulnientenada dus...
En dat past, naar nu blijkt, bij het antwoord dat ik inmiddels van Dccconcepts heb ontvangen:
Hi Frans
We've had a lengthy discussion regarding this scenario.
The bottom line is that the Cobalts behave with every DCC system, including the IB 2, but not the IB 1 !!
Maybe that is why IB 1 was discontinued? !
Sorry Frans - we can find no other answer .
Kind regards Chris
Einde verhaal dus: zowel Uhlenbrock als Dccconcepts hebben geen idee. Alles blijft toch bij vermoedens; Cobalt te kritisch, IB met spikes en waarschijnlijk niet heel stabiel?......
Groet! Frans
-
Bijzonder verhaal. Zowel Uhlenbrock als DCCconcepts weten dat de combinatie niet werkt. Maar kennelijk heeft geen van de twee aanvechtingen gehad om uit te zoeken hoe dat komt.
-
Dus de eindconclusie is dat de IB (of de Cobalt) niet volledig compatibel is met de NMRA DCC normen en dat dit dus niet oplosbaar is? Het is jammer dat Uhlenbrock of DCCConcepts dit niet uitgezocht hebben, het riekt naar een protocol fout (nr of preamble bits?).
Dus we stoppen hier want het is niet simpel oplosbaar?
Groet Meino
-
Jammer jammer :-\
Heb zelf helaas geen IB, anders had ik er eens een logic analyzer (of scope) aan gehangen. Je zou zeggen dat dat voor DCCconcepts ook een koud kunstje is...
Timo