It's been a while since my last post, as I've been deep in a programming project and not working on anything else. It's model railroad-related, and I’ve written a lot of code, but as yet it doesn’t actually do anything and there's nothing really interesting to say about it. I’ll write about it when I actually have it doing something. Maybe next month.

But, as is usual for me, along the way I've tripped over a few of my own misconceptions, and learned a number of useful things. One of the latter is that I now know a heck of a lot more than I really wanted to about Arduino memory use, and in particular about how that changes in the Cortex ARM M0+. Since this version of the Arduino doesn't seem to be well-documented online yet, I thought I'd write up some notes about what I’d learned. This is fairly off-topic for a model railroading blog, but since a lot of what I'm doing these days relates to model railroad control and signaling systems using the Arduino and other microprocessors, it's not entirely off-topic.

And if you skip to the end, you'll find a useful function if you're programming one of these.
Read More...

Tags: Arduino

This is one of those “interim posts” I mentioned at the beginning of the year, posts where I don’t have something yet in a state where I can really talk about it, so I focus in on one detail that’s been taking a lot of my time, as a form of update. But today’s topic, rotary controls for computer-based systems, is a generally useful one, so I don’t think you’ll count this post a waste of time. At least not if you are interested in this aspect of the hobby.

A rotary control, or knob, is a control that can select a continuous range of states arranged in a circle, such as the volume knob on a stereo. Any rotary control can also be laid out as a linear one, simply by straightening out the underlying mechanism (they have to be designed that way, but often are). In schematic diagrams, a linear symbol is typically used to describe either kind, since from an electrical perspective they are identical.

In model railroading the most common application for this kind of control is a throttle. My first power pack, an ultra-cheap kit pack from Tyco, had a linear control (actually it was rotary inside the box, but the lever sticking out the side looked linear to me). Later, my first good DC power pack (my MRC 501, which you can see on my Power Pack Testing page) used a knob, albeit a simple one.

But today, I need a continuously variable control for a digital system, an Arduino to be specific. And yes, it’s for a throttle, but I’m not going to talk about the actual project I’m working on, as it’s still in the early design stages and there’s nothing much to say yet. Instead, I’m going to talk about the various options for this one control, and then go into more detail about the one I’m using, seen in the photo above attached to an AdaFruit Feather M0 Proto (a type of Arduino) for testing.
Read More...

Tags: Arduino

Well, it didn’t take long. The first useful commercial products based on the LCC standards are out, and I have a set. While I may have some reservations about the state of the standards themselves (see my earlier series of posts), I’m very excited to see real products, and at fairly reasonable prices. Well, somewhat reasonable; I’ll have some comments on that.
Read More...

Tags: JMRI, LCC, RR-CirKits, Tower-LCC, CTC, Signals

Today’s post is going to be one of those interim ones I promised last time, where I report on progress made (or not), mostly about my work with testing the use of I2C as a short-range communications bus.

I decided to start with examining the code I’d written last spring, only to find that most of it was irrelevant as it was doing things the I2C hardware would do for me, or it had functional compromises I didn’t need to make now. About 90% of it got deleted, and I started working on something that would work with I2C, using a couple of my test programs to create a library that front-ends the internal Wire library used to directly control I2C. That’s working to the point that I can pass messages to/from the master, and detect damaged messages, but there’s a lot more to do.
Read More...

Tags: Arduino, I2C

I'm going to usher in the new year with a new project, and try to get back to doing more frequent but smaller posts than I've done of late. I'm not quite back to railroading yet, although this is ultimately in support of that. But for the moment, I'm still playing with microelectronics. And today's post is just a summary of where I'm going and what I've done so far, which doesn't amount to much when you put it down in words.

I'm still thinking about and planning the next layout. Control systems are a big part of that, because I was never happy with the DCC-throttle control of turnouts I used on Sumida Crossing, and my attempt at a single big computer-driven system never got off the ground, and would have had some of the same issues if it did.

As you may have noticed, I've spent a lot of time looking at control bus systems over the last two years. I'm still on the fence about what to use, as I don't particularly like any of the current systems. LCC has promise, but so far that's all it has, and I'm not expecting much from it in the next couple of years; it's too new.
Read More...

Tags: Arduino, Raspberry Pi, Design, JMRI, LCC, LocoNet, Signals, CTC

Back in October I started what I thought would be a relatively easy, if perhaps a bit long, post on messaging in LCC. I was trying to cover it in detail, explaining how the ideal LCC had to be adapted on CAN Bus. That proved distracting and I put that material aside to just focus on the basic messaging capabilities of LCC rather than the implementation on CAN Bus, at least to the extent I could.

In the process of doing this, I've managed to chase myself in circles more than a few times. The LCC standards are very confusing, even by NMRA standards. We're talking about documents written by volunteers rather than professional standards-writers, and generally without a whole lot of editing. I've been reading NMRA standards for more than 25 years and I'm used to having to work at it to puzzle out the actual meaning. But still, the lack of clarity in the LCC documents is exceptional.

I'll detail problem areas throughout this post, but it basically boils down to things either being omitted entirely from the documents or being covered in one of the other technical notes than the one you’d expect. And there's a fair bit of using two different names for the same thing and, conversely, using similar names for two different things.

