Kalender

[AP3737]

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]

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

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

[reinderlf]

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]

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 )

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.

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.

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.

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

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

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.

@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

Grtzz,
Karst

[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 

Ik las dat ooit op dccwiki, maar ik heb nooit onderzocht of de centrales die we hebben dit ook daadwerkelijk doen of niet.

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

Refereer je hier naar software of hardware of beide?

Mvg,

Bas

[Karst Drenth]

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.

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]

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 

alleen moet er dan een verbinding zijn tussen alle "Global" detectors en de centrale.

Je boosters hebben toch loconet  .

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

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

Mvg,

Bas

[Karst Drenth]

Je boosters hebben toch loconet  .

Juist dit soort info wil je niet via een besturings bus rond pompen... 

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  )

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

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

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.

Grtzz en weekend-ze,
Karst

[bask185]

Ik bedoelde wanneer je als EIND gebruiker wilt overstappen op BiDiB

Oops  die had ik niet door