Hey Y'all, I originally posted this in the O Scale forum, then realized there was a section for electronics/DCC. Being sleep deprived is not fun.... 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.
Hi ?? - Perhaps someone on this forum will step forward, but ... I recommend you post this question on the JMRI Users group on Yahoo. It is a fantastic resource. Many of the creators of JMRI post on the group every day, so you'll be getting expert advice from the people who wrote the program. https://groups.yahoo.com/neo/groups/jmriusers/info Knowing a little about JMRI (and nothing about TMCC), I'm 99% sure that their first recommendation will be to update to the most recent versions of JMRI and Java. Then you can start debugging with the group's help. - Jeff
Thanks for the reply Jeff! You brought up the two words I was fearing, Java update. The machine we hoped to use is an old netbook running XP. The test was switched to a Win7 machine as I knew it both JMRI and Java were updated. I'm glad you mentioned it as we may now have to rethink the use of the XP machine. I'm much in the same boat: setup JMRI for dcc use on several laptops, and even a Raspberry Pi running in headless mode (thanks to an awesome Aussie who posted instructions on his blog!). Thankfully, I know someone who understands TMCC better than I, and knows far more people in the Lionel community. As for the link, I'll check them out when I get home this evening. Thanks for pointing them out!!! -Andy
The last time I tried updating Java on my backup computer, which runs XP Pro, it would no longer update. Apparently Java updates for XP have stopped and the error message was to update to a later OS.
Despite the warning you see when installing the latest version of Java on Windows XP, it WILL install. Many, many JMRI users are using XP and are running the latest version of Java. There may be other reasons why your old XP machine is not suitable (slow performance, maybe), but Java installation is not a stopper. - Jeff
I use XP too and JAVA installs after ignoring the warning. I think that is just to say they are not supporting XP anymore so they don't guarantee it will work.
Mine would not install. It stopped right there and that's as far as it would go. Sorry all. Will stop here so as to not hijack the topic.
If you have not done so, use the manual install for Java 8. Get it here: http://www.java.com/en/download/manual.jsp You want the Windows Offline version. Or if you happen to be running 64-bit Windows XP, download the Windows Offline (64-bit) version. - Jeff
I called CTT today, just to ask if anyone has done this and if they were aware of any resources. No, and no. Everyone they know of simply uses the provided TMCC handpiece. They said there is not a lot of dcc crossover into 3-rail. The question they asked me was "why?" And I have no idea. Oh, and Java loads fine, as everyone else says, on XP after the warning of impending doom. Now I'll ask...why trying to use JMRI and whatever else when you have the TMCC handpieces? (oh, and my 3-rail is ZW controlled....) Dave
Have to try the Java update then. We tried Linux, but the USB to serial adapter is not recognized, even by the flavor the manufacturer intended for use. We're running another test tomorrow. I'll post the results then. We've quite a bit to try.
Use Bluetrain. Its just like JMRI but uses blue tooth. Uses a usb to bluetooth adapter. Windows freindly and works with TMCC. Sent from my SM-G920P using Tapatalk
You can buy $40 smartphones all the time... I have about 5 old Apple iPhones, most were given, they are worthless now... JMRI free, Wi-Fi in smart phone... done.. Greg p.s. nice that this never got solved, and was resurrected after 5 months to fight over old cell phone prices.
