JMRI / EngineDriver

Engine Driver - JMRI Throttle for your Android device
https://enginedriver.mstevetodd.com/
GNU General Public License v3.0
31 stars 20 forks source link

Engine Driver on ESU MC2 loco headlight turns off unexpectedly #212

Closed KenNinomiya closed 6 years ago

KenNinomiya commented 6 years ago

Hardware: ESU MC2 OS: Android 4.1.1 Engine Driver version: 2.18 JMRI version: JMRI for Raspberry Pi by Steve Todd DCC: CVP EasyDCC If it makes a difference: Engine Driver theme used is "High Contrast Outline"

Minor issue noticed during ops session. Intermittent headlight loss (turns off). Light "button" indicates light function still "on", but headlight is off on loco. To turn light back on, I have to cycle through the on off on using the "Light" "button."

I'm not sure what triggered this each time. Once, it was after the loco was moving but I had "swiped up to lock the screen." Another time, I noticed the light was off after the loco had slight stall or hiccup. However, there was another time when I had no issue with the loco's running when I noticed that the light was off.

I suspect this is an Engine Driver issue and not hardware related since the Engine Driver is running under Android on the MC2, but I thought I'd mention it's running on the MC2 anyway.

Ken

mstevetodd commented 6 years ago

@KenNinomiya does the light indicator actually change from on to off, or does the indicator not update after you send a change? Not much change of debugging it without a consistent way to repeat. Even then, it'll be difficult since I don't have CVP hardware. As background, the indicator changes on a message from the WiThrottle server. If that message isn't sent, the indicator won't update.

KenNinomiya commented 6 years ago

The indicator on the MC2 display remains in the "on" setting (bright border and text) when the loco headlight goes out. The indicator on the display will dim and highlight again when I press/touch to cycle and restore the headlight back on on the loco.

Sent from my iPhone

On Apr 8, 2018, at 1:37 PM, mstevetodd notifications@github.com wrote:

@KenNinomiya does the light indicator actually change from on to off, or does the indicator not update after you send a change? Not much change of debugging it without a consistent way to repeat. Even then, it'll be difficult since I don't have CVP hardware. As background, the indicator changes on a message from the WiThrottle server. If that message isn't sent, the indicator won't update.


After Weeks Of Rumors, Joanna Gaines Comes Clean risingstarnewspaper.com http://thirdpartyoffers.juno.com/TGL3131/5aca8cd1b6a8ecd10863st02vuc

mstevetodd commented 6 years ago

@KenNinomiya do you see the same behavior with the default theme?

KenNinomiya commented 6 years ago

Sorry, never thought about trying the default theme.

Ken

Sent from my iPhone

On Apr 8, 2018, at 4:18 PM, mstevetodd notifications@github.com wrote:

@KenNinomiya do you see the same behavior with the default theme?

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.


1 Simple Trick Removes Eye Bags & Lip Lines in Seconds Fit Mom Daily http://thirdpartyoffers.juno.com/TGL3131/5acaa6723bc6e26710e24st02duc

mstevetodd commented 6 years ago

It would also be helpful to try it with another command station type, even a simulator. Feel free to use my jmri.mstevetodd.com:44444 if you'd like. I'm trying to narrow down if we have a CVP problem or and EngineDriver problem.

KenNinomiya commented 6 years ago

Since your simulator won't have an actual loco to monitor the headlight, that won't work. I'll have to get on an actual layout to test.

Sent from my iPhone

On Apr 8, 2018, at 4:58 PM, mstevetodd notifications@github.com wrote:

It would also be helpful to try it with another command station type, even a simulator. Feel free to use my jmri.mstevetodd.com:44444 if you'd like. I'm trying to narrow down if we have a CVP problem or and EngineDriver problem.

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.


1 Cup of This Before Bedtime ''Ends'' Tinnitus (Ear Ringing) Healthier Patriot http://thirdpartyoffers.juno.com/TGL3131/5acabba3254d23ba2778fst02vuc

n3ix commented 6 years ago

