Samengevat: De 'MiNiDiGi' Centrale

[HansQ]

Heren,

Ik was een 1/2 jaar geleden bij een bejaarde man van wie ik voor een heel zacht prijsje een Trix Mobile Station overnam omdat hij gek werd van dat ding. Hij heeft nu een Multimaus en daar is hij heel gelukkig mee. Grootste probleem was natuurlijk het 'bedieningsgemak' van de mobile station, voor hem veel te ingewikkeld dus...

Wat die man nodig had was iets waarvan hij niet in de war raakt en wat het altijd op dezelfde manier doet, en de Multimaus komt daar een heel end mee. Maar hij heeft nog steeds iemand nodig die voor hem z'n nieuwe lokjes inprogrammeert. Als dat nou es automatisch gaat in de toekomst met RailCom vind ik dat pure winst!

Eenzelfde redenering kun je ophangen voor de verwende Nintendo generatie, die (misschien heel terecht?) niet begrijpt dat je een DCC centrale eerst moet vertellen dat er een nieuwe lok bijkomt op de baan...

Het zou me niets verbazen als locdecoders over een paar jaar een uniek 'MAC' adres hebben en ook gelijk info over welke grote broer of zus hun drager voorstelt met wat gegevens zoals aantal assen, gewicht stoom/diesel/electrisch en maximale snelheid erbij. Daar kan bijvoorbeeld Koploper dan vast ook slimme dingen mee, bijvoorbeeld afremgedrag?

Graag jullie (onvermijdelijke?    ) commentaar...

[Wim Ros]

Volgens mij meld RailCom alleen maar terug wat er in een decoder is vastgelegd. Iedere nieuwe lok uit de doos staat op adres 3, wat ik ook al eerder zei.
Je zult dus nog steeds als gebruiker aan de decoder moeten vertellen dat hij een ander adres moet krijgen. Verder lijkt het me niet echt handig als de centrale of de handregelaar iedere keer van adres verandert als er een lok over een railcom detectie heen komt. Dus het automatisch aanmelden bij de centrale of de handregelaar is denk ik niet echt werkbaar.

Mvg
Wim.

[Albert.H0]

Wat moet er op zo'n programmeerspoor dan gebeuren, herkenning adres, doorgeven aan besturing "heb je dit adres al?" en zo ja automatisch omprogrammeren in 1e vrije adres? Ben het met Wim eens, leuk allemaal, maar wel een behoorlijke "overkill".

Enige zinvolle toepassing RailCom toepassing die ik kan verzinnen is in een baan met blokbeveiliging zonder PC sturing. Zoiets als, komt lok in blok met seinbeeld "geel" wordt adres uitgelezen en past centrale snelheid van dat adres aan naar lage snelheid, is het seinbeeld "rood" past centrale snelheid van dat adres aan naar 0. Soort Lenz ABC maar dan gebaseerd op lokadres. Is ook wat sjieker dan de Lenz en Roco remgenerator waar je een compleet blok met een relais omschakelt naar een andere booster achter de remgenerator.

Overigens, wat gebeurt er bij RailCom uitlezen van een dubbeltractie? Is hier in voorzien?

[Patrick Smout]

Enige zinvolle toepassing RailCom toepassing die ik kan verzinnen is in een baan met blokbeveiliging zonder PC sturing. ..

Albert,

als via railcom een indicatie van de afgelegde weg zou teruggeven worden, bvb. via aantal omwentelingen + richting van een motoras, weliswaar gereduceerd, dan komt bvb. volautomatisch rangeren wel heel dicht bij.

mvg,

Patrick Smout

[Han Zijlstra]

@Hans q
Kijk : zinvolle bijdrage. Niet iedereen ( of bijna geeneen ) van de vele modelspoorders is genegen alle in- en outs van een lok ergens in te programmeren. Als de lok dat zelf kan vertellen is dat mooi meegenomen. Vergelijk het eens met zappen op de tv. Je kunt elke keer je tv vertellen dat je freq. xyz moet hebben, beeld ratio abc, kleurcorrectie def, etc etc maar je kunt ook gewoon op knopje 2 drukken en ned 2 ontvangen. Gemak dient de mens.
Hoewel ik bepaald geen m* fan ben is hun systeem met lok-kaartjes een hele leuke oplossing voor besturing van een modelbaan. Sommige van ons vergeten wel eens dat niet iedereen altijd maar lekker aan het programmeren is maar gewoon makklijk wil rijden. Rail com gaat daar straks en nu al enorm bij helpen.

[henk]