The revised post is about messaging in LCC and what you can do with it now, and additionally I'm coming at this as a review of the LCC standards, not anything external to them. The OpenLCB team has written a lot of words about OpenLCB, and that’s often helpful, but what matters in a standard is what's actually incorporated in it, either directly or by reference to or citation of an external document.

Read More...

Tags: LCC, NMRA

This is the second in a series of posts on the NMRA's new Layout Command Control (LCC) standards. The first post covered the reasons why a control bus, and specifically LCC, were important, as well as providing a fairly high-level view of how LCC works. Today we'll get into some very specific details regarding the physical aspects of the network, specifically the CAN Bus wiring and usage. Next time, I'll cover the actual messaging on the network (i.e., what you can do with it).
Read More...

Tags: LCC, NMRA

Three years ago, in 2012, the NMRA published their first standard related to a layout control bus, at the time known as NMRAnet. This was standard S-9.7.1 NMRAnet: CAN Physical Layer, which defined the electrical characteristics of the bus (e.g., details of the wire, connectors, bit rate, and voltage levels). Several companies were producing useful circuit boards based on the standard, although their functioning depended on capabilities not adopted at that time.

This standard, and the not-yet-adopted parts used to make the first implementations, were based on something called OpenLCB, which stands for Open Local Control Bus (not "Layout Control Bus"). Open LCB was one of several competing proposals for NMRAnet. The OpenLCB team demonstrated how this would work at the 2010 NMRA convention, and has a page of videos and other information from then. Over the subsequent two years it came out on top as the solution of choice. However, some of the potential demonstrated there does not seem to be fully fleshed-out in even the current standards. We're not done with the development of LCC by any means.

But we have had significant progress this year. Back in February the NMRA adopted 21 additional documents, 10 more Standards and 11 clarifying Technical Notes. They also renumbered them slightly, and changed the name to Layout Command Control, or LCC. These were formally adopted with a six-month comment period that ended on September first. Updates based on those comments are still possible, so the standards aren't quite done yet, but they're probably very close to their final form.
Read More...

Tags: Lenz, NMRAnet, LCC, NMRA

If you follow the RSS feed on the main page, you can see that my interest in signals continues. However today’s topic is about what signals describe: track, and in particular the turnouts, or track switches, or just switches, used to direct the motion of trains, although I do mention the relation to signals briefly. And yes, it’s finally a post about the layout, even if it is about the as-yet unbuilt future layout.

I’ve been spending some time thinking about how I’ll do turnouts on the new layout. As part of my overall design, I’m planning to use code 55 rail on a mixture of concrete and wooden tie track (I’m undecided between PECO and Micro Engineering). And I may custom-build some track to replicate slab-type track, which is used by both Shinkansen (sometimes) and in some newer construction for narrow-gauge track, particularly in stations and on viaduct. Although I dislike unnecessary work (and hand-laid track is, to me, generally more effort than it’s worth), I do plan to put substantial effort into getting the track to both operate reliably and look as prototypical as I can. And thus hand-laying some portion of it for appearance purposes may be worth the effort.

Note: some Japanese models have issues with code 55 track due to larger-than-spec wheel flanges, and I’ll need to do some testing. But most of my models are Kato, and they generally use low-profile flanges that should work.

I’m also planning for very wide radius curves, although I have not yet picked a specific standard or minimum radius. I want both Shinkansen and commuter stock to look good on curves, with minimal overhang. That means I need much wider curves than the minimum operating radius. I may skimp a bit for storage and yard tracks, including modeled layover terminals where trains are kept off-peak. But mostly I’m considering track radii in the 30” or larger (750 mm or larger) range. And that raises the related question: what type of switches do I want to use?
Read More...

Tags: Design, TAM Valley, JMRI, NMRAnet, Peco, Flextrack

I’m going to vary from my normal focus on modeling Japanese railroads today to talk about signals and modeling them in a more general sense. Heck, who am I kidding, there haven’t been many posts on modeling Japanese railroads of late. But I digress from my digression. Back to the subject: signals.

If you want to cut to the chase: I’ve written an Arduino library for controlling lineside LED-based signals. It’s only part of a complete signaling system that I’m working on, and at present you’d have to do more work to make practical use of it. But the code is public and can be used independently of anything else I’m eventually going to create; skip down to the end for details.
Read More...

Tags: Electrical, Design, Arduino, Signals

My interest in the design of transistor-based DC throttles (aka Power Packs) for model railroading ended up causing me to pick up the DVD set of Model Railroader back issues (henceforth identified as MR). While US$200 seems like a lot, I think it was well worth it, if only to satisfy my curiosity. And it works out to less than US$0.30 per issue, so in a sense it’s a bargain. I also dug up a copy of Peter Thorne’s 1974 book Practical Electronic Projects for Model Railroaders (mine is the third edition of 1975), which has a number of throttle circuits, including one using an SCR. This book can go for rather high prices online, but I found mine at a train show last week for the cover price of US$3.50; quite the bargain.

