Jump to content

Nigelcliffe

Members
  • Content Count

    2,978
  • Joined

  • Last visited

Community Reputation

394 Good

About Nigelcliffe

  • Rank
    Member

Recent Profile Visitors

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

  1. Ofcom's table of spectrum use, and a fair way down to find 900Mhz: http://static.ofcom.org.uk/static/spectrum/fat.html And then digging into the low-power use stuff: https://www.ofcom.org.uk/__data/assets/pdf_file/0028/84970/ir-2030.pdf Where I haven't found an application for model use in the 900Mhz area. It is possible that I'm mis-reading Ofcom's information. However, spectrum could be said to be irrelevant, as the lack of CE testing is an issue for any company importing and distributing: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/664824/radio-equipment-regulations-2017-guidance.pdf - Nigel
  2. Iain, you're quoting the WiFi frequencies, in the 2.4Ghz band. NCE wireless is in the 900Mhz band. Nigel
  3. Illegal to use in UK and EU: wrong frequencies, so a redesign of the radio hardware to make it legal. (Unlike some other maker's stuff, where its a paperwork testing and approvals matter, the frequencies and likely power outputs are correct). I can't see any situation where Brexit would change that - the use of radio spectrum is in UK legislation. Its also illegal for companies to import and sell them, but some model railway retailers don't seem bothered with compliance with the CE regulations.
  4. There is alternative MERG firmware for the MERG DCO which is fine on RailCom, available on the MERG website - I've tested it on two systems (Lenz and DCC4PC cutout generator). - Nigel
  5. If the loco in the starter set is one you want, or one you're happy to use for experiments, then the starter system has its uses. They can be a bargain (lots of people have bought Roco starter sets in the past for the low-priced DCC controller). BUT, people say the Select is a poor (to rubbish) controller for a number of reasons. Some are technical at the back-end (quality of DCC signal, number of features supported), but some are user-interface (number and sequence of button pushes to achieve anything). The back-end stuff might be easily ignored by someone starting out and intending to replace it - they may never bump into the issues - , but will they ignore the user interface issues, or assume that all systems are the same when it comes to button sequences to achieve results ? And, you then wrote about the concern about writing off stuff invested already. Well, you are almost certain to have to write-off the Select controller, and may (depending on your modelling interests) also write off the loco. A decision for you to resolve. One approach to write-off kit is to express it in terms of fags, booze or coffee to gain knowledge. If you smoke, how many cigarettes ? Drink how many pints ? Or use coffee shops, how many coffees with frothy milk ? ( There are really cheap ways of trying DCC, but they involve a computer as the user interface to the control system. Cheapest is well below £20, but requires a modest amount of computer/electronics nerdy-ness. Less knowledge/skill/effort is around £60. ). - Nigel
  6. Indirectly yes, it may be part of the cause of the "internal" setting in previous releases, saying "yes" to that could cause the "internal" setting (depending on the status of external hardware). Now, it shouldn't be an issue *if* the bug fixes in 4.14 (December 2018) dealt with the issue - the bug fix is supposed to stop changes to "internal" happening quietly and accidentally. ( The detailed explanation as to what was going on gets complicated, but essentially various tools trying to be helpful, but not fully explaining actions to users, would result in the settings being "internal" - to the system that is "working", but to a real user it's not working because internal doesn't communicate with any external hardware ! ). - Nigel
  7. All of the reported Lenz behaviour is normal: Constant braking distance, yes a Lenz loco follows a curve down, then crawls along at stupid slow pace to the distance point. I did say Lenz ****ed up their constant braking distance algorithm, you're now seeing that in action. Work-around is to use the CV4 deceleration and not use the constant braking setting, then the loco just slows down to a stop, but it won't be at a constant distance. If you always set the throttle speed to be about the same level, then it will always stop in about the same place. (Zimo and ESU have nice constant braking distance algorithms that work as one might expect them to, and stop the loco where you want it to stop in a smooth manner. But they don't do the shuttle option ). The loco will begin deceleration when it's last pickup wheel is inside the braking zone. But, if you have a train with wheels which pickup (can be metal wheels, but will definitely happen with coach lighting), then those vehicles will reset the braking zone as they bridge the insulation gap. So, the deceleration point will begin when the last vehicle to reset the braking zone has entered the area. What happens exactly depends on the train in question. There are ways around the ambiguity of when braking commences: have a spot detector more than a train length inside the braking area, when the front of the train reaches the spot detector, an electronic connection from detector causes the brake zone to be enabled. Or, some decoder makers (but not Lenz) offer a setting which can delay braking in one direction for locos on push-pull trains to allow for the length of the train. Loco runs backwards after one reverse. Yes, Lenz does that. They do the shuttle by faffing with the normal running direction in CV29. So, after an odd number of automatic reverse changes, the loco will run backwards. Fix is to run loco through an even number of reverse changes before taking manual control again. - Nigel
  8. Exact cause/effect is hard to diagnose, but here's my guess.... In recent times (last six-nine months) there has been a bug in JMRI which means it is very easy to accidentally set the settings for a connected device to "internal" - a setting which means nothing works as its assuming no external world (setting is on the defaults tab in preferences). Failed startups to JMRI can even do it (think there may be a user-confirmation action in it, but its far from clear to the user what they are confirming). JMRI 4.14 (current release from December 2018) has some fixes to deal with this issue, but if your machine's preferences were already set to "internal" somehow, you have to get out of this setting first. "hitting save" may well have done that change to your saved preferences. That bug has been a right pain in the neck on the JMRI support forums; it's an unintended side-effect of a change made for other reasons, it took a while to get noticed as the cause of the problem, and a further time to untangle. - Nigel
  9. As indicated by RonRonRon, above, there is an alternative to Alan's Diagram 2. It does not need dozens of direct wires back to the physical mimic panel, but instead, control the turnouts via DCC (as in diagram 1) and use a physical panel device which passes instructions into the DCC system. So, the only extra wires are entirely local within the panel, its output to the rest of the world will be two, four or six wires, depending on the technology in use. Commercial examples, by far from a complete list of how to do it, and there are a lot of DIY options to reduce the cost: Signatrack CML DTM30. Works with any LocoNet system, which is Digitrax, Uhlenbrock, Roco Z21, Digikeijs, ESU (with ESU LocoNet adaptor), etc.. (The DTM30 is incredibly powerful, doing things which are quite complex to wire up on a manually connected panel). Lenz LW150 Mimic panel module. Works with anything offering a Lenz throttle interface: Lenz, Roco, Digikeijs, ESU, etc.. DCC Concepts Alpha system. With the "right" combination of bits, can work with almost anything. But that "right" combination can be expensive for some systems, lowest cost is probably if using NCE system. and others mentioned by Keith above, plus no doubt many more. - Nigel
  10. What I can't understand is why British/American companies can't be bothered to write manuals in other languages, given that many of their sales could be to speakers of other languages. ESU is a small firm, not a multi-national with hundreds of employees. I'd expect most of their staff work in German, so write things in German first. English manual will come along eventually. - Nigel
  11. If the lines continue beyond the stopping areas - ie. more layout, then an insulating gap at the end of the brake-zone rail, and then any further rails are fed from the normal DCC bus wires. If wanting to by-pass the brake zone, fit an single pole on/off switch, so that when "on" (connected) it joins the two terminals of the BM1, and the brake zone receives normal DCC. Thus "on" means "normal running" and "off" means "brake zone active". Note that whilst BM1 devices have only two connections, there is an "in" and an "out" connection and if you get those the wrong way round, then the brake zone works in the wrong running direction (because you've biased the DCC signal in the wrong direction). Make the braking zone adequately long, so either loco with its train has plenty of space to slow down and stop. Then set the various options for stopping distance in the decoder to work for your situation. My experience - if just wanting stopping, then Zimo and ESU do a very good job on constant stopping distance settings. But, if wanting a shuttle, then the only decoder option is Lenz, and my view is that Lenz have ****ed their constant stopping distance algorithm, so I just use the normal deceleration (CV4) and run the train at a known to be sensible speed to allow it to stop sensibly in the braking zone. - Nigel
  12. Yes they work if fitted correctly. That you are seeing a short circuit suggests a very basic and fundamental wiring error, because there presence should be invisible to the command station. Fitting of a BM1 or homemade equivalent to the rails on a single track shuttle line: - Nigel
  13. Run away. Its an ancient design, never that good in its day. There are MUCH better alternatives.
  14. Some clarification here needed, what you've described could be two functions or one, depending on precise reading, or mis-reading. A single front light, which can be directional (ie. only works in forward direction) needs a single function output. If, at the same time, someone also wires a tail light to the same wire, so it switches identically, that that's the same single function. But, a front light at one end (optionally tied to its matching tail light at the other), and a second front light at the other end needs two outputs so they can work independently (ie. one works in forwards, one works in reverse). The "common positive" can be achieved without a decoder output. Instead connect the common positive on the lights to one of the track pickups. The result is half-wave rectified power, but it will work fine for 95%++ of decoders on sale, and is fully documented in many decoder maker's manuals. It is the way that all locos fitted with a 6-pin decoder socket are wired. - Nigel
  15. It is fine to buy incrementally, but decisions you take now on control system for the locos WILL impact the design of a mimic panel later if your intention is to have DCC control of signals and points. The addition of a mimic panel (real buttons or software) to some maker's systems is a lot easier than for some other maker's systems. Or, you need to have a clear view that you'll sell the initial system if it proves difficult/expensive to add the mimic panel later. In addition, whilst I find the control of turnouts and signals through a DCC handset to be sub-optimal, some types of handset make it easier than others. Another thing to factor into your buying choices. - Nigel
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.