ingebouwde decoder van Haber & Koenig

[dutchbuilder]

Beste medespoorders
Ik heb hier een loc van ROCO met een ingebouwde decoder.
Als ik JMRI naar een decoder laat scannen is het een decoder van Haber & Koenig.
Is voor mij een first, nog nooit van gehoord.
Om het programmeren wat makkelijker te maken gebruik ik JMRI  bij de PC.
Bij de spoorbaan doe ik alles met Lenz.
Nu doet zich het rare voor dat met JMRI de loc het uitstekend doet maar met de Lenz zo dood als een pier is.
Dit is voor mij de eerste keer dat ik dit meemaak.
Kan iemand mij een opheldering geen voor dit verschijnsel?

Ton

[Dirk J]

Op welk adres staat hij?

[bask185]

Programmers gebruiken een algemeen broadcast om te rijden en te programmeren. Elke decoder luistert hiernaar, daarom rijdt een trein altijd op een programmer ongacht wat zijn adres daadwerkelijk is.
Het komt voor dat mensen een adres programmeren, denken dat het gelukt is omdat de trein rijdt op de programmer (wat dus door de broadcast komt) terwijl het programmeren helemaal niet gelukt is.

De trein rijdt niet op de Lenz centrale omdat het adres van de decoder niet is, wat jij denkt dat het is.

Dit kan zijn omdat het programmeren dus niet goed is gegaan
Dit kan zijn omdat jij het primaire adres programmeert terwijl de decoder op extended adressen staat-> bit 5 van CV29 is '1'. Dan haalt de decoder zijn adres uit CV17 & CV18 en niet uit CV1.  Of het is vice versa, dus je probeert extended adressen maar bit 5 van CV29 staat nog op '0'.

Ik ken die decoder verder ook niet. Er bestaan decoders die niet goed werken als railcom aanstaat in de Lenz centrale. Of die van jou er een van is, weet ik niet. Ik zou er aanvankelijk wel van uit gaan dat hij goed werkt met railcom. Dus pas als je 100% zeker weet dat de decoder echt goed geprogrammeerd is en hij rijdt nog niet? Dan pas zou ik railcom uitzetten in de centrale.

Mvg,

Bas

[Karst Drenth]

Programmers gebruiken een algemeen broadcast om te rijden en te programmeren. Elke decoder luistert hiernaar, daarom rijdt een trein altijd op een programmer ongacht wat zijn adres daadwerkelijk is.
Het komt voor dat mensen een adres programmeren, denken dat het gelukt is omdat de trein rijdt op de programmer (wat dus door de broadcast komt) terwijl het programmeren helemaal niet gelukt is.

Sorry Bas, dit is volledig kletskoek…

Overigens vraag ik me af waarmee JMRI dan praat. 

Grtzz,
Karst

[bask185]

Ik weet dat je me niet mag, maar alleen roepen dat is kletskoek en vervolgens niks verbetert, vind ik persoonlijk niet echt bevorderlijk ofzo. Kan je dan tenminste wat constructiever zijn en inhoudelijk aangeven wat er volgens jou niet aan klopt, Karst?

Voor zover ik weet werken meeste programmers/programmersporen met broadcast adres/adres 0. Het is dit wat ze instaat stelt om een adres uit te lezen.

Ik heb eerder meegemaakt op BNLS met een of andere amerikaanse trein die 2 decoders had, dat beiden decoders prima werkten op het programmeerspoor maar op het hoofdspoor wilde er maar eentje luisteren naar zijn adres. Dat kwam toen doordat een van die twee decoders niet goed zijn adres had meegekregen tijdens het programmeren.  Dan kan het toch niet anders dat dat programmeerspoor adres 0 gebruikt voor het rijden?

Overigens vraag ik me af waarmee JMRI dan praat.

Hoewel dit totaal nergens op gebasseerd is, gok ik vandaag op een Sprog  maar dat wachten we af.