Early-on electric model trains were run with car batteries (some early ones used AC motors with AC from a transformer instead), first apparently at 6 volts but by the 1930’s DC motors were apparently designed for 12 volts even before cars switched to the larger batteries, requiring two batteries placed in series (per MR August 1934 article on the use of DC power). DC at 12 volts was more than enough to run small motors, and early throttles were little more than a variable resistor (rheostat) to reduce voltage for slower speeds, and a Dual-Pole, Dual-Throw (DPDT) switch to reverse polarity for direction control. Often a “knife” switch would be used for the reverser, which could be left in a central “off” position to disconnect the throttle from the track.

But modelers weren’t very satisfied with these. DC didn’t allow for smooth low-speed operation, and “jackrabbit” starts with a minimum speed over 10 or even 20 scale miles per hour (16 - 32 kph) made for poor switching operations. Plus, modelers wanted to model the behavior of real trains, with simulated momentum and realistic braking action.

This led to designs for more sophisticated “throttles” and ever more complex designs as electronics technology improved. Some of the results did a fairly good job of replicating the real behavior of trains, right down to simulating the performance of air-brake systems similar to the one in the diagram at the top of this post. It’s possible some of this took place before the transistor was introduced; vacuum tubes could have been used for similar things. However, nobody appears to have published their experiences with these, so it seem likely that little or nothing was done until the transistor came along.

The development of the low-cost transistor in the late 1950’s made more complex throttles accessible to a hobbyist with a relatively minor amount of electronics skill and for a reasonable price, and the next decade was a time of rapid change, with evolution continuing into the 1970’s. By 1980, interests had shifted towards running multiple trains using command control systems (the precursors of DCC), although the roots of those went back further. And even in 1980 you could still buy rheostat throttles, although they were definitely behind the times by then. None of these technologies fully displaced the others. The transistor has in fact soldiered on into the era of digital controls, and you can still buy transistor throttles today that aren’t too different in principle from those designs of a half-century ago.

Read More...

Tags: DC, Design, Throttle

About fifteen months ago work on adding occupancy detection to Sumida Crossing stalled. That was in part because I’d planned to use the BDL168 detectors to also do transponding, and a few months earlier had abandoned that plan since I was unable to get that aspect to work reliably, even on a simple test track. The number of solder joints on the BDL was also a nuisance that caused me to put off further work.

Recently I’ve been rethinking my approach. The BDL168 is an amazingly cost-effective solution. Ignoring the transponding part, you get 16 detectors on a board that includes a LocoNet bus interface for US$120 (street price). That’s $7.50 per detector (if you can use all 16). That’s really hard to beat for a bus-connected detector. I’d originally planned to install one per table on the layout, and my cost would have worked out to around $10 to $15 per detector on average.

On the other hand, I’m thinking that I might want to move to either a OpenLCB/NMRAnet bus (if I want a feature-rich bus for the future) or a really dumb serial bus (like S88 or C/MRI). The latter is attractive since I can potentially interface to it with an Arduino, opening up some room for home-brew devices. Of course I could do that with NMRAnet, but today that requires a US$45 shield to add to the Arduino (or one with it built in), which kind of takes away from the appeal of using $10 Arduinos to do things like drive signal masts.

While thinking about this, I went off and started researching what was available commercially or as home-brew circuitry and software libraries for these busses and for doing occupancy detection with them, as the latter would be a good way to get my feet wet and solve my “don’t want to solder those #$@! BDL168s any more” problem.

But in the past week I’ve been sidetracked into looking at homebrew inductive-coil detection circuits.

Read More...

Tags: Digitrax, BDL168, BD20, DCC, LocoNet, NMRAnet, Arduino, CMRI, S88

I’ve continued working on the code to drive LED signals with an Arduino. I’d previously discussed my approach, and provided the code I was using at that time. I’ve learned a bit since then, and cleaned up the code significantly. I’ll provide a link to the current example program at the end of this post.

Fundamentally nothing has changed. I’m still planning to use NJI common-anode SMD LED signals (in fact, I’ve ordered them). What I did do was change the code so that a “bank” of two signals would always have both lit (meaning two of the four LEDs would be on when the bank was active) so that I could get through the full set of signals more quickly. One reason for this has to do with video camera shutter speeds. I think it’s worth saying a bit about that issue.

I’ve also made some changes to make the time wasted in turning the pins on and off less, since at these speeds that is becoming a significant percentage of the total LED cycle, and I need that time for the eventual Tram Controller program to be doing other things. These changes consisted of adding a library that provides faster versions of writeDigital and pinMode, as well as keeping track of what state pins are on, and not trying to change them unless the new state differs (this got rid of a number of “change disabled pin X to disabled” changes).

In my test program, when cycling at 8 milliseconds, I’m now spending just a quarter millisecond changing those pins with three banks (6 signals) in use. My One Point Five Meter line will only use four signals, as it doesn’t have the extended double-track section of the full Tram Line, which needs six. And so it will run even more efficiently. Read More...

Tags: Arduino, Signals

I’m continuing to work on the Tram Controller project (main page, past musings), to the exclusion of all else layout-related, which doesn’t make for interesting posts here. But I’ve made a number of decisions in the past month, and it’s probably worth summarizing them and where that puts the project overall. Short answer: making good progress, but slower than anticipated (what else is new; all my projects run “slower than anticipated”).

