Nieuws:

Zin in een spoors uitstapje? Kijk eens in onze kalender!

Esu Switch Pilot V2.0

Gestart door Anne W maandag 03 februari 2020, 21:54:53

0 leden en 1 gast bekijken dit board.
Esu Switch Pilot V2.0
Lid sinds: 2007

Elk vogeltje zingt zoals het gebekt is.

online
Esu Switch Pilot V2.0
In een ander topic is mij verteld dat de Esu Switch Pilot V2.0 het niet kan "handelen" dat alle opdrachten door de centrale verzonden worden zowel in Motorola als wel in DCC, tevens is mij verzocht om daarover niet in dat topic verder te discussiëren, dus dan maar een nieuw topic.

Op mijn baan rijden 19 loks met zowel Motorola als wel DCC decoders, dus mijn centrale, de Raptor, zet beide formaten op de "centrale voeding leiding", wat ook betekent dat opdrachten voor wissel/schakel/seindecoders ook uitgezonden worden in zowel het Motorola als wel het DCC formaat.

De door mij gebruikte wissel/schakel/seindecoders zijn van de merken Edits (Motorola), Viessmann (Motorola) en LDT (DCC), ze werken al jaren prima en ze hebben geen last van het extra formaat wat ze "te horen krijgen".

De vraag is dus waarom zou de Esu Switch Pilot V2.0 niet kunnen wat Edits, Viessmann en LDT wel kunnen.

Groet, Anne W
Re: Esu Switch Pilot V2.0
Lid sinds: 2009

offline
Re: Esu Switch Pilot V2.0
hoi,

op het ogenblik heb ik geen esu switch pilot in gebruik,
maar op mijn vorige baan werkte het perfect samen de viessmann decoders.

Hank
Re: Esu Switch Pilot V2.0
Beste Anne,

Goed, op het risico dat je mij nog onaardiger gaat vinden. Omdat ik je toch even moet helpen om het antwoord van Wim / Sprinter te begrijpen.

Citaat van: Anne W op maandag 03 februari 2020, 21:54:53
In een ander topic is mij verteld dat de Esu Switch Pilot V2.0 het niet kan "handelen" dat alle opdrachten door de centrale verzonden worden zowel in Motorola als wel in DCC, tevens is mij verzocht om daarover niet in dat topic verder te discussiëren, dus dan maar een nieuw topic.

Dat bewuste topic is: problemen met wisseldecoder Digikeijs 4018.

Je haalt nu een aantal zaken door elkaar heen. In het draadje van de DR4018 wordt uitgelegd dat door het per adres aangeven van welk protocol gebruikt moet worden voor het wisselcommando het aantal data die verstuurt moet worden beperkt wordt. Jij geeft een opmerking dat het niet slim is en jouw centrale lekker dom is door alle commando's in Motorola en DCC op de baan te zetten.

Citaat van: Anne W op zaterdag 01 februari 2020, 23:58:09
Beste Martin,

Ik snap dat je "er in trapte", ik vind het ook niet de slimste "uitvinding" van de centrale jongens....

Groet, Anne W

Wim antwoord op jou:

Citaat van: Sprinter op zondag 02 februari 2020, 16:29:30
Ik vind het wel heel slim. Beperkt namelijk de hoeveelheid data, die de centrale moet sturen.

Lijkt me ook niet zo slim voor een decoder die zelf kan uitfilteren wat het format is. b.v. een ESU decoder. Want naar welk format moet hij dan luisteren.

Jij antwoord dan:

Citaat van: Anne W op zondag 02 februari 2020, 23:16:39
Maakt dat wat uit dan, in beide formaten komt dezelfde opdracht, dus naar welke hij luistert maakt niets uit, nu moet de centrale eerst kijken naar wel algemeen formaat aanstaat, dan of de desbetreffende wisseldecoder in het register "afwijkende formaten" staat en indien ja, dat afwijkende formaat produceren.

Als ik me niet vergis wordt een wissel instructie slechts 2 keer 2 keer uitgezonden, vergeleken met het aantal instructies voor een accelererende lokdecoder op 128 stappen helemaal niets....

Wim geeft aan dat het uit maakt. Nu stel jij dat ESU-decoders moeite hebben met de verschillende protocollen op de baan:

Citaat van: Anne W op maandag 03 februari 2020, 21:54:53
De door mij gebruikte wissel/schakel/seindecoders zijn van de merken Edits (Motorola), Viessmann (Motorola) en LDT (DCC), ze werken al jaren prima en ze hebben geen last van het extra formaat wat ze "te horen krijgen".

Normaal luistert iedere decoder naar het protocol waarop ze ingesteld zijn, Motorola, DCC, Selectrix of MFX. Dat is handig want dan hoeft de decoder alleen de commando's van het betreffende protocol te filteren. Alleen maar goed.

Zet je nu altijd alle commando's in Motorola, DCC, Selectrix en MFX op de baan en een decoder moet naar alle protocollen en commando's dan wordt het niet echt efficiënter. Dit omdat wisselcommando's in 4 protocollen achter elkaar op de baan gezet worden. Dus een decoder weet dan niet of het een "oud" of een "nieuw" commando is. Buiten dat probleem heb je natuurlijk nog het probleem met de de adressering en de manier van werken van de diverse protocollen. Het aantal gegevens dat een centrale moet genereren is dan een veelvoud en kost meer processorkracht dan even kijken in een register of een ander protocol gebruikt moet worden.

Citaat van: Anne W op maandag 03 februari 2020, 21:54:53
De vraag is dus waarom zou de Esu Switch Pilot V2.0 niet kunnen wat Edits, Viessmann en LDT wel kunnen.

Dus een Esu Switch Pilot werkt gewoon goed op een baan met meerdere protocollen. Het ding luistert gewoon naar alleen het ingestelde protocol. Niets moeilijk aan. Digikeijs doet dat ook: Luisteren naar het ingestelde protocol en dan heeft Digikeijs de voorkeur voor DCC in plaats van motorola. Alleen jij interpreteert het antwoord van Wim niet goed door te denken dat een ESU decoder daar niet meer om kan gaan. Dat is dus klinkklare onzin. Buiten het feit dat Esu zelf centrales maakt die DCC, Motorola en MFX (M4) gelijktijdig op de baan kan zetten. Dan zou het vreemd zijn als hun eigen decoders daar niet tegen kunnen.

Groet Ronald.
Re: Esu Switch Pilot V2.0
Lid sinds: 2008

graag een glaasje wijn

offline
Re: Esu Switch Pilot V2.0
ding werkt perfekt op multiprotocol.Hier samen met MM k83,k84 en LDT 
Re: Esu Switch Pilot V2.0
Lid sinds: 2007

Elk vogeltje zingt zoals het gebekt is.

online
Re: Esu Switch Pilot V2.0
Beste Heer Ronald,

Ik reageerde in het door jou gemelde topic op het feit dat je bij de Tams centrale van de Topic starter een protocol voor de wisseldecoders moet instellen en een stap verder het protocol voor uitzonderingen, iets wat ik ook niet wist en wat schijnbaar bij veel centrales zo is.

Mijn primaire reactie was simpel, mijn centrale zendt de opdrachten voor alle wisseldecoders altijd in beide protocollen uit, lijkt mij makkelijker als steeds te moeten bedenken of de decoder een standaard ingesteld formaat heeft of een uitzondering is, de door mij gebruikte decoders hebben daar geen problemen mee.

Mijn vraag wordt niet door jou beantwoord, ik denk inmiddels dat decoders die met een schakelaar of jumper voor het soort protocol werken, zoals de door mij gebruikte merken, geen problemen hebben met de gelijke opdrachten in beide protocollen die vlak na elkaar langskomen.

Maar ik denk dat de decoders die werken met automatische herkenning van het protocol zoals de Digikeijs en ook de 2 servo uitgangen van de Esu Switch Pilot hier wel problemen mee kunnen hebben.

Ken jij een andere centrale die altijd elke wissel "schakel" opdracht in twee formaten vlak na elkaar uitzendt?

Efficiency: moet een wissel verzet worden dan wordt het betreffende wisselbesturingskommando 4 maal achter elkaar tussen twee lokbesturingskommando's uitgezonden en daar merken de loks helemaal niets van.

Verder: inderdaad.

Groet, Anne W
Re: Esu Switch Pilot V2.0
Hallo Anne,

Citaat van: Anne W op zaterdag 08 februari 2020, 16:44:13
Mijn vraag wordt niet door jou beantwoord, ik denk inmiddels dat decoders die met een schakelaar of jumper voor het soort protocol werken, zoals de door mij gebruikte merken, geen problemen hebben met de gelijke opdrachten in beide protocollen die vlak na elkaar langskomen.

