Nigelcliffe

39 minutes ago, Pendle Forest said:

Your last paragraph is my point entirely :)

Which I'll reproduce it below

47 minutes ago, Nigelcliffe said:

 

There is a case for model manufacturers being clearer about how their locos are wired to various plugs/sockets fitted inside locos.  That's probably supplementary information beyond "DCC Ready, socket-X".    That would make the fitting of decoder of choice a little simpler to understand.   

 

That's a long way from a set of instructions around how to configure a decoder.   Its just a list of what's connected to what pin. 

An example of what I mean would be:  

DCC socket = Plux22

Wiring:   
     speakers fitted (or not fitted)

     FoF -  white headlight cab1

     FoR -  white headlight cab2

     Aux1 - red taillight cab1

    Aux2 - red taillight cab2

    Aux3 -  cab light cab1

    Aux4 -  cab light cab2

    Aux5 -  nighttime headlight cab1

    Aux6 - nighttime headlight cab2

    Aux 7 -  fan motor

    stay-alive fitted (or not fitted).   If a three-wire stay-alive, the which pin is the "control".   

And, if a 21pin decoder, clarity over which of the two different 21pin wiring standards are used (Marklin or NMRA) which changes which outputs are logic level or normal. 

It can get a little more complex if a maker has "suppression" features in a decoder,  eg. some of Farish' recent Next18 decoders have: 

   FoF - white lights at cab1,  red at cab2

   FoR - white lights at cab2, red at cab1

   Aux1 - disconnect cab 2

   Aux2 - disconnect cab 1

Which means using the Aux1 or Aux2 results in some lights going out if they are turned on.   And controlling them all independently is difficult (some combinations impossible).  

And that's it.   You're on your own to work out whether a given decoder has enough capabilities, and how to setup the CV's in the chosen decoder.     

- Nigel

43 minutes ago, Pendle Forest said:

Quote

But is that not something that should be covered in Gaugemaster's User Manual?  It would seem very strange to expect say Accurascale, advising how to reprogramme an ESU decoder to overcome an issue with the Gaugemaster command station.

Yep maybe it should indeed be, then when it's purchased there is something that at least alerts you to why, for instance, the tail lights won't stay on on your newly purchased model.

Which manual or which maker would be handing out this advice ? 

Gaugemaster - advise you about an arbitrary decoder in an arbitrary model ? 

Loco maker - advise you about an arbitrary decoder controlled by an arbitrary DCC system ?

Decoder maker - advise you about control with an arbitrary DCC system, when decoder has been configured (or partially configured) for an arbitrary model ? 

The various retailers where stuff was bought, probably not one retailer, and highly unlikely to be all done in a single purchase ?

For any of the above, there are a few hundred DCC systems on sale, and goodness knows how many decoders (JMRI lists about 4,000 and their list is far from complete), and I've no idea how many different model loco makers. 

Yes,  the F2 issue is sufficiently widespread that possibly loco makers offering "decoder fitted" ought to either avoid the F2 key, or make sure its used for things which are "momentary" in their use (typical US system design key behaviour).    But not sure who else can advise beyond that detail.   

There is a case for model manufacturers being clearer about how their locos are wired to various plugs/sockets fitted inside locos.  That's probably supplementary information beyond "DCC Ready, socket-X".    That would make the fitting of decoder of choice a little simpler to understand.   

- Nigel

26 minutes ago, Bryn_Bach_Railway said:

The other issue with ESU is you can only really re-map or change detailed CV’s on their chips either via a lok-programmer, or by some other computer interface. Even just to get a list of cv’s you need their software to find what needs to be change. The manual is useless for detailed function mapping

You can change anything on an ESU *if* you read the manual carefully.  It has a very logical and consistent method.   (I worked it out, and documented it, for the LokSound V4 before there were any manuals, by observing the outputs of the LokProgrammer software.  ).   

