Voir les contributions
1
Le logiciel DCC++ / Re : DCC++ EX
« le: août 20, 2022, 06:22:36 pm »
Dear Locoduino Friends,
Please allow me to apologize for writing in English. I'm sure Google Translate will do a better job than my school French from 55 years ago.
I have taken the liberty of reading your DCC++EX discussions with interest as I am the person responsible for the initial design of DCC++EX (now called DCC-EX).
I can see from the discussions above that there are a few misunderstandings about the differences between DCC++ and DCC-EX and therefore also with Locoduino.
In no particular order:
1) we have managed to resolve the Withrottle timeout issues. We were interested in Thierry's fix but we realized that this did not solve the problem for all processors and was specific to a particular problem in our ESP32 experiments.
2) DCC-EX works best on a Mega or better as we have so much to offer that will not reasonably fit on a UNO either for PROGMEM or RAM. However there are a number of DCC-EX features which do add considerably to a UNO environment.
For example:
- Reading CVs and program track actions do not block throttles on the main track.
- CV reading diagnostics are available (as you have seen) that allow us to discover why certain decoders cause problems and we have commands to tune the ACK algorithm to handle out-of-spec decoders.
- We have high-level program commands such as <R> which will detect the address that can be used to drive a loco. This may come from a consist, a long address or short address. We also have a <W locoid> command that will also manage the long/short address issue.
- We manage PROG track power automatically, and we allow the PROG track to be automatically joined to the main track (perhaps as a siding) so you can drive a loco from the prog track onto the main track.
3) We issue function reminders and have new commands that make functions easier to invoke.
4) Our DCC signal generation on nano/uno/mega uses hardware timers for high accuracy by default on a Mega and can be achieved with configuration and jumpers on a UNO.
5) We ae currently working on ESP32 and other processors. Sometimes this is not easy because the newer processors introduce additional hardware signal generation techniques that are wildly incompatible and sometimes much harder to use than the basic AVR processors.
Strangely, the faster processors are often less able to generate high quality signals from portable code.
6) We also have EXRail, which provided a vast range of automation possibilities without having to learn C++ or Arduino environment. Our latest builds are able to do some of this on a UNO.
If you do have problems or wish to discuss DCC-EX with those of us who wrote it, or you would like to contribute your expertise, please join our Discord group (invitation on the website) where you may write in any language and we will do our best to help.
Best Regards,
Chris Harlow On Discord as UKBloke (AKA Chris)
Please allow me to apologize for writing in English. I'm sure Google Translate will do a better job than my school French from 55 years ago.
I have taken the liberty of reading your DCC++EX discussions with interest as I am the person responsible for the initial design of DCC++EX (now called DCC-EX).
I can see from the discussions above that there are a few misunderstandings about the differences between DCC++ and DCC-EX and therefore also with Locoduino.
In no particular order:
1) we have managed to resolve the Withrottle timeout issues. We were interested in Thierry's fix but we realized that this did not solve the problem for all processors and was specific to a particular problem in our ESP32 experiments.
2) DCC-EX works best on a Mega or better as we have so much to offer that will not reasonably fit on a UNO either for PROGMEM or RAM. However there are a number of DCC-EX features which do add considerably to a UNO environment.
For example:
- Reading CVs and program track actions do not block throttles on the main track.
- CV reading diagnostics are available (as you have seen) that allow us to discover why certain decoders cause problems and we have commands to tune the ACK algorithm to handle out-of-spec decoders.
- We have high-level program commands such as <R> which will detect the address that can be used to drive a loco. This may come from a consist, a long address or short address. We also have a <W locoid> command that will also manage the long/short address issue.
- We manage PROG track power automatically, and we allow the PROG track to be automatically joined to the main track (perhaps as a siding) so you can drive a loco from the prog track onto the main track.
3) We issue function reminders and have new commands that make functions easier to invoke.
4) Our DCC signal generation on nano/uno/mega uses hardware timers for high accuracy by default on a Mega and can be achieved with configuration and jumpers on a UNO.
5) We ae currently working on ESP32 and other processors. Sometimes this is not easy because the newer processors introduce additional hardware signal generation techniques that are wildly incompatible and sometimes much harder to use than the basic AVR processors.
Strangely, the faster processors are often less able to generate high quality signals from portable code.
6) We also have EXRail, which provided a vast range of automation possibilities without having to learn C++ or Arduino environment. Our latest builds are able to do some of this on a UNO.
If you do have problems or wish to discuss DCC-EX with those of us who wrote it, or you would like to contribute your expertise, please join our Discord group (invitation on the website) where you may write in any language and we will do our best to help.
Best Regards,
Chris Harlow On Discord as UKBloke (AKA Chris)