I'm trying to use DCC++ to control a rather old LGB locomotive that only supports 28 speed steps. I've read and confirmed that DCC++ only supports 128 speed step mode. I've been using DCC++ with JMRI and a few newer locomotives, so I know that my base station is working. Has anyone tried modifying DCC++ to support 28 speed steps instead of or in addition to the 128 speed step mode? Would it be possible to use the speed step mode from the JMRI roster to determine which speed step mode to use for a locomotive?
Hi namniart, You're right - the DCC++ basestation code would need to be modified to actually support the 28 speed step mode, but it's not a quick fix. Currently the 128 step mode is hard-coded, taking into account step 0 (Stop!) and step 1 (Emergency Stop!). The packet registers do not have decoder modal metadata associated with them, that would have to be added to the register structs, and every time a throttle was set, it would require an additional test (for step mode) to properly format the speed packet. Using JMRI roster data to obtaining the decoder speed step mode is very reasonable, but you still have to affiliate the register (and thus locomotive) on the basestation so DCC++ properly formats the packet. Setting/clearing register speed step mode formatting requires another DCC++ command on the basestation and one more UI command to implement on the controller. All that said, I have a Bachman E-Z DCC decoder equipped loco that only has 28 speed steps and it seems to work fine, despite what DCC++ is sending it. Qualifier - I'm not using JMRI, but my own controller code, but that shouldn't impact what DCC++ is sending, or how it's interpreted by the decoder.
@chrisat I'm not sure I understand why the DCC++ basestation needs to track the speed step mode for a register; it looks like the only place where it is assumed is when generating the DCC speed control packet. I see that the speed is stored in `speedTable`, but I don't see any other code in DCC++ basestation that generates new packets based on that value. I managed to get transmission of the 14/28 speed step packet working with just a few lines changed as a proof of concept: https://github.com/DccPlusPlus/BaseStation/compare/b385acc...0687e96 . I was able to get my loco working with this, and discovered that it's actually in 14 speed step mode. I'm thinking that instead of needing to track the speed step mode in the DCC++ basestation, I can just add an extra field to the `t` packet to request a different speed step mode. Then any logic about the desired speed step mode for a particular loco could live in the controller.
You DCC fans deserve a lot of credit for making your own lives difficult. More power to you. Real railroaders only deal with Run One through Run Eight. And they get paid.
Yep. I decided when I got into DCC++ that it was an aspect of the hobby where I wanted to spend some of my time. I write embedded software for my day job, so this is a walk in the park compared to what I have to deal with a work, and it's either fix a bit of code here, or spend more money on a new G scale locomotive or decoder.
Sorry, got a bit out of hand above - adding the speed step mode as a throttle command parameter works. The simplest solution to the immediate problem is usually the best. Last year I did an analysis of the DCC++ commands and message length, as well as memory usage. (I use BLE in a custom controller to communicate with the basestation.) With restricted message length, I'm constantly thinking how to store repetitive/redundant message data on the basestation and just look it up when needed.
