Met loconet kunnen we al een soort van alles. We hebben railsync, boosters, throttles, terugmelders.. d'r bestaan schakeldecoders. We kunnen railcom en ext. instructies sturen. Dus waarom willen we dan nog een bus die zo'n beetje hetzelfde kan?
Daarnaast is Bidib technisch veel moderner en krachtiger
maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie).
De DR5088RC doet toch precies dat?
Nee, nog erger: 192 IOs
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren. AVR 328/2560 kan je meteen vergeten. Xmega's zijn exclusief en duur.
Kan ik dit zo lezen dat V3.6 voor 100% wordt ondersteund, maar de nieuwe V4 slechts een deel??
Dat het Z21 protocol populair is, zie ik zelf tegenwoordig ook. Maar dat je ook OpenDCC noemt, verrast me wat. Bedoel je BIDIB? Dat zou een interessante ontwikkeling zijn.Sorry, maar ik begrijp het nu helemaal niet meer Over welk XpressNet commando heb je het? Of heb je het over DCC commando's??
Het lijkt er inderdaad op dat vendor lock-in belangrijker wordt gevonden dan standaardisatie. In plaats dat het voor de gebruiker eenvoudiger wordt, komt er steeds meer verschil tussen fabrikanten. En open beschikbare documentatie wat het apparaat ondersteund is ook niet altijd beschikbaar. Daarnaast lijkt het er ook op dat Europa en de VS steeds verder uit elkaar groeien; fabrikanten opereren steeds vaker alleen voor hun "lokale" markt. Illustratief vind ik dat de Lenz XpressNet V4 spec, voor zover ik weet, niet mee in het Engels heeft. In de VS heb je LCC, waarover je in Europa niets hoort. Enz.
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren.
...AVR 328/2560 kan je meteen vergeten. Xmega's zijn exclusief en duur.......Daarnaast is Bidib technisch veel moderner en krachtiger...
...Maar zeggen dat Loconet alles al kan ..... ...
...maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie)...
Ik heb het OPC_MULTI_SENSE bericht formaat uitgepuzzeld door gewoon te proberen, loks met andere adressen, andere ingang en kijken wat er verandert, zoveel bytes zijn het niet, dat puzzel je zo uit. Heb wel contact gehad met Digitrax over de NDA, maar toen ik vroeg hoe dat samen ging met open source software toen kreeg ik geen reactie meer.... Toen ben ik het maar gaan reverse engineeren, als ze dat niet oke vinden dan hoor ik dat wel, kunnen we dan verder praten.
De DR5088RC ondersteund ook nog OPC_MULTI_SENSE_LONG, daar zit veel meer RailCom info in.
@Karst bij de YD70xx doe je dus wat speciaals met de OPC_IMM_PACKET als het DCCext is, dat is wel een mooie feature Wat doe je dan met de repeat count van OPC_IMM_PACKET?
With the help of RailCom ... Any commands which are received can be acknowledged by the decoder, increasing the operational reliability and bandwidth of the DCC System, since commands that have already been acknowledged will not require repetition.
Het grootse probleem naar mijn mening is, dat je óf van 0 beginnen moet, óf je hele bestaande installatie moet vervangen
Kan je via de global railcom detector ook horen dat decoders hun 'rijpakketjes' hebben ontvangen met het doel dat je niet hetzelfde pakketje 10~20x hoeft te herhalen om een snelle responstijd te garanderen. Ik denk als elke decoder en tevens accessoire decoder hun commando's kunnen bevestigen (al is dat met een enkele bit), dat het 'dcc plafond' aanzienlijk verhoogd kan worden
Refereer je hier naar software of hardware of beide?
alleen moet er dan een verbinding zijn tussen alle "Global" detectors en de centrale.
Verder is het leuk, maar wat als er een stroomonderbreking is naar de decoder toe
In eerste instantie de hardware.
Je boosters hebben toch loconet .
Gewoon verder gaan wanneer zijn cyclisch herhaalde instructie weer voorbij komt (en je rails poetsen om te voorkomen dat ze uitvallen in de eerste plaats )
Maar je zegt hier iets interessants. Als een trein een x aantal keer op rij geen pakketjes ackt, dan kan je centrale en daarmee iTrain oid weten dat die trein is uitgevallen. Een mobile/central station gaat ook knipperen als je je mFx lok van je baan plukt.
Ik weet niet met welk pakket je werkt. Maar ik doe bijvoorbeeld in KiCad veel met hierarchische sheets werken en ik kan daarbij stukken board recyclen. Dat + mijn geliefde 'replicate layout' en 'place footprint' plugins zijn geweldig. Maar ik mis eigenlijk design blocks. Ik heb dit verder uitgedacht. Als je op voorhand rondom bijvoorbeeld een uProcesser, en bijvoorbeeld een Loconet circuit een beetje ruimte reserverveert. Dan kan je in 5 minuten tijd van een pcb ontwerp ff de microprocessor swappen. Je moet er alleen er voor zorgen dat de voor-geroute printsporen bij je nieuwe uProcessor blok op dezelfde plaats eindigen als de oude. Daarvoor zou ik dan een dummy connector(s) gebruiken op vaste locatie(s). Met zelfde wijze kan je een loconet terugmelder bijvoorbeeld in no time omzetten naar de BiDib equivalent. Dit moet je dus allemaal bedenken voordat je begint..... Ik had dit echt veel eerder moeten bedenken
Ik bedoelde wanneer je als EIND gebruiker wilt overstappen op BiDiB
Het grootse probleem naar mijn mening is, dat je óf van 0 beginnen moet, óf je hele bestaande installatie moet vervangen. En laat dat nou net iets zijn, dat nou niet echt tot acceptatie voert. Een ander merk heeft onder andere als motto: "COMPATIBILITY is ESSENTIAL"
Maar het is maar net wat je onder de term "Open" verstaat. Persoonlijk vind ik Z21, XpressNet, WiThrottle allemaal behoorlijk Open: goede, publieke specificaties, die voor iedereeen zonder restricties te gebruiken zijn
Nach Rückfrage bei unserer Entwicklungsabteilung kann ich Ihnen mitteilen, das wir dies planen, aber leider noch keinen Termin nennen können.