Trip

I think it does put out a higher voltage, yes. Can you explain what you mean by 'the filters on the end'? I don't think I've come across that.

Change the connection type in JMRI preferences to Loconet LocoBuffer-USB (you've selected Locobuffer-II which is for old-style serial ports). Restart JMRI. Then go into preferences again and see if the available COM ports are reported differently. Did you set the loconet connection on the DR5000 to be COM 4? By default it's COM 6 I think.

As far as I know the only JMRI developer who has a DR5000 is yours truly. And I don't see this problem at all, it works out of the box for me. The COM ports are reported differently on my DR5000. What firmware version are you using on the DR5000 roundhouse?

This seems like a good idea. I'm following this thread because I have an issue with Cobalt IP digital motors losing their addresses occasionally. I recently switched from a DCS50 to a DR5000 command station and the problem become much more frequent. (I've since switched back, for the moment.) Obviously there's nothing a command station should be able to do that would cause the lost address but it's interesting all the same.

I also have a DR5000 and I use it with JMRI. You can safely ignore the connection instructions in the JMRI documentation and connect using the USB which is much easier. You need to make sure you have a command station type that can read/write CVs (ie. NOT the DB150). I use DCS100. Can you explain what you mean by "Track power is connected to the test track outputs of the DR5000." The only outputs on my DR5000 are the main output and programming track outputs. Is the loco you're trying to read from on the programming track? Which JMRI programmer are you using and in which mode? It would be very helpful to see a screenshot of the JMRI programmer and the output on the loconet monitor.

I have given up with a 6 Function DCC Concepts Zen 218 That particular decoder is awful. The older version (4-function) was fine but they burn out very easily. I'm gradually replacing them as they go pop with better ones. The new Bachmann is an ESU and it's pretty good, and quite cheap. I've been very impressed with Zimo and Lenz. Huge range of options and very responsive. The ability to 'turn off' inertia effects with a function button is great, for example.

I'm putting this here for future googlers. I got a DR5000 and plugged my watchmans (watchmen?) via a SSB-gateway into the loconet-T socket. When any of the sensors on the first watchman sent a HIGH signal there immediately appeared a contradictory LOW signal. When the train moved out of the block another LOW signal appeared. The other four watchman were not affected. Swapping out the DR5000 for my old DCS50 also solved the problem. I moved the sensors over to a new watchman. That solved the problem. Then discarding the 'faulty' watchman and programming the new one with the same sensor addresses (1-16) brought the problem back. The problem was this: the DR5000 ships with the S88 bus configured to think it's got 16 sensors attached. Since I had nothing plugged into the S88 bus those 'sensors' were always off. When sensor 1 on the loconet bus said HIGH the S88 bus said LOW and the LOW was sent over the loconet bus as well. The solution is to change the config on the S88 bus and tell it there's nothing there. Hopefully that saves somebody else the several hours of testing I did. Why on earth it ships with that config it is beyond my wit to imagine.

I have a problem with spurious signals apparently from a watchman and two different people have asked me about how stuff is grounded and I don't know. I have a PC connected via USB to a DR5000. The DR5000 is connected via loconet cables to: - a digitrax DB210 booster (I'm not using the track power from the DR5000 at all) powered by a DC power supply - a rr-cirkits SSB-adapter with its own DC power supply - a DCS50 in 'throttle only' mode with its own DC power supply The SSB adapter is connected via three wires to a chain of rr-cirkits watchman units. So: how are the watchman units "grounded"? (The watchman manual says make sure your Loconet Terminator is grounded. I have no idea what a loconet terminator is.)

DR5000 documentation is pretty poor. However, there's a Facebook group here which seems to be quite active and knowledgeable.

Well, this is going to make you laugh. (What I lack in knowledgeable contributions to this forum I make up for in comic relief.) The manual describes 'blast mode' thus: "Allows DCS50 to program decoders that require more power than in service mode." It sounded too good to be true! Elsewhere on the digitrax web site, tucked away in a knowledgebase article is the following stark, bold, but nevertheless quite well-hidden warning: Blast Mode Programming will program EVERYTHING sitting on the main line track so, you MUST remove everything from the track that you are not programming I suppose I should be grateful it hasn't reprogrammed all my turnouts and sig.... er.. back in a minute

Thanks very much Nigel and Andi. There is good news and there is bad news. I have been thinking about replacing the DCS50 for a while and looking through the switches for one that disables command station operation while leaving the throttle functionality I came across an option to turn on 'blast mode' programming for decoders that require more power. Thinking of your replies about the lack of power on the programming track being an issue I thought I'd turn that on and try again. It worked. I could read all the CVs in the problematic loco. That's the good news. When I came to write CVs, every write operation was accompanied by every loco on the layout shunting forwards slightly and the DB210 booster beeping as if it were being turned on and off. (This is with layout power off.) Then, operating a JMRI throttle for the Talgo moved every loco on the layout. Oops. I did a factory reset of the DCS50 and rebooted it and now it won't move anything at all. It still sends loconet messages when I twist the throttle, there's power to the track, but apparently no DCC signals are being sent. So, something of a pyrrhic victory. I've managed to program my loco but at the cost of my command station and all layout operations.

It's a Digitrax DCS50 and a Zimo MX634D decoder. I'm using JMRI to do the programming. However two other decoders (both Bachmann branded but one was actually ECU and the other was Soundtraxx) in the same loco also failed to read from the programming track but worked perfectly (being both programmed and operated) in other locos. The programming track works with all my other loco/decoder combinations. So that really points to the loco being the problem. However I'm assuming all that's required for a decoder to be programmed is a connection to right and left tracks via the wheels. The loco is certainly providing that or it wouldn't move. Odd.