I’ve also been thinking about the diorama-like layout I’m going to initially use this with. The current candidate plans for that are on the new One Point Five Meter Line page.
Read More...

Tags: Arduino, Electrical, Tram

t seems that I can never resist the impulse to make things more complicated. While working on my Arduino sketch (program) for the Tram Controller, the thought struck me that I could add signals at the stations to tell the fictive operators of the trams when it was safe to leave. These would be “starting signals” in typical Japanese practice, and only require two LEDs, red and green. Of course I’m all out of pins, and the only step up from the Uno, which has 20 pins (14 digital, 6 analog) is the Mega with a whopping 70 pins (54 digital, 16 analog).
Read More...

Tags: Arduino, Signals

One point five meters, or about five feet. That’s how much space I’m giving myself for a short layout designed to display my buildings separate from the main layout. It’s also going to give me a short rail line that I can use with the controller I’m working on for the tram line on the Urban Station scene.

The germ of this idea was a conversation at a local hobby store that holds an annual show in the store to display the model-building skills of its customers. Last month, just before the show, I was asked about some of the pre-built buildings I’ve been detailing for my Village scene. At the time, I didn’t think the couple I’d mostly finished were really in a displayable state, but the idea of perhaps doing some kind of diorama crossed my mind as we discussed how to display something next year.

I also wanted some way to actually see the tram line in operation, as on the layout it’s going to be hidden away behind buildings, providing some background activity without really being visible (something I really need to fix on a future layout). And that led me to think: how small can I make a layout with the tram controller and my buildings?
Read More...

Tags: Arduino, Design, FineTrack, Greenmax, Modemo, Tomix, Tram, Display Layout

Having covered the motor control and the sensors, my next step in creating the automated two tram controller was to deal with the very small number of controls I need to have. In my original design, the plan was to have just three pushbuttons:

- Run: when pressed, the trains would start to move.
- Park: when pressed, the trains would return to their starting locations so the system could be turned off.
- Emergency Stop: when pressed, the trains would come to an immediate stop until run was pressed again.

And all three were to be “on when pressed, off when released” pushbutton switches. I was already thinking this needed to be changed, and when I started playing with switches I became even more convinced.

There are two benefits to using toggles versus “on while held” button switches: first, I eliminate a switch, since I need two toggles rather than three pushbuttons. Second, I avoid using those pushbuttons, which have proven to be problematic in my testing. They tend to “bounce” for a long time, and they may remain “on” only for a fairly brief time, making it hard to avoid all bounces and still reliably tell that they were pressed in the first place.

The other control I wanted to add was a way to customize the top speed of a train (or trains, really), so the different models could be made to run at similar (and prototypical) speeds. I don’t want one train rocketing down the tracks while the other creeps along, even if they have very different motors and gear-trains. So I’m going to add a pair of potentiometers, used as “tram #1 max speed” and “tram #2 max speed” controls. And note that these are for the trains, not the motor shield A/B outputs. At various times each tram will be controlled by one or the other.

My first step was to create a simple throttle that used one pot, three switches, and one motor control to run a train on a simple test track. This gives me a proof-of-concept example that ensures I really understand what I think I understand (always a concern with me and electronics).
Read More...

Tags: Arduino, DC, Electrical, PWM

This is going to be a short post: it’s working! I have my IR LED phototransistor sensor program detecting things (not trains just yet), and I’ve posted the example code, see the bottom of the Tram Controller page for a links to that, and the earlier motor control code. Both example programs are public domain, feel free to use them however you see fit. I’ve benefited from a lot of public domain programs, and I think it’s only fair to give something back. When the tram controller program is a bit more polished, I plan to publish it in the same way, although it may be months before I get to that point.
Read More...

Tags: Arduino, Electrical

In my continuing work on the Arduino-based Tram Controller, I’m now playing around with the part I really wanted to work with, the Infra-red optical sensors themselves. This turned out to be rather more complex than I’d anticipated, but I’m most of the way there, even if I don’t quite have the system working yet. This is a post about what I’ve done so far, and what I’ve learned, with a bit about what remains to be done.
Read More...

Tags: Arduino, Electrical

I’m still playing with Arduinos this week, but the little beasties are multiplying. That’s partly because I want to be able to test with the various CPU architectures, but also because each has unique strengths and weaknesses, and I’m still evaluating which of them is going to be the right choice for my tram controller. At the same time, it turns out that there are a number of options for motor shields, as I mentioned last time, and they too have strengths and weaknesses.
Read More...

Tags: Arduino, DC, Electrical, PWM, Tram

Two years ago I wrote about my plans to use an Arduino to control a pair of trams on a double-track line sharing single-track stations at each end, replicating the design of the Tōkyū Setagaya line. That’s briefly written up in that earlier post, and I also have a full page about the project that goes into more detail, with a sub-page about the current testing work.

