Samengevat: De 'MiNiDiGi' Centrale

[Jeroen van Tol]

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. 

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. 

Groet,
Jeroen.

[Jeroen van Tol]

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

 

Groet,
Jeroen.

[Wim Ros]

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.

[piksov]

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

[Jeroen van Tol]

@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... 

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. 
(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... 

Groet,
Jeroen.

[Jeroen van Tol]

@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 

Voor mensen die RailCom niet interessant vinden is dit echt een goeie tip!
Ik was er in ieder geval nooit op gekomen...

Groet,
Jeroen.

[Jeroen van Tol]

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.

[JAB van Ree]

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.

[Jeroen van Tol]

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.

[Jeroen van Tol]

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!

  Nobody's perfect 

Groet,
Jeroen.

[henk]

Waarna de logische vraag volgt doen Digitrax centrales er ook wat mee en zo ja wat?

[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.

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

[ArtMan]

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

[Han Zijlstra]

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.

[Jeroen van Tol]

@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.