Ik geef al aan dat geen decoder er problemen mee zal hebben.

Citaat van: Anne W op zaterdag 08 februari 2020, 16:44:13
Maar ik denk dat de decoders die werken met automatische herkenning van het protocol zoals de Digikeijs en ook de 2 servo uitgangen van de Esu Switch Pilot hier wel problemen mee kunnen hebben.

Nee, dat hebben ze niet. Ze worden ingesteld op het juiste formaat door het geven van een adres. Na het instellen luisteren ze alleen naar het ingestelde protocol. Het zelfde als bij "hard" geschakelde of gecodeerde decoders.

Citaat van: Anne W op zaterdag 08 februari 2020, 16:44:13
Ken jij een andere centrale die altijd elke wissel "schakel" opdracht in twee formaten vlak na elkaar uitzendt?

Nee, ik weet van het systeem van de IB. Één hoofdprotocol en dan aangeven wat de afwijkingen zijn. Dat is een logische gedachte voor een programmeur. Kost nauwelijks een paar regels extra qua programmeren en opslag.

Citaat van: Anne W op zaterdag 08 februari 2020, 16:44:13
Efficiency: moet een wissel verzet worden dan wordt het betreffende wisselbesturingskommando 4 maal achter elkaar tussen twee lokbesturingskommando's uitgezonden en daar merken de loks helemaal niets van.

Het gaat niet over lokscommando's maar over schakelcommando's. Bij de Raptor wordt een wisselopdracht in zowel DCC als Motorola de baan opgestuurd. Dat is in theorie gewoon 1 protocol te veel. Dus inefficiënt. Daarnaast kom met het uitsturen van commando's in alle protocollen (Motorola en DCC) je dus op de limiet van het protocol dat het minst aantal wissels kan schakelen: Motorola met maximaal 320 wisseladressen. Het voordeel van gewoon alle protocollen op de baan zetten is dat je niet hoeft op te slaan welk protocol bij welk adres hoort. Scheelt wat bytes opslag in het geheugen. Voor moderne centrales is dat steeds minder een probleem.

Groet Ronald.
Re: Esu Switch Pilot V2.0
Lid sinds: 2013

offline
Re: Esu Switch Pilot V2.0
Hoi,

Het verbaasde mij in eerste instantie ook dat de Raptor zowel DCC als Motorola na elkaar uitzendt.
Maar na wat gedachtes hierover lijkt het ook een compromis te zijn.
De Raptor is natuurlijk een ander soort centrale die er vanuit gaat dat je geen PC nodig hebt om toch
digitaal automatisch te kunnen rijden.

Dit is zowel een voordeel als een nadeel, de gebruikte processor LPC2292/01 bron post Anne op dit
forum is een processor daterend uit 2004. Destijds een krachtpatser met maar liefst 256 kB Flash memory
en 16 kB Ram. Nu een erg oude processor (16 jaar oud) een eeuwigheid in processor technologie.

Omdat de Raptor een ander soort centrale is moet hij ook veel meer in eigen geheugen opslaan om het
automatisch rijden mogelijk maakt, dit in tegenstellng tot de Centrales die koppeling met de PC centraal
hebben. Deze centrales kunnen met gemak de verschillende protocols opslaan die gebruikt worden door de
diverse schakel componenten. Zelfs als ze de zelfde processor zouden gebruiken als de Raptor.

De automatesering bij andere centrales vind plaats in de PC die daar in principe een gigantisch
geheugen ter beschikking heeft (Gigabytes ipv een paar Mega byte). De PC stuurt de commando's naar
de centrale die op zijn beurt de commando's op de baan zet. Dit kost verder weinig geheugen.

Raptor heeft hier een enorm nadeel namelijk alles moet in zijn interne geheugen passen en dus elke
bit/byte die daar bespaard kan worden is meegenomen.
Om voor alle mogelijke wissels in DCC en Motorola de protocols op te slaan kost uiteindelijk veel bytes,
en die zijn toch al schaars in Raptor.

Het compromis dat nu gekozen is om verder niets op te slaan maar eenvoudig alle DCC als Motorola commando's
na elkaar uit te zenden.