Back then I bought an Arduino Mega 2560 and a bunch of other parts including a “shield” used to drive DC motors, loaded the basic test program that blinks a LED into it just to convince myself I could do it and the hardware worked, and then put it on a shelf for “later”. And forgot all about it while I worked on other things, only infrequently looking at the empty tram tracks and thinking “I really should figure out how to make that work.” It’s not like I dislike the work: I enjoy both programming and soldering simple circuits together. I just never could work myself up to starting what I expected to be a fairly major project. It was always: “I’ll work on that after I finish project ‘X’”, but there was always another “X” to occupy me.
Read More...

Tags: Arduino, DC, Electrical, PWM, Tram

Update (3/29/13): The “percent of maximum” numbers are all wrong. I’m never going to get this right. I need to go back and recalculate those, but that’s not happened yet. When it does, I’ll correct this post (and maybe make another one).

===

I really thought I was going to be done with PWM and back to working on decoders this week. But, as is now noted on the last post, I got it wrong. As I mentioned then: “I’m not an electrical engineer. I think I know what I’m talking about, and my conclusions appear to line up with observed reality. But I could have fallen down the rabbit hole and just not noticed. Take it all with due caution and a grain of salt.” Yep, down the rabbit hole I went.

So, as Bullwinkle used to say, “this time for sure!”. Well, sort of. I’ve fixed my problems, but my model isn’t an exact one. For the details of that, and what conclusions I can draw from what I have, read on.
Read More...

Tags: DCC, Design, PWM

Update 3/16/13: Ok, my graphs (and some conclusions drawn from them) had a serious flaw. I’d modeled both the growth and decay curves incorrectly, and this caused current to drop to zero in a lot of situations where it wouldn’t have. Don provided an interesting simulator model, which led me to do some more reading and correct my model. It’s still not complete, but rather than re-do this post, I’m adding a new one that is the correction. I’ll leave this one here for history’s sake, but please see the new one.
Read More...

Tags: DCC, Design, Kato, Micro Ace, Errors, PWM

DC motors are controlled by varying the voltage and polarity of the DC power connected to them. In a simple DC power-pack a rheostat is used to provide a voltage to the track that varies from zero volts to the power pack’s maximum, which is often around 16 Volts. A simple switch is used to swap the positive and negative outputs to change the polarity (and thus the direction the motor turns). This tends to waste a lot of power as heat, but since that’s happening inside the power pack (and “a lot” isn’t really all that much at these voltages) that’s acceptable.

DCC decoders need to take a constant-voltage AC input from the rails, and control a DC motor somehow. Even if they could use a rheostat, wasting power as heat inside a plastic model is more problematic. The technique normally used instead is called Pulse-Width Modulation, and it’s a fairly simple and commonplace, and efficient, method of controlling DC motors from a digital controller. The same technique is used in many other applications. Read More...

Tags: DCC, Digitrax, TCS, PWM

A computer is part of my model railroad. Why, and how do I use it? Well, the answer to the last question is “not very much”, so far, but I have plans. I recently had to re-do the monitor support attached to the layout, and I thought I’d discuss the reason it’s there, as well as the work on the support itself.
Read More...

Tags: DCC, DCS100, Design, JMRI, LocoNet, RR-CirKits, LogicRail, SE8C, Signals

Comparing decoders for cab cars is actually relatively simple. These don’t need to do very much, so it’s really about checking basic functionality. I’ve laid out the full testing details on my Decoder Comparison Testing page, and here I’m going to summarize the findings for the capabilities of interest to me.
Read More...

Tags: DCC, Digitrax, JMRI, Lenz, Railstars, TCS, Zephyr, PWM

’m turning my attention to the cab car decoder install now, and a recent discussion with Don along with a question from a reader had me thinking about potential problems with DCC conversion of N-scale EMU cars with cab lighting. And the one that really worried me was overvoltage from high DCC track voltages, and its harmful (fatal) effect on LEDs. DCC decoders essentially pass track voltage (minus a small bit) through to their function outputs.
Read More...

Tags: DCC, Digitrax, E231, Micro Ace, Greenmax, NMRA, Zephyr, RRampMeter, Lenz

November, as you may have noticed from recent posts, went largely to laying the groundwork for installing wire-in DCC decoders, and a bit of testing of same. After a few delays, most of what I was waiting for finally arrived, although a few things are still backordered. In particular, the six-pin NEM651-compatible plugs and sockets mentioned in the comments last time have arrived. For the curious, the parts list has been added to my page on DCC Decoders. Read More...

Tags: DCC, Digitrax, Lenz, TCS, Administrivia

Although the rest of my decoder order still hadn’t arrived, I decided to start work on my first wire-in motor decoder, to let me get some experience with the installation process, and to do some more experimentation. I used the Micro Ace Sobu E231 as previously planned, and to start with, a DZ125 decoder from Digitrax.
Read More...

Tags: Digitrax, DCC, Micro Ace, E231, Bachrus, Zephyr, PWM

My plans to start installing decoders were somewhat upset when a large quantity of the ones I’d ordered turned out to be out-of-stock, and a box arrived containing only a couple of decoders and some wire. I actually have a number of decoders on hand, though not enough to do a full EMU the way I want, or all of the models I wanted to experiment with. So, while I could have made a start, instead I decided to spend some time working out my standard configuration settings for the Digitrax decoders. I’m going to have a number of these even if I don’t use the DZ125 wire-in decoders, since my Kato “DCC Friendly” models use Kato’s EM13, which is essentially a Digitrax FX3-Series decoder. And I have a few models with lightboard replacement Digitrax decoders.
Read More...

