Problem with Operating TMCC with JMRI

Tubabuhda Sep 23, 2015

Tags:
  1. Tubabuhda

    Tubabuhda New Member

    6
    0
    2
    Greetings,

    I'm assisting my club with the installation of JMRI on the O Scale layout. There's a problem that I've been unable to rectify, and I'm hoping someone here may be able to help.

    Before I list the problem and settings, I'd like to point out that, while I'm not a computer programmer (unless you consider threatening them with sledgehammers counts), I am fairly computer savvy. My experience with JMRI is primarily with Digitrax DCC operations. I am not an O-Scale person, so TMCC, Legacy, etc is very much a mystery to me. My only practical experience with the scale is my very conventional 0-8-0 switcher and a few cars.

    For those wondering why we're doing this install, our club's HO division has been using JMRI and it's Wi-Throttle function for some time now, with great success. In the last six months, I've been able to do the same with the Club's N-scale layout after teaching myself how to implement it on my T-Trak layout at home using a Raspberry Pi. Our goal is to allow a standard method of control for locomotives on all three scales, which will allow anyone in the club familiar with a smartphone to operate any layout. The short story is that a $20 smartphone beats a $150-$300 controller, no matter which scale you operate!

    The JMRI version currently installed on the testing computer is 3.4 and will soon be updated to the newer V4+. When setting up the configuration in Preferences, we followed the setup recommendations as posted on JMRI's website: http://jmri.sourceforge.net/help/en/html/hardware/tmcc/index.shtml

    Once everything was connected, we tried a few low speed runs of a locomotive. Just enough throttle (speed steps) to creep the locomotive along. No apparent problems but seemed a little laggy. Horn and bell seemed okay, but there was a stutter in them when they started. We thought nothing of it as it was an older locomotive and figured it had something to do with the unit. It wasn't, but I'll detail that in another paragraph or ten.

    We proceeded to test the locomotive at higher speed steps. It was at this point that we noticed the locomotive appeared to become a runaway. Lowering the throttle speed or pressing the emergency stop button did nothing. To be safe, we resorted to cutting track power before any damage could be done.

    After some consideration, the computer was disconnected from the layout and a TMCC controller was used to test the locomotive itself. There was no problem what so ever. The locomotive was under control the entire time. Bell and horn worked properly, but there was no stutter.

    The computer was reconnected to the layout, and a "Data Traffic Monitor" was started (please forgive me as I'm at home and don't remember the exact name of the tool JMRI has for monitoring the data packets). As a test, the locomotive was being controlled by the TMCC controller, and no throttle was open in JMRI. There was a single command given to operate the horn, turn on and off the bell, and one command per increase or decrease in speed steps.

    We proceeded to acquire and control the locomotive through JMRI's built in throttle. Each of the commands mentioned above were sent four times each instead of once. Just to verify it wasn't the built-in JMRI throttle, an Android device using Engine Driver was connected via Wi-Throttle. Sadly, it wasn't much of a surprise to find the same results as JMRI's throttle.

    For these tests, the locomotive was set for approx 15-25%, held there for less than 5 seconds, then throttle was decreased to 0% on the TMCC controller for an operational time less than 15 seconds. The locomotive responded very quickly to the commands. With JMRI, the throttle was set to 10-15%, and immediately hit the emergency stop. The computer was still sending speed step increases long after 15 seconds. The initial take off was slow to respond, and the locomotive was still accelerating long after the emergency stop was pressed as the computer was still sending speed step increase commands. It finally got the stop command, but had it been a real emergency, track power would have to have been cut.

    So, now we know why the horn and bell sounded like it was stuttering, and, after a carefully controlled test, why it looked like we had a runaway locomotive. With JMRI sending four commands for each speed step, it was taking much longer for the locomotive to respond to them. It should also be mentioned that the command or command prefix sent for increasing/decreasing speed steps from the TMCC controller and JMRI are different. Again, I'm not sure as to what the commands are as I'm not staring at them currently. There were something along the lines of <init> and <cmd>.

    Two of us have been searching the web and asking others if they knew how to solve this, but without luck.

    Now that I've written that book, here's the questions:
    -Is there a method to force JMRI to NOT repeat commands four times for each button press (ie the horn)?
    -Is there a method to change JMRI's command prefix to match those issued by the TMCC controller?
    -Has anyone successfully overcome the problem through other methods, and what would those be?

    I'm aware of Lionel's new interface, but the $137 and the fact that at least half of all our club's members with smart phones use Android devices make it a moot point. IF they release an Android app, it may be a reasonable alternative.

    Thank you for taking the time to read this. Any help would be appreciated.
     
  2. ScaleCraft

    ScaleCraft TrainBoard Member

    2,176
    98
    26
  3. Tubabuhda

    Tubabuhda New Member

    6
    0
    2
    Indeed.
     
  4. ScaleCraft

    ScaleCraft TrainBoard Member

    2,176
    98
    26
    While all the verbiage indicates it works well....talking to the CTT folks...it doesn't....often.
     
  5. Tubabuhda

    Tubabuhda New Member

    6
    0
    2
    Well, from the standpoint that it sends commands to which the locomotive responds, it works.

    I've had the chance to look at some of the java coding since my original post and have been considering several potential solutions since the original post. Please note that I'm not a programmer, and freely admit I wasn't able to find any of the TMCC related material in the code I was looking at (or it was staring me in the face and I never knew it is equally possible.
    -Find and tweak the java code to send a single command instead of 4.
    -Send the same command as the TMCC controller.
    -Create a TMCC 'decoder profile.'
    -Possibly problematic as I suspect JMRI's CV approach is probably highly incompatible with TMCC.
    -A 'setting' that forces JMRI's throttles to sync with TMCC speed steps vs throttle percentages.

    Overall, I'm left with the feeling JMRI can be used with TMCC, but only after it receives some serious coding to make it more compatible.
     

Share This Page