Als je dit zou moeten doen voor 320 Motorola wissels en mogelijk 2048 DCC wissels gaat dat de nodige tijd
(bandbreedte) kosten. Het uizenden van commando's kan heel erg lang gaan duren en zelfs het totaal missen
van commando's behoord tot de mogelijkhedden.
De lok commando's zijn hier nog buiten beschouwing gelaten dus die hebben per lok ook de nodige invloed.

Nu zul je op een relatief kleine layout hier weining of niets van merken maar hoe groter de layout hoe trager
het systeem.

Andere centrales zijn hier in het voordeel zijn omdat zij veel minder commando's (alleen het nodige)
per seconde op de baan zetten.

Mvg,
Peter
Re: Esu Switch Pilot V2.0
Lid sinds: 2007

Elk vogeltje zingt zoals het gebekt is.

online
Re: Esu Switch Pilot V2.0
Beste Heer Ronald,

Uit jouw bijdrage van jou van zaterdag 08122020 19HR12:

Maar ik denk dat de decoders die werken met automatische herkenning van het protocol zoals de Digikeijs en ook de 2 servo uitgangen van de Esu Switch Pilot hier wel problemen mee kunnen hebben.

Nee, dat hebben ze niet. Ze worden ingesteld op het juiste formaat door het geven van een adres. Na het instellen luisteren ze alleen naar het ingestelde protocol. Het zelfde als bij "hard" geschakelde of gecodeerde decoders.

Uit de bijdrage van Sprinter in https://forum.3rail.nl/index.php?topic=77890.msg1341277#msg1341277

Lijkt me ook niet zo slim voor een decoder die zelf kan uitfilteren wat het format is. b.v. een ESU decoder. Want naar welk format moet hij dan luisteren.


Voor de zekerheid, omdat ik een beetje het gevoel krijg dat je niet helemaal begrijpt wat de Raptor doet met schakeldecoders, een voorbeeld:

de Raptor staat ingesteld op Motorola en DCC
ik wil wissel 5 afbuigend stellen
ik druk op 5 en op rood
de centrale stuurt in het formaat Motorola 2 maal de schakelinstructie 5 Rood uit
de centrale stuurt in het formaat DCC 2 maal de schakelinstructie 5 Rood uit
wissel 5 schakelt afbuigend.

Ik weet zeker dat decoders die qua IC's gebruik maken van de specifieke Motorola IC 145027 geen last hebben, ik weet nagenoeg zeker dat decoders die het formaat Motorola of DCC instellen met een schakelaar of een jumper geen last hebben.

Ik twijfel over decoder die aan "formaatherkenning" doen, zoals de 2 servo uitgangen van de Esu Switch Pilot (de schakel uitgangen hebben een schakelaar) en de Digikeijs en nu zeg jij dat er geen probleem is, maar Sprinter doet een tegengestelde uitspraak......, dus als er iemand is die het definitieve antwoord weet dan hoor ik dat graag.

Ik meen me te herinneren dat als je een Digikeijs decoder, als je DCC beschikbaar hebt deze dan beter met DCC kunt aansturen, want met Motorola gaat het soms niet goed.

Nee, het aantal beschikbare adressen wordt niet gelimiteerd door het Motorola formaat, je moet alleen logisch nadenken en je Motorola decoders in de adressen reeks van Motorola zetten en de andere boven de Motorola reeks, voor de zekerheid: je hoeft in de Raptor niets in te stellen voor de schakeldecoders, gewoon de decoder een adres geven, op het gewenste nummer drukken en op rood of groen drukken.

Beste Johnny,

Ik denk dat het multiprotocol systeem van de Raptor afwijkt van de andere centrales, bij mij werken de K83, K84 (is hetzelfde als Edits en Viessmann) en LDT (lichtseindecoders met jumper voor het te gebruiken systeem) ook prima, maar daar zit het vraagpunt ook niet.

Groet, Anne W
Re: Esu Switch Pilot V2.0
Lid sinds: 2007

Elk vogeltje zingt zoals het gebekt is.

online
Re: Esu Switch Pilot V2.0
Beste Peter,

Dank je wel voor je uiteenzetting, ik heb er weer wat van geleerd, maar:

op mijn baan rijden 19 treinen, ik heb geen uitgebreide schaduwstations, dus alle 19 treinen zijn vaak in bedrijf, met een gelijktijdigheid van maximaal 10 rijdende treinen (schat ik), ik heb geen last van niet schakelende wissels en seinen (mechanische- en lichtseinen), de afgelopen jaren heb ik wel twee maal een "gemiste" afschakelopdracht gehad, maar of dat aan de Edits decoder of de Raptor lag was niet te traceren.

als je mij volgt dan weet je ook dat mijn 100% visueel gehandicapte clubcollega bezig is met een Raptor op de hele grote 3-Poot baan op de club, de Raptor moet niet alleen de veel grotere baan besturen, maar ook nog een braille-leesregel aansturen en de baan is een één-terugmelder per blok baan, dus er is nieuwe software ontwikkeld.

inderdaad, de geheugenruimte van de Raptor bleek niet groot genoeg, daarvoor is het programma onderdeel "baanplan invoeren middels leer-traject" opgeofferd.

ik heb niet het idee dat de Raptor het zo druk heeft dat hij schakelopdrachten mist, dat je natuurlijk tegen de grenzen van het Motorola en DCC systeem aanloopt bij grote banen is evident, maar dat ligt niet echt aan de Raptor, de systemen op zich beginnen te "knellen".

Ik weet dat het programma iTrain ook draait op Raspberry computertjes (ook bij mij op de club), wat mij interesseert is hoe de capaciteit van de processor in de Raspberry's zich verhouden tot de door Raptor gebruikte, inderdaad oude, processor.

Nog iets voor de goede orde: mijn theoretische kennis over de digitale systemen zijn voor een groot gedeelte gebaseerd op het boek over de Edits centrale uit 1991 (de centrale hang nog steeds niets te doen onder mijn baan) en natuurlijk door op forums te lezen en lezen enz.

Groet, Anne W

Re: Esu Switch Pilot V2.0
Hallo Anne,

Citaat van: Anne W op zondag 09 februari 2020, 17:23:34
Ik twijfel over decoder die aan "formaatherkenning" doen, zoals de 2 servo uitgangen van de Esu Switch Pilot (de schakel uitgangen hebben een schakelaar) en de Digikeijs en nu zeg jij dat er geen probleem is, maar Sprinter doet een tegengestelde uitspraak......, dus als er iemand is die het definitieve antwoord weet dan hoor ik dat graag.

Wim / Sprinter geeft juist aan dat het slim is om één basis protocol die je het meeste gebruikt in te stellen. Dat is slim. Hij zegt ook dat als je alle protocollen op de baan zet en alle decoders moeten naar alle protocollen luisteren. En dan de vraag hoe moet de decoder weten naar welk protocol hij moet luisteren? Dat zie jij niet echt als een probleem volgens je berichten:

Citaat van: Anne W op zondag 02 februari 2020, 23:16:39
Maakt dat wat uit dan, in beide formaten komt dezelfde opdracht, dus naar welke hij luistert maakt niets uit, nu moet de centrale eerst kijken naar wel algemeen formaat aanstaat, dan of de desbetreffende wisseldecoder in het register "afwijkende formaten" staat en indien ja, dat afwijkende formaat produceren.

Als ik me niet vergis wordt een wissel instructie slechts 2 keer 2 keer uitgezonden, vergeleken met het aantal instructies voor een accelererende lokdecoder op 128 stappen helemaal niets....

En met hij bedoel je de wisseldecoder. Wim stelt dan dat het wel slim is. Dat is de kern van het "probleem" want jij wil niet begrijpen als er commando's in twee of meerdere protocollen langs komen dat de vraag is naar welk commando moet de decoder dan luisteren? Dat is de vraag en die vraag stelt Wim / Sprinter ook. Dat is de kern van de vraag. Het is dus waar moet een decoder naar luisteren? De eerst binnenkomende? Dat is de vraag. Daarom wordt een decoder ingesteld op het protocol waar deze naar moet luisteren. Daarbij heeft het ding ook geen problemen met andere protocollen op de baan.

Citaat van: Anne W op zondag 02 februari 2020, 23:16:39
Nee, het aantal beschikbare adressen wordt niet gelimiteerd door het Motorola formaat, je moet alleen logisch nadenken en je Motorola decoders in de adressen reeks van Motorola zetten en de andere boven de Motorola reeks, voor de zekerheid: je hoeft in de Raptor niets in te stellen voor de schakeldecoders, gewoon de decoder een adres geven, op het gewenste nummer drukken en op rood of groen drukken.