I can't do a decoder reset because I can't set CVs I had thought of moving it to another loco and programming it there (which I'm sure would work) and then moving it back but I like to fiddle with momentum settings and speed tables quite a bit, experiment, fiddle more and so on. I have an automated layout where the combination of speed, momentum and timing is important for precise movement. All that would mean pulling the decoder in and out of locos quite a bit. So before I do that I thought I'd see if this is a situation those experts here present had come across before and had some suggestions.

I have an odd problem with one loco. When I fit a decoder it appears to be dead on the programming track. But if I move the loco to the main track and use address 3 it moves around fine. Programming it on the main track does not work. This problem is peculiar to this loco. The same decoder in another loco works fine on the programming track. It's an Electrotren Ave Talgo with a 21 pin socket. Any ideas?

Thanks gents. After checking with a multimeter I swapped out the AR1 with another one on a less used part of the layout and it works fine. I've got a solid state dual frog juicer on the way to replace the other one.

I have an AR1 switching a reverse loop and it seems to have stopped switching. A loco entering the loop is fine but when it exits the booster detects a short and shuts down. I've had this AR1 for two years and it's worked fine until yesterday. Power is still being supplied to the loop. Is it possible for a AR1 to fail this way? I have a single DB210 booster set to 5A.

For the benefit of future googlers DCC concepts have confirmed that the new Z218 6 function decoder has an issue a great new feature whereby any momentary loss of track power results in the speed being reset to zero and then slowly accelerating again. They didn't seem to think that was a big deal, which it isn't if you don't mind me buying other people's decoders until that issue is resolved feature is designed away.

Just a teeny correction to that: C++ programmers are not really in demand any more. Java certainly, and also C#. Easier to learn and just as much in demand are Ruby and Python. C++ has died a long overdue death largely at the hands of C# which makes far more sense.

And then set aside about three times that amount.

I have a bunch of Z18 4-function decoders and other than going pop from time to time (no overload protection) I like them. I bought 2 new Z218s and they have been updated to 6 functions. Both decoders were very slow to respond on the programming track and run a loco very hesitantly. Here are two videos of the same loco on the same track and the same throttle position: the top one has the new 6-function Z218 and the bottom one has one of the older 4-function versions. I bought a third decoder direct from DCC Concepts with the same result. I contacted DCC Concepts and they say they have not had any reports of problems with the new decoders. Any one else seen a problem with these decoders? I have a certain amount of brand loyalty to DCC Concepts because I have dozens of their Cobalt IP digital points motors which are brilliant for the price. Not sure I'll be using their decoders again for a while.

I use a desktop PC which is plugged in, but it sound like the ground path thing is a non-issue because I'm using the rr-cikits Locobuffer. Thanks everyone for your replies.

I bought a NCE DCC packet analyser to help debug a problem with turnouts intermittently failing to respond. I read the manual on NCE's site before buying it and sourced a DC power supply to fit into the 3.5mm jack on the unit. However, the version of the analyser supplied does not have a 3.5mm socket and indeed the manual that came with it has references to it removed. There are two other ways to power it and I'd like some advice on which to use: 1. From the track, using jumper sessions. This is not recommended, according to the manual, if there any chance that there is a "ground sneak path such as when a laptop is used". I have no idea what that means. I use a desktop PC connected to a DCS50 which powers the track using a Locobuffer. What's the 'ground sneak path' risk? 2. Via the NCE cab bus. This looks easy but there's no mention of what voltage the power supply should be. Given my recent record with 9v batteries I'm reluctant to plug something in there without being sure. Any ideas?

There are definitely no resistors between the top terminals, where I was reading 7.6v, and the bottom terminals (I measured the resistance across the contact that join them: 0.2 Ohms). Quite possibly there are resistors between the bottom contacts and the LEDs but I connected my 9v battery to the bottom terminals, not to the LEDs directly. Anyway, thanks for your replies gents. Now I have to work out how to extricate the lighting board...

I have a Bachmann class 150 with a DCC decoder fitted and the lights stopped working. So I opened it up to see if I could work out why. Exhibit A: The LEDs are near the bottom. The four terminals at the top are labeled with LED colours and +/-. When the lid is on those four terminals are connected to the bottom four directly - there are no resistors involved. Exhibit B, copper connections on inside of body: So I put my voltmeter across the top terminals and determined that there was 7.6v DC between some of them and by changing the loco direction and hitting the lights function I'd worked out that those were working as expected. So next I took a 9v battery and connected it across the bottom terminals labelled R+ and R- expecting to see the red LED come on. Which it did, once, briefly. Then I couldn't get it to work again. So I tried the yellow LEDs, same result. The white LED actually produced a puff of smoke when I connected the battery and it was at this point that I began to suspect all was not well. I measured the voltage across the battery terminals: 9.6v. Can the difference between 7.6v and 9.6v really mean lighting the LED vs incinerating it? Or have I done something more fundamentally stupid?

About two years ago I was in the same position as OP. After a lot of experimenting I ended up with a cheap second hand Digitrax DCS50 as a command station, a Locobuffer USB to connect that to a PC and JMRI as the software. For block detection I use rr-cirkits watchman and inductor coils. I use DCC Concepts cobalt IP digital turnout motors. With that lot I can automate everything I want including stopping at platforms. Loconet is a fantastic system, I'd need a very good reason to go with anything else. The only bit that might not suit is JMRI. I am a software developer and when I want to know how to do something in JMRI I find reading the code is actually less time consuming than reading the documentation. Sometimes JMRI doesn't do what I want and I write the JMRI feature I need and it gets included in the next release. JMRI is brilliant, and free, but but it's written by volunteers and quite difficult to understand.