Gordon H

Doubt whether you would find the springs themselves as spares. Might be worth checking to see if the Peco version of skeleton microswitch is compatible (PL-32).

From MERG. Not sure whether the SuperBloc information is visible on the public website, but have a look here if you can:

https://www.merg.org.uk/merg_resources/superbloc.php

You would need to be a member of the group to buy the PCBs. If you do join you may find that other members would have some of these available second-hand.

I would have suggested the MERG SuperBloc system, which was conceived for just such a situation. However, the complete kits for these are no longer available, though the PCBs used to build them are. The advantage of the system over many commercial equivalents is that it needs no optical or other sensors out on the track - it works by detecting current in the module itself, so only wires connect to the track.

Not sure if anyone has ever used the system on an outdoor layout.

Here is another version for installation on a baseboard joint before cutting across with a razor saw or similar.

As such, it would also allow angled joints, up to the point where the end sleeper corners would overlap the joint.

The '449' will be a manufacturing date code, week 49 of a year ending in 4, so either 1974, 84, 94 etc. Most likely 1984.

On ‎30‎/‎04‎/‎2019 at 10:27, AY Mod said:

 I intend to set out a design for the right sleeper dimensions and spacing to match Peco bullhead if that's of any interest?

Can you specify the dimensions and spacings you anticipate using?

It would be a simple matter to design an actual PCB of the right shape and size to do the job. The sleeper shape would just be part of the board outline and be routed (i.e. milled) in the process. Probably easier than milling a full sheet too, as you could automatically include the isolation break in the copper tracking. You could even include screwdown holes if desired as part of the design. You can get 50 x 50 mm PCBs made very cheaply nowadays.

23 hours ago, Phil S said:

LIVE overhead is NOT recommended by any manufacturer, for digital model railways - because of several factors:

1/ Reliability of contact for the serial data content  ..... 'sparking' as with the real thing representing a failure to maintain contact.

2/ With 2-rail (as opposed to 3-rail/centre-stud Marklin) - then there is a 50-50 chance only of the 'live wheels' being placed on the correct rail.

3/ There is a risk of double voltage or no-voltage - if you attempt to uise 2 differing circuits (overhead or the other rail) with a common rail return.

4/ For storage and tunnelled areas of a layout, it would require continuous overhead catenery - restricting access and increasing cost

5/ partly a repeat of the contact problem - many model railways with overhead run with pantographs DOWN or below line height.

 

Manufacturers always have to assume their customers don't understand such matters in order to avoid the endless questions that might arise when something goes wrong.

Those who have contemplated working overhead wires before will already have identified most of the issues involved, not least of which is the 'live wheels' side issue. Many of these perceived issues are no different whatever the supply method.

Even the live side issue can be overcome with a bit of engineering. For the Nottingham club layout 'Carstairs' I devised a relay board which would adjust the track supply polarity on the Edinburgh line depending on the combination of point settings around the triangle.

The double voltage DCC issue could only arise when two independent boosters are being used, and happen to be out of phase when the boundary is crossed. However, this is really no different to what could happen with standard two-rail supplies in similar circumstances, especially if pick-up is only on opposite bogies for each rail.

With a properly arranged pantograph head there will be at least two points of contact, so the issue there is no worse than a two-wheel bogie pick-up. If anything the pantograph arrangement should be better because it is naturally self-cleaning due to the continuous wiping action.

Have a look at Paragraph 7.3 of the instruction manual. It specifically refers to setting the pulse duration for each output.

Most likely a power supply problem - the power supply probably can't provide sufficient current to overcome the initial surge at power-up.

On ‎26‎/‎03‎/‎2019 at 16:45, peach james said:

I suspect I am far from the only one on the forum whose choice of 2nd vehicle on the driveway was in part directed by what is needed for ones hobby interests (and one's spouse's interests...I had to be able to move a horse box) .

 

Noting your location as BC, you probably have no problems with space for putting such additional vehicles.

Many in the UK don't have driveways, let alone space for a second vehicle.

It is somewhat impractical to try to do this using just manual switches.

At the very least, you need to devise a way of interconnecting the signals to produce the required effect on each one.

You will also need a way of detecting where the trains are.

With four aspect signals you are dealing with (at least) two bits worth (I.e. two binary digits) of information to pass from one to the next.

You also need to ensure that each signal prioritises the highest danger level presented to it, i.e. if a train is in the section ahead, the signal protecting it must be set to red regardless of any lower setting being passed back from the signal ahead.

All of this can be achieved in a number of ways, essentially the same in principle, but using different technologies to implement them.

