Hello Gerhard, Is this referring to your Sigrok maintainers?:
"Neither maintainers nor other active developers are familiar with the protocol, could neither review in useful ways, nor tell how these variants relate to each other or which one should be preferred. Nor have I seen other feedback from non-developers (in other words: users of those decoders). " I don't know if there are other forks or other completely separate decoders for DCC, but the only one as far as we are concerned is the LittleYoda GitHub repository. I will ask Roland to make a PR there so we are all working from the same master. I will look into how to add a Wiki page to your site. You are the founder or one of founders of Sigrok, yes? I was trying to find the context for your email. I asked my parents, but they did not fully understand your last paragraph either regarding the sigrok structure of dumps, tests, etc. ;) But I'll look into it to learn more. The DCC protocol (Digital Command Control) is a pulsed packet format defined by the NMRA (National Model Railroad Association). It's 58us one and 100us zero, create a ~8kHz signal with idle packets when no data is being sent, then a preamble, then 1 to several byte packets that are sent over the tracks to decoders that control model trains and accessories like servos for track switching, signals, etc. Thank you for the email. I'll organize who I can to put things in one place and to create a Wiki Best Regards, Fred Fred Decker DCC-EX On Thu, Jan 6, 2022 at 6:46 AM Gerhard Sittig <gerhard.sit...@gmx.net> wrote: > On Wed, 2022-01-05 at 17:13 +0100, Roland Nöll wrote: > > > > i have updated the DCC decoder: > > - added RCN-218 norm > > - added additional search function > > Can those who are working on DCC decoding please join forces, > inspect the different implementations that were suggested so far, > and compare and ideally merge them or decide on which one is to > get picked? > > This is a subjective perception, but here is what I have seen so > far: Neither maintainers nor other active developers are familiar > with the protocol, could neither review in useful ways, nor tell > how these variants relate to each other or which one should be > preferred. Nor have I seen other feedback from non-developers > (in other words: users of those decoders). That's when none of > the suggested decoder implementations will get picked, and all > of them will keep sitting somewhere outside of mainline. > > Consider creating or updating the DCC protocol decoder's wiki > page, regardless of whether an implementation is in mainline. > This may be useful to get there, and could start with an overview > of what became available so far out of tree. > > > Independent from the necessary review and identification of the > most appropriate candidate: Consider providing example captures > and decoder implementations in ways that are easier to pick up by > developers. Leave fewer work on the maintainers' side, by > following style and providing docs similar to other protocols. > Keeping all the parts in one repo _may_ be acceptable to avoid > the split into the PD and dumps and tests on the submitter's > side, _when_ the subdirs would at least correspond to what will > be taken into the sigrok repos respectively. Don't expect the > work to be done by those who are unfamiliar with the protocol or > the setup, that would reduce the probability of being taken. > > > virtually yours > Gerhard Sittig > -- > If you don't understand or are scared by any of the above > ask your parents or an adult to help you. > > > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel >
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
