ESU nyheder 2014

[Søren]

Hej Ole

Tak for svar. Det forklarer en del. :)

[moppe]

Der kommer også en "funkhandregler" til ecos.

"Funkhandregler":
http://www.esu.eu/produkte/digitale-ste ... ontrol-ii/

En Android ting med drejeknap :-)

Klaus

[Søren]

En Android ting med drejeknap :-)

Så fik vi svar på det. Spændende koncept.

Potentielt kan man vel så installere en MS2 app på den og bruge den til en CS2. Alternativt installere en anden app og bruge den med et vilkårligt digitalsystem?

Jeg kunne ikke se hvilken version af Android den kører. Det er forhåbentlig nyeste skrig.

[moppe]

Det vil være fint med andre app's - hvis de kan læse drejehjulet......

Klaus

[Søren]

Det vil være fint med andre app's - hvis de kan læse drejehjulet.

Det er selvfølgelig rigtigt, det kommer an på hvordan det er implementeret. Det virker nok ikke som udgangspunkt.

[moppe]

Så er nyhederne helt officielle

Rullende materiel:
http://www.esu.eu/fileadmin/download/br ... _eBook.pdf

Alt det andet
http://www.esu.eu/fileadmin/download/br ... _eBook.pdf

Her stå der en masse om Mobile control, motoriseret drejeknap, som vi kender det fra ecos, trykknap til retningsskift og ikke mindst at de vil frigive API'en så andre kan skrive app's de bruger de ekstra knapper og drejeknappen.

Der er og den længe, længe ventede nyhed. Loksound 4 med plux22 og 9 funktionsudgange!

Klaus

[Søren]

Her stå der en masse om Mobile control, motoriseret drejeknap, som vi kender det fra ecos, trykknap til retningsskift og ikke mindst at de vil frigive API'en så andre kan skrive app's de bruger de ekstra knapper og drejeknappen.

Det er en god start, at de har valgt at åbne deres API. Så kommer der i det mindste en mulighed for apps til andre systemer. Håndkontrollen er dog stadig væsentlig dyrere end andre, i hvert fald hvis man skal have til en fem seks personer. Den åbner dog nogle muligheder som ingen andre håndkontroller har, så det kan være det flytter noget for nogen.

Jeg har aldrig forstået hvorfor drejeknappen skal være motoriseret. Det ser da "automatiseret og autopilot"-agtig ud, men jeg synes nu det er en unødvendig funktion, især i en håndholdt enhed, der helst ikke skal fylde for meget. :-) Jeg synes deres Mobile Control II er en smule tyk, sammenlignet med en mobiltelefon. MultiMouse og MS2 er jo heller ikke åleslanke, så måske ender det med ikke at betyde noget. Det finder jeg ud af, når jeg har prøvet den live.

Kudos til Plux22 decodere. Så kan jeg få skiftet min Uhlenbrock ud.

[moppe]

Den motoriserede drejeknap er i mine øjne ikke kun "rent blær" men også et resultat af at knappen derpå (med sin udhulning) er en "absolut hastighedsviser" og ikke bare en "drejeknap".
Den er noget stor - 16,5 x 5,5 x 1,5 cm er en "ordentlig basse" i forhold til en mobiltelefon, men "lille" i forhold til en Multimaus.

Klaus

[Søren]

Den motoriserede drejeknap er i mine øjne ikke kun "rent blær" men også et resultat af at knappen derpå (med sin udhulning) er en "absolut hastighedsviser" og ikke bare en "drejeknap".

Jeg formoder at jeg også kan se hastigheden på skærmen, som det er tilfældet med de andre produkter.

[mr-data]

Denne "Mobile Control II" ser rigtigt interessant ud, ingen tvivl om det. I øvrigt er det da vist helt nye toner fra ESU at man vil frigive API'er til et produkt, herom længere nede.

Hidtil har ESU, ligesom de fleste andre producenter, mig bekendt kørt med mere-eller-mindre lukkede, propietære "busser". Der findes et utal af disse, f.eks. LocoNet (principielt set åben, men bl.a. Uhlenbrock kører mig bekendt deres egen variant af denne), ESUs ECoSLink, Märklins version af CAN, samt forskellige andre. At man som producent vælger at bruge et lukket system er for så vidt forståeligt nok, da det kan sikre at forbrugerne i større eller mindre grad bliver afhængige af dem (producenten) for at få det fulde udbytte af en af de avancerede centraler. Det kan dog også gøre at nogen forbrugere fravælger disse producenter, hvilket eksempelvis Märklin har indset.

