Jump to content

Nigelcliffe

Members
  • Content Count

    3,706
  • Joined

  • Last visited

Community Reputation

1,085 Excellent

1 Follower

Recent Profile Visitors

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

  1. Latching state, function labels (eg. "horn", "brake squeal"), and icons on the throttle are configurable on a per-loco basis in JMRI, using the "roster" view to make those settings (where you start programming from). The labels and latching behaviour also goes out to throttles on smart-phones. There is a JMRI global preference which defaults Fn2 as non-latching, users setting individual function key behaviours probably want to find this setting and change it so it doesn't over-ride the individual choices. The throttle panel is configurable, though probably not as
  2. The decoder in question is a rebadged moderately new ESU LokPilot design. So, should be better than those of 10 years ago. The behaviour is what one would see with a failed decoder's output stage. So, I suspect faulty/failed decoder. As the EZ-Control system has no ability to set anything in the decoder (other than address of 1-9), there isn't anything to do. Its possible there is a fault in the loco which is causing this, or causing decoders to fail. Requires a multimeter to test it - do you have one ? - Nigel
  3. NCE, Digitrax, Gaugemaster (made by MRC) are all US systems. These systems have the issue with lack of user-setting of "latching" keys that LocoMan identifies. It makes a big difference to sound decoder control. European system makers, which tend to have user control of how keys work, include: Roco, Uhlenbrock, Piko (rebadged Uhlenbrock and rebadged ESU). And at higher prices, ESU, Lenz, Zimo, and others. From the UK, there's the Signatrak ACE system. Touch screen, control of latching functions, optional handsets. - Nigel
  4. Wrong bus (you stand here all day and three buses come along at once). Throttles connect to a throttle bus system. These questions are about the DCC track feeds, also callled the DCC bus.
  5. I'm not aware of anyone doing it (I have built a RC double decker bus in 2mm). There are a number of N gauge models which are shown in R/C, including quite small things (such as the old Minitrix Dock Tank). The problem will be battery space once you've put a motor and gears inside the mechanism. Then weight and balance of weight (don't want all the weight at one end of a loco). Motors won't be an issue, if anything running the small can and coreless motors typically used in 2mm on circa 4v (single LiPo cell) may be better than the nominal 12v-14v of DCC. If y
  6. Yes that's correct *if* the programming track only ever submits a loco to the short programming pulses. Some makers programming tracks do this. And some don't, because the programming track can also be used for running and "automatically switches over when programming". So, when not "automatically switched over" its no longer the safe extremely low current and total power environment, but something else which can submit loco and decoder to more power. Its a mess, and I don't think maker's of systems are helping users with their powered programming tracks.
  7. Brake Mode, stopping distance and constant brake mode are to do with automated stops from external triggers, such as Asymmetric DCC trackside units (bunch of diodes around a rail gap in the track). I don't think they will help you. - Nigel
  8. You’re right . but I get a message of ‘writing is completed OK’ on the controller. All the loco lights flash during the writing job. Disagree with conclusions. All you have is "read" isn't working. Everything zero isn't sensible, it just says something seriously wrong. Some CV's (eg. 7, 8) should come back with non-zero and non-changing values. If the motor outputs don't seem to work, that's probably why the readings are nonsense. You don't seem to have addressed the more basic question as to why a loco can
  9. This is a sound loco. I think the following may be happening: In many sound projects, there is a delay built into the start-off from zero. The cylinder drains open (big hiss) and various other noises play, before the loco starts to move. The software may be accelerating the loco away from zero through several speeds, whilst the sound chip is still clearing the cylinders and the loco is not actually moving. When the loco starts to move after the delay, the speed its being told is "25mph", so it romps to that almost instantly because acceleration is only "3" (ie. really f
  10. Can't tell. Could be anything, but does point to a possible decoder failure. BUT, if a loco destroys two decoders, it suggests a problem with the loco which should be investigated, as pointed out in previous posting. It is possible to have a fault which destroys decoders yet gives correct running on DC.
  11. Yes, I agree with that concern. But, that can be got-around by using the other set of contacts on the Cobalt to switch the frog - take power into the switch from the track DCC signal, and the output from the switch to the frog. That might be cheaper/easier than replacements. - Nigel
  12. I hope 7013's experiences are better than mine. I found them unreliable and therefore useless on hand laid track in EM, P4 and 2mm finescale, both with almost direct link to tiebar, and through remote links. They might work with Peco (etc.) track, I have not tried that option. A fair sized box went back as "not suitable" to the supplier. The one which was opened is still in search of a situation where it will reliably work.
  13. Quality decoders do have output protection - Lenz, Zimo, etc.. But, US products don't typically fit such devices. Gaugemaster DCC products are bought-in devices rebadged as Gaugemaster, some of their decoders are from Digitrax, and some are the common Chinese copy of an old TCS design - both US origins. Back at the loco, having blown two, I'd be (a) checking the current draw, and (b) putting a multi-meter over the PCB to check that tracks are not connecting "pickups" to "motor leads" when the decoder socket is empty. - Nigel
  14. Not "master" as such. JMRI (via the PowerCab USB device) is another "cab" (= throttle in NCE language). It can see and control as much as a second throttle device. But, being a decent bit of software, it can respond to every throttle message seen on the NCE system, plus remembering all the user's settings entered. So, can control the system. Your existing PowerCab remains the "master" device. Unplug that, and everything stops. In relation to the phones, JMRI is the "server" process, to which the phone apps must connect. - Nig
  15. Yes if you run the open-source JMRI software on the laptop. Within JMRI there is an option for the "WiThrottle Server". That's the server process to allow smartphones to connect to JMRI, and thus to the layout. Typically using WiThrottle App on Apple devices or the Engine Driver App on Android devices. For further enhancements, adding your locos into the "Roster" within JMRI, and setting the Function Key labels in the Roster, and those details are used on the smartphone Apps, thus keys labelled "horn" "door slam" rather than F2, F5, etc..
×
×
  • 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.