BeneluxSpoor.net forum
Vraag en antwoord => Digitaal => Topic gestart door: Jeroen van Tol op 17 February 2009, 16:33:45
-
*****
Omdat de informatie en de voorgeschiedenis van dit project verspreid staan over een draadje of 4 begon het verhaal voor sommigen wat onduidelijk te worden. Om die reden heb ik besloten het 'totaalplaatje' in een nieuw draadje te zetten. Van hier uit kan de ontwikkeling op de voet gevolgd worden en kan men, met het totaalplaatje in gedachten, meedenken en discussieren over het project. Het doel is natuurlijk om tot een zo goed mogelijk resultaat te komen.
*****
De gedachte achter de 'MiNiDiGi' centrale...
Toen ik opnieuw in de treinhobby stapte kwam al snel naar boven dat ik een keuze moest gaan maken uit de vele merken (al dan niet zelfbouw) centrales welke tegenwoordig voor handen zijn. Dat kiezen is me nooit gelukt. Geen enkele centrale voldeed aan al mijn eisen! Nu zaten daar eisen bij waar je achteraf je vraagtekens bij kunt zetten, maar het heeft er wel toe geleid dat ik ben gaan nadenken over wat (voor mij) nou de ideale oplossing zou zijn.
Uiteindelijk, na vele, vele, vele en nog meer boeken, internetpagina's, specificaties en wat al niet meer doorgespit te hebben kwam ik uit op het volgende verhaal.
Wanneer je digitaal gaat rijden is de kans groot dat er een dag komt dat je de baan middels een pc wilt gaan besturen (bv. met Koploper). Als die pc er dan toch gaat komen waarom dan niet de investering van een centrale uitgeven aan de pc en de centrale op de pc laten draaien? Software op een pc is immers heel gemakkelijk aan te passen waardoor de mogelijkheden 'onbeperkt' zijn en je nooit meer een nieuwe centrale hoeft te kopen. Dit op zich is overigens geen nieuw idee, zoals je kunt zien bij projecten als MRDirect, DDL en DDW. Stuk voor stuk mooie oplossingen. Maar met mijn opgedane kennis (of gebrek daar aan) bleek lang niet alles aan die systemen even ideaal te noemen. Zo kennen deze voorgangers een aantal lastige voorwaarden en beperkingen. Ik noem bijvoorbeeld de noodzaak van een tweede pc, oude of exotische besturingssystemen als bijvoorbeeld DOS of Linux, of het verplicht aanwezig zijn van de welbekende RS232 aansluiting.
Het moest dus één computer worden voor zowel de software-centrale als voor de treinbesturingssoftware, met gangbare aansluitingen zoals bijvoorbeeld USB en een 'modern' besturingssysteem zoals WindowsXP of VISTA. Al snel viel de keus op een laptop, welke je gemakkelijk mee kunt nemen en waar je ook iets aan hebt naast de treinhobby.
En daar begon de uitdaging. Het is namelijk niet zomaar mogelijk om een moderne laptop met Vista te gebruiken als centrale. Er zit in een centrale namelijk een tijdkritische functie, te weten het genereren van het uiteindelijke dcc-signaal. Een moderne laptop heeft geen aansluitingen waarmee een dergelijke precisie bereikt kan worden dus moest er een 'apparaatje' bedacht worden wat 'niks' mocht kosten (het gaat immers ten koste van je laptop budget) maar wat wel in staat moest zijn om enkel en alleen de tijdkritische functie uit te voeren.
Geinspireerd door de OpenDCC centrale ben ik aan de slag gegaan met een microcontroller van Atmel. Voor mij was dat een logische keus omdat mijn kennis van microcontrollers en het programmeren er van zo'n beetje ontbrak, en de rest van mijn programmeerervaring ook niet overdreven geweldig genoemd kan worden. Het leek me dus handig om het van een 'voorbeeld' te leren en OpenDCC is gebaseerd op opensource.
Nog geen week later zag ik Peter zijn draadje waaruit bleek dat hij min of meer hetzelfde aan het doen was. Hij had weliswaar (om redenen die hij in zijn draadje genoemd heeft) gekozen voor een andere microcontroller maar het was overduidelijk dat zijn gedachtenkronkels precies hetzelfde deden als die van mij. Om die reden heb ik Peter voorgesteld om de krachten te bundelen. (Waar ik overigens nog geen 'officieel' antwoord op heb gekregen...)
Mijn variant van het project kent (inmiddels) de volgende doelstellingen:
1. Software-Centrale
- De software-centrale voorziet in alle functies, met uitzondering van het genereren van de dcc-pulsen, welke nodig zijn om de treinbaan te bedienen.
- De broncode van de software-centrale zal als opensource beschikbaar gesteld worden
- De software-centrale dient te kunnen draaien op elke willekeurige (moderne) pc of laptop met USB aansluitingen
- De software-centrale zal zich gedragen als een LocoNet gespecificeerde centrale
- De software-centrale zal zo mogelijk geschikt gemaakt worden om ook met ander bussoorten overweg te kunnen
2. DCC Pulse Width Modulator (DCC-generator)
- De DCC-generator is in staat om een bitstream van logische nullen en enen om te zetten in DCC Pulsen
- De DCC-generator functioneert daarbij conform de laatste specificaties van de NMRA
- De DCC-generator zal volgens het Driver/Receiver (Voltage) principe werken
- De DCC-generator dient te beschikken over een USB interface waarlangs gecommuniceerd zal worden met de software-centrale
- Het streven is om de kosten van de DCC-generator te beperken tot ongeveer € 50,- aan onderdelen
- De print met onderdelen moet ook door een minder ervaren hobbyist te solderen zijn
- De broncode van de microcontroller(s) op de DCC-generator zal eveneens als opensource beschikbaar gesteld worden
Tot slot nog even de verwijzingen naar de voorgeschiedenis waar dit idee uit ontstaan is:
https://forum.beneluxspoor.net/index.php?topic=16652.0
https://forum.beneluxspoor.net/index.php?topic=16732.0
https://forum.beneluxspoor.net/index.php?topic=17350.0
Alsmede het draadje van Peter:
https://forum.beneluxspoor.net/index.php?topic=16967.0
Projectgroep
Nu kan kan ik natuurlijk alles in mijn eentje uit gaan zitten vogelen en in elkaar gaan zitten sleutelen (zoals ik tot nu toe heb gedaan met hulp en informatie vanuit het forum). De kans is echter groot dat er diverse paralelle projecten (zoals blijkt met het project van Peter) gaan lopen en we met z'n allen een berg tijd verspillen.
Geen ramp natuurlijk want het is ook gewoon leuk en interessant om het lekker zelf te doen maar erg efficient is dat niet... Ik ben daarom van plan om een groepje van een persoontje of 8 bij elkaar te zoeken om het één en ander gezamenlijk op te pakken. Dus heb je interesse om een actieve bijdrage te leveren aan dit project dan kun je me een PB'tje sturen.
Specifiek zoek ik mensen met in meer of mindere mate kennis van:
- Programmeren (.Net/C/Assembler/..)
- Microcontrollers (Atmel ATMega8/..)
- USB interface (FTDI RM232/..)
- Electronica (op en rondom het circuit van de DCC-generator / USB interface)
- LocoNet / XPressNet / Overige bussoorten
- NMRA specs (bv. DCC/..)
- Brainstormers en andere enthousiastelingen welke menen een bijdrage te kunnen leveren (wat natuurlijk ook gewoon mag middels dit draadje)
Communicatie zal veelal per mail verlopen maar het is wellicht leuk om later in het project ook een keer bij elkaar te komen om het (tussen)resultaat in een praktijksituatie te zien.
Tevens stel ik een (beperkt) budget beschikbaar om zonodig in bepaalde onkosten te voorzien.
Groet,
Jeroen.
-
Hmm,
Alles op 1 PC....... DDW dus.
Even mijn systeem samenstellen.
PC met DDW en Koploper.
LocoBuffer (interface) voor alles wat LocoNet te bieden heeft.
XpressNet via LocoNet.
En klaar is Wim.
Mvg
Wim.
-
Jeroen,
Er zijn al een tweetal belangrijke stromingen die tot een werkend open source resultaat hebben geleid:
- OpenDCC, zie http://www.opendcc.org, had je al gevonden volgens mij...
- Digital Direct in een aantal vormen: http://sourceforge.net/projects/ddw, maar ook MRDirect (http://www.mrdirect.nl) is hier een variant op.
Het ene principe werkt op basis van een microcontroller, de ander op basis van een PC.
Waarom sluit je je niet gewoon aan bij een van deze projecten?
Als je mogelijkheden mist kun je ze zelf toevoegen, daar is open source nou net voor bedoeld...
Wat ik in dat verband ook net begrijp is hoe je erbij komt om een onkosten vergoeding beschikbaar te stellen, of heb je soms commerciele bedoelingen?
Als dat het geval is denk ik dat je nummer zoveel in een lange lijst bent, kijk es naar de recentelijk uitgekomen Raptor bijvoorbeeld, dus dat lijkt me niet zo zinvol.
Als je doelstelling is om het nog goedkoper te doen dan bijvoorbeeld MRDirect of het OpenDCC project, neem dan geen AVR maar ga uit van een echt goedkope oplossing met een PIC.
Ook dat wieltje is al es uitgevonden, zie de site van Paco http://usuaris.tinet.org/fmco, en wat Wim en Karst op basis van de LokMaus al hebben gepresteerd (en dat is niet echt eenvoudig, zie de recente bugfix)...
Als je dan toch met een AVR aan de gang wilt en hulp wilt, raad ik je aan om verder te borduren op OpenDCC, daar zijn vast nog meer mensen actief mee bezig.
Veel succes en vooral plezier gewenst, 8)
-
MiNiDiGi centrale, is dat een ander woord voor Profi-Boss?
Voor 100 euries heb je alles wat je wil.
DCC generator (Centrale) en LocoNet aansluiting. Wat wil je nog meer?
Mvg
Wim.
-
Ik zat even te twijfelen of ik op deze eerste reacties moest reageren of dat ik gewoon zou zeggen:
"Neem even de moeite om het hele verhaal te lezen voordat je vragen of opmerkingen plaatst welke reeds beantwoord zijn of waarvan het hoe en waarom reeds is uitgelegd."
Maar dat is natuurlijk niet helemaal eerlijk want ik vraag zelf om feedback. ;D
@Wim
De reactie over de Profi-Boss lijkt me overbodig. Die info staat reeds overal op het forum. Het is geen software-centrale en zodoende een hele andere oplossingsrichting. Bovendien weet je al dat ik die heb want ik heb een bestelling bij jou open staan om diezelfde Profi-Boss aan de pc te koppelen. Of was je me alweer vergeten? :P
(Is er trouwens al zicht op uitlevering van de betreffende LocoNet interface???)
DDW is inderdaad een mooi (en vergelijkbaar) systeem. Sterker nog, door DDW ben ik op het idee van een software-centrale gekomen.
Wat is er dan mis met DDW? Tja, wat was er mis met DDL? Of waarom MRDirect? En zo kan ik natuurlijk nog wel even doorgaan. Ontwikkelingen volgen elkaar nu eenmaal op.
Mijn probleem met DDW was de RS232 poort. Die zit niet op mijn laptop. Ja, dat is op te lossen maar ik heb ter lering en vermaak een andere oplossing gekozen.
Zoals je bijvoorbeeld ook een RS232 -> USB converter kunt aanschaffen om een 'aansluit-probleem' te overbruggen (jij gebruikt dat ook!), zo kun je ook dit interface bouwen als je geen RS232 poort hebt maar wel DCC-signalen wilt fabriceren. Of wanneer je wel een centrale wil programmeren maar niet uit wil zoeken hoe je dat om moet zetten in DCC-pulsen. Of ... vul maar in...
Wil je dat allemaal niet dan heb je niks aan dit gevalletje...
@HansQ
Voor het eerste gedeelte: Zie boven...
Commerciele doelen? *rofl* (voor wie het niet kent: Rolling On the Floor Laughing)
Alsof het 'commercieel' verantwoord zou zijn om alle ideeen hier te delen. Ik vraag me af hoe er in deze situatie sprake kan zijn van een winstgevend verhaal...
Het gaat mij er om dat er misschien mensen mee willen doen die het net even te ver vinden gaan om er ook kosten voor te maken. Kosten die ik er wellicht wel voor over heb omdat ik ze anders zelf toch ook moet maken. Een (trein)hobby kost nu eenmaal geld...
Is een PIC goedkoper? Dan zal ik die optie zeker bekijken. Al staat ook in de tekst waarom ik in de eerste plaats voor een Atmel had gekozen...
Ik denk dat die link interessant is voor Peter, want die gebruikt een PIC als basis.
OpenDCC... Dat is inderdaad de basis.
Toch bedankt voor het meedenken en het tonen van interesse. Ik hoop dat ik niet al te bot over kom want ik heb heus waardering voor de input.
Groet,
Jeroen.
-
Jeroen,
Met alle respect die er op de wereld te vinden is, maar waarom het wiel opnieuw uitvinden. Open DCC is er DDW/DDL is er. Join theme.
Kind Regards
Wim.
-
Beste Wim,
... ik heb ter lering en vermaak een andere oplossing gekozen.
Ik neem het je niet kwalijk, er zijn namelijk hele volksstammen in mijn omgeving te vinden die zich afvragen waarom ik ineens een halve studie electronica zit te volgen. ;D
Diezelfde mensen vragen zich ook af wat een volwassen vent met treintjes moet...
Tja, wat moet je daar nou op zeggen? Sommige dingen zijn voor de één heel duidelijk maar voor de ander totaal onlogisch.
Feit is dat ik weer helemaal opleef sinds ik eindelijk weer tijd heb/neem om 'nieuwe dingen' uit te proberen. Sinds de start van mijn 'bedrijfje' in 2002 heb ik geen moment rust meer genomen. Toen ik begon moest ik alle zeilen bij zetten om niet over de kop te gaan en sindsdien heb ik steeds al het werk beetgepakt wat ik kon krijgen, puur uit angst dat er weer een slechte tijd zou komen. Aan het eind werkte ik meer dan 80 uur per week!
Op een dag gaan je ogen open en denk je: Dit is ook geen leven. Het stomme is dat het al tijden zo goed gaat dat het al lang niet meer nodig is om zoveel te werken.
Ik werk nu 'gewoon' 40 uur per week en heb opdrachten liggen waar ik nog het hele jaar mee vooruit kan. Dat betekent dat ik ineens gemiddeld 4 uur per dag over hou voor leukere zaken.
Mijn goed recht toch om een flink deel van die uren te vullen met iets waar ik met volle teugen van geniet? Meer of minder zinvol, het is best een interessant project. Een centrale nabouwen is ook leuk maar ik wil het allemaal ook echt begrijpen. Door dit project ben ik gedwongen om het tot op de bodem uit te zoeken en met een beetje geluk wordt het daardoor een beter of goedkoper alternatief. En zo niet dan was het een leuke en leerzame bezigheid...
En wees gerust. Ik ben echt niet het hele wiel opnieuw aan het uitvinden. In grote lijnen ben ik de OpenDCC centrale in tweeen aan het hakken en knoop ik beide delen weer aan elkaar met een USB interface er tussen. Door een stuk naar de pc te verhuizen wordt het wat eenvoudiger om koppelingen te maken met andere systemen. En de hoeveelheid hardware neemt ietsje af waardoor het weer makkelijker en goedkoper zal zijn om na te bouwen.
Groet,
Jeroen.
-
Hi Jeroen,
Helaas ben ik geen elektronicus anders zou ik zeker meewerken. Het is gewoon leuk om dieper in deze materie te duiken en is eigenlijk een uitbreiding op je bestaande hobby (modelspoor)
Heb je al contact gehad met Dave van der Locht? (Diegene met Atmel als avatar) Hij heeft verschrikkelijk veel kennis van deze materie en is altijd heel behulpzaam. Als ik goed geïnformeerd ben is hij ook met z'n eigen centrale bezig, uiteraard de Atmel als basis)
Ik wens je veel succes.
Groetjes,
Arthur
-
Arthur,
Heb je de andere draadjes al gelezen?
@Jeroen: Dat is nu het gevolg van een nieuwdraadje starten wat over hetzelfde gaat. Nog meer spreiding van informatie dus.
Mvg
Wim.
-
Jeroen,
Ik begon over een PIC omdat die net wat goedkoper zijn, de eenvoudigsten geen externe clock nodig hebben en heel eenvoudig (en dus goedkoper) te programmeren zijn...
Ik wou je ook even wat goedbedoeld advies geven. Ik zit zelf al bijna 20 jaar in de IT en ik heb als hobbyist het een en ander aan ervaring met embedded systemen. Daarom peins ik er zelf niet over om zoiets complex als een 'OpenDCC' centrale te gaan bouwen omdat het al lang en breed eens gedaan is. Als ik me niet vergis hebben een aantal mensen daar jaren aan gewerkt en hadden ze van te voren al behoorlijk wat kennis van de materie.
Als je toch wil proberen om helemaal opnieuw te beginnen moet je dat natuurlijk zelf weten, je zult er in ieder geval een heleboel van leren. Maar ik denk dat het sneller gaat als je je gewoon aansluit bij een bestaand alternatief. Als je nuttige nieuwe dingen aandraagt voor OpenDCC of DDW zal dat vast gewaardeerd worden...
Als je nog weinig of geen ervaring hebt met embedded systems of programmeren van PC's op systeem nivo, kan ik je alleen maar aanraden eerst eenvoudig te beginnen. Bijvoorbeeld net als Dave met een ontwikkelboardje. Over in 2en hakken; ik neem aan dat je naar het principe van DDW/DDL hebt gekeken, dat is dus niet meer nodig... :)
-
Tja... Wielen opnieuw uitvinden... Zelf heb ik het ook gedaan (en nog), en vindt het nog steeds erg leuk... En de redenen waarom? Die van mij zwerven hier ook ergens op het forum. En Wim, met o.a. het LocoNet interface idem dito (met alle respect). Dergelijke initiatieven en projekten van anderen vindt ik altijd leuk en interessant, en met mij vele anderen.
@HansQ: PIC ietwat goedkoper klopt in de meeste gevallen, maar appels kennen ook meerdere soorten welke niet prijs-gelijk zijn... Onderling zijn er toch meestal wel wat verschillen, wat uiteraard ook te zien is in de prijs. Maarja, of die 1 euro verschil nou de keuze voor AVR of PIC moet uitmaken? Sorry, maar dan ben je echt aan het mieren..... ;) In principe maakt het niet zo heel veel uit, gebruik gewoon wat je het beste ligt en voldoet aan je specificaties, wensen en eisen. AVR's hebben overigens ook een interne clock (en externe) en zijn ook eenvoudig te programmeren (en goedkoop), of dat PIC dan goedkoper te programmeren is? Tja, het systeem ISP en ICSP is nagenoeg gelijk en een programmer daarvoor ook, dus lijkt me sterk dat dat bij PIC dan goedkoper te programmeren is. Maargoed, dat is een totaal andere discussie die niet echt relevant is maar waarvan ik bovenstaande toch even wilde opmerken.
Eenvoudig of geavanceerd, vele microcontroller schakelingen beginnen hier op een breadboard. Erg handig in gebruik en om aanpassingen/toevoegingen te maken.
@Arthur: Waar heb jij de afgelopen dagen gezeten? ;) Centrale is overigens inmiddels al een flinke tijd in gebruik zoals deze nu is (eigenlijk al compleet). Echt bezig ben ik er niet (meer) mee, wel met andere dingen. ;)
Maar verder, ik zie voor het MiNiDiGi gebeuren wel een mogelijke goede toekomst als open source projekt...
Er zijn toch wel wat dingen waarvan ik denk dat 't wel eens nuttig / handig kan zijn. Zeker ook gezien de punten die in de andere topic(s) zijn aangehaald. Deelnemen hieraan is echter (nog) niet voor mij weggelegd denk ik, heb 't redelijk druk en benut m'n vrije tijd momenteel liever aan andere dingen... :P
Groetjes,
Dave
Groetjes,
Dave
-
Hi Wim,
Ik heb ze heel vluchtig een keer doorgelezen. Ik reageerde dan ook alleen op het bovenstaande bericht. Ik vind dat Dave het hier heel goed verwoordt. Die gedachtegang heb ik ook.
@Dave: Tja ik heb je project niet zo heel goed gevolgd. Maar ik begrijp dat 'ie naar volle tevredenheid werkt? Ondanks dat je misschien geen tijd hebt voor zo'n project is het dan geen idee om jouw project als open source aan te bieden? Met schema's, software, enz.
Wie weet wat voor moois er uit komt. Zie de andere projecten zoals met de multimaus of loconet. Petje af hoor.
Voor de rest kan ik weinig toevoegen aan dit draadje en heb ik ook de benodigde elektronica kennis niet. Ik ben wel van mening dat een project zoals dit te ingewikkeld is als je niet over de benodigde kennis beschikt.
grt,
Arthur
-
@jeroen
Vooral doorgaan met je project. Ook al lijkt het veel op het wiel opnieuw uitvinden, jouw gedachten kunnen bijzonder leuke nieuwe gezichtspunten opleveren. De eigenschap om dingen te willen veranderen/verbeteren is een betere eigenschap dan de achteroverleunende eigenschap: "dat hebben we toch al?"
-
@jeroen
Vooral doorgaan met je project. Ook al lijkt het veel op het wiel opnieuw uitvinden, jouw gedachten kunnen bijzonder leuke nieuwe gezichtspunten opleveren. De eigenschap om dingen te willen veranderen/verbeteren is een betere eigenschap dan de achteroverleunende eigenschap: "dat hebben we toch al?"
Volgens mij wordt er nergens gezegd dat Jeroen moet stoppen, er wordt alleen gezegd om aan te sluiten bij al reeds bestaande projecten, en die met deze ideeën aan te vullen. Wat heeft het voor nut om van nul af te beginnen?
Mvg
Wim.
-
@Dave: Tja ik heb je project niet zo heel goed gevolgd. Maar ik begrijp dat 'ie naar volle tevredenheid werkt? Ondanks dat je misschien geen tijd hebt voor zo'n project is het dan geen idee om jouw project als open source aan te bieden? Met schema's, software, enz.
Ja deze werkt reeds een tijdje naar volle tevredenheid zoals ik destijds voor ogen had...
Ik ben nu langzaamaan bezig om een van een aantal van mijn eigen projekten gereed te maken 'voor het publiek'. Dit houdt voornamelijk het maken van handleidingen in. Gecompileerde software, schema's en PCB-layouts zijn reeds klaar. Echter zal ik mijn (huidige) projekten niet als open source aan gaan bieden om een aantal redenen.
Als ik wat meer (vrije) tijd zou hebben, zou ik op zich wel mee willen werken aan een nieuw open source projekt. Wielen opnieuw uitvinden zou in dat geval ook niet zo'n issue zijn aangezien ik zelf die wielen al reeds opnieuw heb uitgevonden. Ze dienen dan 'alleen' in een nieuw projekt toegepast te worden. Maargoed, zoals ik reeds aangaf is (vrije) tijd op het moment toch een probleempje... ;)
Groetjes,
Dave
-
Het begint alweer een aardige opsomming te worden van voors en tegens, mogelijkheden en onmogelijkheden, do's en don'ts...
Dat vind ik nou het mooie aan een forum. Het is net één grote brainstormsessie, maar dan op een manier dat je achteraf nog eens rustig kunt nalezen wat er ook alweer allemaal werd geroepen.
Zoals altijd, en ik zie dat als positief, zijn er ook kritische geluiden. En hoewel opbouwende kritiek nu eenmaal makkelijker 'geslikt' wordt dan 'recht voor zijn raap' kritiek, aan het eind van de rit is ook kritiek geven een valide manier om kennis en ervaring te delen. Ik hecht er dan ook evenveeel waarde aan als aan alle andere vormen van informatie.
Ik heb inmiddels eens nagedacht over het idee/advies om me aan te sluiten bij bijvoorbeeld het OpenDCC project.
Eerst dacht ik: Dat wordt niks, want mijn idee past niet in hun doelstelling.
Maar ik ga er toch een paar mailtjes aan wagen. Een beetje netwerken kan immers nooit kwaad.
@Dave
Geen probleem dat je geen tijd hebt. Ik ben al lang blij dat je me door je reacties steeds weer op weg helpt als ik vast dreig te lopen. 8)
Inmiddels ben ik aan de hand van de gevonden code uit OpenDCC in de datasheet gedoken van de ATMega8. Er ging een wereld voor me open! Als je eenmaal weet waar je het moet zoeken dan is het alleen nog een kwestie van goed lezen (soms 10x maar het lukt!) om het te kunnen volgen.
De ontwikkelomgeving begint ook vorm te krijgen. Heb AVR-Studio aan de praat in combinatie met het evaluation board en WinAVR. Zit alleen nog even te vogelen met de vraag hoe ik de code kan debuggen. Dat lukt wel in AVR-Studio maar niet in de C-code op WinAVR... Blijkbaar iets niet goed gelezen. >:(
Verder zijn de experimenteer printjes binnen, samen met de setjes draden, weerstanden, elco's, ledjes en een kleine(re) soldeerbout. (wat ik had was niet geschikt voor het betere priegelwerk)
Trouwens, even een gekke vraag: wat is die geur die van de printjes af komt? Kon me niet herinneren dat daar zo'n sterke lucht aan zat... ???
De bestelling was overigens nog niet binnen of ik bedacht me dat ik natuurlijk wel op tijd een booster moet hebben wil ik iets kunnen testen. Dat verhaal stond voor een later tijdstip op de planning maar dat ga ik toch maar wat naar voren halen. Vanavond even uitzoeken of ik inderdaad de OpenDCC booster ga gebruiken en wat ik daar allemaal voor nodig heb...
Tot zover de stand van zaken. En tot zover bedankt voor alle input/motivatie/kanttekeningen enz. ;D
Groet,
Jeroen.
-
Bij het bekijken van de OpenDCC booster liep ik tegen de DCC-Sniffer aan. Een handig apparaatje om dcc-signalen mee te lezen/testen.
Dat betekent:
1. Ik wacht nog even met een booster
2. De eerste kandidaat voor een experimenteerprintje is gevonden
8)
Groet,
Jeroen.
-
Jeroen,
Als ik het goed begrijp gaat er een wereld voor je open. Soms is het advies nog niet zo slecht als men zegt kijk eerst wat er is, en ga dan verder met ontwikkelen. Of kom tot de conclusie dat alles er eigenlijk al is, alleen moet het nog even op smaak gebracht worden. ::)
Een booster hoef je niet te bouwen. Je kunt een Delta Control 6604 van Marklin gebruiken op beurzen te koop voor ongeveer 15,-- euries.
Mvg
Wim.
-
Jeroen...
Heb je nu al een centrale?
Zoniet, bestel dan gewoon de print van de OpenDCC centrale en ga dat ding bouwen!
Jij bouwt dan de versie met usb naar rs232 omzetter, maar met de booster.
Dan heb je een start punt!
Een sniffer is leuk, maar je moet wel een dcc centrale hebben om een signaal te genereren.
Wil je zelf snifferen, dan heb je ook genoeg aan 3 weestandjes en 2 diodes, een pc met een geluidskaart en een programmaatje.
Met dat zelfde programma'tje heb ik ook het screenshot gemaakt van de dcc stack, in een ander topic een tijdje geleden.
Ik heb het idee dat je heel enthousiast bent, dat is heel goed, maar je moet wel ergens een start punt hebben.
Met de OpenDCC centrale heb je gelijk een mooie ontwikkelset, met een JTAG adapter kun je dan ook de code debuggen, je hebt een programmeerspoor en een hoofdspoor, 3 s88 bussen, eventueel een expressnet interface, en wat knopjes en wat ledjes. behoorlijk compleet dus.
groet,
Guus
-
@Wim
Bedankt voor de tip, ik zal bij een volgend beursbezoek eens snuffelen.
@Guus
Komt goed, ik ga dat ding bouwen... Op mijn eigenwijze manier... ;D
Spulletjes voor de sniffer zijn besteld. Gelijk maar wat extra componentjes genomen om de verzendkosten uit te sparen...
Dit is trouwens ook een aardige. Van die sniffer heb je 2 varianten, DIL en SMB. Dus ik kies voor de DIL variant want dat is makkelijker solderen. Heb je daar een kabel van ftdi voor nodig. Dus ik zoeken wat dat voor kabel is. En wat zie ik?
*****
The TTL-232R is a USB to Serial (TTL level) converter cable which allows for a simple way to connect TTL interface devices to USB.
The TTL-232R uses a FT232RQ device which is housed inside the USB 'A' connector, and is terminated at the end of a 1.8 meter cable with a 0.1" pitch header socket which provides access to transmit (Tx), receive (Rx), RTS#, CTS#, Vcc (5V), and GND.
*****
Ik was al zoiets van plan maar omdat ik die chip niet wou solderen had ik mijn zinnen gezet op het evaluatiekitje (UM232R). Daar zat de chip op een printje voorgesoldeerd, samen met een USB aansluiting. Met aan de print pennetjes zodat je hem in een DIP kan steken. Maar dan had ik natuurlijk wel een 'gedrocht' van een USB interface.
Dit is veel mooier en blijkt hetzelfde te kosten. 8)
(Ik zie alleen wel dat het de moeite loont om die dingen op een dag zelf te leren solderen want dat scheelt meer dan de helft)
Weer een stukje van de puzzel op zijn plek... ;D
Groet,
Jeroen.
-
@Wim
De Delta Control 6604 valt voor mij af want deze kent geen cut-out functie. Nu nog niet erg, maar ik zal hem dus 'ooit' moeten vervangen. Dan stop ik die €15,- liever meteen in de booster van OpenDCC. Deze komt natuurlijk wel iets duurder uit (ongeveer €7,50 extra) maar dan ben ik wel meteen klaar. En zo kan ik weer iets zelf bouwen, anders komen die experimenteerprintjes nooit op ;D
Voor mensen die RailCom niet interessant vinden is dit echt een goeie tip!
Ik was er in ieder geval nooit op gekomen...
Groet,
Jeroen.
-
Toen ik de LocoNet specs ging downloaden kwam ik ook een patentaanvraag tegen, met betrekking tot bidirectionele communicatie.
Tot vandaag had ik daar nog niet heel veel aandacht aan besteed omdat het stuk nou niet bepaald 'leesbaar' is voor het algemene publiek.
Vandaag heb ik dan toch de moeite genomen en geprobeerd te begrijpen waar ze het nou eigenlijk over hebben... Viel niet mee maar inmiddels is de strekking van het verhaal me duidelijk. Voor wie geen zin had om het stuk te lezen of er nog minder van begreep dan ik volgt hier een *ahum* zeer vereenvoudigde versie, bedoeld voor mensen die enigzins bekend met het fenomeen tweeweg-communicatie met decoders...
Het onderwerp is overigens niet helemaal 'on-topic' maar omdat ik juist vanwege dit soort nieuwe ontwikkelingen zelf een centrale ben gaan bouwen leek het me toch wel weer op zijn plaats...
Het patent gaat in feite over een 'verbeterde' versie van RailCom. Of het ook echt 'beter' is blijft altijd de grote vraag. In theorie lijkt het van wel. In de praktijk zijn beide systemen nog niet operationeel dus valt er niets over te zeggen...
De gedachte achter beide systemen is hetzelfde, namelijk tweeweg communicatie met decoders. Hoe je de communicatie (het antwoord) van de decoder 'leest' is daarbij wezenlijk anders.
Bij de RailCom-variant wordt op afgesproken tijdstippen 'tijdelijk' de spanning van de baan weggenomen (cut-out periode) en in die tijd kan de decoder een 'antwoord' op de baan zetten. Dit antwoord bestaat uit digitale stroompulsen, vergelijkbaar met het dcc-signaal, welke door een zg. RailCom-detector gelezen kunnen worden.
Omdat er echter nog behoorlijk wat 'storing' op de baan aanwezig kan zijn tijdens de cut-out periode moeten de antwoordpulsen dusdanig sterk zijn dat ze overduidelijk gehoord kunnen worden, met nogal wat piekstromen als gevolg, welke een potentieel gevaar op kunnen leveren voor alle aangesloten apparatuur. Daarnaast keert na de cut-out periode plots de stroom weer terug en die 'klap' moet een decoder wel op kunnen vangen. En tot slot kunnen 'echo's' van de antwoorden per ongeluk verward worden met echte antwoorden.
Bij het Digitrax patent wordt geen cut-out voorgesteld maar antwoord de decoder 'dwars' door het reeds op de baan aanwezige signaal heen. De decoder kan dus niet geconfronteerd worden met een plotseling terugkeren van de spanning. Het signaal van de decoder is in tegenstelling tot RailCom juist beduidend 'zwakker' gekozen dan het dcc-signaal waardoor er van potentiele schade aan aangesloten apparaten geen sprake kan zijn en het dcc-signaal er niet door gestoord wordt. De grote vraag is dan natuurlijk: Hoe kun je het antwoord dan nog 'horen'?
Nu is dat het grote 'abracadabra' gedeelte van het patent maar ik zal een poging wagen om het onder woorden te brengen.
De grap is dat je twee verschillende pulsen in één signaal kunt onderscheiden, mits ze op vooraf bepaalde momenten 'uit de maat' lopen.
Een dcc puls bestaat bijvoorbeeld uit 58 microseconden lang een positief signaal, gevolgd door 58 microseconden lang een negatief signaal. (het bitje "1"). Je weet dus dat er gedurende die 58 microseconden geen faseverschuiving plaats kan vinden van positief naar negatief.
Stel nu dat een decoder precies in die periode (heel zachtjes) antwoord geeft waarbij zijn signaal wel degelijk wisselt tussen positief en negatief maar dat dat signaal niet zo sterk is dat het dcc-signaal er last van heeft.
Precies! Dan moet je dat zwakkere signaal er uit kunnen filteren omdat je immers weet 'waar' het 'sterke' dcc-signaal zich op dat moment bevindt.
En zie daar, het principe van Digitrax.
Tot slot het 'echo' probleem. Ook weer hogere wiskunde, maar het komt er op neer dat een juist antwoord met dezelfde polariteit begint als het startpunt van het dcc-signaal (dcc +, decoder antwoord +) en de echo is precies tegengesteld (dcc +, decoder antwoord -).
Tot zover voor de liefhebbers...
Mocht ik het bij het verkeerde eind hebben dan staat bovenstaande text natuurlijk open voor verbeteringen.
Groet,
Jeroen.
-
Ik snap niet wat je bedoelt met "niet operationeel" als het om Railcom gaat. Diverse decoders ondersteunen het en oa Lenz heeft al een soort van "uitleesunits" op de markt gebracht. Zie http://www.digital-plus.de/digitalplus/digitalplus_railcom.php
Let wel, ik heb het zelf niet werkend dus kan niks over de praktische mogelijkheden zeggen.
-
Beste JAB van Ree
De RailCom techniek bestaat al wel, maar je kunt er momenteel nog niet zoveel mee. Er zijn namelijk nog geen duidelijke afspraken gemaakt over de berichten die men over RailCom uit wil gaan wisselen. Sommige decoders lopen dus een beetje op de feiten vooruit, en zijn zeg maar 'voorbereid' voor RailCom. Er zijn inderdaad apparaatjes die bv. het adres van de decoder laten zien. Daar kun je alleen niet zoveel mee. Het wordt pas echt interessant wanneer er bv. centrales komen die naar de decoders kunnen luisteren.
Groet,
Jeroen.
-
Ook een aardige. Ik heb weer eens niet verder gekeken dan mijn neus lang is... Want het patent van Digitrax is wel degelijk operationeel onder de noemer 'Transponding'. En daar had ik dan ook meteen de eenvoudige uitleg van het systeem kunnen lezen!
;D Nobody's perfect :P
Groet,
Jeroen.
-
Waarna de logische vraag volgt doen Digitrax centrales er ook wat mee en zo ja wat?
-
De RailCom techniek bestaat al wel, maar je kunt er momenteel nog niet zoveel mee. Er zijn namelijk nog geen duidelijke afspraken gemaakt over de berichten die men over RailCom uit wil gaan wisselen. Sommige decoders lopen dus een beetje op de feiten vooruit, en zijn zeg maar 'voorbereid' voor RailCom. Er zijn inderdaad apparaatjes die bv. het adres van de decoder laten zien. Daar kun je alleen niet zoveel mee. Het wordt pas echt interessant wanneer er bv. centrales komen die naar de decoders kunnen luisteren.
Dat is niet wat er op de Lenz website word gesuggereerd :
http://www.digital-plus.de/digitalplus/digitalplus_railcom.php
Daaruit maak ik op dat het een complete bezetmelder/terugmeldoptie is, optioneel via USB terug naar de PC
-
Heel toevallig las ik op de site van Freiwald (Railroad % Co) een topic over railcom. Railroad ondersteund alleen communicatie met bepaalde Zimo decoders die overweg kunnen Railcom.
Voor de rest werd er niet dieper op ingegaan, dus don't shoot the messenger :)
grt,
Arthur
-
De Lenz producten voor railcom LRC 130 en 135 komen in de zomer 2009 beschikbaar.
De Ecos detector en detector extension 3 of 4 kwartaal 2009,
Tams Fabrikanten met decoders en of detectors waarin Railcom al is ingebakken: ESU, Lenz, Digitrax, Zimo, Tams, Kuehn.
Railcom wordt stevig ontwikkeld en zal uiteindelijk leiden tot een zeer interressant terug meldings systeem voor loks, magneetartikelen en aktie gestuurde mogelijkheden.
-
@JAB
Je hebt gelijk, ik zie dat ze alweer een stuk verder zijn dan een maand geleden! Al begrijp ik van Han dat het nog niet leverbaar is.
@Henk
Goeie vraag... Mijn woordkeus is misschien ook niet ideaal, want eigenlijk is het veel interessanter of er treinbesturingssoftware is die er iets mee doet...
@Han
Bi-directionele communicatie is zeker reuze interessant! Wel jammer dat er weer verschillende oplossingen op de markt worden gebracht, die niet uitwisselbaar zijn. Het had mooier geweest wanneer de oplossingen in ieder geval 'decoder-onafhankelijk' waren geweest. Maar ja, je kunt niet alles hebben...
Moet ik weer gaan kiezen welke variant er nu eigenlijk beter bij me past! (Om nog maar te zwijgen over de 'oorlogen' die uit gaan breken over welk systeem nu eigenlijk 'beter' is)
Groet,
Jeroen.
-
Keus zal voornamelijk gaan over de Global detector en de localdetector. Men wil er uiteindelijk een nmra norm van hebben ( ze zijn pas bezig vanaf 95 of zo:) dus de verschillen zullen uiteindelijk wel meevallen.
Tis nu even wachten wat de software boys er mee doen ( ben zeer benieuwd of koploper hier al iets over heeft) De truc van Esu om zijn terugmelder uit te rusten met 16 terugmelders waarvan 4 met Railcom lijkt me op dit moment de meest interressante. Met een beetje goede wil is zagen in de rails om melding mogelijk te maken straks zooo jaren 2000:)
-
Men wil er uiteindelijk een nmra norm van hebben ( ze zijn pas bezig vanaf 95 of zo:) dus de verschillen zullen uiteindelijk wel meevallen.
Dat geldt alleen voor RailCom. Digitrax heeft de hoop op nomering voor hun Transponder-systeem lang geleden opgegeven.
Met een beetje goede wil is zagen in de rails om melding mogelijk te maken straks zooo jaren 2000:)
Voor locatiebepaling zul je volgens mij nog steeds moeten zagen... Ook bij RailCom toch?
Het grappige is overigens dat de Digitrax variant blijkbaar al even in omloop is en dat ik daar nog niets over had gelezen. Daarentegen is de RailCom variant net wel/net niet op de markt maar lees je er overal al over...
En dat terwijl ik bij het vergelijken van de specs eerder voor Transponding van Digitrax zou kiezen... Volgens mij moeten die jongens meer aan marketing doen! ;D
-
Jeroen, het RailCom verhaal is ook al heel wat jaren oud, waarschijnlijk net zo oud als het Transponder verhaal. Een slap aftreksel is MFX van Märklin (ESU).
Al met al een systeem met veel haken en ogen, en vooral nog steeds in de kinderschoenen.
Mvg
Wim.
-
@Henk
Goeie vraag... Mijn woordkeus is misschien ook niet ideaal, want eigenlijk is het veel interessanter of er treinbesturingssoftware is die er iets mee doet...
Nou Jeroen, de vraag is of deze vorm van terugmelding de makers van treinbesturingssoftware voor de computer eigenlijk wel zoveel biedt. Paul Haagsma heb ik er nog nooit iets positief over horen zeggen.
Zoiets als Railcomm maakt stand alone automatisering met alleen een centrale wat gemakkelijker. Zoiets als Lissy, maar dan niet met infrarood.
-
Voor locatiebepaling zul je volgens mij nog steeds moeten zagen... Ook bij RailCom toch?
Railcom geeft een aantal dingen door: o.a snelheid . samen met bv wissels die hun actuele wisselstand terug melden en de lengte van je baanstukken moeten je treinbesturingssysteem die info geven waar de lok zich bevindt.
Het Lissy gebeuren lijkt interressant totdat je uitgaat rekenen wat dat kost. ( onbetaalbaar)
Dan kun je nog beter met het RFID van littfinski werken wat overigens al samenwerkt met railroad & co.
-
Dat moet je toch eens toelichten Han. De centrale/computer kan alleen iets met de snelheid en de lengte van de baanvakken in relatie tot een vast punt. Zo'n punt kan denk ik niet te ver weg liggen in verband met de betrouwbaarheid. Hoe worden die vaste punten dan doorgegeven?
Dit heeft overigens weinig met Railcomm te maken. De meeste computerprogramma's passen het door jou genoemde principe al toe. De centrale weet immers van zichzelf al hoe hard de locs rijden.
-
Nou Jeroen, de vraag is of deze vorm van terugmelding de makers van treinbesturingssoftware voor de computer eigenlijk wel zoveel biedt. Paul Haagsma heb ik er nog nooit iets positief over horen zeggen.
Henk,
Beetje kort door de bocht maar het klopt wel wat jij zegt. Als een besturingsprogramma goed werkt kan het voor mij op slechts 1 plaats toegevoegde waarde hebben en dat is de plek waar een handmatig rangeerterrein eindigt en de trein meegegeven moet worden aan het automatisch rijden.
Echter met de handregelaar optie van mijn programma is dit ook niet echt meer een probleem.
Als op het koploperforum gebruikers mij echt kunnen overtuigen van de meer waarde van deze toevoeging wie weet komt het dan wel, maar vooralsnog laat ik deze toepassingen links liggen.
-
Ik denk deze vorm van terug melding is echt belangrijk, voor een grote baan.
Ik heb immers de idee, dat de mogelijkheden met een programma beperkt zijn als je een vaste volgorde in de omlopen hebt. Dan denk ik immers an TV kijken. Ik heb meer de Idee van spelen op de baan, een niet de baan (of de PC) spelt voor mij. Nu is dit niet echt de punt van het transponder, maar als je nu van dit volgorde afwijkt, door een fout, een actie van een "met club lede" of een ongeluk en een foute herstel van dit ongeluk. Ben ik zeker zo'n transponder systeem is toch een goede hulp. Bijzonders als iedere station een bestuurder heeft met een eigen PC, dan heb je echt zo'n systeem nodig,..
Groet
Bernd
-
Hallo Bernd,
We wijken wel af van het oorspronkelijke onderwerp....
Je hebt wel gelijk met wat jij zegt, echter dat is niet mijn doelgroep. Mijn doelgroep is degene die lekker thuis met zijn treinen bezig is en dit graag geautomatiseerd wil doen. Koploper is gemaakt voor automatisch bedrijf!
Trouwens dit hoeft echt niet volgens een vast patroon te gaan. Hangt er echt vanaf hie je de software gebruikt. Ik denk dat meest gebruikte software producten beide mogelijkheden in zich hebben (vaste patronen of random gebeurtenissen).
Mvg,
Paul.
-
Je hebt gelijk, wij dalen af...
Ik dacht al, dat koploper niet voor dit bedoeld is...
@Jeroen, let op dit digitrax transponding werkt slechts met digitrax hardware en dan ook niet echt eenvoudig, maar als dit systeem werkt, werkt het goed...
Ik heb goede contacten met Zimo, se hebben ook een transponding-system noemt HLU, werkt ook niet met alle decoders :-|
Ik denk gebruiken van de code in de loconet specs is "envoudig" maar je hebt toch echt veel hardware voor nodig, kijk maar naar de handleiding van de BDL 168...
Groet
Bernd
-
De eerste kandidaat voor een experimenteerprintje is gevonden
Volgend ideetje, voor afremmen/stoppen zonder PC?
Vandaag mijn Lenz LG100 remsignaalgenerator eens opengemaakt, zit een Philips chip in met een dikke streep erdoor. Wat nog leesbaar is is P87C515? 4A. Lijkt tot de 8-bit microcontrollers te horen. Kent alleen de stand stop, is een "broadcast"bit waar alle decoders op reageren, en niet remmen tot lage snelheid (geel sein). Zoiets zou toch op een intelligentere manier met een PIC/Atmel kunnen, waarbij in stand "geel sein" alle snelheden boven een ingestelde waarde verlaagd worden naar een vaste waarde en snelheden die er al onder liggen ongewijzigd blijven, en bij stand "rood" alle snelheidsinformatie op 0 gezet wordt? Vraag is alleen of je dit met een sniffer oplost, dus systeem onafhankelijk op het DCC signaal, of op bus-niveau (xPressNet of LocoNet). Uitgang dan naar aparte booster(s).
Nadeel is dat je alle binnenkomende snelheidsinformatie moet bewerken. Bij uitbreiding met RailCom functionaliteit zou je dit kunnen beperken tot het gedetecteerde adres.
-
@ Henk
Een wissel is een vast punt en kent twee posities. die doorgegeven worden aan de centrale.
Het baanvak daarachter kent een lengte x(en is ingegeven in besturingsprogramma), Lok ( = uitzendende decodere) komt voorbij meldpunt met snelheid y en de besturingssoftware rekent in no time uit waar de lok in het baanvak zich gaat bevinden.
Het is inderdaad niet allemaal nieuw het enige wat nieuw wordt is dat de communicatie twee richting wordt. Maw de besturingssoftware ( denkt) te weten waar een lok is maar krijgt nu de bevestiging van de lok zelf.
-
Han, ik snap wel dat een wissel een vast punt is, maar de centrale/computer zal toch moeten weten wanneer de trein om het even welk vast punt (een wissel lijkt me eigenlijk niet zo handig) passeert, wil hij kunnen gaan rekenen. Dat wordt toch stukjes rails isoleren.
-
...Dat wordt toch stukjes rails isoleren...
Hoi,
Ook van mij maar eens een bijdrage aan dit onderwerp :)
Dat klopt helemaal Henk.
RailCom is eigenlijk niets anders dan een middel om data van de loc naar een 'RailCom-detector' te sturen.
Er kan allerlei nuttige info verstuurd worden, b.v. of een wissel is omgegaan, hoe warm een decoder is, wat het actuele motor toerental is etc. etc. Hier praten we over de z.g. dynamische CV's.
Dit is een generiek mechanisme, dus zover de fantasie reikt, zover kun je gaan.
Om echter te weten WAAR een trein zich bevindt, heb je idd lokale RailCom detectors nodig. Deze luisteren dan alleen specifiek naar dat stuk je rails waarop ze zijn aangesloten.
In essentie niets anders dan de huidig bekende methode van stroom detectie, alleen nu met de zekerheid dat er niet alleen bekend is DAT er een trein ergens is, maar ook WELKE.
Overigens elimineer je hiermee de generieke mogelijkheden van feedback van uit de decoder om dynamisch voornoemde parameters op een centraal punt uit te lezen en dit aan b.v. een computersysteem door te geven.
Interessant zou het worden, als er op de decoder een lees-inrichting zou zijn die b.v. 'bakens' in het spoor zou kunnen lezen en dit via railcom zou kunnen doorgeven. Dan kan e.e.a. wel weer centraal.
( overigens kom je hier dan weer op het verhaal van een RFID lezer in de loc die RFID tags uitleest die in de baan liggen, vergelijk b.v. ERMTS )
Een volgend probleem is het gebruik van boosters. Omdat RailCom alleen werkt in de stroomkring waarin zich de decoder opdat moment bevindt, zal in het geval van het gebruik van boosters, dus de RailCom info naar die betreffende booster met ingebouwde detector gaan.
Om naar Henk's opmerking terug te keren, puur als terugmelding kom je dan ook nog op het aspect kosten. In principe moet dan elke 'bezetmelder' als RailCom detector worden uitgevoerd. Deze signalen moeten dan b.v. via LocoNet ( of een ander bussysteem ) doorgegeven worden aan een centraal punt, b.v. een PC met besturingssoftware.
Kortom eens met Paul en Wim's opmerkingen, een goed werkend software systeem weet op de bezetmelder nauwkeurig WAAR een trein zich bevindt en heeft derhalve geen extra info nodig voor de positie bepaling. Wel zou het wellicht handig zijn om b.v. de actuele snelheid te weten voor b.v. het remmen. Maar zelfs dit is 'fraglich'.
In het geval wat Bernd beschrijft is e.e.a. wel degelijk zinvol. Je hebt het dan over meerdere onafhankelijke computersystemen, die bij binnenkomst van een loc in je controlegebied kunnen aangeven welke trein dat is.
Overigens heeft Uhlenbrock dat met z'n Lissy al aardig voor elkaar. De nieuwe IB's kunnen een loc automatisch op 1 van de regelaars zetten als die door Lissy gedetecteerd wordt.
Verder onthoud ik me van waarde oordelen over de zinvolheid van RailCom. Technisch is het aardig bedacht, wel redelijk gefreubelt overigens, dat de decoder stroom moet sturen door een kortgesloten centrale/booster uitgang !
Toepassingen zijn er ook voldoende, alleen denk ik dat je ze niet moet zoeken in het bereik van automatisch rijden en op bezetmelding lijkende systemen.
Grtzz,
Karst
-
@Wim
Je hebt (weer eens) gelijk. Het is inderdaad allemaal rond dezelfde tijd begonnen. (Heb het nog even opgezocht) Alleen is Digitrax uit de DCC-werkgroep gestapt omdat men gezamenlijk geen oplossing kon bedenken waarbij het aanpassen van bestaande apparatuur niet nodig zou zijn. (Bijvoorbeeld de aanpassing voor de cut-out)
Na een zelfstandige doorontwikkeling vond Digitrax een of twee jaar later wel een oplossing. En zo te zien is het zelfs al een tijdje op de markt. Dan moeten er toch mensen te vinden zijn die er ervaring mee hebben...
@Henk
Ik denk dat Han bedoelt dat je een blok (tussen twee wissels) niet meer in stukken hoeft te hakken omdat je met RailCom 'zeker' weet wat de trein wel of niet aan opdrachten heeft uitgevoerd en je dus ook preciezer uit kunt rekenen waar de trein zou moeten zijn.
Zoals jij zegt afleiden vanaf de pc kan ook maar dan weet je niet zeker of een opdracht ook echt door de decoder is uitgevoerd dus is het minder precies.
Al met al dus nog steeds de rails in blokken verdelen, alleen mogelijk niet meer in start-, rij en stopsecties. Het zal denk ik nog wel even duren voordat er een systeem ligt dat zó precies de locatie kan bepalen, maar dat is inderdaad de dag dat we de opmerking maken die Han hier schetst. ;)
@Paul
Ik ben met je eens dat het niet 'noodzakelijk' is. Maar het is op zijn minst 'handig'. Het is makkelijker om een trein willekeurig op de baan te kunnen zetten en dat de software hem automatisch met locatie en al registreert dan dat je die informatie handmatig aan de software moet vertellen. (Vooral na een pc-crash erg prettig)
Zoals jij en Bernd al aangeven is het pas 'noodzakelijk' wanneer je met heel veel vrijheid handmatig wil rijden. Kortom, wanneer je zoveel vrijheid hebt dat er wel eens (al dan niet per ongeluk) twee treinen in hetzelfde blok kunnen belanden. Dat 'zie' je alleen met zoiets als RailCom.
Omdat ik het speel-element heel erg belangrijk vind mik ik op een systeem waarbij je kunt aangeven of je die vrijheid wel of niet moet krijgen.
Ik vergelijk het met de parkeerhulp op een auto. Niet noodzakelijk, wel een toevoeging op het rijgemak, en heel af en toe behoed het je voor een stomme fout door een hoop lawaai te maken. Maar... hij trapt nog steeds niet op de rem voor je, en er hangt een prijskaartje aan. ;D
@Albert
Leuk om te lezen dat er meer mensen zijn het niet kunnen laten om een 'kastje' open te trekken en uit te zoeken wat het nou eigenlijk doet.
Heel erg leerzaam en dé manier om er achter te komen of er soms tekortkomingen in zitten die verbeterd kunnen worden.
Nu ben ik juist van de software, dus hardware die zelfstandig beslissingen neemt probeer ik zoveel mogelijk te vermijden. Maar dat is ieder voor zich natuurlijk want het kan net zo goed werken.
De sniffer bouw ik overigens puur om later de zelfbouw centrale te kunnen testen. Niet om functioneel toe te passen in het gebruik van de baan.
@Karst
Je was me voor dus ik dacht dat ik mijn verhaal wel weer weg kon gooien... Maar het valt mee. ;D
Vanwege die kortsluiting (en cut-out apparatuur) en de LocoNet aansluiting viel mijn oog op de digitrax variant als zijnde een 'betere' oplossing. Ik zou dat alleen wel eens gestaafd willen zien met ervaringen van gebruikers. En het prijskaartje is natuurlijk ook knudde.
Prijstechnisch wil je zelf een print kunnen maken welke bi-directionele communicatie en bezetmelding combineert waarbij de vraag is of je de aloude 'stroomdetectie' dan nog wel nodig hebt. Communiceren lukt immers alleen als er een decoder is om mee te praten.
Groet,
Jeroen.
-
Jeroen, volgens mij blijft stroom of massa detectie altijd nodig. Denk aan de wagons/rijtuigen, of wil je die ook van een zender voorzien (kassa).
Vooralsnog zie ik het als een leuk speeltje. Of het echt nuttig is bij computersturing heb er ernstige twijfels bij.
Crash van een PC wanneer komt dat voor? Bovendien onthoud koploper altijd de laatste situatie. Je kunt in de meeste gevallen gewoon weer verder.
Mvg
Wim.
-
Helder stuk Karst. Verder heb ik er wel eens in MiBa over gelezen. Daar proberen ze de lezers er op alle mogelijke manieren van te overtuigen dat het heel nuttig gaat zijn. Maar de praktische voorbeelden die ze dan noemen klinken zo onbenullig, dat ze mij er vooral van overtuigen dat de voordelen zeer beperkt zijn en in geen verhouding tot de (ombouw)kosten staan.
Ik begrijp dat het op een hele grote baan met verschillende besturingsterminals gemakkelijk kan zijn als een loc bij de overgang even vertelt wie hij is. Klinkt logisch, maar dat is een beperkte markt. Daar gaat het commercieel niet op draaien.
En voor de doorsnee zolderpiloot die het leeuwendeel van de markt vertegenwoordigt?
Basale informatie weet de centrale al. Hij heeft namelijk zelf de bijbehorende opdrachten verstrekt. Controleren of die opdrachten wel zijn uitgevoerd, is het paard achter de wagen spannen. De boel moet gewoon werken en in de praktijk blijkt dat ook mogelijk te zijn. De doodenkele keer dat een opdracht niet wordt uitgevoerd levert op de hobbyzolder ook niet gelijk grote rampen op hè.
Daar komt nog bij dat de retourcommunicatie ook kan falen en zelf een bron van storingen kan zijn. Het doet me een beetje denken aan alle electronica die tegenwoordig in auto's zit, waarbij door defecte electronica soms meer problemen worden veroorzaakt dan opgelost. Welke kans is groter: dat een opdracht niet wordt uitgevoerd of dat bijvoorbeeld een verkeerde wisselstand via Railcomm wordt gecommuniceerd?
Toerentallen, temperatuur, ja ja, nee nee, goh. ;D
Ik zie eigenlijk niet onmiddelijk hoe het terugmelden daarvan mijn modelspoorlol gaat vergroten, maar misschien zie ik grote mogelijkheden over het hoofd.
-
@ henk
T heeft idd veel te maken met de beleving van het modelsporen. In Europa rijden we bv veel liever in de rondte met vastgestelde treinen en trajecten. volg je daarentegen de Amerikaanse markt dan zie je veel point to point banen waarbij tijdens een operating sessie al veel meer het rijgedrag van een lok van invloed is( wordt gemaakt) op de uiteindelijhke doelstelling nl het vervoeren van vracht van a naar b. Denk maar eens aan het Way bill system. Als je dan kunt simuleren dat het toerental, kolenvoorraad en "what ever"snelheid- en reikwijdte bepalende elementen zijn (conform realiteit) dan wordt een systeem als Railcomm echt leuk.
Bovendien: Evolutie hou je niet tegen tenzij je woonplaats urk is ;) ooit begon dcc ook als speeltje ....
-
Ik ben volledig met Karst en andere eens Railcom heeft geen grote meerwarde voor een normale baan, ook niet voor een grote baan. Een PC met contact naar de centrale kan op elke punt het rem gedrag berekenen. Informatie uit de slot en van een detector icm de lengte van een sectie...
@han Ja, het Amerikaanse systeem point-to-point is heel leuke, maar heb je dit nu in europe? Veel club-banen zijn niet geschikt voor dit gebruik, heb je een geschikt baan, moeten nu alle clubleden railcom decoders aanschaffen, echt duur... Grappig is ook dat digitrax niet mee maakt aan Railcom,...
Het enigste voordeel van Railcom is denk ik het transponding van de Adres, de snelheid kan je niet echt uitlezen (heeft iets met de "Reibung, Massenträgheit" te doen) Dit is het zelfde met de terug melding van een wissel, de DS 54 geeft een melding "wissel heeft geschakeld" maar geen idee als de tongen nu in de juiste positie zitten...
Ik denk zo'n Railcom techniek heb je niet echt nodig voor een kleine baan, een voor mij ook niet voor een grote..
Groet
Bernd
-
Eens : nodig is het niet , maar wel leuk als het allemaal kan. Enne ik denk dat fabrikanten( en niet de minste) niet voor niets Railcom in hun decodertjes stoppen. We zullen zien. ::)
-
Ik zit net voor de grap even met een collega te brainstormen over dit verhaal. Deze collega weet niet zo heel veel van modelspoorbanen maar is net als ik wel een automatiseerder...
Vraagt hij op een gegeven moment aan me:
Wat vind je belangrijker? Dat de gewenste kwaliteit en functionaliteit geleverd worden in een technisch perfect maar prijzig pakket of dat precies diezelfde kwaliteit en functionaliteit geleverd worden in een technisch verouderd maar spotgoedkoop pakket?
Ik zeg: Dat laatste natuurlijk! Maar het is in dit geval niet dezelfde functionaliteit...
Hij zegt: Ik kan me niet voorstellen dat er zoveel functionaliteiten zijn die je niet op goedkopere manieren op zou kunnen oplossen.
En daar gingen we... We namen een functie van RailCom en gingen op zoek naar alternatieve oplossingen. En wat bleek? We konden maar 1 belangrijke functie bedenken die we niet zonder RailCom konden reproduceren: Het willekeurig plaatsen van een trein op de baan waarna deze automatisch bij het systeem wordt aangemeld.
Hij zegt: Nou, dat is nog ruim genomen want zolang je een trein niet in een bezet blok zet detecteert de pc al dat er 'iets' is neergezet. Dus je hoeft alleen nog maar te weten of dat 'iets' een trein is die aangemeld moet worden.
Ik zeg: Grappig, dan heb je naast RailCom decoders dus maar 1 Global RailCom detector nodig.
Hij zegt: Is het in de praktijk niet zo dat je altijd op dezelfde plek een trein op de baan zet? Bij een rangeerterrein of zo... Want dan hoef je alleen op dat stukje met de decoder te praten.
Ik zeg: Dan heb je helemaal geen RailCom meer nodig, maar alleen een stukje 'programmeerspoor' van waaruit je de baan op rijdt.
Ik ben geloof ik van mijn geloof gevallen... :-| :-| :-|
Groet,
Jeroen.
-
Maar met een dergelijk 'programeer' spoor doe je dan hetzelfde als het plaatsen van je locomotieven op de sporen in Koploper met het voordeel dat het bij Koploper overal kan.
Gr. Remco.
-
Jawel Remco, maar dan moet je wel een keer met je muis klikken om Koploper te vertellen om welke loc het gaat. Dat valt niet mee. ;D
Nou ja, als je een loc de allereerste keer op de rails zet is het aardig als die loc gelijk allerlei basale informatie doorgeeft. Hoef je dat niet in te voeren. Precies de basale variant van MFX.
-
Ja, dit is een oplossing, maar noem je dit fail-safe? Als ik slechts dit spoor gebruiken kan is het dan nog een flexibel systeem noemen?
Ik denk er zitten wat meer problemen in als een bezet melding volgen met enkele data in een buffer van een programma. Bijvoorbeeld een problem: Als je een trippel tractie koploper met drie adressen in een spoor aan de perron hebt, dan enkele stel vertrekt naar een andere richting, war is nu welke nummer? en ben je zeker?
Ik denk zo'n systeem hoeft aan enkele punten melders (Railcom, Transponding, RFID en zo...) nodig.
Groet
Bernd
-
@Remco
Ik bedoelde eigenlijk dat je op zo'n 'programmeerspoor' een trein volledig automatisch kunt aanmelden. De software detecteert daar een bezetmelding en gebruikt de 'speciale' programmeer-aansluiting van de centrale om de decoder uit te lezen. Met de gevonden gegevens wordt de loc vervolgens aangemeld en kun je rijden.
Handig of niet, ook dat is een beetje overkill (zoals Henk ook aangeeft)...
@Bernd
Nee, dat is niet heel erg flexibel, maar wel erg goedkoop!
Kijk, ik zou ook nog eerder voor 1 Global RailCom detector kiezen zodat je meteen kunt 'genieten' van de exotischere functies van RailCom.
Het lijkt me namelijk wel weer mooi als een decoder kan aangeven dat er iets mis is voordat hij door brandt...
Maar mijn eerste idee, om bij elke sectie ook een local RailCom detector (of soortgelijke functie) te plaatsen blijkt totaal overbodig.
Ook het voorbeeld van de triple-tractie trein met drie decoders is zonder RailCom op te lossen. Op voorwaarde dat de software bij het samenstellen van de drie treinen heeft onthouden wie waar zit (voor - midden - achter).
Ik moet overigens wel zeggen dat sommige oplossingen die we bedachten het gebruik van extra blokken noodzakelijk maakte. Maar aangezien die niet zo duur zijn weegt dat al snel op tegen het veel duurdere RailCom.
Groet,
Jeroen.
-
Ik bedoelde eigenlijk dat je op zo'n 'programmeerspoor' een trein volledig automatisch kunt aanmelden. De software detecteert daar een bezetmelding en gebruikt de 'speciale' programmeer-aansluiting van de centrale om de decoder uit te lezen. Met de gevonden gegevens wordt de loc vervolgens aangemeld en kun je rijden.
Handig of niet, ook dat is een beetje overkill (zoals Henk ook aangeeft)...
Het gebruik van een doodlopend *invoeg* spoor dat maar in één richting bereden wordt pas ik toe in mijn besturingssoftware om op een veilige manier automatisch een nieuwe trein op mijn baan te introduceren zonder dat je het risico loopt dat de nieuw geïntroduceerde trein een deadlock situatie veroorzaakt met 1 of meerdere treinen die reeds aanwezig zijn in de baan. De railcom detectie zou hier mooi in passen. Overigens heb ik voor het tegenovergestelde doel ook een uitrijspoor.
mvg,
Patrick Smout
-
Leuk hoor al die theorie, maar de praktijk is dat het besturingsprogramma de lok al kent als het gaat om het uitrijden naar een rangeerterrein. Hij gaat dan gewoon uit het automatische bedrijf en verder onder handbediening.
Wil je hem weer opnemen dan zet je hem van handbediening weer op automaat en sleep je hem naar het volgende blok in koploper. Koploper bepaald dan wanneer hij vertrekt.
Heb je voor dit spel (speel) element dan railcom nodig?
Railcom verteld iets aan de centrale, maar verteld nog steeds niets aan het besturingsprogramma zelf. Doe dat gewoon zelf zou ik zeggen en denken.
Iedere nieuwe lok zo uit de winkel staat op adres 3, dus die moet je toch via een programmeerrails een ander adres geven, en dan kun je die gelijk bij het besturingsprogramma invoeren, met naam soort trein enz. enz.
Mvg
Wim.
-
Leuk hoor al die theorie, maar de praktijk is dat het besturingsprogramma de lok al kent ... koploper. Koploper bepaald dan wanneer hij vertrekt.
Heb je hier railcom voor nodig? Nee dus, maar het kan wel in deze toepassing als was het maar om te voorkomen dat je bvb een loc met een dubbel adres de baan op zou sturen. Kan dit met Koploper - geen flauw idee? Is het zinvol? Voor een thuisbaan waarschijnlijk niet maar misschien wel voor een grote clubbaan waar leden diverse locs van thuis meebrengen.
mvg,
Patrick Smout
-
Patrick,
Ik zie niet hoe Railcom kan voorkomen dat een lok met een al bestaand adres kan worden tegen gehouden. Lijkt mij eerder dat het sneller wel kan gebeuren, dan dat de treindienstleider van een grote clubbaan bepaald of een lok kan en mag meedoen.
Als je het aan het automatische melden overlaat ben je de controle over dubbele adressen denk ik kwijt. Een lok kan en mag zich namelijk op twee plaatsen tegelijk bevinden. Denk aan overgangen van Railcom detectie secties, die aan elkaar grenzen.
Mvg
Wim.
-
Patrick,
Ik zie niet hoe Railcom kan voorkomen dat een lok met een al bestaand adres kan worden tegen gehouden. ... Een lok kan en mag zich namelijk op twee plaatsen tegelijk bevinden. Denk aan overgangen van Railcom detectie secties, die aan elkaar grenzen.
Wim,
mijn uitgangspunt was 1 enkele railcomdetector op het invoegspoor, voortbordurend op de vorige mail(s).
Zoals jij het brengt kan het idd. niet.
grtz,
Patrick
-
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? ;D ) commentaar...
-
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.
-
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?
-
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
-
@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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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...
-
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.
-
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.
-
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?
;D ;D ;D
Groet,
Jeroen.
-
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)?
Het begrip *TTL* bij deze optocoupler slaat op de uitgang van de optocoupler, niet op de ingang (led). De optocoupler led gedraagt zich al een gewone led en heeft dus een voorschakelweerstand nodig om de stroom te begrenzen. De weerstand dient dus niet om van +12V over te gaan naar TTL. (Zou je dat wensen dat heb je en zogenaamde spanningsdeler nodig bestaande uit 2 weerstanden). De waarde van de weerstand kan je berekenen vanuit de spanning (+12V) en de typische stroom door de led. Deze haal je uit de datasheet en bedraagt tss. 5 en 15mA. Neem maar 5mA. Wil je het helemaal goed doen moet je ook nog rekening houden met de spanningsval over de LED. Halen we ook uit de datasheet, 1.5V .
Met de wet van Ohm komen we dan op op R=(12V-1.5V)/5mA = 2100 Ohm, afgerond 2K2.
En klopt het dat ik de booster met de geplaatste weerstand kan testen door hem achter de profiboss te hangen?
Kan ik je geen antwoord op geven - Ik weet niet welk uitgangsniveau een profiboss heeft.
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?
Nee, dan gaat het aardig fout. De stroom wordt dan enkel begrenst door de uitgangsweerstand van de TTL uitgang van de minicentrale - zie ook boven.
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?
Ik zou zeker geen andere hobby zoeken, al doende leert men.
-
Ik weet niet welk uitgangsniveau een profiboss heeft
Ik wel ;) 12v op de pinnen 1 en 6 t.o.v. de LN GND op pinnen 2 en 5 op de LocoNet aansluiting.
Let op 1 en 6 niet kortsluiten, hier staat hetzelfde signaal, alleen dan in tegenfase.
Grtzz,
Karst
-
:-| *zucht*
Bedankt voor de uitleg! Ik ben blij dat ik het toch maar even gevraagd heb...
Er had natuurlijk een lampje (ledje?) moeten gaan branden want dat van een voorschakelweerstand wist ik en dat de optocoupler met een led werkt ook...
dom dom dom :-[
Hoewel ik er dus hardstikke naast zat geeft je uitleg gelukkig wel weer wat houvast. Ik kan hiermee dus aan de hand van de uitgangsgegevens van de profiboss berekenen wat voor weerstand ik moet plaatsen om de booster met de PB te kunnen testen.
(het spanningsverval is neem ik aan wat aangeduid wordt met 'Vf = Input Voltage' uit de datasheet?)
Nu wordt het uitgangsvoltage van de minicentrale ongeveer 5V (USB voeding). Wanneer ik uitga van 10mA (Typische waarde voor de led in de optocoupler) dan moet ik in dat geval dus een weerstand plaatsen van 350 Ohm?
@Karst
Jouw antwoord lezende heb je me waarschijnlijk in een ander draadje ook weer moeten corrigeren... ::)
Groet,
Jeroen.
-
@Karst
Jouw antwoord lezende heb je me waarschijnlijk in een ander draadje ook weer moeten corrigeren... ::)
Klopt ;D ;D ;D
-
Nu wordt het uitgangsvoltage van de minicentrale ongeveer 5V (USB voeding). Wanneer ik uitga van 10mA (Typische waarde voor de led in de optocoupler) dan moet ik in dat geval dus een weerstand plaatsen van 350 Ohm?
Hier heb ik toch enkele bedenkingen bij. In een vroegere post lees ik dat je wil sturen vanuit een TTL signaal.
Jouw verhaal klopt indien je zeker bent dat de zwaai van je uitgangssignaal 5V is. Dat is met quasi zekerheid zo als je de anode van de led aan de +5V hangt en de de signaaluitgang van je centrale via een weerstand verbind met de Kathode van de led (aktief laag gestuurd)
Jouw verhaal klopt niet als je de singaaluitgang van je centrale via een weerstand verbind met de anode en de kathode aan de 0V legt (aktief hoog gestuurd).
Het hoog niveau van de (TTL) uitgang is namelijk niet gegarandeerd +5V. Afhankelijk van de technologie waarmee de poort opgebouwd is kan hier heel wat spreiding op zitten. Zoek even op in de datasheet wat de minimale *hoog* uitgangsspanning is voor de poort die je gebruikt. Kan behoorlijk wat lager zitten (bvb 3V).
mvg,
Patrick Smout
-
@Patrick
De uitgang van de atmel is geloof ik maar 3,3V maar die wou ik niet direct gebruiken. Het ging me er meer om dat ik de minicentrale niet 'extern' met een trafo wil voeden als dat niet nodig is, maar gewoon de 5V van de USB wil gebruiken.
Ik ging er van uit dat ik het uitgangssignaal van de Atmel niet verder kon versterken dan de aanwezige voedingsspanning, dus zodoende kwam ik uit op 5V.
Eigenlijk zoek ik een manier om met diezelfde voeding van 5V een uitgangssignaal te krijgen van 12V omdat de minicentrale anders alleen met 'aangepaste' boosters kan werken... Omdat ik (nog) niet weet hoe ik dat voor elkaar moet krijgen dacht ik voor nu even de ingang van de booster aan te passen zodat ik de rest alvast kan testen...
Dus mocht je een tip hebben hoe een dergelijke schakeling genoemd wordt dan hou ik me aanbevolen. :P
*** edited
Ga ik weer de mist in omdat ik dingen door elkaar haal... Ik heb de OpenDCC booster gekozen omdat ik ook (stukken van) de OpenDCC centrale ging nabouwen. Leek me een makkelijk uitgangspunt omdat je dan weet hoe die twee met elkaar werken.
Nu is dit een booster van het type 'current-interface' (en de centrale dus ook), gebaseerd op de optocoupler ingang, terwijl ik een tijdje terug had uitgevogeld dat ik in mijn geval makkelijker het type 'voltage-interface' kon gebruiken, gebaseerd op een driver/receiver pair. Deze werken namelijk met de lagere voltages waar ik steeds mee in mijn hoofd zit.
Nu lijkt het er op dat de meeste boosters van het eerstgenoemde type zijn. En aangezien ik compatibiliteit belangrijk vind kom ik dus weer terug op het eerste type. Volg je het nog? Ik was mezelf in ieder geval even kwijt...
DC/DC converters gaat het volgens mij ook niet worden dus ik denk dat ik de minicentrale toch maar gewoon aan een 12V voeding ga hangen...
***
In ieder geval super bedankt voor het meedenken!
Groet,
Jeroen.
-
Jeroen,
mijn centrale maakt gebruik van een standaard RS232 transceiver (genre max3232) (zie Elektor, september 2008). De logica is hier 3,3V gevoed. De uitgang swingt ongeveer tussen -5V/+5V. Hier kom je een heel eind mee in de richting van NMRA compatibiliteit al kan je maar een beperkt aantal boosters parallel op de uitgang plaatsen van het commandstation (2 tot 3). Overigens zijn ook niet alle DIY boosters echt NMRA compatibel op vlak van de boosteringang. Als je boosterschema en NMRA specificaties naast elkaar legt komen de knelpunten zo naar boven.
mvg,
Patrick Smout
-
Patrick,
Ik zat vanavond nog even naar de schema's van OpenDCC te kijken en zag ineens dat ik wel erg moeilijk aan het doen was. Ik kan de Atmel van de minicentrale voor het testen volgens mij gewoon áchter de optocoupler van de booster aansluiten, dus echt op TTL nivo... 8)
Dat verhaal zette me ook weer aan het denken. Want de Atmel op de OpenDCC booster(versie 2.0) doet zo niet heel veel, behalve de cut-out sturen (en wat ledjes).
Dit viel me pas op toen ik het schema van de booster in de OpenDCC centrale (gebaseerd op een tweeweg LN6206 voor programmeerspoor en hoofdspoor) met het schema van de 'externe' OpenDCC booster (gebaseerd op de enkelvoudige LN6203) vergeleek.
Ik was een minicentrale aan het bouwen zonder 'ingebouwde' booster om het zo modulair (en goedkoop) mogelijk te houden. Maar nu ik de centrale van een eigen voeding moet gaan voorzien terwijl dat niet hoeft wanneer ik hem combineer met de booster, en ook nog blijkt dat ik dan de Atmel van de booster weg kan laten en die functie(s) over kan laten nemen door de Atmel van de centrale, denk ik toch dat ik het anders ga doen. De onderdelen van de booster (zonder de Atmel en de opto) kosten minder dan 15 euro, dus daar hoef ik het niet voor te laten.
Nog even verder gepiekerd (onder het tikken)... Dit wordt het (aangepaste) idee:
Ik voeg de minicentrale samen met de booster zoals hierboven beschreven. Tevens heb ik dan voldoende vermogen aan boord om naast de ingebouwde booster een uitgang (conform NMRA specs) te maken waar je eventueel extra boosters op kunt aansluiten. De ingebouwde booster kun je optioneel schakelen als hoofdspoor (wanneer je geen extra booster(s) gebruikt) of als programmeerspoor, waarbij de 'externe' booster(s) dan automatisch als hoofdspoor dienen.
Spannend! Want dit klinkt weliswaar leuk maar nu moet ik (althans voor een deel) iets gaan bouwen wat ik niet kan 'afkijken'... :P
Maar goed, laat ik me eerst maar even beperken tot het samenvoegen van centrale en booster. Dat lijkt me voorlopig uitdagend genoeg...
Groet,
Jeroen.
-
Hee Jeroen,
hoe staat het met je project?
Guus
-
Het gaat langzaam maar zeker de goede kant op. Inmiddels zijn de opendcc boosters (op eigen printontwerp) een feit. Daarmee is eindelijk het eerste functionerende brouwsel werkelijkheid geworden. (Als ik nog eens langs iemand met een scoop kom dan ben ik nog wel benieuwd of hij ook een 'mooi' signaal genereert)
Van de OpenDcc centrale heb ik de dubbele H-brug (het booster-gedeelte van de centrale) letterlijk overgenomen en dat zit nu tijdelijk op een breadboard. De oorspronkelijke Atmel van de opendcc centrale heb ik vervangen voor een ATMega8 omdat ik natuurlijk veel minder functies gebruik. Het is nog even vogelen of ik het daar mee ga redden... De USB aansluiting van de opendcc centrale heb ik vervangen voor een kant-en-klare ftdi kabel, want daar had ik er twee van liggen. Alle overige aansluitingen blijven uiteraard achterwege want de bezetmelding e.d. loopt straks via LocoNet direct naar de PC. (Bezetmelders, LocoBuffer en LocoNet interface van Wim Ros)
De opendcc software aan de kant van de mini-centrale heb ik inmiddels aan de praat. Alleen kan ik op dit moment alleen 'hardgecodeerde' opdrachten uitvoeren omdat ik de USB verbinding nog niet werkend heb...
Verder ben ik aan het knutselen met de seinenprint en de servodecoderprint van Karst Drenth en zit ik tussen de bedrijven door een regelbare voeding in elkaar te knutselen.
Nu het zonnetje wat vaker schijnt zit ik buiten lekker baanplannen te tekenen.
Op dit moment staat alles heel even op een laag pitje, want ik ben de keuken en de tuin aan het verbouwen. Daarna ga ik de zolder in orde maken en kan ik beginnen met het proefbaantje.
Groet,
Jeroen.
-
tja als je moet kiezen tussen een keuken en de modelbaan, nou dan wist ik het wel...
(ik zou ook voor de keuken gaan ....)
groet,
Guus
-
Even geheeeeeel off-topic maar dit kon ik jullie niet onthouden:
Er is zojuist nog een 'kleine' kink in de kabel gekomen...
Jawel, het vrouwtje is 'in blijde verwachting'!
;D (y) ;D (y) ;D
Dus dat wordt duimen voor een zoontje ;)
(dochtertje mag natuurlijk ook, mits ze treintjes leuk vindt :P)
Hmmm, en wellichtt ook een beetje duimen dat er nog wat zolderruimte overblijft...
Groet van een superblije Jeroen!
-
Goh Jeroen, dat je daar nog tijd voor had. :-X :-X :-X
Maarre van harte (y)
Mvg
Wim.
-
Feli he (y)
Enne:
Goh Jeroen, dat je daar nog tijd voor had. :-X :-X :-X
Zo veel tijd hoeft dat te zijn hoor ;)
Gr. Remco.
-
Ah, begrijpen we gelijk hoe het kan dat je zo snel vorderingen maakt met de modelbaan Remco. ;D
Gefeliciteerd Jeroen ... (y)
... en sterkte in de toekomst. 8)
Ik ga nu het resultaat van zo'n blijde verwachting bij een vriendinnetje wegsleuren.
-
Terug van weggeweest...
Het is alweer een behoorlijk tijdje geleden dat ik een update heb geplaatst over mijn vorderingen met de minidigi centrale. Niet dat ik stil heb gezeten maar een baby op komst knaagt toch wel behoorlijk aan de vrije tijd. Even off topic: De buik groeit gestaag, kinderkamer is er zo goed als klaar voor, nog drie maandjes geduld... (y)
Eerst maar even het laaaaaang beloofde plaatje:
(https://images.beneluxspoor.net/bnls/P1012248.jpg) (https://images.beneluxspoor.net/bnls/P1012248.jpg)
(links de STK500, boven de OpenDCC booster op eigen print en rechts de 'centrale')
Inmiddels zit de centrale, met uitzondering van de microprocessor op een experimenteerprint. De microprocessor zit nog op een ontwikkelbord (STK500) want dat werkt in deze fase toch wel het makkelijkst. Er zijn wat momenten geweest dat ik het idee kreeg dat ik het allemaal wat te hoog gegrepen had maar na veel (heeeeel veel) pogingen krijg ik toch steeds weer een stukje meer aan de praat. Een heerlijk gevoel overigens, om iets voor elkaar te krijgen waarvan velen (inclusief ikzelf op momenten ;D) dachten dat het nooit zou lukken. De centrale is inmiddels zover dat ik vanaf de pc opdrachten kan sturen. Dat klinkt als heel wat mooier dan de werkelijkheid. Middels een terminal programmaatje kan ik hexadecimale opdrachten intikken en versturen. De centrale pakt dat op en vertaalt het naar DCC. Niet echt werkbaar natuurlijk maar het betekent wel dat ik op de goede weg zit, met name omdat het gedeelte waar ik het minste van snapte (elektronica en microprocessors) in een werkend stadium begint te komen.
Vanaf hier wordt het langzaam uitbreiden. Het programmeerspoor is er qua hardware wel maar wordt nog niet aangestuurd. Dat moet ik dus ook nog in de communicatie bouwen zodat de centrale weet of het een opdracht voor het hoofd- of programmeerspoor is. Tevens geeft het programmeerspoor een bevestiging die afgevangen moet worden.
Vervolgens nog de controle op kortsluitingen en het aansturen van de cutout voor RailCom. Wellicht pas ik het ontwerp nog aan zodat je geen kant-en-klare ftdi kabel nodig hebt (de kabel kost alleen al meer dan alle andere onderdelen bij elkaar)
Oh, en natuurlijk nog een 'mooie' printplaat ontwerpen want dit is geen gezicht.
Is dat allemaal gelukt dan kan ik eindelijk beginnen aan het pc gedeelte, waar ik me stukken meer thuis bij voel.
Voor de beeldvorming: De kosten van de centrale zijn tot dusverre € 75, waarvan €45 voor de ftdi kabel. Het belooft dus nog steeds een heel goedkope centrale te worden.
Groet,
Jeroen.
-
En Jeroen, al nieuwe ontwikkelingen?
-
Jouw toekomstige machinist is verplaatst naar dit (http://forum.beneluxspoor.net/index.php/topic,29326.0.html) onderwerp.
-
Hmpf, ik ben blijkbaar niet de enige die hem niet los wil laten... Moeders heeft m te pakken. >:(
Maar goed, heb ik mooi even de tijd om de vorderingen te vertellen.
Ik ben aan het rommelen geweest met 'zelfbouw H-bruggen' in een poging de L6206 te vervangen voor een goedkoper alternatief. Dit heeft me (met een beetje hulp van Karst) heel veel duidelijk gemaakt over de feitelijke werking van de minicentrale. Aan het eind van de rit was de conclusie echter dat het a: niet zo eenvoudig is om met name alle bijkomende functies van de L6206 na te bouwen, en b: je nauwelijks goedkoper uit bent. Oftewel, het was een leerzame actie maar ik hou het bij de L6206. Bij OpenDCC hebben ze bijna letterlijk het voorbeeld uit het datasheet gevolgd dus dat hou ik hetzelfde. Alles er omheen wordt zoals ik eerder al aangaf heel anders.
Wel heb ik inmiddels een goedkoper alternatief voor de ftdi-USB kabel. Dit ga ik met een Atmel ATMEGA32au oplossen. Deze USB chip gaat alle communicatie uitvoeren tussen PC en de overige chips op de minicentrale. Dit is echter een nogal klein gevalletje (1 bij 1 cm met 44 aansluitingen :o) dus ik heb een microscoop moeten kopen om het kreng gesoldeerd te krijgen. En het was natuurlijk weer een uitzoektocht om er achter te komen hoe ik dat allemaal moest programmeren maar er zit gelukkig schot in de zaak. Bovendien kan ik door het gebruik van een 'centrale chip' vrij eenvoudig allerlei 'uitbreidingen' aan de centrale toevoegen.
Verder heb ik zitten rommelen met het hoofd- en programmeerspoor. Ik wil ze apart aansturen zodat er geprogrammeerd kan worden terwijl de hoofdbaan gewoon in bedrijf is. In mijn oude 'ontwerp' kon dat niet tegelijk waardoor je de hoofdbaan eerst stil moest zetten.
Ik zal binnenkort wat nieuwe plaatjes schieten waarop de vorderingen te zien zijn.
-
Het is weer ruim 10 maanden geleden dat ik een update heb gegeven. Veel van de vrije tijd gaat natuurlijk naar de kleine. Maar ik heb alles behalve stilgezeten dus er is veel nieuws...
Het ontwerp van de centrale is door "voortschrijdend inzicht" op allerlei fronten aangepast. Zoals eerder aangegeven wilde ik mikken op een centrale met "onbegrensde" mogelijkheden, hetgeen is begonnen bij het genereren van DCC signalen en is geeindigd bij het ondersteunen van zowel LocoNet en XPressNet, als een eigen bus welke ik LocoNetPlus heb genoemd.
DCC
Voor DCC heb ik vier aparte stroomkringen gemaakt. Eén stroomkring voor het hoofdspoor (zoals iedere centrale dat heeft), welke ik alleen ga gebruiken voor mobiele decoders. De tweede stroomkring is een ringleiding waarop de overige decoders aangesloten worden. Deze splitsing zorgt er voor dat je twee keer zoveel DCC opdrachten per seconde kunt versturen dan normaal, mocht je heel veel DCC decoders in gebruik hebben. De derde is het programmeerspoor en de vierde is bedoeld voor het aansturen van omgevingsverlichting (dat bij "nacht" de lampjes langzaam uit gaan dus).
Bussen
De centrale beschikt over 3 "netwerkaansluitingen". De bekabeling welke ik ga gebruiken is dan ook cat5e. Middels verloopstukken kun je zowel LocoNet (aansluiting 1,2 en 3), LocoNetPlus (aansluiting 1 en 2) en XPressNet (aansluiting 3) aansluiten. De centrale kan de verschillende protocollen door elkaar gebruiken. (Wie had dat gedacht? LocoNet en XPressNet in één kabel? ;D) Ook het signaal voor de boosters (Railsync) loopt over dezelfde kabel, waarbij iedere netwerkaansluiting een aparte stroomkring aanstuurt. (de vierde is het programmeerspoor, welke middels een tweeaderige kabel, zonder booster aangesloten kan worden)
Tot slot is er een aansluiting om uitbreidingsmodules op aan te kunnen sluiten. Dit is feitelijk een aansluiting op de communicatiebus tussen de verschillende microcontrollers van de centrale.
PC
In eerste instantie was ik een centrale aan het maken welke alleen werkte als de PC ook aan stond. (de logica van de centrale is feitelijk een stukje software op de PC) Vervolgens kreeg ik hier te horen dat het toch wel erg prettig zou zijn om snel even iets te kunnen testen, zonder eerst de PC op te moeten starten. Ik was overtuigd en daarom kan de centrale straks ook (zij het met enige beperkingen) stand-alone werken.
Modulaire opbouw?
Het moge duidelijk zijn dat mijn plan om het allemaal onder de 75 euri te houden niet gaat lukken. Tenminste, dat is een beetje aan de gebruiker. De centrale bestaat uit twee printplaten (10 x 8 cm) welke boven elkaar gemonteerd worden. De hoofdprint bevat de communicatie met de PC, de dcc-generator voor het hoofdspoor, de tweede dcc-generator voor (bv.) het programmeerspoor, en de XPressNet module. De tweede print bevat wederom twee DCC-generatoren en de aansluitingen voor LocoNet en LocoNetPlus. Je hoeft niet alles in één keer op de print(s) te zetten. Je kunt beginnen met alleen één DCC-generator. De treinen bedien je dan middels de (virtuele) handregelaar op de pc. In dat geval moet 75 euro best haalbaar zijn.
Vervolgens kun je steeds verder uitbouwen. (tweede stroomkring met XPressNet, derde stroomkring met LocoNet, vierde stroomkring met LocoNetPlus, eigen uitbreidingsmodules, enz.)
Stand van zaken
Het klinkt misschien allemaal mooi (of niet :P), maar om heel eerlijk te zijn weet ik nog niet of dat echt zo is omdat ik nog niet voor alle onderdelen een "proof of concept" heb... De stand van zaken is als volgt:
- Elektronische schema's en printontwerpen gereed (concept)
- Software microcontrollers gereed (concept)
- Schema H-bruggen werkend en getest
- Communicatie microcontrollers onderling werkend en getest
- LocoNet(Plus) en XPressNet communicatie (testfase)
- Koppeling met PC (nog te programmeren USB)
- Software op de PC (centrale) nog te ontwerpen
- Software treinbesturing nog te ontwerpen
Al met al moet er dus nog een hoop gebeuren! Na het (elektronisch) testen van de laatste onderdelen kan het printontwerp definitief worden gemaakt en kan ik een paar printen laten maken. Daarna wordt het volop aan de slag met het (verder) programmeren van met name het PC gedeelte.
Binnenkort zal ik de schema's uploaden zodat er op geschoten kan worden.
Groet,
Jeroen.
-
Bij deze de (concept) schema's van de centrale. Alle op- / aanmerkingen zijn welkom aangezien ik tot de start van dit project nog niet eens wist wat een H-brug was. ::)
(https://images.beneluxspoor.net/bnls/UDCC_BRD1_L.png) (https://images.beneluxspoor.net/bnls/UDCC_BRD1_L.png)(https://images.beneluxspoor.net/bnls/UDCC_BRD2_L.png) (https://images.beneluxspoor.net/bnls/UDCC_BRD2_L.png)
***edit
De plaatjes zijn helaas niet goed leesbaar en het lukt me niet om een grotere versie te uploaden. Het plaatje eerst opslaan op je computer geeft een beter resultaat dan het via de browser bekijken maar het is niet ideaal... Wie interesse heeft kan me een pb'tje sturen, dan mail ik ze wel.
Groet,
Jeroen.
-
Je bent flink bezig!! (y)
-
Met dank aan Peter v/d Leek hier dan de grote plaatjes. (y)
(https://images.beneluxspoor.net/bnls/UDCC_BRD1_L_full.png) (https://images.beneluxspoor.net/bnls/UDCC_BRD1_L_full.png)
(https://images.beneluxspoor.net/bnls/UDCC_BRD2_L_full.png) (https://images.beneluxspoor.net/bnls/UDCC_BRD2_L_full.png)
*** edit
Mijn fout, nu doen ze het wel!
Groet,
Jeroen.
-
Uhm... mijn pc loopt bijna vast op een script dat hier uitgevoerd wordt (dat opzich vind ik al heel vreemd)
Tweede punt: Je weet dat er in Eagle een optie 'Smash all' zit? Daarmee kun je namen en waardes van onderdelen op een mooiere/logischer plek zetten, zodat het niet tussen verbindingslijnen en dergelijke zit.
Daarnaast vraag ik me af of een busschema niet handiger was geweest.
Begrijp me niet verkeerd, zelf ben ik niet in staat zoiets te bedenken en te programmeren, maar ik weet wel weer het nodige van het schema-programma ;)
-
@menno
Ook Eagle had ik tot voor kort nog nooit gezien/gebruikt (uberhaupt nog nooit schema's getekent) dus ik zal ongetwijfeld iets gedaan hebben wat "not done" is in schemaland. Dus ook die tips zijn welkom...
Ik zal de door jou genoemde opties eens bekijken. Bedankt!
-
Even voor de duidelijkheid: 'smash all' is een scriptje dat via 'File > Run' en dan 'smash' intypen alle onderdelen de mogelijkheid geeft de naam en waardes op een andere plek te zetten via Move.
Nog 1 vraagje uit nieuwsgierigheid: past dit op een eurokaart? (Het maximale formaat van Eagle Light en ik geloof ook een paar betaalde versies)
-
Ja, de grootste print is 10 x 8 cm. Ik heb nl. ook alleen de gratis Light versie.
Was wel een beetje passen en meten... :P
-
Ik had van de 'elektronica specialisten' op dit forum eigenlijk wel wat reacties verwacht... Zijn er wel mensen die er naar gekeken hebben? Ik snap uiteraard dat niet iedereen daar zin in (of tijd voor) heeft maar ik ben zo benieuwd of ik nog (grove) dingen over het hoofd heb gezien. ???
Alvast bedankt! (y)
Groet,
Jeroen.
-
... Ik nog niet, maar ik heb nu vakantie!
-
Ja, de grootste print is 10 x 8 cm. Ik heb nl. ook alleen de gratis Light versie.
Was wel een beetje passen en meten... :P
Dit is een halve Eurokaart. De voledige is 160x100 mm.
Knap dat je alles op dat formaat krijgt.
Waarschijnlijk alles in SMD?
-
Het maximum formaat voor Eagle Light is 10x8 cm (voor zover ik had begrepen). Dat ging niet passen dus zijn het twee printplaten geworden. (welke samen op één eurokaart passen) ;)
Er zit welgeteld 1 SMD onderdeel op, te weten de Atmega32. Het doel was echter om helemaal geen SMD componenten te gebruiken omdat ik het voor een ieder zo toegankelijk mogelijk wilde houden. Maar helaas zijn er geen microcontrollers (althans niet van Atmel) met USB in een DIP behuizing.
Er is een alternatief in de vorm van een kant-en-klare USB kabel van Ftdi. Daar zit de microcontroller voor het USB gedeelte al in de USB stekker ingebouwd en heb je aan het andere einde van de kabel gewoon een 5-polige printplaat-stekker (USART/RS232). Mijn testopstelling werkt vooralsnog op die manier. Het vervelende is alleen dat die kabel € 20 euro toevoegt aan de kosten van de centrale en dat je dan nog steeds een alternatief moet hebben voor de Atmega32 omdat deze meer doet dan alleen de USB. Bovendien moet ik dan nog meer 'proppen' om alles op één print te krijgen omdat een microcontroller in DIP behuizing natuurlijk veel meer ruimte in beslag neemt.
Ik zit nog te piekeren over het al dan niet bieden van een alternatief...
-
Jeroen,
ik heb zonet even de tijd genomen om je ontwerp te bekijken. Het zijn veel 'standaard' blokken die met elkaar via een interne TWI bus met elkaar praten. Ieder blok heeft z'n eigen interfaces naar buiten.
De schakeling lijkt me tot nu toe niet spectaculair, zoals zo vaak zal 'em de crux zitten in de software.
Heb je de afzonderlijke blokken al getest?
Wat is precies de reden om voor loconet + te gaan?
groet,
Guus
-
Guus,
Je zult wel veel van de schakeling herkend hebben want ik heb wat dat betreft heel wat geleerd (en afgekeken) van OpenDCC. ;)
Een paar posts terug staat de stand van zaken, daar is niet heel veel in veranderd. Ik ben momenteel veel tijd kwijt aan het testen van combinaties van blokken, en dan met name het berichtenverkeer. De hardware blijkt goed te functioneren maar mijn software is (nog) niet altijd in staat om zichzelf uit een foutsituatie te redden.
Communicatie over de TWI bus had ik getest, maar ik kwam er achter dat de externe TWI aansluiting het niet deed. Dat bleek te maken te hebben met het ontbreken van een common ground. Hoewel TWI staat voor 'Two Wire Interface' geldt dat alleen wanneer je alle TWI apparaten op één voeding aansluit. Dus wanneer je externe modules aan wil sluiten zal het op zijn minst een 'Three Wire Interface' moeten worden. ;D
Het blijkt overigens gebruikelijker om externe modulen ook vanuit de 'hoofdmodule' te voeden zoals dat ook bij USB kan. (dus 4 draden) Ik moet dan ook nog even bekijken of ik de externe TWI aansluiting ook van voeding zal voorzien.
De Atmega32 is wat lastig te programmeren omdat deze voor 'minicentrale' moet spelen als er geen verbinding met de PC is en dat juist niet moet doen als de PC centrale het voor het zeggen heeft. En omdat ik zowel LocoNet als XpressNet wil ondersteunen levert dat wat uitdagingen op. Vooral omdat er domweg niet heel veel geheugen op die chip zit. 32KB voor de programmatuur gaat nog wel lukken maar 2,5KB RAM werkgeheugen is heel snel vol wanneer je daarin berichtenbuffers, LocoNet Slots en XPressNet moet bijhouden...
De reden voor LocoNet+ is omdat ik berichten wil versturen welke niet (volledig) voldoen aan de LocoNet specs (of waarvan de specs niet genoemd worden in LocoNet Personal Edition). Mijn eigen modules wil ik bijvoorbeeld op afstand (via LocoNet+) kunnen (her)programmeren. Zou ik dat over een normale LocoNet lijn versturen dan zou dat bij bestaande LocoNet apparaten wel eens voor verwarring kunnen zorgen. En daar hebben we helaas al genoeg voorbeelden van dus leek het me goed om dat nu eens te voorkomen.
Nu had ik ook een geheel nieuwe bus kunnen bedenken maar ten eerste is het principe van LocoNet gewoon goed, en ten tweede zullen er zat bestaande LocoNet apparaten zijn welke geen last hebben van de 'onofficiele' LocoNet berichten die ik verstuur. En wanneer iemand 'mijn' bijpassende modules helemaal niet gebruikt is er ook geen sprake van 'onofficiele' berichten. Dan is het een gewone LocoNet lijn en verdubbel je daarmee de capaciteit.
Bedankt overigens dat je de moeite hebt willen nemen om de schakeling te bekijken!
Zodra ik weer (enigzins meetbare) vorderingen heb geboekt hoor je me wel weer.
Groet,
Jeroen.
-
Jeroen,
I.p.v. de bijna end-of-life Mega32 AVR zou je eens kunnen kijken naar de Mega644 of zelfs de Mega1284.
Beiden in PDIP uitvoering verkrijgbaar en volgens mij eveneens pin-compatible met de Mega32, maar veel meer geheugen en mogelijkheden.
Verder... Leuk om te lezen dat er nog iemand bezig is met een zelfbouw centrale. Die van mij daar heb ik naast monitoring van power-levels en LocoNet implementatie niet veel meer aan gedaan. Dingetje voldoet al een tijdje prima hier, wordt bijna wekelijks wel enkele uurtjes mee gereden en geprogrammeerd. ;)
Owja... RAM van 2KB in de Mega32 zou toch veelal voldoende moeten zijn, misschien eens kijken of je op de 1 of andere manier NOG slimmer kunt omgaan met de ruimte. Bijvoorbeeld door de grootte van buffers zoveel mogelijk te beperken door verbetering en optimalisatie van je code (=snelheidswinst, =minder bufferruimte nodig etc. etc.), met grote buffers kun je daar enorme winst mee halen. En anders gewoon een Mega644 of Mega1284 (met 16KB SRAM) erop zetten of extern geheugen erbij. ;D
Maareh, blijf je draadje volgen! (y)
Gr. Dave
-
wil ik bijvoorbeeld op afstand (via LocoNet+) kunnen (her)programmeren.
Dit wat voor zoverre nog niet bekend?
http://embeddedloconet.sourceforge.net/bootloader/index.en.html
Je zocht een goedkope USB converter, dit wat? Hier is een Tiny2313 gebruikt als
USB controller....
http://www.ulrichradig.de/home/index.php/avr/atmega8-experimentierboard/beginner-tutorial-teil-1
Verder, je ontwerp ziet er indrukwekkend uit, en gelijk afschrikkend... Heb je modulariteit in gedachten of
is het alles of niks?! Met zoveel processoren schrik je nabouwers af...
Robert
-
@Dave
Ik was niet helemaal compleet, het is de Atmega32U4 met USB. De USB was in deze keuzebepalend.
Voor wat betreft mijn gehannes met geheugen, het gaat wel lukken maar het is wat krap. ;D
@Robert
Updaten via een bootloader is inderdaad het idee. Het kán al wel over LocoNet, maar het voldoet niet (of nog niet) aan de specificaties. Het is overigens maar een voorbeeld. Het gaat er om dat als ik iets verzin wat met de LocoNet specs niet kan, dat ik eigen codes kan gebruiken, zonder het risico dat ik problemen met 'echte' LocoNet apparaten veroorzaak.
Een softwarematige USB controller! (y) Daar had ik nog helemaal niet over nagedacht, maar is inderdaad ook een optie. Zodra de rest werkt (USB staat als laatste agendapunt ;)) ga ik dat zeker eens onderzoeken.
Interessante links! Bedankt daarvoor.
Indrukwekkend? Die eer kan ik helaas niet opstrijken... Ik heb alleen maar allerlei stukjes van bestaande schakelingen aan elkaar geplakt. Stukje OpenDCC, stukje Karst, stukje Hans DeLoof, en ik weet niet waar ik nog meer stukjes vandaan geplukt heb. Als dit eenmaal werkt ga ik nog eens opnieuw kijken of bepaalde stukken nog beter kunnen maar heel veel verbeteringen verwacht ik niet. Er zijn natuurlijk vele oplossingen mogelijk maar al deze mensen hebben goed nagedacht!
Afschrikkend? Geen idee, zou goed kunnen. Maar wanneer je bedenkt dat ik ook zonder enige kennis van schakelingen en microcontrollers aan dit project ben begonnen zou dat velen toch weer een beetje gerust moeten stellen. Het is een kwestie van gewoon doen. Zo kon ik al wel programmeren maar had dat nog nooit in C gedaan. Het kost allemaal wat meer tijd (ben nu met alles al twee jaar aan het rommelen) maar met een beetje goede wil kun je alles. En of je nu één of vijf microcontrollers hebt, solderen is hetzelfde, programmeren is hetzelfde... Als je de software niet meer zelf hoeft te bedenken hou je een heel goed na te bouwen projectje over. Niet moeilijker dan bv. OpenDCC.
En voor 'al' die moeite krijg je natuurlijk wel wat terug. Het gaat nog wel even duren voor het af is maar dan kun je er wel 'alles' mee. (Zo niet dan ga ik het er waarschijnlijk wel bij bouwen) Voor een centrale die onder de € 150 aan onderdelen moet gaan kosten is dat voor sommigen wellicht een mooi alternatief. En zo niet, dan heb ik in ieder geval zelf (waar ik het in de eerste plaats voor doe) de centrale van 'mijn dromen'.
-
Niet helemaal on topic hier, maar ik denk wel de beste plek:
Voor de programmeurs onder ons die zelf decoders e.d. maken heb ik laatst CoCoOs ontdekt.
Met behulp van deze routines kun je zelf simpel multitasken op een microcontroller.
Er is een voorbeeld project die een atmel mega32 gebruikt, ik gebruik het zelf in mijn 64 voudige wisseldecoder in een mega162, maar volgens mij kun je het netzo goed op een pic aan de gang krijgen.
De link: www.cocoos.net (http://www.cocoos.net)
Doe er je voordeel mee.
-
@Piksov: heb net je website bekeken. Vind daar niets over de 64 wisseldecoder. Kun je daar iets meer over vertellen of laten zien?
-
Ruud,
hier: http://www.piksov.com/index.php?id=wisseldecoder.php
Guus
-
Hoi Guus,
Vlgs mij heb je bij het maken van de link het MAIL knopje gebruikt.
Maar jouw decoder ziet er goed uit, alleen mis ik het schema op de site.
Groetjes
Harry