Uhm en naar welk protocol luistert je decoder dan? Als je dan een Digikeijs onder de baan hebt hangen en het motorola protocol wordt als eerste uitgestuurd heb je hem in Motorola en niet in DCC wat je eigenlijk wil hebben. Dat gaat dus niet werken. Of kan je de Raptor zo in stellen dat DCC als eerste verstuurt wordt? Dan heb je dus weer een "voorkeursprotocol". Over de wisseladressering: Gelukkig heb je bij de Raptor geen probleem met adressen hoger dan 255 want dat kan de Raptor niet aan volgens de handleiding van het "Raptor interface protocol over RS232"



Maar om even op de beginvraag terug te komen en zonder verder af te dwalen wat je (Anne) graag doet:

Citaat van: Anne W op maandag 03 februari 2020, 21:54:53
De door mij gebruikte wissel/schakel/seindecoders zijn van de merken Edits (Motorola), Viessmann (Motorola) en LDT (DCC), ze werken al jaren prima en ze hebben geen last van het extra formaat wat ze "te horen krijgen".

De vraag is dus waarom zou de Esu Switch Pilot V2.0 niet kunnen wat Edits, Viessmann en LDT wel kunnen.

Met meerdere protocollen op de baan heeft de Esu decoder geen problemen mee. Hij pikt gewoon het protocol eruit waar hij op ingesteld is. Net als alle andere decoders. Daar zal echt geen verschil tussen de Edits, Viessmann en LDT's zitten. Als je het niet gelooft: Koop een ESU, zet hem onder je baan en stuur hem aan. Dan weet je het. Het is een kleine investering, je kan daarna het ding altijd weer verpatsen.

Groet Ronald.
Re: Esu Switch Pilot V2.0
Lid sinds: 2008

offline
Re: Esu Switch Pilot V2.0
Ik heb 6 servodecoders ESU Schwitch Pilot V2.0 onder de baan hangen.
Ik heb ze geprogrammeerd met de LokProgrammer van Esu.
Op welk protocol?  Ik zou het echt niet weten!
Raptor staat bij mij op Motorola en DCC.
Re: Esu Switch Pilot V2.0
 @citaat / Jos: Dat bedoel ik nu ;) Het maakt niet echt uit op welk protocol ze gezet zijn. Ze werken gewoon. Je hebt er geen omkijken naar en ze werken gewoon ondanks dat er motorola en DCC op de baan staat. Anne maakt zich druk om niets.

Groet Ronald.
Re: Esu Switch Pilot V2.0
Lid sinds: 2013

offline
Re: Esu Switch Pilot V2.0
Hoi Anne,

Ik probeerde met mijn betoog duidelijk te maken dat het sturen van beide
protocollen meteen achterelkaar niet erg efficient is en dat het extra geheugen
en bandbreedte op de baan kost.

Met bandbreedte bedoel ik elk commando heeft tijd nodig om uitgezonden te worden
als je nu een commando twee maal uitzend kost dit dubbele tijd. Daar wordt elk
systeem trager van. De vraag is wanneer begin je hier daadwerkelijk iets van te
merken op de baan.

Over het gebruik van beide protocollen op de baan zegt het Raptor Handboek V2.15.pdf
het volgende:
Citeer
Standaard is Raptor ingesteld op Motorola en DCC.
Opmerking:
   Hoewel het in principe mogelijk is om de Motorola en DCC protocollen door elkaar
   heen te gebruiken is er echter het advies om, indien u enkel een Motorola
   installatie of  enkel  een DCC installatie bezit, om deze beide protocollen NIET
   te mengen als dit niet echt nodig is. Wanneer u toch beide protocollen door elkaar
   gebruikt, kan het bij zeer grote modelspoorbanen(meer dan 40 treinen tegelijk
   gebeuren dat de verwerkingssnelheid van het systeem ietwat minder snel wordt.
   Ook kan het voorkomen dat sommige decoders het niet prettig vinden om voor hun
   "vreemde" signalen aangeboden te krijgen.
   Fabrikanten van decoders vermelden dit vaak in hun beschrijving die wordt
   meegeleverd bij de decoder.

   In de engelse Raptor Manual 2.4 is in de vertaling van Nederlands naar Engels;
   40 in 60 treinen vertaald. :)

