On my Doodlebug decoder install using an ESU LokPilot Nano Standard I have F2 turning a LED on/off with Aux 1 output. I have F3 turning a LED on/off using Aux2 output. Using JMRI's throttle F2 and F3 both turn the LEDs on/off each time they are pushed. They stay on and stay off. Using EngineDriver and a phone as a wireless throttle via JMRI (on Raspberry Pi) and DCC++EX (Arduino) F3 turns the LED on or off each time it is pushed and it stays on or off. F2 is acting like a momentary switch though. The LED controlled by it stays on as long as the function key is pushed but goes off as soon as I let up on the key. I can't find anything in EngineDriver where you can setup a function key as momentary or latching. Also don't see it being an option in DecoderPro or LokProgrammer for this decoder (not saying it isn't there ). I've read a few places that F2 and F3 with some systems can be momentary but then wonder why F3 isn't a problem but F2 is. I have a feeing if I reprogrammed the function to a higher function key the problem would go away. Any thoughts? I'll also email Steve and see if he can enlighten me. Sumner
Steve replied to me and it is an easy fix.... "There is a JMRI Preference under WiThrottle Server called "F2 Always Momentary?". Uncheck that." Sumner
I'm guessing you don't have any sound decoders. If you think you might ever get any, I would suggest remapping the function and switching F2 back to momentary because F2 has become the accepted default for the horn on sound decoders.
Pardon my ignorance, but... I would have thought that the momentary vs latched property of a given function should be a [programmable] property of the decoder, rather than controlled by the command station. In the case of the latter, the CS must consume additional DCC bus bandwidth for as long as a latched function is on. If the latching/momentary property were programmed into or controlled by the decoder, then the DCC bus bandwidth required would be reduced, perhaps significantly. Are diesel sounds' and steam chuffs' persistence also controlled by the CS (excluding VSD)? Or has this whole can of worms been hashed out before, and I'm arriving late to my seat (as usual)?
From the decoder's point of view all functions are latching - when the decoder sees a function on command that function stays on until it sees a function off command. From the command station side if it is latching it sends alternating 'on' and 'off' with repeated presses of the button, and when momentary it sends 'on' when you press the button and 'off' when you release it. Having the command station side momentary or latching does not change the required bandwidth, it just changes when the 'off' signal is sent. Having a function momentary from the decoder's point of view would take more bandwidth because the command station would have to send continuous 'on' commands to hold the function on.