Bas

[Rico [momfer]]

Wat rondzoeken in on eigen BNLS en stummiforum.de leert dat deze fabrikant ook verantwoordelijk is voor veel van de Märklin/motorola decoders.

Helaas heb ik in mijn korte zoektocht geen H&Ke handleidingen kunnen vinden, maar mijn gok zou zijn om de resetwaarden van verschillende Märklin decoders eens te proberen, om zo verder te komen.

[Karst Drenth]

Ok, omdat je het zo vriendelijk vraagt:

Ik weet dat je me niet mag, maar alleen roepen dat is kletskoek en vervolgens niks verbetert, vind ik persoonlijk niet echt bevorderlijk ofzo.

Nog meer kletskoek Ik vind het niet in orde, dat mensen met grote stelligheid iets beweren dat overduidelijk niet correct is (of op ongefundeerde aannames berust). Dat heeft niets met dat ik je niet of wel zou mogen te maken, ofschoon het jou wel regelmatig overkomt...

Kan je dan tenminste wat constructiever zijn en inhoudelijk aangeven wat er volgens jou niet aan klopt, Karst?

Jazeker kan ik dat, het programmeren van een decoder onder het DCC protocol, vindt plaats middels ongeadresseerde DCC pakketten, namelijk z.g. Service-Mode packets. Dit zijn géén broadcast pakketten. Ze dienen uitsluitend en alleen voor het programmeren. Er kan niet mee gereden worden.

Voor zover ik weet werken meeste programmers/programmersporen met broadcast adres/adres 0. Het is dit wat ze in staat stelt om een adres uit te lezen.

In dit geval zou ik mijn kennis bij gaan spijkeren als ik jou was. Zie boven de uitleg hoe het wel zit.

En je zou hier: https://www.railcommunity.org/index.php?option=com_content&view=article&id=49&Itemid=61 de normen RCN210 t/m RCN216 eens aandachtig kunnen nalezen. Daar heb je je hele verdere modelspoorelectronicaontwikkelleven iets aan

Hier alvast een quote:

2.1 Hinweise zur Benutzung des Programmiergleises
     Der Programmierausgang darf keine elektrische Verbindung zum Rest der Anlage haben.
     Die Datenpakete des Programmiergleises benutzen keine Adressen und sollten daher nicht auf der Anlage verwendet werden, wo ggf. mehrere Fahrzeuge ungewollt umprogrammiert werden.
     Damit ein Lesen der Konfiguration auf dem Programmiergleis möglich ist, sollten in einem Fahrzeug alle Verbraucher, die nicht von einem Decoder versorgt werden, auf andere Art abschaltbar sein.

Ik heb eerder meegemaakt op BNLS met een of andere amerikaanse trein die 2 decoders had, dat beiden decoders prima werkten op het programmeerspoor maar op het hoofdspoor wilde er maar eentje luisteren naar zijn adres. Dat kwam toen doordat een van die twee decoders niet goed zijn adres had meegekregen tijdens het programmeren.  Dan kan het toch niet anders dat dat programmeerspoor adres 0 gebruikt voor het rijden?

Wederom een incorrecte conclusie c.q. aanname. Adres 0 onder DCC wordt gebruikt voor Analoge "zero-stretching" een oude techniek die het mogelijk maakt 1 analoge lok te rijden op je digitale centrale.
Inmiddels wordt dit nog nauwelijks geïmplementeerd, omdat het, zeer, slecht is voor je analoge motor.

Hoewel dit totaal nergens op gebasseerd is, gok ik vandaag op een Sprog  maar dat wachten we af.

Dat bedoel ik nu, en gokken zou ik in het Casino doen

Grtzz,
Karst

[bask185]