Electromechanical Relays is one solution, but is probably a bit cumbersome.

Hard wired logic, such as TTL or CMOS, is another method which I have used in the past.

Nowadays I would probably use a simple processor like a PIC for each signal, which would have the capability of cascading between signals and driving signal LEDs directly. Again, lots of ways to actually do the information cascading, the choice of which would be down to your own preference.

All of this assumes you don't have a centralised control system available to do the information distribution, such as DCC or MERG CBUS.

The fact remains that in spite of all the observations made in the early days of this thread to point out the error, they appear to have gone ahead and fitted the wrong type of pantograph.

Hopefully this will be corrected before production.

This simple rectanglular version was produced in a few minutes using Sketchup.

Text is in 'Iskoola Pota' font, which seemed to be the nearest to hand.

The '1715' is in 'Bodoni MT Bold to get the '7' about right.

The curved text was laid letter by letter on arcs drawn beforehand.

As the device next to it appears to be a PIC16F873, I would suggest the component in question is a crystal, as the '873 does not have an internal oscillator. Also, it is near PIC pins 9 & 10 which are the crystal connections. Presumably the heatshrink is there to prevent accidental contact with other components nearby (especially the PIC).

The way to avoid the need for non-polarised capacitors would be to set up the amplifiers so that their non-inverting inputs have a DC bias on them, greater than the anticipated AC signal swing (rather than all being connected to the same 0V reference). A bit inconvenient to do this though, in the overall scheme of things.

I am not using RS485 as it is not an in-built feature of Arduinos and the distances for my data have not yet required me to add the extra hardware.

 

 

So what will you do if/when it does become a requirement?

Surely you should select a hardware solution based on the requirements likely to be encountered.

Designing systems based merely on the apparent cheapness of Arduinos could quickly become a false economy in time and effort once real life practical considerations like this are included.

I am wanting a new pantograph for my Hornby class 86.

Hornby want one too...

Yes. Each message contains the ID of the slave it is addressed to and when it receives a message with its ID the slave replies. That way only one slave uses the "bus" at any one time. If the master does not hear the Reply within a specified time it goes on the next slave - or deliberately causes the system to stop. The IDs are set on the slave boards with a jumper (or 2).

 

That is how the MERG RPC System works too, using RS485 as the half-duplex transport mechanism. The system and its protocol have been available to members for over 20 years now (the G16 range of MERG Technical Bulletins), and it now includes many other options which have been developed as a result.

They are neon bulbs.

Useful in this application as high voltage indicators as they need about 80V or more across them to light.

Still used extensively as indicators in multi-gang mains extension leads where they provide a convenient low power method of 'Power On' indication.

Suggest you measure the pitch quite accurately before purchasing anything. These connectors come in at least four different pitches, typically Imperial sizes 5.08mm (0.2"), 3.81mm (0.15") and actual metric sizes 3.5mm and 5mm.

Also note that most, if not all of the mating halves (the headers) are intended for PCB mounting.

It might work, but you are relying on the forward voltage of each LED being the same.

This is quite likely to be the case if the LEDs are from the same manufactured batch, but cannot be guaranteed.

Better to connect them in series and use a lower value resistor. Less power wasted too.

That's not necessarily true Gordon.

Although originally conceived and mostly used in that format, as an alternative, wireless transmission of (NMRA) DCC exists and is used by a few systems, most commonly in 'dead rail" applications.

 

.

DCC in its original guise is exactly how I described it.

Now that its components have been further developed to allow the same data to be transmitted wirelessly, and an independent power source used, is a separate matter.

The fact is that combining the power and controls in the same signal is how DCC came to the fore, which in itself is quite a neat solution to the original 'problem' it was designed to overcome.

The only reason to use the same data format now for wireless use is for backward compatibility with existing command stations.

If that was not deemed necessary, much better and more comprehensive communication protocols could be used.

DCC is merely a convenient way of combining both power and control over a single pair of connections, i.e. the two rails.

If anything, DCC should be regarded as a subset of Computer Control rather than the other way round.

The various control busses that are now being developed and used (MERG CBUS, NMRA LCC, etc) are also applications of computer/digital technology - but they don't necessarily have to use DCC to achieve their ends.

Chances are in most cases that DCC would be used as the means of delivery of power and control to the trains because that is what it is good at, but it remains a servant to the higher system which can achieve much better results for accessories by other, more appropriate means.

Can I make the case for Computer Control to be moved under DCC because DCC and Computer Control are so intrisically linked?

No, they're not. They only appear to be so because DCC has been seen as an easy route for achieving it.