Hier wordt dus in een iets andere bewoording precies hetzelfde gezegd namelijk:
"het systeem wordt trager".

Verder nog even over de decoders die aan protocol herkenning doen o.a. digikeijs
DR4018
Citeer
   Stukje uit de handleiding van de DR4018:
   Omdat de decoder multiprotocol is en DCC en Marklin Motorola ondersteund,
   zal het kiezen van een wisseladres ook het protocol selecteren. Tijdens het
   ontvangen van het wisselcommando zoals we in bovenstaande volgorde hebben gedaan
   kijkt de decoder welk protocol gebruikt wordt en slaat dit op in zijn geheugen.

M.a.w. het eerste Wisselcommando wat geldig is wordt opgeslagen, als het Motorola
formaat het eerst wordt uitgezonden zal de decoder zich op Motorola instellen.
Het omgekeerde geldt natuurlijk ook.

Als je met Raptor de Multiprotocol decoder gaat programmeren (zo een die na het
indrukken van de programmeer knop gaat luisteren naar een commando) ben je dus
afhankelijk wat Raptor als eerste uitzend.

Stel dat dit Motorola is dan kun je met Raptor dus in het Motorola addressen bereik
nooit een DCC addres programmeren. Wil je dit wel kunnen heb je een centrale van een
ander merk nodig waarbij je kunt kiezen welk protocol gebruikt wordt voor welk adres.

Zoals je zelf schrijft dien je dus de DCC gerelateerde decoders achter het max aantal
Motorola adressen te zetten.
Dat is logisch want dan word het Motorola commando namelijk niet meer uitgestuurd.

Citaat van: Anne W op zondag 09 februari 2020, 17:46:41
Ik weet dat het programma iTrain ook draait op Raspberry computertjes (ook bij mij op de club), wat mij interesseert is hoe de capaciteit van de processor in de Raspberry's zich verhouden tot de door Raptor gebruikte, inderdaad oude, processor.
Deze processoren kun je eigenlijk niet met elkaar vergelijken, ja het zijn allebei ARM processoren
maar daar houd het dan ook wel bij op.

De LPC2292 heeft meer on chip I/O mogelijkheden zoals Digital Input/Output, Analoge Input/Output etc
en worden voornamelijk ingezet in b.v. Wasmachines en kleinere electronische apparaten die veelal
ook een klein LCD schermpje hebben voor bediening.

De Processor van de Raspberry PI is te vergelijken met die in je Telefoon, heeft mogelijkheden voor
wireless netwerk, bluetooth, USB, HDMI en generieke Input/Output.
Op de Raspberry PI draait meestal een Operating systeem, b.v. Linux waar je weer applicaties op kunt
zetten zoals iTrain.
Het is in feite een kleine PC.

Hieronder een paar van de balangrijkste specificaties o.a. Geheugen en processor snelheid.
De gebruikte processor bij Raptor LPC2292/01 met 1 Core 16/32 bits

  • 256 kB Flash memory
  • 16 kB Ram
  • Max frequentie waarop de processor werkt: 60 MHz

Raspberry Pi 3B+ specs:

  • Quad Core 64 bits processor 1.4 GHz --> 1400 MHz
  • 1 GB Ram
  • Micro SD kaart Max 32GB voor besturings systeem

Raspberry Pi 4 specs:

  • Quad Core 64 bits processor 1.5 GHz --> 1500 MHz
  • 1,2 of 4GB model afhankelijk
  • Micro SD kaart max 64GB voor besturings systeem

Oh ja, ik heb destijds ook de Edits centrale gebouwd, staat nog steeds op zolder. Ben daarna wel gaan bedenken hoe ik zelf mijn
eigen decoders kon ontwerpen met behulp van de FPGA's van Altera. Het ontwerp heb ik nog altijd (werkte ook in simulatie). Daarna heb ik ook mijn eigen decoders ontworpen m.b.v. Microchip microcontrollers en hier mijn eigen software voor ontwikkeld zowel voor Motorola als DCC. Het gerucht ging destijds dat de productie van de Motorola IC's gestopt zou worden, dus vandaar mijn eigen decoder ontwikkeling.
Ik heb me dus wel enigzins verdiept in de protocollen.

Mvg,
Peter
Re: Esu Switch Pilot V2.0
Lid sinds: 2009