Kan Railcomm dan een loc programmeren?
Volgens mij wordt er nu opnieuw onterecht een oplossing voor een probleem aan Railcomm toegeschreven. Zoiets staat en valt vooral met het standaard inbouwen van locdecoders en dat heeft ook weer grote nadelen.

[Han Zijlstra]

Nee Rail com is niet bedoeld om een lok te programmeren, wel om info van het geprogrammeeerde door te geven aan de besturings eenheid/software.

Situatie nu is dat een gebruiker zijn decoder programmeert (en niet alleen het adres wijzigt maar ook topspeed, remvertaging, verlichting etc. Je zult op redelijk korte termijn lokomotieven kunnen verwachten waarbij al die functies al zijn voorgeprogrammeerd. Denk aan sound loks met hun geluidsvolgorde , starten, toeren etc. Je krijgt dan de combinatie van ( voorgeprogrammeerde )functionaliteit in de loc , doorgeven middels Railcomm aan besturingseenheid/software en vervolgens de rules ( of policy in IT termen) die een gebruiker heeft gedefinieerd toepassen voor het rijbedrijf.

[Wim Ros]

Han,

Dat is nu toch ook al zo, dat zijn de default waarden!!!!!!
Dat niet iedere baan en niet iedere modelspoorder hetzelfde is zal dit aangepast worden aan de wensen van de modelspoorder. En daar draagt Rail-Com niets aan bij.
Je dicht allerlei opties toe aan Rail-Com, die helemaal niet terzake zijn, en waarschijnlijk ook nooit zo zullen werken.
Railcom leest alleen maar de gevens uit die de gebruiker en de fabrikant er in gestopt heeft.

Mvg
Wim.

[henk]

De mogelijkheden die Hans en Han noemen komen er in de kern op neer dat de fabrikant de gegevens in de locdecoder stopt en dat de centrale en/of de computer die gegevens in één keer uitleest als de loc voor de eerste keer op de baan wordt gezet. Dat kan alleen met Railcomm-achtige voorzieningen. Met MFX kan dat ook, maar zo beperkt dat nog een bestaande locbibliotheek moet worden gebruikt.
Mag iedereen zelf uitmaken of dat de moeite waard is.

Ik denk dat we daar vanzelf achterkomen als fabrikanten inderdaad locs met ingebouwde decoders met Railcomm gaan leveren. Als optie voorlopig, hoop ik.

[fissy]

Ik denk het is niet handig als een fabrikant een loc direct af fabriek gaat programmeren, niet iedereen is met zo'n mainstream instelling tevreden...

Er is al een mogelijkheid om CVs uit te lezen via programming "on the main", maar deze heb ik nog nooit gebruikt een er is (denk ik) geen software die dit gebruikt.

Maar ik denk ook, dat deze discusion iets onzinnig is, het is iedereen heeft toch een eigen smaak en op dit moment zijn er nog niet zo veel producten met actief Railcom...

Groet

Bernd

[henk]

Ik denk het is niet handig als een fabrikant een loc direct af fabriek gaat programmeren, niet iedereen is met zo'n mainstream instelling tevreden...

Nee, maar wat dat betreft heeft Han gelijk. Nu redeneer je vanuit de 'die hard' liefhebber die liever zelf een decoder uitzoekt en programmeert. Er is ook een categorie hobbyïsten die het helemaal niet erg zou vinden als de fabrikant dat voor ze regelt, zodat ze van al dat CV-gezeur af zijn.
Onder drierailers hoor je weinig klachten over de standaard ingebouwde decoders. De meeste hobbyïsten vinden dat blijkbaar prima en de 'die hards' kunnen de decoders natuurlijk altijd naar eigen inzicht herprogrammeren.

Maar, zoals ik al zei, het blijkt vanzelf hoe dat bij tweerail wordt ontvangen.

[fissy]

je hebt gelijk, er zijn veel mensen met deze wensen.

Als je kan kiezen tussen een loc met decoder of zonder is dit een idee, maar als je standaard voor een Decoder betaalt, die je niet wilt dan heb ik er toch een problem met. Dekoder on-board is immers een problem voor mensen met een andere smaak van decoder...

maar deze discussie was er al...

[Han Zijlstra]

Misschien toch maar apart draadje "Railcom etc " maken.?

dit linkje http://www.nmra.org/standards/DCC/Minutes/Minutes_Nuremberg_2007_NA.pdf geeft inzicht in hoe men met elkaar samenwerkt . De minutes van 2008/2009 zijn nog niet openbaar.

[Jeroen van Tol]

Het was niet bepaald mijn bedoeling om deze discussie wederom los te laten barsten maar (tegen mijn verwachting in) heb ik toch weer een hoop nieuwe ideeen en vraagstukken gezien.

Wanneer ik aan de software ga beginnen zal ik een hoop van wat hier genoemd is zeker mee gaan nemen. Ik zal iedereen hier in ieder geval op de hoogte houden van de gekozen oplossingen...

De bouw van de DCC-sniffer is zo goed als afgerond. Ik mis helaas nog het USB-snoer van ftdi dus ik kan het nog even niet testen.
Het programmeren van de Atmel voor dit verhaal was met mij EVK-board echt een fluitje van een cent. Zo simpel zelfs dat ik het schema van de sniffer deels niet op de print heb uitgevoerd. Alles uit het schema met betrekking tot het 'on-print' kunnen programmeren van de Atmel heb ik achterwege gelaten... (Waarbij ik hoop dat ik niet teveel heb weggelaten)

Verder begin ik eindelijk te snappen waarom Dave zijn schakelingen eerst op een breadboard uitprobeert. Ik heb de sniffer direct op een experimenteerprintje gebakken maar aangezien dit mijn eerste 'bouwsel' in deze vorm is verdient het niet bepaald de schoonheidsprijs. Ik wou nog 'trots' een foto plaatsen maar ik geloof niet dat iemand daar iets van kan leren, laat staan dat ik er trots op kan zijn...
Als het straks niet blijkt te werken zou ik wensen dat het op een breadboard zat want de wirwar van aan elkaar gebakken draadjes die ik nu heb is volgens mij niet meer te corrigeren...

Hoe dan ook, ik heb er weer het nodige van geleerd. Bijvoorbeeld ook dat je de soldeerbout ten allen tijde bij het handvat moet vasthouden en niet ergens anders!

Inmiddels ben ik begonnen met de bouw van de booster. En hoewel ik dat ook meteen op een experimenteerprintje aan het doen ben ziet het er al een stuk beter uit dan de sniffer. Ik hoop dat de resterende onderdelen uit duistland snel binnen komen zodat ik het kan afmaken. (En in die bestelling zit het breadboard zodat ik het voortaan eerst kan uitproberen)

Het 'knippen en plakken' vanuit de code van de OpenDCC centrale naar mijn minicentrale begint ook behoorlijk op te schieten. Ik ben inmiddels zo ver dat ik nullen en enen conform de dcc-standaard kan genereren! Dat gebeurt nu nog op basis van hardgecodeerde bitjes maar het is een begin. Ik probeer momenteel te doorgronden hoe je bij zo'n chip nu eigenlijk 'data' van het geheugen naar de PWM moet sturen. Af en toe gebeuren er namelijk 'rare' dingen in zo'n chip! Maar dat zal ongetwijfeld liggen aan het gebrek van mijn kennis...

Tot slot snap ik nog steeds niet helemaal of ik nu wel of niet genoeg heb aan de voeding vanuit de USB voor mijn minicentrale. Het is meer dan voldoende om de centrale zelf te laten werken maar of het uitgaande dcc-signaal sterk genoeg is voor de booster weet ik dus niet... Ik dacht eigenlijk dat alle dcc-compatible boosters 'hetzelfde' waren maar er zijn wel degelijk verschillen. Plus dat ik natuurlijk de OpenDCC booster aan het bouwen ben die qua uitgang weliswaar DCC-compatible is maar qua ingang is afgestemd op de OpenDCC centrale...
Lijkt me handig dat ik dat op korte termijn eens goed ga onderzoeken!


Groet,
Jeroen.

[Jeroen van Tol]

Nog even teruggelezen hoe het ook alweer met verschillen tussen boosters zat...
Blijkbaar wist ik dat al maar de kennis was weer even weggezakt.
(Too much info 'opgezogen' de laatste tijd  :-|)

De OpenDCC booster die ik aan het bouwen ben heeft op aan de dcc-ingang een TTL optocoupler (HCPL2631) zitten met een 2k2 weerstand er voor. Als ik het goed begrepen heb zorgt dat weerstandje er toch voor dat de 'standaard' 12V wordt teruggebracht tot 5,45V (TTL nivo)?

En klopt het dat ik de booster met de geplaatste weerstand kan testen door hem achter de profiboss te hangen?

En tot slot, gaat het dan ook werken als ik mijn minicentrale op TTL nivo laat praten met de booster wanneer ik de weerstand weg haal?

Dit is voor mij een beetje het moment van de waarheid... Heb ik de elektronica-boeken een beetje begrepen of kan ik beter een andere hobby zoeken?

 

Groet,
Jeroen.