Doel:€250.00
Donaties:€88.00

Per saldo:€-162.00

Steun ons nu!

Laatst bijgewerkt
op 03-06-2025

Vacature: secretaris bestuur
Algemeen

De stichting

Recente berichten

lampjes in huizen willekeurig schakelen door Bert55
Vandaag om 11:19:41
Van British Railways Class 58 naar ACTS 5814 in 0 door RobbertJan
Vandaag om 10:55:10
Allereerste lok(je) door henk
Vandaag om 10:39:29
Bentheimer Eisenbahn, gisteren, vandaag en morgen. door Hans Reints
Vandaag om 10:37:30
Noorwegen - interessante spoorzaken langs vakantieroute door martijnhaman
Vandaag om 10:34:01
Toon hier je nieuwe (model-) spooraanwinst(en)... door VAM65
Vandaag om 10:27:28
Mijn eerste H0-modeltreinbaan in aanbouw door Frank 123
Vandaag om 10:04:12
BNLS-Module: "Rvbr-Btk, Ringvaartbrug Haarlemmermeer nabij Buitenkaag" NS H0 door MOVisser
Vandaag om 10:03:11
Fleischmann Anna ombouw. door puntenglijder
Vandaag om 09:39:00
Bauarbeiten im gange door puntenglijder
Vandaag om 09:32:05
Mooi weer om buiten te spelen door puntenglijder
Vandaag om 09:30:32
Ombouw/Pimpen Bolle neuzen door bollen neus
Vandaag om 09:24:42
Aanbrengen van (kleine) nummerplaten en dergelijke door RikM
Vandaag om 08:53:39
Aanbrengen nummerschildjes, maar met welke lijm? door Sikko
Vandaag om 08:12:04
Aachenau West door puntenglijder
Vandaag om 07:48:44
Ronald doet de Fork Challenge! door Ronald Halma
Vandaag om 02:25:29
Verwijderen van het nummer op Roco 1631 – tips gezocht door Jos B.
Vandaag om 01:22:32
Acherntal 2.0 H0 TP III/IV door wob
02 August 2025, 22:30:44
NS 9500 scratch build uit Fleischmann BR94 door Erwin 054
02 August 2025, 22:12:27
BR-18.6 Schaal-0. door FritsT
02 August 2025, 21:55:45
't Boemeltje door RobVille
02 August 2025, 21:36:12
Nieuwe ruimte voor baan na ca. 30 jaar door ruudns
02 August 2025, 20:24:06
Modules van Kees Gorter (vervolg) door ca.gorter
02 August 2025, 20:21:24
BMB-Module: “Corfe Castle Station” door Sofie
02 August 2025, 19:52:29
Schets Weistra regeling met arduino UNO door keesg
02 August 2025, 19:29:23
Länderbahn en Reichsbahn locomotieven. door puntenglijder
02 August 2025, 19:05:08
Vitrinekast door Frits C
02 August 2025, 19:03:57
Grootspoor in Frankrijk door ruben derks
02 August 2025, 19:00:16
Artikelen "Het matblad" door ES44C4
02 August 2025, 18:24:12
Schwarzburg-Neuffen-Bahn door NS264
02 August 2025, 18:15:26
  

Auteur Topic: Yamorc 7010 en xpressnet voor communicatie richting PC  (gelezen 3222 keer)

AP3737

  • Offline Offline
  • Berichten: 330
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #15 Gepost op: 10 July 2024, 11:04:57 »
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?
Er zijn toch behoorlijk wat functies die Bidib kan, maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie). Daarnaast staat de complete Bidib specificatie gewoon op Internet, terwijl die van Loconet slechts gedeeltelijk openbaar is. (Commerciële) nabouw van Loconet is beperkt mogelijk. Daarnaast is Bidib technisch veel moderner en krachtiger.

Voorkeuren (en toepassingsgebieden) verschillen, en dat is ook prima. Maar zeggen dat Loconet alles al kan ..... ;)

Groet, Aiko

bask185

  • Offline Offline
  • Berichten: 5003
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #16 Gepost op: 10 July 2024, 11:32:37 »
Citaat
Daarnaast is Bidib technisch veel moderner en krachtiger
Moderner geef ik niet altijd om, krachtiger klinkt opzich wel leuk maar dan ga ik me altijd afvragen. Do we need krachtiger?  ;D. BiDib heeft wel een hogere baudrate 500k vs 16.6k, maar mensen rijden al succesvol op loconet apparaten. Die atmega328 gingen volgens mij niet zo hoog kwa baudrate. En ik hou m'n good ol' 8 bitter. If it works...

