Reality Reduced Blog

LocoNet Testing

Tue, 29 Mar 2011 08:26:36 -0500

At the St Charles show a few weeks ago I found a number of odd LocoNet behaviors. Given my DCC in a Box was new, I worried that I had bad components or bad cabling that was causing the issue. I wanted to test, but quickly realized I did not have good tools for testing.

I come from a networking background. My day job is making the Internet (or at least the part I work on) operate smoothly. I’ve gotten used to tools like ping, and traceroute, and sniffers like tcpdump to figure out how my network is operating. LocoNet does not have a complete set of test tools. JMRI has the “LocoNet Monitor”, a sniffer of sorts, but that’s about it.

The great thing about JMRI is that it is open source, which means you can download the source code and modify it. I did just that, and went to work on some simple things in the LocoNet Monitor application. I added some decodes, made several much clearer, and re-factored some of the complicated code. I submitted this work back to JMRI, and I’m pleased to say it will be in the next version that goes out.

I kept coming back to the fact that there was no “ping” like tool. There was no way to generate traffic. I had a feeling that a number of the issues I saw only appeared under heavy load, which for me means only at an N-Trak show. I’ve been to dozens of shows with minor issues I just couldn’t replicate back at home. But now that I had the source and some experience doing modifications, I set my sights on something much larger.

LocoNet Tester

I call it LocoNet Tester. It started out to be a simple ping program, but as I thought about how LocoNet worked I realized it wasn’t that simple. Unlike IP where “ping” is more or less built into every device, LocoNet didn’t work that way. The result was two different sort of tests, which have slightly different uses.

LocoNet Ping is like the traditional ping used on IP networks. A packet is sent, and a reply is generated. The difference here is that one node must be designated to send the replies, as there is no way to address a specific device on the LocoNet. Basically you need two computers running JMRI. One is set to reply to LocoNet pings, the other to generate the packets. Drops and duplicates are counted, and displayed back to the user. The good part of this test is that with two-way traffic on the wire collisions are relatively likely at higher data rate, which makes this function very useful for testing the behavior of devices under heavy traffic and collisions.

LocoNet OneWay is a slightly different test. This can be a one-to-many test, with a source JMRI instance generating a sequence of test packets, and one or more JMRI instances receiving the stream of packets. This is much less likely (if no other devices are sending) to generate collisions, which may be useful for some tests. Also, by being one to many it is easy at a show to test multiple LocoNet segments (e.g. off splitters or LNRP’s) simultaneously by using multiple listeners.

This software isn’t quite ready to go, I would suggest my code is “Beta” quality at this point in time for a number of reasons. This blog post is referenced in a post to the jmri-developers mailing list where I hope to find some folks to review my code, check that I’ve done things properly, and suggest improvements. If you’re not a programmer, stop reading here and come back in a few weeks for an update. If you are, read on for the details.

Code Details

LocoNet tester is a separate mini-application on the LocoNet menu. There are really three interesting code paths:

1. Input packet processing. The code is always looking for a OneWay test, and if it sees one will reset the counters and start displaying the results. If the check box for ping replies is checked, the input code will also generate a ping response and send it out immediately. Note that LocoNet interfaces like the PR3 and LocoBuffer echo back commands, so the input routine will see any tests we generate. This is how we get local statistics for a test.
2. OneWay test generation. If the user selects and starts a one way test then a Java timer is set up to emit a packet every few milliseconds. This calls a routine to emit the packet.
3. Ping test generation. Very similar to a OneWay test, if the user selects a ping test we set up a Java timer and emit a packet every few milliseconds.

LocoNet doesn’t have a packet format, so I had to make one up. This is one of the areas that gives me some concern, as I don’t want to conflict with anything else out there but I don’t know the procedure for getting an assigned code.

Ping Test:
FF 0A 01 <sequence number> <magic cookie> <checksum>
FF 0A 02 <sequence number> <magic cookie> <checksum>

The sequence number/number of packets are a 32 bit integer encoded across 5 bytes not using the 8th bit in each byte. This provides a 7 bit clean set of numbers. The magic cookie is there to help distinguish this from some other FF op codes. The sender generates the “01” messages, and the designated receiver replies with a “02” message with the exact same sequence number.