Tags: DCC, Kato, DE10, Digitrax, JMRI, Bachrus, DCS100, Zephyr, E233, Throttle

As noted last time, I’m going to (finally) install DCC decoders in some of my commuter (and other) trains that aren’t Kato “DCC Friendly” designs, meaning I have to use wire-in decoders. And since these are EMUs where the motor car is in the middle of the train, that means installing three decoders per train, a Motor Decoder and two “function-only” decoders for the cab cars.

But to start with, I need to set up my workspace since it’s been a while since the last decoder install, and the various elements had all moved off the bench to other uses. And the bench had filled up with important stuff (meaning junk I couldn’t stuff somewhere else), so I needed a better workspace. Besides, I’m going to want to sit down for this work, and the workbench is really better for standing work. Read More...

Tags: DCC, JMRI, Kato, DE10, Digitrax, Bachrus, Micro Ace, E231

This is the first of what I expect will be several posts about wire-in DCC decoders. Up to this point I’ve either been using the Digitrax-made Kato decoders that snap into Kato trains, or lightboard-replacement decoders for locomotives. But I have a large number of trains that don’t take either of those, many of them the commuter trains I’ll want to run on my new commuter line (once I finish the DCC wiring for that). Read More...

Tags: Digitrax, TCS, DCC, Design

In August, the NMRA adopted standard S-9.7.1, NMRAnet Physical Layer, and a short article about it appears in the November issue of the member's magazine. What is this, and why should you care about it?

Well, if you care about Digital Command Control (DCC) for controlling a model railroad, it's an important addition to model railroading that will enhance that. And if you don't care about DCC, it's compatible with other control systems, and you may still want to use it. Read More...

Tags: Arduino, DCC, JMRI, LocoNet, Railstars, TCH, RR-CirKits, NMRA, NMRAnet, Signals

One of the hardest lessons in model-railroading, at least for me, has been that “good enough” really is good enough. I spent fifteen years on my HO layout doing very little, in large part because what I did do fell short of what I’d set out to do, and I’d get frustrated and go do something else for six months. With Sumida Crossing, I started with the premise that I wasn’t trying to do a picture-perfect layout of the kind featured in magazines. Neither my skills nor my available time were up to that. Read More...

Tags: Kato, Lighting, Administrivia, DCC, E233, DCS100

After saying I was going to finish up the DCC electronics several times, I’ve finally made a start. There are two parts to this. The first is finishing up the remaining DCC power protection and occupancy detector panels. I did the first three tables last year, starting around January. The third was the first I’d done as a removable panel, which I wired up back in November. At the same time I’d begun the work of setting up a third accessory power bus, adding a switch and meter to the main panel. However at that point I’d stalled, with my attention off the layout over the holidays, and when I returned it was to work on buildings.
Read More...

Tags: BDL168, PM42, DC, DCC, Digitrax, Construction

The DCC Power work continues, but it’s still not done, as I have to do the power panels for the urban scene and the unsceniced return loops, but with the panel I built and tested back in September/October finally installed under the tables of the River Crossing scene, I’m at the halfway mark (having done the Riverside Station scene back in March).

To recap, the board contains a PM42 DCC circuit breaker that provides four separate circuit breakers and a BDL168 occupancy detector that can provide up to sixteen occupancy detectors and eight transponding sensors (see my pages on occupancy detection and the BDL168 for more details). This board provides occupancy detection for six electrical blocks, two each on the commuter tracks and one on each subway track where it loops below the expressway. Although I’m also wiring up the transponding sensors, as mentioned previously I’m having doubts about them due to problems in testing and the anticipated low power draw of my trains being borderline to register on them.
Read More...

Tags: DCC, BDL168, Electrical, DC, River Crossing, Digitrax, PM42, SE8C

I’ve been playing around with JMRI some more, and trying to debug my transponding problem with the first of the electronics boards. This is really baffling. I checked the wiring, and it was fed through the RX sensor properly. I replaced BOTH the PM42 and the BDL168 circuit boards (I’ve got a stack of them waiting for more electronics boards once I get this one working) and I tried using other blocks. And I had more transponding sensor failures. On both sets of RX sensors. One defective set I might accept, but two?

So I tried a variety of things, and noticed that the non-functional detectors would, every once in a while, work. In fact, I discovered that with the train motionless, one of them would periodically cycle from detection to non-detection, emitting a LocoNet message reporting the change in status each time. I tried moving the wires. I pulled a fresh RX1 set out of a bag, and set it up atop a trash can (see above) with every wire fed through it fully separated from every other wire in mid-air (about the middle of this I was holding things in both hands and wishing I had a third arm). And that failed too, reliably as it were.
Read More...

Tags: Administrivia, JMRI, DCC, BDL168, PM42

Some weeks I don’t get much done. Well, that’s not quite true, I did a lot of work on the website this week, but the railroading time suffered. I did find some time to play with the test track I’d set up last week though, configuring JMRI to report block status based on the BDL168 outputs.