Ik ga binnenkort een test opstelling maken met 10 loconet terugmelders. Elke melder zal dan tegelijk alle 16 contacten door willen geven. Met een beetje mazzel kan ik dat dan goed vastleggen op een terugmeld monitor op de PC.

Citaat
maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie).
De DR5088RC doet toch precies dat? Je kan als ontwikkelaar sws van alles doen met die vrije OPCODE waar Karst het over had. Er kunnen tot 255 bytes in een bericht. Daarin kan je elke data zetten wat je maar wilt. En als de nood echt hoog is, voeg je zelf een OPCODE toe.

Met LNCV programmering kom je ook nog eind met dingen instellen. No problem.

Mvg,

Bas
Train-Science.com
Train-Science github
It ain't rocket science ;-)

reinderlf

  • Traintastic!
  • Offline Offline
  • Berichten: 104
    • traintastic.org
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #17 Gepost op: 11 July 2024, 00:03:08 »
De DR5088RC doet toch precies dat?

Klopt, alleen het nadeel van OPC_MULTI_SENSE is dat die net wat te beperkt is. Je kan bijvoorbeeld de trein richting niet doorgeven. De DR5088RC kan dat wel, maar dat gebruikt die de hoogste bit van het sensor adres of lok adres. Nadeel daarvan is dat je de helft van je adressen kwijt bent. Als je de richting in het lok adres codeert heb je "maar" 4096 adressen, daarboven krijg je een rollover, voor thuis niet zn issue, maar hier op de club geven ze ieder lid een 100 adressen blok, toen de persoon met de 41xx range zn lok op de rails zette ging dat aanmelden niet goed. TrainController 9 ondersteund helaas alleen de Blücher GBM 16XN methode (richting in adres).

De DR5088RC ondersteund ook nog OPC_MULTI_SENSE_LONG, daar zit veel meer RailCom info in.

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.

@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? (Ik heb die nu op 2 staan voor DCCext, leek me wel voldoende, die decoders zitten toch direct op DCC, zonder wielen ertussen :))

Nee, nog erger: 192 IOs  :)

Wow dat zijn er echt een boel, als je een topic begint (met foto's) let me know (via PM), ben heel benieuwd.

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.

BiDiB heb ik ook wel eens naar gekeken, op papier een mooi systeem, tot ik de prijs zag van modules, dat viel me wel tegen. Denk toch dat als je een nieuwe strandaard wil zetten (bij voorkeur een open standaard), dan moet de hardware niet te duur zijn, dan kopen veel mensen toch eerder wat anders waarbij de prijs per poort lager is.

Karst Drenth

  • Offline Offline
  • Berichten: 10481
  • NS blauw, groen, rood, bruin, grijs en standgroen
    • Plan U op Sleutelspoor
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #18 Gepost op: 11 July 2024, 12:43:34 »
Kan ik dit zo lezen dat V3.6 voor 100% wordt ondersteund, maar de nieuwe V4 slechts een deel??

Dat klopt. de V4 implementaie is "on-going". ( pick your cherries ;) )

Citaat van: AP3737
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??

Nee, ik bedoel echt OpenDCC. BiDiB is een ander beest. Hoewel het onder water veel van de OpenDCC specs gebruikt. En ja, het gaat dan over XpressNet commando's.

Zie hier: https://www.opendcc.de/elektronik/opendcc/xpressnet_commands_e.html Dat is de Lenz V3.6 set, aangevuld met "eigen" commando's. Die dan weer deels door Z21 overgenomen zijn.

Citaat van: AP3737
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.

Ik volg op verzoek van de noord-Amerikaanse klanten al geruime tijd die ontwikkeling... Ik heb helaas maar 1 conclusie: volledig over-engineered, conceptloos ( alles "kan" alles ) en amateuristisch ( de gebruiker moet zelf ALLES letterlijk programmeren. Een grote hobbel voor 99% van de modelspoorders ) : ==> Niche.

Citaat van: AP3737
De enige echt "open" ontwikkeling is Bidib, maar dat vraagt veel meer om te implementeren.

Dat is wat men ( de BiDiB jongens ) de wereld graag wil doen geloven. 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.

Citaat van: AP3737
...AVR 328/2560 kan je meteen vergeten. Xmega's zijn exclusief en duur....
...Daarnaast is Bidib technisch veel moderner en krachtiger...

Hoewel ik de XMega's heerlijke, goed doordachte MCU's vind, zijn ze allesbehalve modern. Dat hebben we wel gemerkt tijdens de chip-crisis....
In plaats van krachtiger en moderner zou ik eerder de term "over-engineered" willen gebruiken. 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" ;) :P

...Maar zeggen dat Loconet alles al kan ..... ;) ...