OneWay Test:
FF 0A 03 <number of packets> <magic cookie> <checksum>
FF 0A 03 <number of packets> <magic cookie> <checksum>
FF 0A 04 <sequence number> <magic cookie> <checksum>
...repeat once per sequence number...
FF 0A 05 <number of packets> <magic cookie> <checksum>
FF 0A 05 <number of packets> <magic cookie> <checksum>

The sequence number/number of packets are a 32 bit integer encoded across 5 bytes not using the 8th bit in each byte. This provides a 7 bit clean set of numbers. The magic cookie is there to help distinguish this from some other FF op code message, should one ever exist, and is a simple constant. The message is 10 bytes long, to make doing the mental math on the data rate easy. I use “03” messages (always sent twice) to represent the start of a new test, “04” for the test data, and “05” (always sent twice) to represent the end. We send start and end twice in case we are testing on a LocoNet with issues in an attempt to generate a higher probability of success.

The following areas are where I am particularly interested in having people look around and offer feedback:

A. My use of Java timers. I’m not sure the method I use to generate packets represents the best practice and is compatible with the way the rest of JMRI works.
B. The user interface is quite basic, I’m not sure the counters are represented in the most useful way, or that the overall layout is pretty and intuitive.
C. It seems to me there is too much duplication in the code to generate ping and one way tests, and that in fact more could be folded together resulting in less code and more code reuse.
D. I have found a number of devices that appear to behave badly under load. Before I go bad-mouthing particular products, I want to be sure that I don’t have any code bugs, and that the results can be repeated by others. Testing on many devices with moderate to high packet rates would be interesting.

The Code

Since the code isn’t checked into JMRI yet, I have to provide patches. I’m making the code available in 3 forms, click on the file names to download...

1. Patch+Tarball against 2-11-13. The patch applies to the JMRI files in CVS, while the tarball represents files that are not in CVS, and thus CVS diff won’t create.

JMRI-2-11-13/java% cvs diff > ~/LocoTester.patch
JMRI-2-11-13/java% tar cf ~/LocoTesterNew.tar src/jmri/jmrix/loconet/locotester

1. Tarball against 2-11-13. This is simply all of the changed and added files in a single tarball, unpack over a 2-11-13 source tree and you should be good to go.

JMRI-2-11-13/java% tar cf ~/LocoTesterAll.tar src/jmri/jmrix/loconet/locotester src/jmri/jmrix/loconet/LocoNetBundle.properties src/jmri/jmrix/loconet/swing/LocoNetMenu.java

1. 2-11-13 source tree modified. Perhaps you are not a CVS developer, but still want to test. This is a tarball of the entire tree, ready to run.

workspace% tar cf ~/JMRI-LocoTester.tar JMRI-R2-11-3-LocoTester
workspace% gzip ~/JMRI-LocoTester.tar
workspace% ls -l ~/JMRI-LocoTester.tar.gz
-rw-r--r-- 1 bicknell 66188969 Mar 29 09:09 /Users/bicknell/JMRI-LocoTester.tar.gz

Address 00 Surprises

Sun, 6 Feb 2011 13:32:46 -0600

Most DCC users are aware that Address 00 references a sort of compatibility mode that allows a DC locomotive to operate on a DCC track. Probably only a few folks are aware of how that actually happens. The DCC signal looks like a set of low and high pulses to send a computer signal from the command station or booster to the decoder. The decoder interprets these pulses, decoding the signal into a series of commands. To make an analog locomotive work these pulses are distorted in a way that makes the analog motor see a voltage difference, and thus makes it go.

I found on the web some DCC waveform graphs put up by Jim Banner where you can see the exact behavior on an oscilloscope. You can see how the pulses get longer and longer to try and make the analog motor go faster and faster.

If you read the DCC for N-Trak Layouts document produced by the North Raleigh Model Railroad Club they strongly recommend disabling the address 00 feature. The relevant section is on page 30:

It is very important that analog locomotive operations be disabled (OpSw#20 = c) and the speed of address 00 set to 00 during normal layout operations. The stretched pulses generated when using analog address 00 consume system bandwidth rapidly as the speed of address 00 is increased.
The pulse width of normal DCC pulses (OpSw#20 = c, address 00 speed=00) is 95μS. Analog operations allow this 95μS to be stretched up to 12000μS, which means that fewer packets can be sent per second, thus cutting bandwidth and slowing response to throttle commands.

Typically I keep address 00 disabled, partly due to this advice, but also because I don’t like how hot my analog locomotives get in this mode, so I don’t use it. While at the show the Gateway folks asked me to enable this feature, as some of their members had DC only locomotives. Figuring it was a small layout, and since it was Gateway’s layout I was happy to oblige.

What we saw latter was two weird behaviors caused by having address 00 enabled. It was quite confusing at the show, as I had not tested for this at home, and the problem seemed to come and go mysteriously. We now know that the cause was an address 00 user choosing to go faster or slower, but you can imagine the confusion when you don’t have that knowledge.

The first weird behavior came from the meters in the box. The RRAmpMeter’s sense the DCC signal, and use the presence of the signal to both light an indicator and also to change the formula used to calculate the voltage. When the signal is stretched too far they stop seeing the signal as a DCC signal, flipping their indication over to AC. This also causes the formula to be changed to a straight AC formula, making it seem like the voltage has rises on the rails. There were even a few times when the speed would be just right that they would flip back and forth between DCC and AC mode quite quickly, making for a flashing effect.

If you stop and think about that for a moment, you can see why address 00 is bad. The RRAmpMeters are listening to the same rail signal that the decoders are receiving. While it appears the RRAmpMeters are more sensitive than most decoders, the fact that they are losing their lock on the DCC signal is troubling. Are the decoders on the layout having the same trouble receiving the signal? Probably, but it’s hard to say for sure.

The second weird behavior involved my LocoBuffer-II. You see, I have the older serial version, not the new USB version. Serial ports don’t put out any power, unlike USB ports. The serial version needs power, and it can either get it from the LocoNet, or from a wall-wart. My box was designed so that the computer plugs directly into a port on the command station, and the other port on the command station goes directly into an LNRP. I know drawing power for the LocoBuffer from the LocoNet was probably not the best idea, but I reasoned that it was the only device drawing power, and so everything should be ok.

The problem is that the Rail Sync lines on the LocoNet are a mirror copy of the signal being sent out to the rails. The same stretching behavior occurs on those pins. The voltage on the LocoNet should be between 5 and 7 volts, and is in that range when address 00 is at 0 speed. However as the speed increases, the effective voltage on the LocoNet decreases. Unloaded it drops into the mid-four volt range, loaded it can drop even further. This lower voltage reduces the amount of power available on the LocoNet.

This probably wouldn’t be an issue, except it turns out the LocoBuffer-II draws 30ma from the LocoNet, when the spec only allows 15ma of draw! This was something I didn’t know until I had researched this problem after the show. The result is that when address 00 hits a speed of about 40-50% the LocoBuffer no longer has enough voltage to power it, and it drops out. Watching from the computer you simply stop seeing all LocoNet messages, as the LocoBuffer is no longer powered.

The fix is easy, with my serial version I just need to take the wall wart, plug it in and draw no power from the LocoNet. Everything works fine, even with address 00 at a speed of 99. Another fix would be to use a USB device, like a LocoBuffer USB or a Digitrax PR3 as they can draw their power from the USB port.

Now you have a picture of the strange behavior that confronted us at the show. RRAmpMeters blinking and showing weird voltages, while the computer is unable to talk to the LocoNet anymore....and yet everything appears to be working normally! People are running trains, LNRP’s are not showing any errors. It can be quite confusing if you’re not prepared for the situation.

However, the reality there may have been any number of bad effects going on under the hood:
• A LocoNet that had enough power for devices without their own power, like my LocoBuffer, or unpowered UP5’s may not have enough power when address 00 is at a high speed. This would appear to be a works sometime, doesn’t work sometime LocoNet.
• Decoders may have had a hard time reading the DCC signal, resulting in poor response.
• The LocoNet appears to be busier when the stretching occurs, which may result in slow throttle response.
• Diagnostic tools like the RRAmpMeters may not work as expected.

While I probably will be turning address 00 back off on my command station and recommending strongly not to use it in the future, I’m glad the Gateway folks had me turn it on so I could discover this and document it. There’s plenty of advice out there not to use address 00, and there are some vague descriptions as to why, but a limited amount of practical, here’s how some things might break examples. I hope by showing in the video above some of the effects it will make the problems of address 00 a bit more real and obvious.

The good news in all of this? Well, the box worked great! The layout ran, and neither those running trains nor the general public knew there was anything amiss. While I need to document some of these problems and be ready for them, it’s just a user education issue. The design has been validated with real world tests.

St. Charles Missouri Great Train Expo!

Mon, 31 Jan 2011 08:51:13 -0600

On January 29th and 30th I had the pleasure of setting up with Gateway N-Trak at the Great Train Expo (GTE) show in St. Charles, Missouri. This show was also very important to me, as it was my first opportunity to have my DCC in a Box run an entire layout!

My DCC in a Box setup performed quite well, but we did learn a few things about the box and about DCC in the process. I’ll be posting a separate video in a few days with some more details on the technical aspects.

This show had lots of N Scale! Gateway had a nice sized N-Trak layout. The Mississippi Valley N Scalers club had a separate N-Trak layout. There was a T-Trak layout set up by some of the guys affiliated with Gateway as well. Add in an Lionel layout, two nice HO layouts, a rare S scale layout and even Lego for a show with plenty of displays! I wish all of the traveling shows could have this many different layouts. 
You know, I always get requests for “more trains” in the videos. I am listening, but unfortunately I have failed again. At the good shows there are a lot of people around. That makes my best time to shoot video the hour before the show opens on Sunday, when there aren’t a lot of trains running. I’ll generally try and catch some during the busier parts of Saturday and Sunday, but I was kept fairly busy with my DCC in a Box this time. I know, that’s no excuse, and I’ll try and incorporate more trains, but I also want to show off as many of the amazing modules as possible and the only way to get good shots is when the people aren’t around!

Anyway, watch the video for a tour of our layout and a glimpse of what was at the show. Make sure you go out and support your local train show, and also support me by subscribing to my YouTube Channel.

Power Management and Feedback

Wed, 26 Jan 2011 10:12:04 -0600

The DCC in a Box system was built for capacity. The DB200+ 8A boosters can run a lot of trains in N scale, but they can also be dangerous. 8A can be enough to “weld” the rails if just the wrong thing happens and the circuit breakers don’t trip.

DCC circuit breakers are the solution. I happen to like the PowerShield X or PSX series, available in 1 to 4 unit modules. Indeed, the 2-4 unit modules are just the PSX-1 repeated on the same circuit board, they are even scored so you can break them apart! Need four PSX-1’s, buy a PSX-4 and break them apart. The other cool thing about these units is they can be programmed to respond to switch commands to turn the power on or off which will show up on the JMRI panel. I think the thing I like best about these units is they are 100% electronic, but they are also very flexible units with lots of configuration options and plenty of external inputs and outputs.

It is those outputs that will let us do something really cool here. My “remote” box is a PSX-4, allowing me to run a cable out from one booster to the box and then power the Red, Yellow, Blue and Green N-Trak lines each via their own breaker. But this box is going to be physically remote, so I need a way to centrally see the status. The outputs will let me run the status into something that speaks LocoNet, and a Digitrax DS-64 comes to the rescue.

Most folks think of a DS-64 as a switch machine driver. That’s a great use for the box as well. However I’m interested here in its 8 inputs, and ability to use them to report general sensor messages. It’s the cheapest box I could find for 8 sensor inputs. Each of the PSX-1 units has an output for “block occupied” and “block shorted”, we’ll run those into the DS-64.

Wiring is simple. I use DCC track power to power the DS-64, as when it is not driving switch machines it uses very little power and this means I don’t need more cables and power supplies. A common wire comes out and hooks up to the positive sensor terminal on each PSX-1. I then run the negative side of each sensor terminal to one of the 8 inputs on the DS-64.

The DS-64 is given an address, which determines its sensor numbers. I’ve built a simple panel in “Panel Pro” (a JMRI tool) to display the status on the screen. Here’s a screen shot:

The first colored icon is the track status. Green is no trains present, for example the red and green line outputs. Yellow means a train is present on that track, which is shown on the yellow line. Red indicates a short circuit, the blue line is shorted here. These are updated in real time by the DS-64. Next to that are little power button icons. These issue switch commands directed at the PSX units to turn an individual segment on or off. Green means the segment is currently on, here the red, yellow and blue lines. Red means the segment is off, in this case the green line.

Now from a centralized point I can monitor the layout by looking at the RRAmpMeters and other lights on the box itself and also monitor from my PC, knowing instantly how many blocks have trains in them and if there are any shorts anywhere on the layout! As you might imagine, on a large N-Trak layout it’s a huge win to have a central monitoring console. Plus, if there are runaway trains or other problems I can disable individual segments, no need for the global power off button. This sort of central control isn’t often done due to the setup time required, but by pre-building all of this at home I have reduced the show setup time to almost zero, which makes central monitoring quite practical.

I still need to learn some things about JMRI. I would like to be able to play a sound when a short occurs to provide an additional alert. I’m also going to make a “Layout” view, so you can visually watch the layout in that form. That’s all software though, and can be easily played with over time.

It is now I can claim my DCC in a box is “done”. There are a few minor loose ends, like cabling up the other two PSX-4’s and DS-64’s when they come in (they are on order) and figuring out how to pack everything nicely for travel, but those items won’t be worth reporting on in the blog. I do promise to make a video when I finally get the box out to a show!

DCC in a Box, The Final Solution

Mon, 24 Jan 2011 14:35:44 -0600

It’s been a while since I wrote about this project, but I owe everyone the final solution. With the help of some great folks from online, in particular TwinDad from nScale.net I was able to come up with a very nice, but not quite perfect solution.

The answer ended up being a fairly simple circuit, seen here:

The theory of operation is fairly simple. When the circuit is turned on R0+R1 form an 11 Ohm resistor that limits the inrush current. I had to use 2x22Ohm because finding an 11 Ohm resistor is really hard. In our case this charges the input capacitor bank on the boosters. As the voltage in the bank rises the Zener diode D1 begins to conduct, charges C1 for a small amount more delay, and eventually turns on Q1. This causes R2 and R3 to split the voltage to a point that Q1, a high power MOSFET turns on, bypassing the 11 Ohm resistor with a low resistance path for the current to flow.

I ended up creating a circuit board using software from ExpressPCB and using their service to produce 20 boards. Here’s the design I came up with...
livepage.apple.com
Top:

Bottom:

Silkscreen:

The finished board looks something like this:

With a little bit of soldering and testing I ended up with boards that looked like this:

And finally, installed in my box:

Everything now works as I originally intended. You flip the switch to turn the box on, the power strip energizes, the boards limit the inrush current, and the boosters all come up just fine!

Still, many of you are probably thinking I’m crazy, and frankly, you are right. A sane person would have switched to a power strip that used a good old manual on/off switch and avoided all of the issues with the soft switch. That would have really beat up on some of the components, but probably would work just fine. Aside from the time, what did this solution cost?

Well, the circuit boards were $308.98 for 20 boards. So far I’ve attempted to assemble 10, destroying 2 in testing leaving me with the 5 I needed and 8 spares. There was another $100.17 in components from Digikey, enough to make 10 boards. So in total I spent $409.15 on 8 working boards, or $51 per booster to fix my problem. Yes, I am insane.

However, if we look at what this would be in a more reasonable quantity, at a run of 50 the boards would have been about $8 each, and the components about $9 per board. So in theory this problem could be solved for more people for around a cost of $17 per booster, if folks were interested.

Now that I have forged this path I would not recommend others follow it exactly. Put your DCC system in a box, but power it slightly differently! I’ve also provided feedback to Digitrax through this process, I still don’t think they did anything wrong but that doesn’t mean they can’t do things better! Some day they will design a new generation of boosters, and I’m sure they will keep in mind some of the problems that I had during that process.

There are a few more steps that need to occur for me to have a complete system. I am still working on the PSX-4 “remotes” that will go with the box. I will try and post an update on them quite soon. As soon as I can get the box in a show, I’ll make a video of it in action.

It was folks on the forums that got me through this project. I couldn’t have solved my problems without help from folks online and from Digitrax, and I wish to thank all of them. The forums are some of our best resources as modelers, out there is someone with the expertise we need to fix our problems.

HDR goes mainstream...

Wed, 8 Sep 2010 12:56:00 -0500

Taking pictures of models can be difficult. The lighting doesn’t always cooperate, and physics can really make things hard. Fortunately, technology has come to the rescue! There have been two technologies floating around that can make a big difference, HDR imaging, and focus stacking.

Today is HDR’s day.

Previously these techniques required a DSLR with manual controls, or perhaps a high end point and shoot with the right controls. The photographer had to take multiple images and spend a few minutes to a few hours working with the software to produce the desired results. I knew though that since this was all software, that it would get better over time and eventually be found in a easy to use consumer form factor.

Apple released IOS version 4.1 today which brings a number of new features to iPhones and IPod Touches. The most interesting to me is the inclusion of “one button” HDR photography on the iPhone 4 platform. The iPhone 4 came with a greatly improved camera compared to older models, which I think finally enabled the level of quality necessary to do HDR on the phone.

What this means is consumers now have one touch HDR imaging in their pocket. What used to take special equipment and hours of work can now be done with the press of a button on your cell phone. Have a scene on your model railroad with some challenging lighting? Give HDR a try.

I’m sure others will follow Apple’s lead. I suspect within 5 years we will see features like HDR, Focus Stacking, and Panoramic Stitch in almost all mid to high end consumer cameras. It will enable all of us to take amazing photographs which would not be possible without loads of technology, and best of all to do it with minimal effort and thought. I expect the quality of photos people take of their models will rise as a result, and increase the popularity of sharing photos of your work online.

I’m sure what you really want to know is how much better the images look, well, let me give you a side by side. The first image is a normal image as the phone would normally take it; the second the HDR version:

Both images were taken with no flash, in a poorly lit room. I specifically want to challenge the camera. I set the phone to keep the normal exposure, so these were both taken from the same button press. The phone actually took 3 images, and combined them to form the HDR version.

Notice down the left side towards the warehouse and semi-trucks that the HDR image was able to even up the exposure. In the HDR image it looks as if the room is evenly and well lit; but as the first image shows it is not. Also note on the HDR image you can see the power lines along the mountain line, if only faintly. That detail is lost in the standard exposure.

It’s not perfect, but it is easy. Under challenging lighting, as can be present at many train shows, I suspect this feature will make a huge difference.

Your turn, take some photos and share them!

Kato P42 MRC Sound Decoder Installation

Sat, 21 Aug 2010 08:28:48 -0500

My box is done, I have found a solution to my capacitance problem. I am testing a few last details, and then need to shoot some final video so I can show you the finished product.

In the mean time, I thought I would share a decoder install. The box does no good on its own, you must also have DCC locomotives, switches, signals and other items to get the full benefit. I thought what better way to show off what DCC can do than to show a sound decoder, which is exactly what I do in this episode.

My Amtrak train is my only passenger train, and it’s pulled by a single Kato P42 locomotive. I figured this was a good place to get my feet wet with sound, there are near drop in decoders for this locomotive and it’s a nice simple train everyone likes to see. After reading some of the forums I decided on an MRC sound decoder; there is still a lot of new development in the sound decoder space and I expect it to heat up in the near future for a number of reasons. I think we may even seen factory sound from major manufacturers soon.

Anyway, watch the YouTube video to see the decoder go in, it’s really quite simple. At the end of the video is a treat, the decoder in action. Listen for yourself and decide if sound in N scale is worth the cost and trouble. This does demonstrate some of the things you can do with a DCC system that just can’t be easily done with DC though, perhaps some of these features will make you take the plunge.

Too Much Capacitance

Tue, 6 Jul 2010 16:31:36 -0500

As documented in my last blog post I have a problem. It turns out I have an incompatibility between my RIGrunner 4010S and my Digitrax DB200+.

Let me first lay out all the documenation:

• RIGrunner: Product Page / Documentation
• Digitrax DB200+: Product Page / Documentation
• International Rectifier IPS0551T Data Sheet

The RIGrunner uses the International Rectifier IPS0551T as a switch. This product was designed to be used in this way, and is not a plain MOSFET but rather has integrated logic to make it ready to use as a switch. One of these bits of integrated logic is an over-current detection circuit which is being tripped in my application.

After describing this configuration to the guys at Digitrax they replied that there was about 12,000 μF of capacitance in each DB200+ booster. I took the cover off of my booster and in fact find a pair of 8200 μF capacitors, so I think the actual amount may be closer to 16,400 μF! I can’t be 100% sure, it the power input side appears to be a fairly simple arrangement. Power goes into a bridge rectifier, and then is buffered by the two capacitors to provide a steady output.

What I believe is happening is that when first powered on the capacitors draw a large inrush of current in an attempt to charge. This may in fact exceed 100A for a few microseconds, or it may just be a high enough inrush that it is fooling the current sensor in the IPS0551T. In any event, I can do this with a single booster, so there is no way I’m going to be able to power all of them on at once.

In an attempt to prove this was the problem and find a temporary work-around I used the automotive tail light in series trick. Visually this shows the inrush current, and it does provide a work around. It’s not a very elegant solution. So what are my options?

1. Replace the capacitors inside the DB200+’s. They are far larger than the need to be, no doubt designed to handle the wide range of inputs and potentially dirty power these boxes may see. My battery feed situation here though is about as clean as power can get, and thus the large filter capacitors are unnecessary. I’ve rejected this though as I don’t want to void the warranty, and want to be able to swap these in the field with factory units if they fail.
2. Install automotive tail light bulbs on each unit. A cheap work around, however they zap a lot of the power going in, and I’m not sure I can get one that will handle the 8A load into the booster. It’s a great solution for testing, but not a good one for production.
3. An inductor. This was my first idea, use an inductor to limit the inrush current. Unfortunately to be able to handle an 8A booster the inductor required is enormous and expensive. It’s just not practical at these amperages.
4. A thermister; or thermal resistor. This is a resistor that starts at a high resistance and as it heats up has a lower resistance. It would work, but has the “hot reset” problem. If a booster were to loose power the thermister would have to cool down before it would allow things to restart. Prematurely restarting would shut down the entire box.
5. Design a circuit to work around this problem.

I took a stab at #5.

Power comes in on the left, and leaves on the right. The bottom line is the negative connection and goes straight through. On the positive side current passes through a 15 Ohm resistor before leaving. This limits the inrush surge to under 10A, which is the fuse rating on the outputs I’m using.

However, you don’t want to keep running through the resistor and generating heat. A variable resistor, R2, controls how fast a small capacitor charges, C1. As it charges it ramps the voltage on a MOSFET, Q1, slowly allowing more and more current to pass via the MOSFET. Once the capacitor is fully charged, all current will take the lower resistance path through the MOSFET to the output.

My idea is to put this on a small circuit board with board mounted Power Pole connectors on the input and output. I’ll literally be able to plug one inline with each booster and adjust the variable resistor. I’ve created the following parts list (all part numbers from Mouser):

1 Q1 - STP16NF06 - 60V, 16A, TO-220
1 R1 - 280-CR15-15-RC - 15 Ohm 15W Wirewound
1 C1 - 140-50U5-104M-TB-RC, 0.1uF ceramic disc
1 R2 - 858-36PR100KLF - 100k-1,000k Ohm variable resistor
4 Powerpole 25 Amp Right Angle Contacts "G1"
2 Powerpole 15/30/45 Red Hoods
2 Powerpole 15/30/45 Black Hoods

However, I’m pushing the limit of my electronics knowledge. I attempted to calculate the right values for the resistors and capacitors and design a good circuit, but for all I know I’ve done a lousy job and this won’t work at all. That’s why I am posting the details here and soliciting input. I need your help to design a good circuit.

Feel free to toss my idea completely out and propose some other method. If you think I rejected one of the methods above when I should be considering it, let me know that as well.

I would like to point out this is probably part of (maybe all of) the reason Digitrax does not recommend powering multiple boosters with a single power supply. The inrush demands are large. Unfortunately this isn’t directly documented, so I had no real way to know in advance. This may also be of interest to folks using Digitrax products with “laptop” power supplies. These devices are FET based switching power supplies, and may not be designed to supply the huge inrush currents the boosters can demand.

I would like to thank the folks at West Mountain Radio, they took a bunch of their time to deal with someone using their product for a new application and helped me figure out the problem. They also were able to provide me the part number of the MOSFET inside so I could get the data sheet. I don’t think they had ever seen one shut down like this before, since the unit is rated only for 40A. The 100A limit was so much higher they had all but forgotten about it.

Digitrax tech support also gets an A+ for a fast reply with the capacitance issue once I reached their technical team.

I’m hoping the power of the Internet can help me solve this problem, if you can help, please post!

DCC in a Box #6 Complete!

Mon, 5 Jul 2010 17:45:04 -0500

At long last, the box is done. Well, done with two caveats. Eventually I will have to add two more DB200+ boosters and I will need to create some more remote circuit breaker pods and the cables to hook them up. Still, for the definitions of documenting this project it is complete!

I had to break the video into two parts. YouTube has a 10 minute limit, and I exceeded it. Normally I hate doing that because I think people just don’t sit through longer videos, but this time I just had to do it. I wanted a fairly detailed overview of everything that is in the box.

The features, at a high level:

• 35 Amp (27 continuous) power supply, Astron RS-35M.
• 40 Amp battery charge controller, Super PWRGate.
• 45 Amp-Hour AGM “Security System” Battery.
• RIGrunner 4010S DC power strip with electronic switch.
• DCS 100 Command Station
• Four DB200+ Boosters (2 installed).
• 4 RRAmpMeters
• 1 “Command Station” LNRP to protect the command station from the layout.
• 1 “Loop” LNRP to protect the backbone from the loop.
• UR91 Simplex Radio for Digitrax wireless throttles.
• UR92 Duplex Radio for Digitrax wireless throttles.
• UP5 Panel
• Two fans to control temperature, one powered directly from the power supply the other powered off the battery so that one is always on.
• “Power On” and “On Battery” indication lights.
• External LocoNet connections for the loop ThrottleNet, a PC, and the LocoNet backbone East and West.
• All plywood construction, stained and polyurethaned. Protective covers front and rear.
• Two fixed and two swivel castors to make moving easier.
• Four track outputs.
• One programming track output.
• One 5A white line output.

There are some accessories that go with it:

• White, Red, Yellow, Blue and Green “T” cables to connect to the layout.
• Three 30’ extension cords to connect it to the layout.
• One programming track.
• One PSX “four pack” of DCC circuit breakers, still in testing.

Eventually more circuit breakers, T cables, and perhaps more extensions will need to be built to travel with this beast.

I’ve produced a “one line” drawing: (Or, download DCC One Line.pdf)

A project like this is a bit on uncharted ground, and no matter how well you plan there are always some lessons learned in the process. Let me review a few of the things I learned:

• The cabinet should have been larger. It’s not tight inside, but it’s not quite as roomy as I would have liked. A few more inches would have made a big difference.
• Digitrax boosters have a large amount of capacitance on their input side which can cause a number of issues with your power supplies and equipment. Indeed, I will be doing a whole separate blog post about this issue as it is highly technical and I have not fully solved it yet.
• Each of the Digitrax small panels (LNRP, UP5, UR91, UR92) have a “Track Status” light. In my current configuration they are all off all the time. There’s really no reason to connect them, as with the RRAmpMeters we get a much better status output. I do wonder though if some folks will miss them, and have considered wiring them all up to the command station track output simply so they are on.

Now that it is done, I would love to hear your comments! What do you think? How could this be improved? How would you have done this differently?

I hope you found this project and the videos useful, and I hope if we end up in a layout together you find my box a reliable way to run the layout!

DCC in a Box #5 Assembly

Thu, 10 Jun 2010 20:33:30 -0500

The day has come to put it all together!

I am taking my time with final assembly, trying to make sure everything fits perfectly. Most of it is quite boring, but I tried to select some interesting video for you. I’m really trying to make this look pretty, both because I just want to take pride in what I did, but also because I will be using this at home and want it to look more like furniture than “train stuff”.

While I did hours of planning, there are always details that don’t come out until final assembly. For instance, the method I was going to use to secure the power supply ended up being way too close to the edge of the box. So I had to come up with a new method during assembly. Such is the case when building one of a kind, or initial prototype devices.

There are a LOT of connections in this box. That’s part of why I did this project, I didn’t want the connections to be set up and torn down at every show; but as I run all the connections it really hits home. I used 5 or 6 packages of cable clips to organize and hold down all the cables. However the inside is neat and tidy.

Anyway, I ran into an issue with the RIGrunner. In the video I thought it was bad, and sent it back. However, it tested fine for them when they got it back. We discussed several things that might be wrong with my setup, and I tested them all, no issues found. They are sending me a new one to try, and have been very helpful understanding how it works and what to look for as I test. It’s really a dead simple device, so it should just work. I either ran into one with a strange failure mode, or something about my application is interacting with it badly.

I’ve committed to get to the bottom of it though, and will install the replacement and do more testing as soon as it arrives. The guys at West Mountain Radio have also said they would help in any way they can. They have sold thousands of these with virtually no issues, so they are curious as well.

Anyway, I’ve been using the box with a RIGrunner 4005 I had laying around. I had to make a couple of Y Powerpole cables to get everything powered, but it’s working good. It’s allowed me to start on the next phase, installing and configuring decoders in all of my locomotives. I’ve already recorded two videos about installing decoders, so you have that to look forward to in the future.

The next episode will be the great unveiling, and I’ll show you all the features of this cool box!