No need for 2-second delay in loop()

[DEGoodmanWilson]

This bit of code really isn't necessary—CmdrArduino runs, effectively, in a background thread. So long as you call dps.update() at the end of every loop, there is no need to send function and speed updates every two seconds—just send them immediately!

Thus, this code:

  unsigned long currentMillis = millis();
  if (currentMillis - previousMillis > interval || force_update) {
    previousMillis = currentMillis;  
    dps.setSpeed128(DCCAddress, DCC_SHORT_ADDRESS, speed_byte);
    dps.setFunctions(DCCAddress, DCC_SHORT_ADDRESS, fn0to4, fn5to8, fn9to12);
    digitalWrite(LED, !digitalRead(LED));
    force_update = false;
  }

can be removed. You are already calling setSpeed128 when you have a speed update; you can do something similar that with setFunctions() when one of the functions changes. CmdrArduino takes care of making sure the packet gets repeated periodically to prevent the locomotive from timing out and halting!

[KermMartian]

Thanks so much for taking the time to look at my code! I made a pass at implementing the changes you suggested in my latest commit, but I notice that a DCC sound-enabled locomotive doesn't start sounds until I try to set a speed (previously, it would make sound even at speed 0), and the sounds shut down after about 6 seconds. Thanks in advance for any feedback you might be able to offer on what I'm missing.

[DEGoodmanWilson]

The first issue is pretty easy: Just initialize the DCC speed to 1 in setup(). The second is curious. Is it always 6 seconds from when you start the program, or is it 6 seconds since the last speed change? What kind of decoder are you using? I've only used ESU sound decoders myself (which didn't exhibit this behavior), and I wonder if this is something peculiar to yours.

[KermMartian]

Thanks, that makes sense for the first issue. For the second issue, I've been using a Kato P42 with a Digitrax SDN144K0a installed as my test loco. I notice the following relevant snippet in the SDN144K0a manual:

If the sound in your decoder shuts down after you stop it and you are not using a Digitrax system for control. On some DCC systems decoders are not addressed by DCC packets after the locomotive is set to 0 speed. In this case after the CV11 timeout elapses (6 second default), sound will “shutdown.”. To defeat this feature, set CV11=00 to remove the timeout and shutdown. To make sounds, the decoder must have a command addressed to it at least once.

I'd like to support decoders with this sort of feature, so I guess I can just add code back in to refresh (say) functions 0-4 every ~3 seconds.

[DEGoodmanWilson]

Curious. CmdrArduino doesn't drop the address from the packet refresh queue when the speed is set to 0. So, in other words, that shouldn't happen.

Stop the presses. We've just found a bug. Speed packets are never repeated. They should be always repeated. D'oh. The workaround for now is to simply just always post the latest speed, even if it hasn't changed, to the packet scheduler. I'll see about getting this fixed this week.

[KermMartian]

DCCPacketScheduler::repeatPacket() appears to insert speed_packet_kind packets into the repeat_queue, but empirically, I too see speed packets not repeating. I'd be happy to help write and test this fix; any pointers on where I should be looking? I'm still working on grokking your code. Cheers.

[KermMartian]

My apologies for bumping this; I just wanted to see if you had gotten a chance to look into the issue. Thanks in advance!

[DEGoodmanWilson]

Sorry Kerm, I dropped the ball totally on this! I'll take a look at this over the holiday coming up; in the meantime the workaround is just to ensure you are periodically transmitting the speed! Would you mind opening an issue_ https://github.com/Railstars/CmdrArduino/issues