LocoNet kan in principe alles. Er is geen technische beperking. Maar terecht opgemerkt: De specs zijn Half-Open en de IP-eigenaar is niet altijd bereid veranderingen door te voeren. ( en dan zeg ik het denk ik nog netjes ;) )

...maar Loconet niet (denk aan RailCom terugmelding, automatische configuratie)...

Ook dat is iets dat de BiDib community graag tegen LocoNet aanvoert. Niets is echter minder waar. Bas gaf al aan hoe het wel zit. Stokpaardje is dan altijd, dat LocoNet te weinig bandbreedte zou hebben om RailCom data ( die met 250 kbps ) uit de decoders komt, te transporteren. Nu, als je even één moment langer conceptueel nadenkt, is het helemaal niet slim om alle RailCom data door te geven: Die data in de detector comprimeren en omzetten in conceptuele berichten, is naar mijn mening de weg die je zou moeten gaan. Zo heeft de DR5088RC en ook de nog te verschijnen YD6016LN-RC voor alle gangbare data die momenteel onder RailCom gedefinieerd is, keurige, conceptuele berichten. En dat alles via 1 OpCode in Loconet... Gaat uitstekend, zonder de bus vol te blèren ;)

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.

OPC_MULTI_SENSE valt idd onde NDA, maar OPC_MULTI_SENSE_LONG kun je zo bij mij opvragen :) ( helaas is die OPCODE dus door Digitrax verworpen, omdat "men" zelf geen RailCom heeft en het niet relevant vindt voor de eigen markt :'(

Citaat van: reinderlf
De DR5088RC ondersteund ook nog OPC_MULTI_SENSE_LONG, daar zit veel meer RailCom info in.

Nou ja, ik zou het niet direct RailCom info noemen. Het is eerder een abstractie van wat RailCom zo allemaal aan bits en bytes uit een decoder laat komen ;)
voorbeeld:

- Decoder (loc) komt sectie X binnen
- Decoder (loc) verlaat sectie X
- Decoder meldt actuele snelheid
- Decoder meldt Quality of Service
- Decoder antwoord op POM-read

etc. etc. Door dit "comprimeren" en afbeelden op conceptuele berichten, is het voor b.v. jou met TrainTastic veel eenvoudiger om de door RailCom veroorzaakte gegevens te verwerken op een zinvolle manier.


Citaat van: reinderlf
@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?

Die wordt vervangen door het aantal in de centrale ingestelde wissel-commando herhalingen.

De speciale behandeling was/is nodig, omdat andere protocollen wel een specifiek commando voor DCCext hebben. En omdat "mijn" centrales opgebouwd zijn rond een conceptuele, event-driven, kernel, was dat niet zo heel ingewikkeld.


Zo... lang antwoord, maar leuke discussie (y)

Grtzz,
Karst

bask185

  • Offline Offline
  • Berichten: 5003
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #19 Gepost op: 11 July 2024, 13:28:40 »
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  :)

Ik las dat ooit op dccwiki, maar ik heb nooit onderzocht of de centrales die we hebben dit ook daadwerkelijk doen of niet.
Citaat
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.


Citaat
Het grootse probleem naar mijn mening is, dat je óf van 0 beginnen moet, óf je hele bestaande installatie moet vervangen
Refereer je hier naar software of hardware of beide? ::)

Mvg,

Bas
Train-Science.com
Train-Science github
It ain't rocket science ;-)

Karst Drenth

  • Offline Offline
  • Berichten: 10481
  • NS blauw, groen, rood, bruin, grijs en standgroen
    • Plan U op Sleutelspoor
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #20 Gepost op: 11 July 2024, 14:23:05 »
Citaat van: bask185
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  :)

In theorie is dat inderdaad mogelijk, alleen moet er dan een verbinding zijn tussen alle "Global" detectors en de centrale. Immers als er een Booster in het spel is ( die dan zijn eigen "Global" moet hebben ) "ziet" de Global van de centrale de berichten in de booster sectie niet.

Verder is het leuk, maar wat als er een stroomonderbreking is naar de decoder toe. Wat gaat die dan doen ? Onthouden wat er het laatst gestuurd is ? Overigens is een slim geprogrammeerde refresh-stack zodanig ingericht, dat veranderingen direkt aan de kop van de queue komen en dus nauwelijk ( enkele millisecoden ) vertraging ondervinden. Het DCC-plafond wordt alleen zichtbaar/merkbaar als er vele, vele commando's quasi tegelijkertijd afgevuurd worden door b.v. besturingssoftware.

Citaat van: bask185
Refereer je hier naar software of hardware of beide? ::)

In eerste instantie de hardware. Software ( besturing  bedoel je ? ) heeft meestal wel een optie andere protocollen te begrijpen.

Grtzz,
Karst

