Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1,002 Excellent

1 Follower

About Nigelcliffe

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There is also a mechanism in JMRI to import CV values for ESU decoders, thus saving the time doing the reading of thousands of CVs. Don't know if that achieves the objective, thus saving buying the LokProgrammer. The LokProgrammer is quicker than CV reading because it uses an ESU proprietary method to communicate with the decoder. - Nigel
  2. Your PowerCab (and layout) does not remember anything. Programming is setting (or reading) a value in a loco. Service Mode programming (program track) will set values to every loco on the track at the moment it happens. That's all Michael is suggesting. When finished with programming, exit from programming, and you're back to running the layout. Replace all the locos on the track, and run them. I repeat, its a lot simpler to understand with some extra bits to separate the Programming Track from the Layout (main line). - Nigel
  3. This is why I wrote "get a programming track, and get an NCE Auto-switch" - they separate stuff out, so programming is clearer - programming track for Service Mode Programming. In Service Mode Programming, you don't need to know the decoder address. You can read it back (it will tell you the address), and you can set the address without reading it if you wish. In Service Mode, anything you write goes to EVERYTHING on the track (hence "remove all locos" in your current setup), and you can only read a single decoder (so two decoders on the track, and the result of a read is chaos). In Operations Mode Programming (programming on the main), the address of the loco has to be known as the programming instructions go to that specific address. With Operations Mode, all other locos stay on the track. (The "Momentum" button on your PowerCab performs Operations Mode Programming changes to the loco under current control). - Nigel
  4. Rob, the Unifrog won't have issues with paint/ballast, apart from anything on the rail tops stopping the wheels picking up. Juicer won't be a problem here. All that might happen with too much paint is the train doesn't run (no pickup), there is no short circuit path, and no risk to the track. ( You may see short circuits from using PVA as ballast glue; its an acid, and conducts electricity. Usually this goes away when it has fully dried. ). Pickup problem usually occurs on top and inside corner of rails, which is a radius - use the ribbed side of a small bit of hardboard to clean track, its usually better than track rubbers. A bit of solvent on the hardboard may help. There are pages of internet stuff on "which solvent", so I'll skip that ! If my theory on the tie-bar of the electrofrog is correct, then paint/ballast around the blades increases the risks. Therefore I wouldn't use a Juicer on that combination because of the problem you saw. A switch associated with the motor movement will be fine; that can be the switch on the Seep, or if that proves un-reliable there are lots of ways of attaching a micro-switch to turnout tie bar movement. Small microswitches are very reliable if used correctly. If the tiebar and electrical switch are in the same orientation, there cannot be a melting incident from poor contact of the blade. If there is poor contact, the switch by-passes that contact, and if there is good contact, the switch is good. What must happen with any switch mechanism is either: a - single pole change over switch, must switch whilst blade is "mid-travel" (ie. not touching either rail). b - two on/off switches, must disconnect, have a "neither connected phase", then connect the second. This must not contradict the blade positions. Nigel
  5. The damage suggests a lot of current flowing, but not enough to cause things to shutdown. Question-1, what current are the Frog Juicers set to switch at ? If its not set the lowest position (2Amps), that is part of the problem. A possible explanation is the blades were a tiny bit dirty at the contact point, creating a local resistance. Enough to let say 0.5A to 1.5A flow, but not quite full contact to trip the "juicer" to switch. That creates a local hot-spot (1A at 13volts nominal DCC output = 13Watts, or very small soldering iron!). But its only a possibility, not a certain explanation. Yes, the Unifrog ought to be better wired for this purpose, you don't ever get the blades and frog fighting each other. Switching with the Unifrog+Juicer occurs via the pickups in a loco - as the driving wheels touch the frog, there is a path via the pickups between frog and fixed rails. In contrast, switching for the (unmodified) Electrofrog+Juicer ought to happen as blades close, but the high current melting at the tie-bar says this didn't happen, and instead there was resistance and heat. Can you stop this happening again with another Electrofrog and a Frog-Juicer ? The answer is "no" if its a "dirty contact" failure due to high resistance, but not enough to trip the Juicer. Other forms of switch are less likely to be "wrong" assuming the point motor movement is reliable. Just using the points as Peco intended (ie. no external switching of frog) avoids the risk completely, but with the risk of poor blade-rail contact failure. - Nigel
  6. Make yourself a programming track. Either fit a DPDT switch, or buy and fit the NCE Autoswitch to separate "main line" from "programming track". Optionally buy the NCE USB adaptor. Download JMRI and ..... In total, comes out at about the same price as a Sprog. Does slightly different things, so depends on aims. - Nigel
  7. A further router test would be to cable connect a laptop to the router's yellow LAN ports, and then seeing the DHCP address the PC has been allocated. If all is good, expect the Laptop to be given an address in the router's 19.168.0.x range. (command line "ipconfig /all" on Windows to find out the network addresses ). That would confirm a "good router" and "good cable". If PC networking skills extend far enough, could then run a server on the PC, and try connecting a wireless device (phone?) to the PC via the WiFi on the Router. Then, with higher confidence in the router, attention could turn to the Z21. - Nigel
  8. See simple edit of my post above with another diode circuit. That may do the job.
  9. Thanks Iain. Unfortunately the manual for the MP1 wasn't totally clear on that detail ! Something with a few transistors should be possible. Edit, think this does what's required. I'm fairly certain the blue diodes are unnecessary, and just a wire would suffice.
  10. Further thinking.... I think this may work. If you have two diodes around, its simple to try. I don't have a MP1 motor, so can't confirm it. But instructions imply it works with anything applied to the terminals. EDIT - scrub the above idea, Iain's comment below makes it clear the MP1 needs a particular polarity on the terminals, so it won't work.
  11. It should just be a simple relay to switch the power around from two-wire reversing to three-wire. The one's Iain refers to should work if wired appropriately. They're not as cheap as many relay modules(*) on Amazon/Ebay/etc.. but, if only two motors required, then paying extra may be worth it for a DCC dealer who'll support you. (* there are lots online, a four-relay module (so four motors) is between £5 and £8 from a variety of suppliers ).
  12. So far, very conventional DCC. You're delivering DCC to track, and "something" to accessories. That accessory signal could be DCC as well, just the same as your track signal, but on a different "power district" so not affected by track issues. Lets split the options for accessories into three main groupings: 1) - analogue, you just wire switches from a panel to devices on the layout, those can be turnout motors, or any other accessory device. No electronics, no digital stuff. 2) - broadcast data only over DCC. Here you need accessory decoders which read DCC instructions to change turnouts or signals. The data goes one-way only, from the command station in the middle out to the accessories. You can still have a real panel to control things, or a software diagram, but that panel has to talk to the command station. 3) - bi-directional communication with accessories. Here there is some feedback from the accessories as to their status to your central system. Has some uses for turnouts and signals, but is necessary if your approach to control needs detection of trains, occupancy of track, etc.. Within ( 3 ) there are a lot of options. There are proprietary bus systems from some makers (eg. Lenz has their system, NCE has a system, etc..). There is LocoNet, which is also proprietary to Digitrax, but has been licensed to a lot of other makers, so is fairly widely supported on DCC systems, and has a number of third-party manufacturers which offer "clever things" - its probably the most capable of the commercially available bi-directional systems, been around a long time so well tested, and is capable of operating hugely complex layouts (*), there's also a lot of DIY designs if into building your own electronics modules. There are at least two (probably more) CAN options, which are mutually incompatible, so you pick one and use it, you can't mix&match - the most widely used in the UK will be MERG's CBUS (DIY hobby club supported system), there is another system used by Zimo on their commercially available control systems. MERG's CBUS can work well, but you do have to be into hobby electronics to at least some extent to build the boards and to get it to work. Addressing your questions on "throttle congestion". Unless you're running a lot of trains, with a lot of operators, no it will never be a problem. The problem can exist in layouts with a large number of operators, often controlling multiple locos (eg. US outline "consists" with perhaps 8 locos pulling a train, and using consisting methods which are inefficient in that they duplicate commands to every loco). No, systems don't route DCC commands to different places (or they don't in normal setups, it would be possible, but people don't). The big advantage of an independent bi-directional system comes in feedback from the layout, which can be just occupancy (for signalling for example), or it can be tied to automated running. So, which to use ? Depends what you're trying to achieve. (* eg. The McKinley Railway, probably the most complex and largest OO model railway in the UK. Find it on YouTube ). - Nigel
  13. ESU have features in the LokPilot (non-sound) decoder to mimic the delays in a LokSound decoder for precisely that issue of starting delays. So, its soluble. Its in CV's 21 and 22, and the values set in those. They determine which function keys are played by the consist address, and which by the loco individual addresses. - Nigel
  14. Very roughly like this, but other parts almost certainly needed, such as pull-down resistors on the servo signal wire. Left hand side of drawing takes signal/0v from the servo controller. Right hand has power at/near servo. There is no need for the two power supplies to be the same, or the 0v to be common, though a common 0v is the usual arrangement. If the 5v to the servo comes all the way from the servo controller, it too may get noise on it.
  15. Most opto-isolators consist of four pins, arranged in two halves. The two halves are "input" and "output". The input side is a LED, just like any other LED, its polarity sensitive, and needs an appropriate resistor to control current. It is usually wired between signal (positive) and 0v of the transmitting end of the setup. The output side is a photo-transistor. Electrically its a transistor switch, with the switching (base) done by the photo-receptor inside the package (illuminated by the input LED). More likely to be wired between +volts and "signal" of the receiving end, though additional "pull down" resistors to 0v may also be needed.
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.