Dwarsliggers op de rails sporen niet

offline
Re: Esu Switch Pilot V2.0
Citaat van: Anne W op maandag 03 februari 2020, 21:54:53
tevens is mij verzocht om daarover niet in dat topic verder te discussiëren, dus dan maar een nieuw topic.
Ik begin te begrijpen waar deze discussie over gaat, met name dankzij de inbreng van pjve64.
Want het gaat niet om ESU, niet om Raptor en niet om andere digitale apparaten, maar puur op het compact houden van de datastroom. Het gaat niet om wat kan, maar om hoe je dat met zo beperkt mogelijke middelen bereikt. De tijd van de eerste Comodore dringt zich bij me op, en zo'n joch wat me vroeg hoe je daar een animatie op programmeert. Ik heb 'm omgeschoold in ansi-C. Beide antiek inmiddels.
Re: Esu Switch Pilot V2.0
Lid sinds: 2013

offline
Re: Esu Switch Pilot V2.0
Nou ANSI-C is niet zo antiek hoor, ik programmeer hier nog dagelijks in.
Ik werk namelijk bij een bedrijf dat Klimaat systemen maakt voor Touring Cars en Stads bussen en de Bedienings Panelen voor de chauffeur alsmede I/O devices worden in ANSI-C geprogrammeerd en communiceren over de CAN bus met elkaar.

Mvg,
Peter
Re: Esu Switch Pilot V2.0
Lid sinds: 2007

Elk vogeltje zingt zoals het gebekt is.

online
Re: Esu Switch Pilot V2.0
Beste Jos,

Een duidelijk antwoord gebaseerd op ervaring, dus goed, dank je wel, voor het programmeren met de Raptor moet je de Raptor even op alleen DCC zetten, ik heb dat gedaan met een paar van die nieuwe Viessmann armseinen, ging prima, daarna weer beide protocollen "aangezet" en alles werkt.

Beste Heer Ronald,

Wat betreft het aantal beschikbare schakeldecoder adressen in DCC, daar moet ik even een onderzoekje in plegen, ik ben begonnen als Motorola mens en op mijn baan ben ik nog niet tegen een grens opgelopen, dus ik heb me daar nooit in verdiept, ook heb ik geen computer aan de Raptor hangen, ik kijk op de baan wat er gebeurt en krijg een alarmpje als er een trein vertraagd is.

Beste Peter,

Nogmaals hartelijk dank voor je uitleg die voor mij heel goed te volgen en begrijpen is.

Bij mij staan beide protocollen aan omdat ik lokdecoders heb van beiderlei kunne, wat ik niet helemaal begrijp is wat je zegt over bandbreedte, natuurlijk het uitzenden van een schakeladres/instructie in 2 formaten kost meer tijd, maar daar staat tegenover dat het uitzenden van schakeladressen/instructies in vergelijking met het uitzenden van lokadres/instructies relatief zeldzaam is (loks: acceleren, afremmen, functies en herhalingen), daarnaast kosten de schakeladres/instructies maar de helft van de tijd die lokadres/instructies nodig hebben.

Je verhandeling over de Raspberry is zeer verhelderend voor mij, de weg van het ontwikkelen van een "gebruikers" update mogelijkheid voor de Raptor liep via de Raspberry 1, inmiddels hadden ze ontdekt dat ze ook in Windhoos konden programmeren, dus nu gaat het via Windhoos.

In die tijd heb ik wel eens gevraagd of de Rasberry niet iets is voor een Raptor V2, het antwoord was toen nee, niet goed genoeg, nu heb ik het gevoel dat dat wel zou kunnen, maar ik denk dat de tijdgeest nu veel meer zichtbare "toeters en bellen" vraagt als de Raptor nu biedt, daarnaast is het menselijk leven eindig zoals het programma Koploper heeft ondervonden en Raptor ook heeft ondervonden (partner is weggevallen).

Nee, ik heb me niet echt verdiept in de protocollen, heb ik ook de theoretische achtergrond niet voor, maar de mannen achter Raptor wel, natuurlijk omdat die DDC, MM, SX en FMZ heeft gedaan (FMZ is nu vervallen gaf ook weer geheugenruimte denk ik), de aanbeveling om maar één systeem te gebruiken ken ik.

Nogmaals hartelijk dank, groet, Anne Wtenweerde