If you’re not familiar with JMRI it’s a free software package that allows a computer to interact with any of several DCC command stations that support computer interfaces, including Digitrax. It’s also available for Windows, Linux and Macs. And while not the most Mac-like program, it works, even on the ten-year-old iMac I’m using for the layout controller.

So what I have is a test track that’s an oval divided into two electrical blocks, each connected to an output of the BDL168. I named them, creatively enough, “One” and “Two”. And I used the Layout Panel editor to draw a schematic of the track. When displayed, red shows occupied (it’s configurable) and green shows clear. Even on my old computer, the change is nearly instantaneous once the locomotive crosses the insulated rail joiners from one block to the other.
Read More...

Tags: DCC, Administrivia, LocoNet, Digitrax, JMRI

After assembling the first of my DCC protection and Occupancy Detection boards, I decided I wanted to test it and get some experience with using it. So I set up my loop of test track with insulated rail joiners separating it into two halves, and connected the feeder to outputs 1 and 2 of the BDL168, which correspond to RX4 A, detectors A & B. All of these are powered by PM42 section 1. For DCC, I used my Zephyr, and for the DC supply I used the 2 Amp, 12 Volt supply I plan to use for these systems (it’s the black box just above the Zephyr in the photo above). Powering it up, nothing went “Zap!”, which I count as a success.
Read More...

Tags: DCC, Administrivia, Digitrax, DE10, LocoNet, PM42, Zephyr

After two months spent working on the website move, I’m back to working on (and playing with!) the railroad. That doesn’t mean I’m done with the website stuff. There are still pages left to convert, and a few problems to solve, and I’ll have more to say on that down below. But the new one is up and running, and relatively problem-free. And I’d budgeted this weekend to model railroad work in case there were problems, so I had some free time on my hands. I celebrated by getting the outer loop wired up and running a couple of trains. Then I turned my attention to working on the DCC protection and occupancy detection circuits so I can get the other two loops up and running.
Read More...

Tags: DCC, Construction, Digitrax, Administrivia, Design, BDL168, PM42

After a relatively quiet winter and spring, work on the layout is picking up (most people do this in the winter, but I don’t seem to work that way). As mentioned in the last musing, I spent most of May working on the subway station of the Riverside Station scene. And I’m still basking in the glow of completing that. I go down to the basement every few days and turn the station LEDs on just to grin at it for a few minutes and think: it’s done, I actually finished something!

A big part of that was making signs using found photographs and graphics images. I’d described that briefly earlier in the month, but hadn’t gone into much detail. This method worked out very well, and I used it to produce the station platforms signs (using images from Tōkyō Metro’s website plus my own text), the subway maps (using an online map, vastly reduced in size), the advertising billboards (from photos found online), and even the vending machines on the platform (from photographs of real ones found on Flickr).
Read More...

Tags: Lighting, Signs, Tram Layout

Today I want to mention one of my other projects: the control system for the Tram line of the Urban Station scene. Now this is a simple, short, out-and-back line, which exists mainly to give me an excuse to buy some of the Tōkyū Setagaya line light-rail vehicles (see the Tram section of my Roster) and to experiment with Tomix’s mini-rail Finetrack. So far I’ve run this manually, with a Kato powerpack. But I want to automate it, since the trams are just supposed to be background activity to make the station look busier, as I concentrate on running my commuter and express EMUs and freight trains.

The problem I had was that I wanted to replicate a two-track line with unidirectional running, and a single track station at each end that let the trains switch between the two tracks, and I wanted to do this with more than one tram running at a time. The track I’m using has slip switches, which allow a train to run through them even with the switch set against it. This lets me leave the switch in one position, and have a train enter the end station from one track and leave on the other, without any switch-control needed. Read More...

Tags: DC, Tram, Urban Station, Arduino, PWM

I seem to spend an inordinate amount of time worrying about light. First it was the layout lighting, then it was the flickering interior lights, which annoyed me when I detailed my first commuter EMU, and which I wrote about nearly two months ago when I did the original planning for a flicker-prevention circuit. Now I’m back, having built several prototypes and refined my design. I think I have a winning solution.
Read More...

Tags: DCC, Lighting, Video

Railroads have always been concerned with time. Early ones used timetables alone to keep trains on the same track from colliding. This didn’t work very well, particularly given the accuracy of mid-1800‘s pocket watches and the lack of synchronized time sources, and many lives were lost. Signaling systems and other protection methods were gradually developed. But timetables continued to be important for all trains in scheduling the use of tracks even with other systems used for protection, and timetables were required for passenger trains, as trains from different places needed to coordinate their arrival and departure at interconnection points, so passengers could move smoothly from one to the next as part of a longer journey. Railroads gradually developed standards for time-keeping (and they’re responsible for the adoption of the standard time zones used in the U.S.), and also influenced the development of clocks and watches to provide accurate and synchronized time sources.

Japanese passenger trains today are famed for their obsessive adherence to schedules, with deviations measured in seconds, not minutes. So it only seems reasonable that a model railroad of a Japanese passenger line should operate to timetable (well, eventually,I need a yard/staging tracks before that will be much fun).
Read More...

