Running trains wirelessly

Something I have been meaning to try out for a while is the “WiThrottle” mode of the JMRI DecoderPro software, which is supposed to allow you to control trains with an iOS or Android mobile device (phone or tablet).

Well, I don’t have an iOS device, and right now I don’t have a tablet (I left it on an aeroplane in Manila, long story), but I do have an Android phone – a Google/LG Nexus 5X.

So I checked out the WiFi Throttle page of the JMRI documentation, and learned that I could choose between 2 Android apps – Engine Driver and Digitrains.

I installed Engine Driver from the Google Play Store, and then opened the WiThrottle page of JMRI settings, where it said it would listen for throttles on port 12090.

On opening Engine Driver on my phone, it asked for an address and a port. I went to my Mac’s Network Utility and saw that its address (on my home network) was 192.168.11.4. So I entered the address and port into Engine Driver. No go. A “can’t connect” message was shown.

I tried disabling my Mac’s firewall but no change. Then I saw a checkbox on the JMRI WiThrottle settings page which said “start automatically when JMRI starts”. So I ticked it and restarted JMRI, which now opened an extra small window saying it was ‘advertising’ for throttles over wifi.

Now we were cooking. Engine Driver connected straight away, and asked me to choose a loco to control. I don’t like leaving my firewall off, so now I switched the Firewall back on, and added DecoderPro to the list of programs that could listen through it. Still OK.

So I chose a loco, dragged the speed slider and presto – a moving train.

And it was really as simple as that. By touching the add engine button on the app, I could add a second loco and it split the screen into two halves, letting me control both individually. If I had a tablet I think it would probably let me control three or four locos at once, but I think the phone’s screen would be pushed to show more than two sets of controls.

One nice thing was that the Engine Driver throttle controls were definitely more responsive than using the on-screen throttles in JMRI. JMRI’s throttle windows often had a delay between clicking a slider or button and the loco actually responding (or turning on its lights, or whatever). Not so with the app – the response was almost instantaneous.

So I can now walk around my (still not built) layout and control my trains on the hoof. I am one happy camper.

Today’s temporary testing layout…

After all this fun, I decided to try out the Digitrains app to see if it was actually better than Engine Driver, but after wrestling with its settings for 10 minutes and failing to move any locos, I uninstalled it. Engine Driver is fine. Its interface is a bit clunky but it works perfectly.

All I have to do now is work out why, when I add a third loco to the track, it keeps starting and stopping (and so do the other locos on the track) when trying to make it move with a throttle. It feels like an insufficient power issue, even though I was told that the Sprog should be able to control several locos at once. But I’ll save that problem for another day.

Share Button

The saga of the BLS Re 4/4

As you will have gathered I’m creating a model railway based on Switzerland, set in the late 1990s to early 2000s. But I don’t want all my stock to be from the SBB state railway, so I’m going to model a location that could feasibly have traffic from other railway companies, particularly the BLS (thanks to some childhood holidays in the Bernese Oberland region).

Imagine my delight when I saw an Arnold BLS Re 4/4 loco for sale (one of my favourite locos). It was billed as new, digital, and original packaging (OVP as they say in Germany). Ker-ching! Sold to the guy from Malta.

About 10 days later it arrived, and this was when the saga really started. The Arnold box said “Digital, channel 25”. So I put it on my programming track and fired up JMRI on my laptop. When you add a new loco, JMRI offers to try and read the decoder type for you. Unfortunately it failed. I had this happen on a new Minitrix loco which proved to be fine so I thought nothing of it and tried overriding with each Arnold decoder in turn. No go. It wouldn’t read any data from the loco, not even a channel.

So much for the ‘new loco wizard’. So I opened up the programmer window and tried to read all the CV variables. Each time it would pick up a series of different random values. Weird. I tried writing a channel, but then when I tried to read the CVs back, they all came back null (empty).

Then, when I switched on the track power, the loco immediately hurtled along at full speed and shot off the end, with no JMRI throttle window even open. Almost as if it was DC and not DCC, huh? Luckily it powered itself into something soft and no damage was done.

After much head-scratching and some more abortive attempts to rectify the situation, I messaged the supplier. They replied within 24 hours with the kind of information that makes you bang your head on the table and shout “of course”!…

There’s digital and then there’s digital

In this case, “Digital” did not mean “DCC”. It meant the early Arnold pre-DCC digital system that used registers instead of CVs. I had assumed that in the world of model railways, “digital” always meant “DCC”. Apparently not so. Suddenly the reason for my programming failures was crystal clear. I was doing it wrong.

This also meant that the loco, while it was admittedly unused, wasn’t new in the sense of being newly manufactured. It was built in the 1980s and had been in storage since that time. I wasn’t sure quite what to make of this. It looked immaculate but I felt a bit cheated somehow.

After a couple of messages each way with me saying that it was natural to assume it was DCC programmable and I wasn’t happy that it wasn’t a new model, the supplier agreed to fit a new D&H DCC decoder into it without charge if I sent it back to them. This was definitely the best solution (I thought the loco itself was stunning) so that’s what we did.

Freshly DCC’ed

Fast forward to today, and the loco arrived back in the post with a brand new D&H DH10C decoder installed. The supplier enclosed the decoder instruction leaflet, which is all in German, but I can always Google translate it if I need to (my German is very rusty).

So I set up my programming track, fired up JMRI and attempted to read the decoder type. JMRI recognised that it was a D&H decoder, but couldn’t identify the model number. So I picked the most likely one from the list (the DH10C with most recent firmware version). This did the trick, and soon my loco was crawling up and down the programming track. As far as I know it doesn’t have a keep-alive installed, but it successfully negotiated Fleischmann points on all but the absolute slowest speed setting (1 out of 28). On speed 1, it stuck in one direction but was fine in the other. On speed 2 and above, no issues.

