Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

754 Good

Recent Profile Visitors

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

  1. 1 - many, but not all, systems have a way of sending an "E-stop" signal to the track. This tells every decoder "stop now, regardless", and any decent decoder will just stop instantly, ignoring deceleration settings or any other factors. This is a DCC emergency stop instruction, rather than removing track power. 2 - assuming your decoders are of reasonable quality, then there will be a CV setting to limit the run time of the decoder on stay-alive without a DCC track signal. Set this to a sensibly short time - say 1 second or so. That's enough for any loco to sail over a pickup problem, but should be enough to cause it to stop if it actually looses track signal from either a derailment or because the track power has been turned off.
  2. As with non-sound, you need a decoder which fits the socket, and can support servo control on the logic-level outputs. Two main players, ESU and Zimo, both offer servo control if appropriately configured in the sound project loaded onto the decoder, or with end-user CV changes.
  3. Yes, JMRI works for Zimo, ESU, (and just about every other decoder maker). The ESU decoder interface presentation is very similar to that in the ESU LokProgrammer hardware/software. So, for CV changes, I'd suggest that a LokProgrammer is an unnecessary luxury. The Zimo decoder interface is a little messy, though it all works. This is because it has grown as Zimo have added new features over more than a decade. It could do with someone to sitting down and re-working it. For Zimo, ESU (and that matter any other maker offering the ability), if you want to load sound files onto a decoder (as opposed to change CVs), then you need the decoder maker's specific hardware to do it. - Nigel
  4. I've no idea which decoders Tweak & Drive works with - ask John Gymer at YouChoos, he's a decent chap so I'd expect him to give you a clear answer. The question you asked was about the Lenz Gold structure Iain mentioned, and whether it was any use for an ESU decoder. The answer is no, it won't be any use for ESU. - Nigel
  5. ESU chips have a very complex CV structure, using indexing to access various values (ie. you can't say "CV456" because that can control many different things depending on the values of the associated index variables). The Lenz Gold information would be useless for setting up an ESU decoder. It took someone about a year to code the JMRI stuff to handle ESU chips, and the interface for it is just about identical for function mapping to that in the ESU LokProgrammer hardware/software combination. - Nigel
  6. Assuming these "relay boards" are the typical Ebay/Amazon units, how have you connected the various jumpers around powering them? The relay coils can take power either from the Arduino (typically via the header connection where there is +, Gnd and a row of data pins for each relay on the board), or from external power. You might have been better controlling the high current CDU from a Mosfet, or similar high current transistor switch (also available as a cheap Ebay/Amazon pre-made board), rather than a relay board. The Mosfet can stay active as long as your Arduino output code wishes it to be. Servo motors, different kettle of problems, which you solve with similar approaches to isolating the causes of noise. - Nigel
  7. "resistance of wiring" isn't going to lead to over-load of a chip. What leads to overload is "too little resistance" which results in too much current. As Pauliebanger said above, there are a lot of circuits in the loco and the pins for PluX and MTC21 are different. As you're re-wiring them, are you doing it correctly, or properly isolating things which are no longer connected ? - Nigel
  8. In principle yes. Before you jump, a few things: 1 - hardware. JMRI supports a lot of DCC hardware, so Sprog is one of your options. As are dozens, if not hundreds of other systems (unfortunately, a lack of documentation from Bachmann about how the Dynamis interface works, and probably a lack of interest in the JMRI development community means that the Dynamis is one of the few systems which isn't supported). The Sprog, as you no doubt know, is a computer device with no external physical throttles. If that suits your needs, fine, but many people find a physical throttle useful. You do have the option of using a phone as a throttle onto the Sprog hardware. 2 - Sprog size - I'd suggest a Sprog2 is more than adequate for the size of N layout you have. The only difference to Sprog 3 is "more current", which requires a bigger power supply, and slightly more robust wiring. If you do go for the Sprog plus JMRI, then: Find out about "profiles" within JMRI. I'd suggest you will want two profiles, one which might be labelled as "run my layout", and another which might be labelled as "program my locos". In the process of creating the profiles, you might want to make them use the same file storage for items, such as the roster (the saved decoder list) so that you can share things automatically between programming and running. Within each profile, you can then setup the Sprog for each of its operating modes: Command Station (to run the layout) and Sprog (for programming track tasks). Computer. If you're using a Windows computer, you may need to faff with the power management settings to stop Windows putting things into "low power" mode (ie. turning them off) to save power. In particular you don't want the USB to the Sprog to be "low power" or "turned off" whilst running JMRI, otherwise you just loose control of the Sprog and have to quit everything and startup again. - Nigel
  9. In this case, no, its not that regular 30-year old confusion. The ECoS requires Java in a Browser, which requires a browser which supports a Java plug-in. Apple withdrew that option from Safari some time ago. An alternative approach would be to use a third-party train control application which runs on MacOS, which would include JMRI and iTrain. Both could control track panel diagrams, run locomotives, and more. Yes, those two are both Java applications, but they are "applications" (so nicely constrained from an operating system security/integrity point of view), so not trying to run a Java plug-in inside a browsers (which has been known as a potential security hole for a long time). - Nigel
  10. As St.Simon says he's using Digitrax hardware, RailCom gets a bit more complicated. It is possible to get a short cutout into a Digitrax track signal (enough for identifying a single loco/decoder within a detection area), but not the long cut-out. The long cut-out can do a bit more, but probably not needed for just train ID. To generate the cutout requires third party hardware either before or after the Digitrax track booster(s). I have a Digitrax command station, and have the hardware for cutout and decoder identification all working. Nigel
  11. ESU's manuals say the remote client uses Java. So, you need a Java plug-in for your browser. I don't know what rules Apple impose on their customers to stop them using 3rd party stuff, so talk to an Apple Genius. - Nigel
  12. As your friend sensibly advised, Zimo make superb decoders, and some of their range is available at a decent "mid-market" price of around £20. What you need is (a) the right number of pins, and (b) enough current to handle your locos. Hornby and Bachmann are usually OK on current draw, so no issues there (unlike some Heljan which can need higher current decoders). Then just pick what has the right connections and a good price. Within the Zimo £20 range include: 8-pin is also called "NEM 652" after then standards body/number for it. Zimo MX600R (R= NEM652 in Zimo codes), other options exist 6-pin (more common in N, but in some smaller OO items) is NEM651. MX617N (N = NEM651 in Zimo codes) NexT socket (eg. new Bachmann J72). MX618 21pin is likely to be more expensive, I think all Zimo options are nearer £30. You might find an ESU LokPilot V4 standard for nearer £22/£23 is more cost-effective for any locos fitted with the MTC-21 pin connector. In all cases you need to check the outer dimensions of decoder matches the space in your locos. If they won't fit, there are many alternatives.
  13. You have, I think, answered "what is going on" in your posting. You say somehow inside the ECoS track diagram there is a link between turnouts 7 and 8. When you relabel them as some other value the link goes away. When you revert back to 7 and 8 the link re-appears. So, something in the way that the slip (7) is defined is assuming a connection to turnout 8 as well. Investigate what that is within the ECoS. (My guess its like this: Slips usually have two moving items, which have to move independently, so that's likely to be part of the issue - an assumption by the ECoS that number 7 (part of a slip) is also controlled by number 8, assumed to be the other part of slip by ECoS. - Nigel
  14. Gordon, the IP addresses you have are local to your house. Someone else, in another house will have *exactly* the same addresses. Publishing them tells someone almost nothing, as they need to be inside your house network to make any use of them (by which time, they know those addresses anyway). The 192.168.* range of addresses are in the standards documents as one of the address ranges to use in local (home) networks, so almost every house in the country will be using those identical addresses within the house. The router between your house and outside (the box from your ISP) does translation between the local addresses (inside the house) and its address on the public network. So, traffic from outside to your house goes to your router's address on the public side, which then translates those back to the devices within your house. Such arrangements are totally safe provided the router linking your private network (within house) to public (outside) has sensible routing rules within it. It acts as the "firewall", and provided nobody (you or your supplying ISP) has configured any "holes" through the wall, it is safe. - Nigel
  15. Comments/thoughts: GoT - single supplier of a niche system used by hardly anyone. Probably works if setup correctly. O-gauge diesels: lots of space inside them, so additional hardware isn't a fundamental issue. So, for your layout, have you evaluated the alternatives to provide tracking information, including: a - fully block sectioning the layout, telling software the starting positions of all locos, and letting the software track every movement (manually driven, or automated) so the software knows the positions at all points in the future ? (this is what a lot of large, and complicated automated model railways do, with the trains correctly responding to signals, the signals changing due to the occupied blocks ahead, etc... ). b - adding a train identification method, which would include RailCom, Lissy, RFID ? Any of those will provide a system with identification of a train being at a particular sensor (or with RailCom "in a particular block"). The system can then use that to initiate tracking via block occupancy, or other sensors from that point onwards. Combined automatic and manual running should be possible in several of the model railway control packages.
  • 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.