With the LokProgrammer software (free, don't need the hardware), and the ESU decoder file (provided for this project), you can get a list of CV settings used in this decoder project.    

You say Zimo is easier - it is only if you know which of the numerous different approaches the decoder producer has used - there being three or four different ways to achieve function mapping.   

Changing things by DCC handset is tedious for both maker's decoders, requiring lots of button presses.    A consequence of powerful and configurable decoders.  

33 minutes ago, TomJ said:

Thanks for explaining. So if the decoder switch is basically a micro switch but without the alignment issue then it ought to be more reliable than the old fashioned use of switches? If so it would seem daft to buy a decoder with that option (because I like the DCCConcepts products) and then pay for a juicer to basically do the same thing as well

It's daft to pay twice.     

The "switch" in the DCC Concepts device will be electronic, or a relay operated by the electronics.   It won't be a micro-switch with a movement to operate it.  

The only possible issue against using the DCC Concepts device might be "switch timing".    Whether this matters depends on "which turnouts", "which maker" and how they are setup.   

For example, Peco N gauge electrofrogs (as supplied, un-modified) don't have any isolation between the blades and the frog.   So, if switching the frog by an external switch (DCC Concepts in this case), it needs to change at the same time, precisely, as the blades move.   If it is "late" or "early", a short circuit occurs as one power connection is via the blades, and a different one via the switch.   

Whereas many (most?) Peco OO electrofrogs have the blades separated from the frog, so there is no electrical connection to worry about, and no timing issue.  

- Nigel

11 minutes ago, Izzy said:

Thanks for all that info @Nigelcliffe, that’s very helpful info for anybody with one of these. It’s such a shame CT are no longer around as I see it’s giving the NGS problems with trying to complete the orders it has for them. I am minded just to thin the flanges and leave it at that seeing as there is quite a bit of body overhang all around to help disguise the wheel width. Thinning them means faffing around with repeating the recess for those brass inserts. 

 

The other factor is that after thinning the flange, the wheels still need to slide out on axles a little.  That makes them a little wobbly in the bearing blocks.  Look at whether turning the blocks round might help.  

Nigel

39 minutes ago, Izzy said:

 

Having had a look at the evolved wheel design used this evening (compared to the last Farish split-axle locos before the return to wiper pickups) I think a re-machine of the wheels will do the job.  They appear to be central castings ( I don't think they are plated machined brass but they might be) with large rear stub axle and an etched brass spokes insert, so thinning the flanges and reducing the overall wheel width seems possible. 

 

Bob 

Bob, 

the wheels are a CNC machined brass, which is plated, with a cosmetic etched overlay for the spokes.   So, relatively easy to machine.   But machining will expose brass.  If you restrict yourself to the rear of the flange, its probably OK, but the front-tread area is "go carefully" on appearance and tendency to pickup dirt from the track.    
If thinking of new steel tyres, they're an awkward size,  fraction too small for one 2mm tyre, fraction too big for the other.    

Under the thick paint on the rods there may be a fairly nicely etched rod     (the pre-production rods were really nice etches, not sure about production ones), so strip the paint off, then decide on how to thin them.  

Swapping the wheels out with the Association shop wheels and bearings for "Farish conversions" works except for one of the muffs.   There is one which interferes with the idler gear, so the muff needs thinning down where it may touch the idler to incredibly thin (feels like wall thickness approaching 0.2mm....).  Bear in mind that the idler can move on its axle depending on direction of motion, so watch for catching in all directions.     
There has been a suggestion of replacing all the gears to solve the clearance issue, but I've not looked into it, so it is currently "just a suggestion"

I've got two converted to 2mm with a third waiting elsewhere to be converted.  One is on a pre-production chassis, the others are production chassis.  I've tried replacement 2mm wheels and turning down the N wheels.   The 2mm wheels look nicer, but its a lot of work on the muff clearance issue.  

Decoder is a custom CT, with an integral small tantalum stay-alive.    Out of the box it ought to run well (I spent long enough tweaking the prototype chassis+decoder, the production uses my settings), and will have the "uncoupler shuffle" on FunctionKey-2.    

Because of lack of spare parts,  I'd suggest "lower your track voltage" should go higher up your to-do list.   

- Nigel

3 hours ago, The Fatadder said:

In an attempt to separate out the DCC content from the core thread on the new Cavalex Class 56.  ........

 

In the meantime, if you have access to an ESU Lokprogrammer Cavalex / ESU have provided the required decoder information here https://projects.esu.eu/projectoverviews/8 ready to install on your decoder.  Hopefully Cavalex will be able to share the CV mapping of these settings as a text file at some point in order that those without a lokprogrammer or a preset chip will be able to use alternative routes to programme their loco.

............

You can decypher the LokPilot settings for zero cost, just time.   The LokProgrammer software is a free download from ESU.  The locomotive file is in the link above.  With the software you can load the locomotive file and see the settings deployed, function outputs used, etc..      If required, that can be exported as a CV list, for import into JMRI/DecoderPro (but that step probably unnecessary if trying to find out how it works, what output does what, etc..).  

First question - what type of point motor ?     There are a lot of different ones available, needing different power and switching arrangements. 

Second question - why the LEDs ?   Switch position would show which way things are pointing, the LEDs seem an unnecessary over-complication, particularly as you seem unsure about a lot of fairly basic electrical switching.   I'd advise to make things clear without them.  

Third question/issue.   Labelling of switches.   No idea whether your switch terminals are "correct"  (though I think diagram B, is likely wrong, not sure what diagram C is expecting to achieve).  
Usually, but by no means certain,  SPDT toggle switches, and DPDT toggle switches are have the C=Common in the centre of the three pins, with the other two connecting to the Common depending on switch position.    But which arrangement of terminals depends on the switch maker's diagram/specification sheet.  

2 hours ago, Izzy said:

 

I had thought about doing something like that, Nick Mitchell suggested reducing the track voltage when the first 16v tantalum went bang some time ago, but I wondered if it would have any side-effect on decoder performance in respect of motor control so didn't take it any further. 

 

Thanks for highlighting how I might achieve it. Would you have any code numbers for suitable diodes Nigel?  I presume you mean fast recovery diodes. I've had a look around but as usual the more I look the more confused I get ....

 

Bob

UF5404  is readily available (including Rapid on the industrial estates in Colchester if they still have a local sales counter).   

Officially they're 3A rated, but should be OK for the use you're giving them - only going to see full current briefly in a short circuit situation.  

I'd also recommend a power district current limiter to reduce the track maximum current;  I run most of my stuff with a MERG cut out built for 0.75A at the track.   We run Burntisland (4mm scale) with them set to 1.5A (there's over half a dozen of them dividing up sections of the layout).     There are some fairly cheap ready to use types,  I think the NCE one is fairly cheap - Kevin at Coastal DCC in Ipswich could say what's available, and their current options.  

- Nigel

18 hours ago, Izzy said:

 

Thanks for the thought Jan. It's 14.9v. As it's a Prodigy PA2 system sadly there are no adjustments I can make. It's a very limited/closed system - expensive for what it is today where the Z21 would be my choice - but as I only want it for loco control I stick with it because the 3.5 amp output gives plenty of overhead for powering the hacked servos etc. through a voltage regulator (plus I have a wi-fi handset).  

 

You could drop the track voltage with a string of diodes.   One pair of back-to-back diodes in one of the track feed wires will drop about 0.7v.  So, three pairs would drop things to 14.9-2.1=12.8volts.   Fast rectifier diodes, and 4A or 5A rated given your DCC system's output.  

5 minutes ago, smokebox said:

How about this.  I think it should work.

 

 

Only where "power" = AC.     Nothing happens with DC.  

2 hours ago, WIMorrison said:

Confirming what Nigel has said and showing that you can get what is needed for less than £10!

 

Screwfix Multimeters

 

Though take care with the Screwfix range.   The £8.99 model lacks "continuity buzzer".   The £9.99 model has it.  The continuity buzzer is worth a lot more than £1 - its probably my most used function on model railway work.    

1 hour ago, sulzer71 said:

Nigel , this is exactly what I thought and wired it as such (no differently to what others do with the standard type switch just a different way around) but for some reason when crocodile clips are attached it will spark/arc as if there's a short and the lights on my 12v solar generator it's connected to for testing (12v DC OUT) go off

Buy yourself a multi-meter.   Ideally one with a "continuity buzzer".  Doubt you need to spend over £25 from UK sources.   It makes testing so much simpler and safer than shorting things on the hope nothing goes burns out. 

If the switch is not a DPDT, then its shoddy documentation.     Without access to it, I can't work out how it is wired.    

- Nigel

2 hours ago, sulzer71 said:

The switches I bought are DPDT , here is the link to them https://www.aliexpress.com/item/1005003539167770.html?spm=a2g0o.order_list.order_list_main.4.17c61802XF9TQm

 

I bought the 3 position LATCHING version , I don't need the LED Ring but I like it , it doesn't need to be wired but I have other uses for them anyway , eg last night I wired one to control something else but did it in a configuration that it comes on when the switch is turned on

 

I bought them for the tortoises as they were DPDT which is needed to run them on simple DC power and assumed the 3 position one would be correct

 

Thanks

From the wiring on the Ali-express page,   the 6 pins are in two columns.   Labelled "C" = common,  "NO" = normally open  "NC" = normally closed.  

So, if it is a DPDT switch,  with a meter on "continuity", I'd expect:

   no contact from one C to adjacent C,  no contact from one NO to the other NO,  no contact from NC to other NC.  

Then, switch in one position, should show:

   C to either NC or NO on the same side.    Identical on the other column of three.  

Switch in other position, should show

   C to the other of NC or NO.    Identical on other column of three.  

Then, wiring is a matter of -  input to the "C" common.    Output from the NC.   Crossed wires from NO to NC (ie. left NO to right NC, and right NO to left NC).  

If that isn't how it works, then no idea how the documentation lines up with the description.  

( I repeat, the Tortoise does not need a centre-off,  and if anything centre-off can be a disadvantage as the motor can relax from its end position  ).  

3 hours ago, sulzer71 said:

Morning All

 

As you guys are clearly more clued up than I am then I would like to know if it's possible to wire the switch pictured here to do what the standard switch people use for tortoises (also pictured)

 

I've bought some from AliExpress and cannot get them to reverse the polarity no matter what I try

 

They are 3 position switches with a centre off I believe

 

Tia

 

 Those switches with LEDs usually have a single pole switch, plus contacts to work the LED.  But what was the specification you bought ?   The diagram isn't clear on that. 

Why do you need the LED, compared to the standard toggle switch ?  The toggle position indicates which way.  Or, if wanting rotary to line up with a track diagram, then normal rotary switches (multiple pole, break-before-make types)  are pretty cheap from UK suppliers.   

Why do you want centre-off ?   Tortoise is a stall motor and expects to be constantly driven, after it has reached end of travel.   

Think you're on the wrong addressing for the Java applications,  see

https://pi4j.com/documentation/pin-numbering/

And use the WPI numbers.  

If using a switch to ground, then need to set the "pullup" within the JMRI sensor .  The sensor will report "Active" if the switch is "open" and "inactive" if it is closed to ground.   You can "invert" this with the checkbox if needed.    

This is WPI 4 and WPI 5  (GPIO 16, and 18).  

The above is from my PI today.   The JMRI running on that PI is fairly old (4.26), and I ought to update it. 

- Nigel

12 hours ago, Magyar said:

So without a button to test. How does JMRI reference the pins? It doesn't say in their docs. I have the connection working fine without the errors as per their docs so all my RPi pre-reqs seem fine. But they have literally nothing on how you should use it. Do I just create a sensor in the sensor table and mark it 1-7 on the hardware address or can you only do it by literal script referencing the pin directly in that?. It's really really vague. Basically says if you can setup the connection you're gravy oh and we use 0-7 but maybe not and maybe you can go higher but who knows just guess?? Has anyone done sensors on JMRI through GPIO on here before?

 

I'll get a button to test but I just can't see anything in their docs that says how it's done outside a straight up script which despite being my dayjob I want to avoid. It's so vague.

Yes, I've used the GPIO as input and output from JMRI.   Yes, put things in sensor table (inputs) or turnout table (outputs), as GPIO elements (rather than whatever your other system may be).    The Pi4J website has a table relating GPIO pins to the numbers used in Java code.   

You don't actually need a button,  just connecting two pins with wires on the GPIO will do, just be sure you connect the correct ones, and not something else.   

And, yes, you're a bit on your own.   That's the case with lots of odd corners of JMRI.  Written by a bunch of enthusiasts in their spare time.   Support is on groups.io  .      

12 hours ago, smokebox said:

Get the Select upgraded to the latest firmware, v1.6, and you can then write to cvs.  It cannot read cvs unfortunately. 

Cost is £15 plus you postage cost to send it to Hornby.  You need to get a returns number before you send it.

For about the same amount of money, someone who is up to unsoldering surface mount parts, could probably put together a DCC-EX system - keep the costs down by using a 12v supply rather than needing two voltages.   That has a proper programming track.  

- Nigel

8 minutes ago, Magyar said:

 

 

Thanks very helpful. Do you know any tutorials for RPi of the top of your head? No worries if not I'll just start googling

Start from the websites produced by the Raspberry PI foundation.   Look at those aimed at teachers for school projects - they cover a lot of basics, and cover them thoroughly as the teacher has to learn how to explain it to a class of children.

22 minutes ago, digger62 said:

 

Zimo decoder appears to be out of stock, but will look for Bachmann one.

 

The MX618N has been replaced with an MN180.   The price is somewhat higher, so the old stocks of the Bachmann are probably the cheapest.  

Typically with Raspberry Pi GPIO you connect a device (or switch) between ground and GPIO pin.   The device then pulls the GPIO pin either "low" or "high".   I recommend some time looking up basic Raspberry PI tutorials (not model railway ones) on how to use those pins before applying it to model railways.  

Your call on which system to use.   CMRI, once working, will have far more pins than the two-dozen on the GPIO, and also allows things to be distributed around a network, so reducing cable lengths for each device.     But GPIO may be up and running quicker for "proof of concept". 

Generally for a detection system you'd be putting a layout control bus device (CMRI/LocoNet/CBus/etc) reasonably local to a few sensors (say four or eight) and from there the data is on the layout control bus back to the computer running JMRI.   

( There are also various wireless networking methods, such as using WiFi for the device with a handful of sensors, and reporting via various network methods back to JMRI.  MQTT and Websockets are probably the two most common.  MQTT would work for this application;  eg: a RaspberryPI Pico processor with, say, eight track sensors, making MQTT reports back to a broker.  That's fairly simple to code in either C or Python on the Pico.   ).  

You need some sort of input channel, or network, defining.   With a PI you may be able to use the GPIO pins as inputs (they are usually available within JMRI), but it depends what pins the Pi-Sprog has used up.  

DCC is one-way, command station out to track (excluding RailCom which you don't have).     Input has to come over a different arrangement.    Typically that's done over a layout control bus, so LocoNet, CBus, CMRI, etc...  

If experimenting with the GPIO,  I suggest you start with a push-button over the relevant pin to ground, and see that register as a sensor message within JMRI.  Then move on to trying to hook up the devices you have.  Note the voltage limits on a PI, go above them and stuff goes "pfff".   

15 minutes ago, Julian B said:

Hi All 

Thanks so much for all the info 

 

Yes to the bit about limiting the current ( school boy laziness on my part )  although im not sure what the revesed biased diode across the resistor does although it wont hurt i guess ,   also i see the valid point of the zenner across the cap just to keep the supply limited   to a sensible level.

The one thing that i didnt see much mention of on the internet and forums was the fact that if you have a massive batttery like "stay alive" then the DCC decoder chip will happily work away regardless whether there is any connection to the host devivce , this means in effectt that if you issue a speed setting and then connection is lost, that speed setting is the one that is acted upon and any other command like" stop" is  obviously not recieved and therfore not processed.  Am i right with this or are the decoders looking for a heart beat signal ? 

With my very limmited knowledge i would therefor suggest that going for the smallest possible value of capacitor is the way to go.   Not sure if you will agree with that 

 

Also thanks for the info on the decoder chips  , i see that there is a lack of love for the Hornby boards   I think the comment that they are nasty rather harsh  but again i am new to this so alternate information on  non nasty electronics boards that you might reccomend is greatly appreciated

 

Thanks again

The diode allows full current to flow from capacitor into decoder during "discharge".   The limit on current will be the max current draw of the decoder (ie. the same current that it draws when running normally on DCC power).   
If you don't have the diode, but only the charging resistor, then the maximum current is limited by that resistor.   If the voltage on the capacitor were, say 15v, and the charging (and now discharging) resistor 100ohm, your discharge max current is 0.15A.   As quite a few motors need 0.2 or 0.3A, or more, there's not enough current to move the motor, which kind-of defeats the point.   

Better decoders (people keep mentioning those :-) )  allow for settings in the decoder to say "1 second without a DCC packet, then stop running because we've lost track signal".    Inferior decoders don't and just run-away until the capacitor empties.   

Better decoders can tell the difference between "DC from the track for DC running" and "DC from a capacitor for stay-alive" and respond accordingly,  others can't so you have to disable analogue (DC) running in those decoders.  

Buy yourself one Zimo decoder and see what it does:   some of them come with the charging circuit built in, so all that's needed is an appropriate capacitor.   Others you add the circuit yourself.    All of them are documented by the maker.   

Other suggestions 

a)  cheap "mini PC"  (aka "NUK") running Windows 10 (should be able to get one for under £100), and use the server capabilities which I think the Lenz software offers.   

b)   depending what software is in use under Windows 11,   a Raspberry PI, and connect the Lenz to that.  Then connect your regular software to the service on the PI.  (I am optimistic that JMRI could do this, but if not using JMRI, then who knows)

Search Ebay for the newer Lenz ethernet+USB device.   I picked up one for the local group (lots of Lenz kit) in the summer for £70.     
Search Ebay for a newer LZV200 command station;  friend of mine picked up one for way under £100 (yes, really!).  Looked like it had never been used. 

- Nigel

2 hours ago, SRG50 said:

Unfortunately, my new laptop/computer does not have an ethernet port.

But chances are that your home network does have one, and you need to arrange the network to reach the layout.   The laptop then connects via its WiFi.  

Or, as Iain suggested, an ethernet-USB adaptor.