This is a very common issue AFAIK. When the loco momentarily loses power, after power returns most/all decoders come up with the headlight Off. Depending on the DCC system the former headlight setting may or may not get refreshed. Setting the Headlight Off and then On has been the only fix I am aware of. I am not sure if WiT/JMRI could periodically refresh the F0-F3 values in the command station, but ED can’t make that happen.

Robin

Robin Becker

San Diego, CA

From: KenNinomiya notifications@github.com Sent: Sunday, April 08, 2018 6:03 PM To: JMRI/EngineDriver EngineDriver@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [JMRI/EngineDriver] Engine Driver on ESU MC2 loco headlight turns off unexpectedly (#212)

Since your simulator won't have an actual loco to monitor the headlight, that won't work. I'll have to get on an actual layout to test.

Sent from my iPhone

On Apr 8, 2018, at 4:58 PM, mstevetodd <notifications@github.com mailto:notifications@github.com > wrote:

It would also be helpful to try it with another command station type, even a simulator. Feel free to use my jmri.mstevetodd.com:44444 if you'd like. I'm trying to narrow down if we have a CVP problem or and EngineDriver problem.

― You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.


1 Cup of This Before Bedtime ''Ends'' Tinnitus (Ear Ringing) Healthier Patriot http://thirdpartyoffers.juno.com/TGL3131/5acabba3254d23ba2778fst02vuc

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JMRI/EngineDriver/issues/212#issuecomment-379598853 , or mute the thread https://github.com/notifications/unsubscribe-auth/ANkC4zJAw-cZlQDvk49jiwR9OcZ-wCX9ks5tmrNbgaJpZM4TLleL . https://github.com/notifications/beacon/ANkC4_6sRnNo43t7wHx5YgWol4Z5LTB7ks5tmrNbgaJpZM4TLleL.gif

KenNinomiya commented 6 years ago

The only thing is, I've used this MC2 on this CVP layout since ED 2.15 or so, and I don't recall having to do this during ops before.

I'll check with my own JMRI on CabControl system to see whether the issue follows this MC2 or not.

I might be able to talk the manager of the CVP to let me run a test this week.

Ken

Ken Ninomiya Oxnard, CA


Royal Family Tragedy Unfolds risingstarnewspaper.com http://thirdpartyoffers.juno.com/TGL3131/5acad2df1cb3052dd4569st02vuc

KenNinomiya commented 6 years ago

@mstevetodd Robin is correct.

I tried the ED on my ESU CabControl command station, and I get no loss of headlight, even after tipping one side of the loco off the track. The headlight comes back on when placing wheels back down.

I ran a test on the EasyDCC layout again today. I noticed headlight flicker just before the headlight completely went out. When I tip the loco over, the headlight will not go back on when the loco is placed back down. The headlight indicates "on" on the touchpad and must be cycled off then back on to have the headlight return to lit on the loco.

So, the issue seems to be that the EasyDCC command station doesn't send headlight state commands after the initial command, or very infrequent.

Since this can't be fixed through ED, I'm closing this issue.

Ken

Ken Ninomiya Oxnard, CA

n3ix commented 6 years ago

Ken - thanks for the thorough testing.

Steve and Peter - as mentioned I run into fairly frequently during Ops, for sure on NCE systems, perhaps others. I wonder if there is something we can do. The headlight is typically transmitted in a DCC Function Group One packet. This packet contains F1-F4 in addition to the headlight. If we (optionally) periodically briefly toggled one of those functions, it would most likely trigger the Command Station to send Function Group One packets to that decoder. If the toggle was done quickly enough to be unnoticeable but not so quickly that a command station might ignore it, the headlight would get refreshed in the decoder. Typically functions are assigned as F0 (Light), F1 (Bell), F2 (Horn) and F3 (sometimes Short Horn), these might be noticeable, so how about it we try briefly toggling F4 once per heartbeat or something like that?

flash62au commented 6 years ago

Robin, I am not sure a I can provide any serious input into this discussion, but a question/observation.

I would be interested to sample a number of different sound decoders to see what F4 does in them.

If it plays a sound in some/any decoders it could be annoying to periodically toggle it. Toggling the headlight, while a bit odd, 'may' prove less annoying.

Peter

On 13 April 2018 at 10:11, Robin notifications@github.com wrote:

Ken - thanks for the thorough testing.

Steve and Peter - as mentioned I run into fairly frequently during Ops, for sure on NCE systems, perhaps others. I wonder if there is something we can do. The headlight is typically transmitted in a DCC Function Group One packet. This packet contains F1-F4 in addition to the headlight. If we (optionally) periodically briefly toggled one of those functions, it would most likely trigger the Command Station to send Function Group One packets to that decoder. If the toggle was done quickly enough to be unnoticeable but not so quickly that a command station might ignore it, the headlight would get refreshed in the decoder. Typically functions are assigned as F0 (Light), F1 (Bell), F2 (Horn) and F3 (sometimes Short Horn), these might be noticeable, so how about it we try briefly toggling F4 once per heartbeat or something like that?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/JMRI/EngineDriver/issues/212#issuecomment-380981472, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab2OA8lLuewu2MRES2FPhLvDqVY72k30ks5tn-0ggaJpZM4TLleL .

n3ix commented 6 years ago

@flash62au F0 might be ok too. What we need to do is "trick" the command station into thinking it needs to send Function Group One. It might be that toggling F0 back and forth with no delay would do that, it might be that some command station code is smart enough to reject (also need to confirm that WiT doesn't discard rapid changes). With functions other than F0 I think the command station might have to send every change since some decoder effects are triggered by the function off-on or on-off transition rather than the level. That's why I initially thought about F4. But F0 does sound safer it is works, just don't want to see the headlight flash so maybe try sending the two toggle commands in immediate succession and see what happens.

mstevetodd commented 6 years ago

I'm not a fan of doing this in EngineDriver at all. IF it needs doing, it seems like it should be handled in JMRI itself, either in the WiThrottle Server, or in the throttle implementations.

KenNinomiya commented 6 years ago

Ive done a little search through email lists for different dcc related lists I'm subscribed to. Apparently, NCE command stations can be set to have f0-4 refreshed so that those function settings are restored after power hiccups in a loco.

The new Digitrax DCS240 sends refreshes to f0-4 as well.

Since those two systems are far and away the most popular in the USA, I don't see that it's necessary to try to address lost function changes to f0-4 from brief power losses, at least in this country :-)

Additionally, my system of choice, ESU also seems to send function refreshes. I would think ESU might be pretty popular in Europe.

My concern with toggling f0 would be that some users like to remap functions and may use f0 for something other than toggling headlight off/on.

I think toggling f0 for a minor user base of EasyDCC is not worthwhile. But that's just my opinion.

Ken

Ken Ninomiya Oxnard, CA


Drink This Before Bed, Watch Your Body Fat Melt Like Crazy risingstarnewspaper.com http://thirdpartyoffers.juno.com/TGL3131/5ad04c609dfee4c602c2ast03vuc

n3ix commented 6 years ago

@mstevetodd I agree with you. Figured the chances of getting in JMRI itself right off the bat weren't good but it would be pretty easy to implement and test as a user pref in ED.

@KenNinomiya I operate regularly on a couple NCE layouts. Despite enabling the refresh option in the command station they still exhibit this problem so perhaps the command station refresh does not really work? Yes some command stations refresh f0-f4 more (effectively) than others, that's why I'd make this feature an option select through a user preference. It's pretty unusual to have F0 remapped, so to just test the idea out it would probably be good enough.

All: This wasn't meant as a cure-all, just thought it might have its place on select systems. There are other weird things that come along with this. For instance the short horn function (if used) can also create issues when a loco loses power momentarily. For soundtrax decoders it seems they trigger the short horn on either a off-on or an on-off transition of the assigned Function. In order to avoid getting 2 toots, you have to make the function latching in ED/JMRI. After the decoder loses power and then resets, it sets whatever function is assigned to the Short Horn internally to Off. Now suppose the short horn is assigned to F3 and that F3 happens to be On when the decoder momentarily lost power. The next time the decoder gets a Function Group1 message, such as when you notice that the headlight is off and quickly toggle it in ED to get it back on, the F3 value will also get sent and presto - a short horn toot :)