Märklin har i mange år holdt sig til egne standarder, og til en vis grad kørt med lukkede systemer i forbindelse med deres digital-system. Men i forbindelse med lanceringen af Central Station 2 har man tilsyneladende foretaget en ko-vending; nu lægger man dokumentation for CS2s variant af CAN-bussen ud, og har sågar gjort plads til at forbrugere (det som tyskere kalder "bastler") kan udvikle egne enheder til denne. Dette kan man f.eks. se ved at kigge på CAN-digital-bahn projektet, som tilbyder en række enheder til CAN, langt de fleste kan stort set kun arbejde med CS2, MS2 og til dels MS1. Man har for de førstnævntes vedkommende sågar gjort det muligt at bruge DCC som digitalformat, istedet for MM1 eller MM2.
Topologien her er opbygget ud fra stjerneprincippet; så hvis man ellers sørger for ikke at skabe ringforbindelser på CAN-bussen har man stort set "frie tøjler" med hensyn til layoutet.
Desuden er denne version af CAN, angiveligt, ikke centreret omkring CS2'eren: Alle enheder kan sende beskeder/ordrer og alle enheder lytter til alle beskeder/ordrer, og reagerer hvis de er adresseret til dem. Desuden vil alle enheder med mulighed herfor, vise f.eks. placering af lokomotiver, aktiverede sporveje, og så videre.

ESU har, mig bekendt, valgt en version af CAN-bussen (herefter deres navn derfor: ECoSLink) som er centreret omkring ECoS. Alle beskeder og ordrer fra alle enheder på ECoSlink-bussen skal lige ind og runde ECoS'en inden de sendes videre, hvis man altså anvender en sådan, hvad jeg formoder de fleste store og mellem-store anlæg baseret på ESUs enheder gør.
Hvad topologien angår, så går ESU også sine egne veje. I følge tegningen på side 12 i nyhedsprospektet, skulle ECoSLink være baseret på en stjerne-topologi; sådan tolker jeg i hvert fald den måde at ECoS befinder sig i midten af ECoSLink nettet, og herfra grener sig ud i et T. Men læser man brugsanvisningen til deres ECoSLink Terminal står der tydeligt, at ECoSLink skal opbygges som en bus i en kæde af terminaler. Det vil med andre ord sige, at hvis man som undertegnede ønsker at placere sin central (i dette eksempel ECoS) mit på anlægget og have disse "terminaler" flere steder på begge sider af centralen, skal man først føre kæden helt ud til fjerrneste punkt i en retning, for dernæst at føre et langt kabel tilbage til den modsatte side af centralen og så fortsætte kæden.
Med den topologi risikerer man at opnå et problem; afstand. ESU understreger flere steder at ECoSLink ikke må være længere end 100 meter lang (som kæde), så hvis man opnår en afstand af 25 meter på hver side af centralen, er det den maksimale udstrækning man kan opnå med ECoSLink. Okay, indrømmet, det er måske de færreste som ender med det problem, men jeg finder det fuldstændig vanvittig at skulle føre sin bus fra en ende af anlægget til den anden; det virker som spild af kabler og giver potentielt set øget rod af kabler under anlægget.

Som afslutning vil jeg gerne understrege følgende: Jeg er IKKE hader af ESU og deres produkter, jeg synes tværtimod at de laver nogle virkelige fede og undertiden innovative produkter. MEN: De hævder at de ønsker at give deres kunder fleksibilitet med hensyn til brugen af deres produkter, hvilket der dog som det fremgår ovenfor ikke just lægges op til med de begrænsninger som jeg nævner.
En anden understregning: Jeg er IKKE ekspert på dette områder, og skriver blot tingene som jeg har opfattet dem og fået forklaret via kilder rundt omkring på Internettet. Så de KAN sagtens indeholde fejl, hvilket jeg naturligvis vil beklage på forhånd.