Ik beken alleen schuld aan het niet weten dat service pakketen ongeadresseerd waren en dus niet een broadcast adres gebruikte. Ik dacht namelijk aangezien je ook met POM kon programmeren dat je dus met 0 en met een keuze adres kon programmeren. Nu snap ik dat POM programmeren andere instructies zijn en die service pakketten ongeadresseerd zijn... Fout zekerweten, ongefundeerd? nee.

Dit zijn géén broadcast pakketten. Ze dienen uitsluitend en alleen voor het programmeren. Er kan niet mee gereden worden.

Programmeren terzijde.. je kan wel rijden op een programmeerspoor met normale pakketen. Het feit dat die lok die ik opnoemde wel reed op een programmeerspoor en niet op het hoofdspoor, hoe verklaar jij dat dan?

Wederom een incorrecte conclusie c.q. aanname. Adres 0 onder DCC wordt gebruikt voor Analoge "zero-stretching" een oude techniek die het mogelijk maakt 1 analoge lok te rijden op je digitale centrale.

Ik vind het niet eerlijk dat je dit zegt en dan appels met peren vergelijkt. Ik weet dat sommige oude centrales adres 0 deden misbruiken voor zero-stretching maar daar heb ik het niet over.

Ik heb het hierover.

B: Broadcast Command for Multi Function Digital Decoders50
The format for this packet is:
{preamble} 0 00000000 0 {instruction-bytes} 0 EEEEEEEE 1
Instructions addressed to "broadcast address" 00000000 must be executed by all Multi Function Digital Decoders.55
The single instruction has the same definition as defined by the Multi Function Digital Decoder packet and can be
one, two, or three bytes in length depending on the instruction. Digital Decoders should ignore any instruction they
do not support. The manufacturer must document which broadcast commands a decoder supports

https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf

Dit zit onder andere in de z21 om alle treinen te laten noodstoppen. De z21 stuurt dan continu een noodstop bericht onder adres 0. Je kan dit zaterdag bij de BMB aanschouwen. Maar eh.. jij bouwt dit toch ook in in die centrale van jou?

Je hebt toch ook van die remboosters die snelheid 0 sturen naar adres 0 om elke trein te kunnen stilzetten?
https://dccwiki.com/Braking_District

Dus daarom en om dit zinnetje

Nu doet zich het rare voor dat met JMRI de loc het uitstekend doet maar met de Lenz zo dood als een pier is.

denk ik dus dat het testrijden op d'n programmer wel goed ging omdat dat gebeurt met adres 0, het programmeren mislukt is en dat daarom de lok niet op de Lenz wilt rijden.

Bas

[Dirk J]

Of hij heeft een adres tussen 100 en 127, wat door de ene centrale als kort adres wordt gezien en door de andere als lang adres.
Mijn oplossing: geen adressen toepassen tussen 100 en 127.

[Karst Drenth]

@Bask

Ik denk dat Dirk het zeer wel mogelijk bij het rechte eind heeft. Eventueel kan het ook nog de ingestelde snelheidsstappen zijn.

En rijden op het prog-spoor... ja logisch, het is wat de packet generator aanbiedt. Ik doe dat zelf niet, maar biedt het signaal van de maintrack packet generator aan


Grtzz,
Karst

[bask185]

Dat denk ik ook, ik legde in mijn eerste antwoord uit dat hij waarschijnlijk probeerde kort adres te programmeren terwijl het eigenlijk een hoog adres is. Of andersom.

Ik las ook dat sommige fabrikanten de grens tussen hoog-laag bij 127 trekken en anderen zoals Lenz bij 99. Ook niet echt handig lijkt mij  .

[Karst Drenth]

Lenz 99

Roco en YaMoRC: instelbaar

Rest vd wereld: 126

[dutchbuilder]

Dirk bedankt voor jouw meedenken.
Ik had de decoder naar het locnummer geprogrammeerd namelijk 120.
Ik heb de loc terug geprogrammeerd naar adres 3 en zie daar ik heb leven op de lenz.
Nu kan ik weer wat doen.
Tnx Ton