As a final test I used JMRI to change its channel from the default 3 to another number, and that worked straight away without any problems.

So my loco roster now consists of three locos – 2 SBB and 1 BLS. The new addition is a little noisy at very slow speeds but the tone of the motor smoothes out as you increase the speed.

So ends the saga. I think there are two lessons I can learn from this. Firstly, a little knowledge is a dangerous thing, and secondly, deal with a supplier courteously and they’re more inclined to go the extra mile for you.

Postscript: since sending the loco back for the decoder to be fitted, I’ve discovered that JMRI has a “register” programming mode as well as the normal DCC modes! Mind you, I have no idea whether this would have worked, and I guess now I never will…

Share Button

Adventures with JMRI

Well that was an interesting three hours…

My Sprog IIv3 DCC controller arrived last week, and today I decided that, busy though I am, I absolutely had to see my new locos moving before Christmas. Here is a gratuitous shot of the locos again, simply because they’re such beautiful models.

New readers should be aware that I’m coming back to N Gauge model railways after 35 years away from the hobby, and my decision to use DCC has effectively turned me into a total newbie.

So I wired up some straight track to the Sprog, connected its power supply, connected it to my MacBook via USB, and launched the JMRI software. After some initial pseudo-random clicking around the application, I worked out that I should remove its settings folder (I had fired it up once before without the Sprog connected), and let it run its “first run” wizard so I could tell it to recognise the Sprog.

That’s where things got interesting. There were two possible entries for the Sprog in JMRI’s list of devices, one just called “SPROG” and another called “SPROG Command Station”. (Much later on I worked out what the difference was but I’ll get to that in a bit.) There were also a number of options for which port it should use, including 2 with the letters “usb” in them, also with no hint as to which was the right one.

I decided that it was time to RTFM (read the flippin’ manual) and found the Sprog and JMRI documentation online. Neither gave me exactly what I wanted though I gleaned a few hints.

In the end I picked some options and continued, encouraged by the fact that the Sprog’s power light was blinking, which meant the track had power.

I worked out that I had to add a loco to the roster, and that was the next hurdle. Trying this with my Minitrix SBB Re460, I found that JMRI was reading the decoder ID as 15227, which is ridiculous considering (as I was told) decoder IDs only go up to 9999. It also would not automatically detect the decoder model, so I had to set it manually to the correct Minitrix one.

To cut a long story short, I spent quite some time adding, removing, and re-adding the loco, trying to write a new decoder ID to it, and getting my throttle window in a mess… I got repeated errors saying “address out of range or throttle in use by another loco”, before I at last managed to set the loco to have a short decoder ID of 3.

That’s not a very scientific description of the process I followed, but I wasn’t doing things very scientifically at this point – I was getting thoroughly befuddled and my scientific method goes out of the window when that happens.

But this last action worked. A little clicking in the throttle window and my loco was crawling satisfyingly along the test track, until of course it hit a dodgy track joint and stopped. But that’s a different problem, solved by solder and wires not software.

One down, one to go…

Having conquered the world of DCC software programming (or so I thought), it was time to get my other loco – the Fleischmann SBB Ae6/6 – running.

This time nothing worked. As with the Minitrix loco, JMRI wouldn’t detect the loco’s decoder, and so I had to try the available Fleischmann decoder entries one by one. But I also couldn’t get JMRI to write a decoder ID. It would read one – in fact it read it as 3 (clashing with my Minitrix loco!) but I couldn’t change it. The program window kept saying “Java null pointer exception” which, since I’m a computer geek, I knew was a serious software error.

If all else fails try another computer

Well. I couldn’t try another loco because this was the only one left to try. I couldn’t try another Sprog because I only have one. So I switched the only thing I could switch – I decided to try with a Windows notebook instead of the Mac.

So after installing the Sprog USB driver and JMRI on my girlfriend’s old Asus ultrabook, I went through the JMRI setup wizard, selected “SPROG” as the controller, the software found the right port automatically, and pretty soon the Minitrix loco was edging down the track once more. At this point I should say that I found a setup guide on an American Sprog website that I hadn’t found before, which was very helpful.

Encouraged by the absence of null pointer exceptions, I put the Fleischmann loco on the track instead of the Minitrix, and added it to the roster. This time, although for some reason I couldn’t get it to accept a short decoder ID of “4”, I did manage to get it to accept a long decoder ID of “150” (picked randomly) which I could then read back.

And sure enough, when I opened the throttle, there was a quiet satisfying hum and the Ae6/6 started moving. I even managed to find and click the stop button before it went off the end of the track.

And this is when I worked out the difference between “SPROG” and “SPROG Command Station” on the device list in JMRI. It turns out that “SPROG” optimises the software for programming decoders (and only allows the use of one throttle at a time), whereas “SPROG Command Station” optimises the software for operations, not programming, and lets you have several throttles in use at the same time.

Back to the Mac?

So, I have a Windows notebook running JMRI with two throttles open, I have a Sprog IIv3 linking the computer to the track, and I have two locos that move happily up and down the track. I’m really impressed by their ability to crawl at almost indetectable speeds by the way – I guess this is a benefit of DCC as opposed to old-fashioned DC.

But do I go back to the Mac, or do I leave well enough alone? In the end I’ve decided that I (eventually) succeeded in fulfilling today’s aim, which was to make sure my new locos worked by getting them moving, and that’s enough for one day.

I’m going to write down all the settings from the copy of JMRI that’s running on the Windows notebook, and then when Christmas is out of the way I’ll then try and configure the Mac JMRI correctly, now that I know both locos will run, and what their decoder IDs are. That way I won’t be stealing the girlfriend’s notebook every time I want to work on the railway.

Share Button