Tags: DCC, LocoNet, Digitrax, JMRI

Now that I have some real working track, I’m even more motivated to get some of my trains converted to DCC (so far there’s just one, the Jōban E231 described on my Adding DCC and Lights page). So, back I go to the hell that is Kato “DCC Friendly” decoder installation. Really, the marketing person who thought that phrase up was truly evil. There’s nothing friendly about this process. DCC doesn’t have to be hard, but with Kato it all too often is.
Read More...

Tags: Kato, DCC

The Internet is a wonderful invention. Without it, I wouldn’t be able to order trains from halfway around the globe and have them delivered in under a week, nor would I have any idea of the difference between an E233-1000 and an E233-2000 (both are commuter trains, but the 2000 is a narrow-bodied variant with a end door for emergency exits; this model runs through onto the Chiyoda subway and nobody makes a model of it yet, but I want one). I hear that some people have more serious uses for the Internet, as well.
Read More...

Tags: Kato, DCC, DC, Electrical, Zephyr, RRampMeter

DCC is really about getting power and control information to the track. But there’s another side to it: how do the commands from the throttle (the controls) get to the DCC system, and how do different parts of the DCC system communicate with each other? The first part isn’t covered by the NMRA’s DCC standards, so each manufacturer does the throttle-to-command-station link in their own proprietary manner. The second part is partially standardized, as the NMRA has Recommended Practice RP-9.1.2 Power Station Interface to describe how a command station sends commands to booster stations, but they don’t say anything about how devices like stationary decoders or occupancy detectors report their status, although there’s a draft of a standard for an “NMRAnet” control bus being developed which will probably fill this gap, someday.
Read More...

Tags: DCC, Digitrax, LocoNet, JMRI, Design, NMRAnet, Zephyr

As I’m finishing up the wiring for the two upper-level loops (one of which will be DCC-only, the other will be the switchable DC/DCC line), I’m also getting my DCC electronics set up and ready for use. There are several aspects to this, and I’ll cover others in future musings. But today I’m going to write about track and motor voltage. I could have just used the command station as it came, and it probably would have worked fine. But I like understanding exactly what’s going on under the hood, and so I ran a number of tests and spent some time researching what the track voltage should be, and why, and what that meant for the motor on a train. And if I ever add a booster, it will be important for it and the command station to be set to output the same voltage (this avoids problems when a train bridges between two power districts), so I may as well pick a voltage now.
Read More...

Tags: DC, DCC, Design, Unitrack, Digitrax, NMRA, RRampMeter

I should be building the topography under the soon-to-be Riverside Station scene’s Commuter Station, instead I’m still obsessing over the scenery where that scene meets the River Crossing scene, and specifically the exact design of the grade crossing I’m going to build there, someday.
Read More...

Tags: Scenery, Digitrax, Circuitron, Design, JMRI, Grade Crossing

DCC doesn’t need to be complicated. At the simplest, it’s a pair of bus wires from the command station running under the track, with feeders connecting the track to it at intervals. I can, however, make anything complicated. Probably more complicated than it needs to be. It’s a talent.

Read More...

Tags: Electrical, DCC, Digitrax, Lighting, BDL168, PM42, SE8C

Rather than turning my attention immediately to the Riverside Station scene, I decided to get the electrical systems ready for the eventual use of the two “ground level” loops, which will require DCC. And that meant I needed to finalize my plans. And although most of them had been worked out last year, and revised (in my head if nowhere else) over the winter, there was still a bit of planning needed before I was ready to start cutting wire. This had to encompass the DCC systems (both power and the LocoNet control bus) as well as the various power strips to supply them, and some additional power supplies for eventual LED lighting. I’d started thinking more intensely about this while I was working on the wiring recently, but needed to bring that to conclusion and write down the results.
Read More...

Tags: Construction, Design, DCC, Digitrax, JMRI, LocoNet, Electrical, BDL168, PM42, SE8C

Today I’ll turn my attention to what goes atop the scenery: buildings. There’s going to be much more on this, and I’ve created a Structures section of the website with its own index page to contain such material, but so far it’s pretty vacant. Today’s post introduces the first page there, describing Kato’s modular multi-story buildings.

Kato makes several modern six-story buildings that are generic enough to use in any city, although they also include signs to decorate them for a Japanese one. But what really makes these buildings special is that they’re modular, and while Kato doesn’t sell the floor units separately, you can combine two or more buildings to make some reasonably tall structures. Read More...

Tags: Kato, Structures, DCC, Signals, Digitrax, SE8C

Work has been progressing more slowly than I’d like, and the first level of foam has yet to be glued down, or the subway track installed. The backdrops were taken down and repainted in a lighter shade of blue, and I’m much happier with them now. Read More...

Tags: Construction, Administrivia, DCC, DC, Preiser, Electrical, Expressway, Backdrops, Subway

The first train ran tonight. As you can see, the table is still a bit unfinished. I added the legs and framing for the end that won’t have scenery, and put down the plywood for the subway level return loop. Read More...

Tags: Design, Construction, DCC, Unitrack, E231, Foam, Kato, JMRI, Digitrax, RR-CirKits, Zephyr, Backdrops, E233