bask185

  • Offline Offline
  • Berichten: 5003
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #21 Gepost op: 11 July 2024, 15:47:40 »
Ik las het op op BNLS een keer van mr Dombug dat een ecosII soms wisselpakketjes niet op de baan wilde zetten. Het bleek dat die ecos te druk bezig was met treinpakketjes. Die kon betrouwbaar maar 7 trein simultaan laten rijden te samen met accessoires. Toen alle wissels op een 2e centrale gingen, kon er naar het schijnt 14 trein probleemloos rijden. Daarom bedacht ik me, als elke laatste decoder gewoon zegt: acknowledged. Dat de mensen met grote banen meer trein met minder problemen kunnen laten rijden. Als er 5 treinen tegelijk moet afremmen van iTrain, zou het enorm schelen of je pakketjes nu blind 20x uitstuurt of dat ze na de 1e keer al ge'ackt worden. Alleen ik zal zelf nooit zo'n grote baan hebben dat ik dit probleem 'mag' ervaren  :'(

Citaat
alleen moet er dan een verbinding zijn tussen alle "Global" detectors en de centrale.
Je boosters hebben toch loconet  :P.

Citaat
Verder is het leuk, maar wat als er een stroomonderbreking is naar de decoder toe
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  ;D)
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.

Citaat
In eerste instantie de hardware.
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 was zo wel ongeveer een uur bezig met een loconet current sense terugmelder. Toen die klaar was, volgde de OPTO variant 10 minuten later. Dat zal je vast ook wel hebben?

Ik ga iig weer weekend vieren, morgen weer papadag :angel:

Mvg,

Bas
Train-Science.com
Train-Science github
It ain't rocket science ;-)

Karst Drenth

  • Offline Offline
  • Berichten: 10481
  • NS blauw, groen, rood, bruin, grijs en standgroen
    • Plan U op Sleutelspoor
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #22 Gepost op: 11 July 2024, 16:30:01 »
Citaat van: bask185
Je boosters hebben toch loconet  :P.

Juist dit soort info wil je niet via een besturings bus rond pompen...  ;) :P

Citaat van: bask185
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  ;D)

Die komt dus niet meer wanneer je eenmaal een ACK hebt gehad. Althans dat is het voordeel dat voorgespiegeld wordt ;)

Citaat van: bask185
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.

Dat kan met de DR5088RC methode ook. Die meldt dan gewoon "Decoder heeft Sectie verlaten". En als iTrain hem niet zelf heeft weggestuurd, kun je aannemen dat er een probleempje opgetreden is ;)

Citaat van: bask185
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  ::)

Interessant, maar ik heb denk ik je vraag niet/verkeerd begrepen ;)  Ik bedoelde wanneer je als EIND gebruiker wilt overstappen op BiDiB ;)  En ja, een ieder "sane" ontwikkelaar doet het op die manier. Om van de YD6016LN de YD6016RB te maken kostte zonder het routen ook maar een kwartiertje of zo. :P

Grtzz en weekend-ze,
Karst

bask185

  • Offline Offline
  • Berichten: 5003
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #23 Gepost op: 11 July 2024, 17:31:31 »
Citaat
Ik bedoelde wanneer je als EIND gebruiker wilt overstappen op BiDiB
Oops  :-X die had ik niet door  :-[
Train-Science.com
Train-Science github
It ain't rocket science ;-)

AP3737

  • Offline Offline
  • Berichten: 330
Re: Yamorc 7010 en xpressnet voor communicatie richting PC
« Reactie #24 Gepost op: 13 July 2024, 10:40:32 »
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"
Dat ben ik met je eens. Als techneut vind ik Bidib prachtig, maar om mijn bestaande spullen weg te doen en helemaal opnieuw te beginnen, is niet realistisch. Ik haal wel graag ideeën weg bij Bidib, omdat Wolfgang Kufer op electronica gebied toch veel meer weet dan ik. Je ziet ook precies wat er in de Bidib hard en software zit, en in die zin is het wel weer een heel open systeem. Maar Bidib in een Arduino omgeving gebruiken, of omzetten naar een andere processor, is weer niet triviaal (CRC, DMA, ...), dus in die zin is Bidib vrij gesloten.

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
Ook daar ben ik het helemaal mee eens. Vraag aan Karst: is er binnen de rail community geen interesse om van XpressNet / Z21 / ... een RCN te maken? Of willen de fabrikanten graag zelf de controlle houden?

Overigens, ik had Lenz ook gevraagd of ze het extended accessory command van plan zijn te implementeren. Hierbij het antwoord:
Citaat
Nach Rückfrage bei unserer Entwicklungsabteilung kann ich Ihnen mitteilen, das wir dies planen, aber leider noch keinen Termin nennen können.

Groet, Aiko