On the Busses

[Ian J.]

7 minutes ago, melmerby said:

Obviously never heard of onboard dcc controlled uncoupling then.

You can couple and uncouple anywhere on the layout.

 

I have heard of it, and it's fine for purely manual human control. It's no use for coupling up automatically using a computer with no human eye to see how close the loco is to the vehicle being coupled to.

[Ian J.]

This is the sub buss video by DCC Guy:

 

 

Interesting ideas with the sub busses, but I'm concerned about some things:

 

1. the level of power in that main buss. He uses 16V DC at I think 10 amps. That's a lot of power down one cable.

 

2. the need to add in step downs for all other busses, with extra electronics required. Not a huge undertaking but it's still a consideration.

 

3. the power drop if all accessories that require power on a sizable layout are powered from it. Power districts will alleviate some of that concern, of course, if each power district is a fully separate arrangement.

[jamespetts]

1 hour ago, Ian J. said:

 

You're missing my point. I am looking for mm-accurate, anywhere-on-layout coupling / uncoupling. That simply can't be served by any kind of sections. The usage of 'block sections' on the real railway is for the movement of trains along their journey, not for knowing precisely where a train is on the track.

 

Triangulation is for being able to know precisely where a rail vehicle is. Think of it as like using a highly accurate version of GPS on the real railway so that you know not just what section a train is in, but precisely where it is in that section. This has to be known so that coupling up by automation can be achieved anywhere (not just at fixed magnet positions as in the 'current' dead reckoning systems).

 

As I've said, the tech within the model railway world isn't there to do this yet.

 

It's a very interesting idea to use triangulation to control uncoupling positioning. Presumably, this would require each feed wire to the layout to know its location and be able, independently and simultaneously, to test its distance to every DCC decoder on the layout, and tell which one is which? It would presumably have to do this to a very high level of accuracy. I suspect that that would be exceedingly difficult to accomplish.

 

Or were you instead imagining using radio transmitters? Such a system would make more sense in the context of dead rail. I am not sure whether it would ever be practical given the large number of items whose position would have to be tracked with millimetre accuracy in a small area, but those who know more about radio frequency technology may have a better idea than I.

 

As noted previously, dead reckoning using good software can give accuracy of about +/- 1cm, which is enough for most purposes, although, in N scale at least, the locomotive does sometimes push back the carriages a few millimetres when coupling.

[Ian J.]

I think of triangulation the way GPS works.

 

You have a number of 'radio' transmitters around the layout*. These transmit a signal of their location widely to the whole layout. Any vehicle decoder on the layout needs a receiver for those signals, so becomes a decoder/receiver. It can take in at least three, maybe four signals and process them, this allows the triangulation. The decoder/receiver can then use RailCom to send that information back to the command station and on to the computer for the location to be displayed or otherwise acted on.

 

Note that the location of the receiver is not enough for coupling up. What's actually needed for mm accuracy in coupling up is the location of the couplings of concern relative to the vehicle receivers. This relative position would have to be stored in either the decoder on the vehicle or in a data store accessible to the computer controller. It also necessitates that every vehicle that might be involved in coupling up has a decoder/receiver.

 

*In exhibition circumstances, each layout's transmitters will need some kind of unique layout reference in their transmissions so that vehicles on one layout know which transmissions to take note of. That reference would also need to be in the decoder/receivers, this prevents interference between layouts.

Edited July 16, 2021 by Ian J.
speeling

[Ian J.]

My current minimum busses as of date/time of this post:

 

Version 2.0

 

Buss 2.1: DCC Track Power & Comms, 2 wires, +/-

Buss 2.2: DCC Powered Accessories & All Accessories Comms, 2 wires, +/-

Buss 2.3: 12V DC 10 amp (!) Power for Accessories (no Comms), 2 wires, +/-

Buss 2.4: CBUS, at least 2 wires (not sure if it should be 4), +/-

Buss 2.5: Power District Boosters (SPROG to SBOOST) Comms, 2 wires, +/-

Buss 2.6: Power District Boosters (SBOOST) Common, 1 wire, -

 

Total wires: 11, with a need for thinking differently about plugs/sockets for that 10 amp power buss, and also beyond the 8 pins of 6 amps each of the current stock I have of Bulgin connectors. The lack of a dedicated model LED lighting buss still concerns me, and there's no allowing for an overall layout lighting buss so that would have to be achieved as per most layouts via a direct connection to the mains (in effect another buss).

Edited July 16, 2021 by Ian J.

[Crosland]

12 hours ago, Ian J. said:

OK, so I've looked up a number of pages on t'internet regarding the MERG CBUS, but none seem to explain what the + and 0 connectors do on a CBUS module, all of which seem to have a four port connector, called mostly either J1 or J2. L and H I can see are the actual CBUS pair, but I don't know what the others are?

 

The CBUS cable can also carry 12V power, or it can be supplied to each module locally. That's the +. The 0 is the common 0V and is required to be connected between all modules.

 

12 hours ago, Ian J. said:

 

@Crosland Will existing SPROGs be usable with your implementation of CBUS, bearing in mind they don't appear to have any way of connecting to it?

 

You can still use them but they will not connect in any way to CBUS.

 

JMRI allows multiple system connections so you could have different hardware for programming, running trains, layout control, ...

 

[Ian J.]

21 minutes ago, Crosland said:

 

The CBUS cable can also carry 12V power, or it can be supplied to each module locally. That's the +. The 0 is the common 0V and is required to be connected between all modules.

 

 

You can still use them but they will not connect in any way to CBUS.

 

JMRI allows multiple system connections so you could have different hardware for programming, running trains, layout control, ...

 

 

Ah, I see. So the CBUS modules need power as any accessory decoder would, alongside the comms. That explains why I don't see a 12V socket on the 12V versions of MERG CBUS modules, as they would be getting their power through though + and 0 connections. If I have a pure 12V DC buss, then that could be used to provide power, but would there still need to be that common to the 0? I'd like to negate the need for four CBUS wires for that buss, leaving it two wires only. Would the common of the dedicated 12V DC power buss be OK for the CBUS units? Also, how would CBUS work across electrically separate power districts? Would that common have to be routed across somehow?

 

So with JMRI I'd need to have the SPROG connected to the PC by USB, and then the CBUS also connected to the PC via a module by USB. I'm OK with that.

 

Are you planning a combined SPROG/CBUS unit, or will you move forward with Pi-based devices that I presume could do both so only having one USB connection back to the PC?

[ISW]

11 hours ago, Ian J. said:

Interesting ideas with the sub busses, but I'm concerned about some things:

 

1. the level of power in that main buss. He uses 16V DC at I think 10 amps. That's a lot of power down one cable.

Ian J,

 

It works for me ... I have a old Xbox 360 power supply to provide the necessary 12v for my MegaPoints Controller bus. It's rated at 14amps! I'm sure all my MegaPoints boards are not sucking up all those amps, but might be getting close at initial switch on for a brief moment. The bus wires are 0.75mm2 twin core cables.

 

Ian

[melmerby]

11 hours ago, Ian J. said:

 

I have heard of it, and it's fine for purely manual human control. It's no use for coupling up automatically using a computer with no human eye to see how close the loco is to the vehicle being coupled to.

Now why do you thing that this cannot be done?

Coaches/wagons aren't just going to be dropped off along the track willy nilly as the train runs around the layout (except slip coaches) so they will always be in a platform, a siding etc.

Current computer control systems are perfectly capable of gently buffing up to stock to couple, with different stopping positions for different stock/locomotives etc.

I have run  arounds with different locos and stock and it works perfectly.

 

I think you are trying to re-invent the wheel because you think the current round one is incorrect.

 

 

 

 

[Ian J.]

24 minutes ago, melmerby said:

Now why do you thing that this cannot be done?

Coaches/wagons aren't just going to be dropped off along the track willy nilly as the train runs around the layout (except slip coaches) so they will always be in a platform, a siding etc.

Current computer control systems are perfectly capable of gently buffing up to stock to couple, with different stopping positions for different stock/locomotives etc.

I have run  arounds with different locos and stock and it works perfectly.

 

I think you are trying to re-invent the wheel because you think the current round one is incorrect.

 

 

 

 

 

It appears to me that you're in the camp for 'I'm happy with how things are with fixed positions for coupling/uncoupling and dead reckoning to get there'. I'm most definitely not, so I think we'll just have to agree to disagree.

[jamespetts]

I note that you are planning on a 10A 12v power bus. Wires rated for 10A would have to be seriously thick (as in, 13A mains appliance cord thick). If you make your wires too thin and they actually ever end up carrying the full 10A (e.g. under a fault condition) they could overheat and even possibly start a fire.

 

I note that you are planning to use MERG CBus. There is a wide range of kits available for this, and this will allow feedback (including RailCom), but software support is limited. It works well with JMRI, but JMRI is not good for full automation of anything other than a simple layout as it lacks the abstractions necessary to make this workable without scripting so extensive that you are effectively writing a whole application from the ground up in scripting language. If you have indeed finally decided not to automate fully with this layout, that will not be a problem, but be aware of this if you are still unsure on this.

 

In relation to triangulation, triangulation works by measuring the distance between the transmitter and receiver. If you can do this with three transmitters simultaneously, you can get the position of the receiver quite precisely. However, "quite precisely" is on the scale of full sized ships and aircraft rather than small model trains. I am not entirely sure, since I am not a professional physicist, but I believe that it is unlikely that current or foreseeable future technology will be able to measure the minute differences in the time that the (speed of light) radio signals to and from objects a few centimetres apart so as accurately to be able to give them a distance. Even if this were possible, the level of technology needed to do this would be likely to make it prohibitively expensive for model railway use. Given that workable albeit imperfect systems based on dead reckoning exist, it seems unlikely that anyone would try to develop a radio triangulation system for model railway position detection. (If any such thing were to be developed, I suspect that it would be an offshoot of systems for detecting the position of robots or self-driving cars).

 

It is also doubtful whether such a system would actually be any better than what is possible at present, or what might be possible with incremental improvements to current level technology. It would have to be a seriously accurate, highly reliable, easily miniaturisable and fairly low cost system to be better enough than current technology for it to be worthwhile anyone developing it.

 

I cannot be entirely sure of being correct on this (and, unless there is someone here who is in fact a professional data engineer or physicist, I suggest that nobody else can be entirely sure either), but it does not seem very likely that such a system will be developed in any of our lifetimes.

 

If you do want coupling and uncoupling in truly arbitrary positions on a layout automatically, then dead reckoning, combined with DCC operated uncouplers (have a look at Krois couplers) can do this with current technology.

[melmerby]

1 hour ago, Ian J. said:

 

It appears to me that you're in the camp for 'I'm happy with how things are with fixed positions for coupling/uncoupling and dead reckoning to get there'. I'm most definitely not, so I think we'll just have to agree to disagree.

They are not fixed positions, they can be practically anywhere logical and tailored to each combination of loco and vehicles.

You clearly do not understand the finer points of DCC control with a computer.

 

If you are not satisfied with a system that can calculate where a vehicle is (with mm accuracy as you quoted) and want something totally off kilter to calculate where something is (with mm accuracy) using currently unknown technology, go ahead and wait for it, I think you will find you will be waiting a long time.

I can assure you the chances of it happening are practically zero.

[Ian J.]

I've already said I'm not interested in automation as things currently stand as I don't feel it's good enough for me, and I don't believe a system I'd be interested in is likely to happen in my lifetime, and I'm not going to change my mind. Considering automation is not the purpose of this thread (though it's understandable it's come up due to the 'missing' LocoNet / Xpressnet element), I'm not going to respond any more to posts about it.

[jamespetts]

Incidentally, before I forget, one non-automation thing that I forgot to mention in the last post: if you are using MERG CBus (and this should be sufficient for your needs if you do not intend to automate), you probably do not need a separate DCC accessory bus. This is because there are CBus modules that will deal with all the types of accessories that a DCC accessory bus would normally power.

 

Before committing yourself to this, however, check that you are happy with the CBus controlled alternatives. For example, as to point motors, some types (e.g. the Cobolt Digital IP) are intended to be controlled by DCC and are simpler to set up if they take DCC power as all that is needed is to connect them to the DCC bus. They can be controlled by an IO card (such as those provided by MERG), but that would then need the IO card to connect to the IO ports on the motor as well as connecting it to the (track) DCC bus. However, against that should be balanced the fact that, if you use only CBus, you will not need all the extra wiring of a DCC accessory bus. If you use servo motors for points, it will make little difference, as these will always need servo specific controllers in any event.

[Ian J.]

11 hours ago, jamespetts said:

I note that you are planning on a 10A 12v power bus. Wires rated for 10A would have to be seriously thick (as in, 13A mains appliance cord thick). If you make your wires too thin and they actually ever end up carrying the full 10A (e.g. under a fault condition) they could overheat and even possibly start a fire.

 

In that video I linked to by DCC Guy he used speaker cable (14 AWG?) similar to that I've already used for my separates based AV system at home, so that's pretty thick stuff. So yes, we'd be talking or 13 amp mains cable. It would obviously have to have its own plug/socket system across boards, and with 13 amp mains cable might as well use household mains parts as they are at least very readily available. But I'm not happy about that much amperage in one buss and relying on electronics to step it down, even though it would only be 16V DC. So while v2 of the arrangement only has the one independent power buss, I don't think it's a route I'll go.

[Ian J.]

1 minute ago, jamespetts said:

Incidentally, before I forget, one non-automation thing that I forgot to mention in the last post: if you are using MERG CBus (and this should be sufficient for your needs if you do not intend to automate), you probably do not need a separate DCC accessory bus. This is because there are CBus modules that will deal with all the types of accessories that a DCC accessory bus would normally power.

 

Before committing yourself to this, however, check that you are happy with the CBus controlled alternatives. For example, as to point motors, some types (e.g. the Cobolt Digital IP) are intended to be controlled by DCC and are simpler to set up if they take DCC power as all that is needed is to connect them to the DCC bus. They can be controlled by an IO card (such as those provided by MERG), but that would then need the IO card to connect to the IO ports on the motor as well as connecting it to the (track) DCC bus. However, against that should be balanced the fact that, if you use only CBus, you will not need all the extra wiring of a DCC accessory bus. If you use servo motors for points, it will make little difference, as these will always need servo specific controllers in any event.

 

I like the idea of having flexibility in my choice of accessories. Having the different busses for comms and for power types as per v1 of my arrangement allows that, whereas reducing the busses by taking those out starts to really put limits on possibilities.

[Ian J.]

On 16/07/2021 at 11:44, Crosland said:

The CBUS cable can also carry 12V power, or it can be supplied to each module locally. That's the +. The 0 is the common 0V and is required to be connected between all modules.

 

@Crosland: According to the MERG page with wiring diagrams of CBUS modules, I'm not seeing a need for a common connection between them all? Am I missing something?

 

https://www.merg.org.uk/resources/cbus2

 

Specifically this image:

https://www.merg.org.uk/merg_resources/cbus/images/Fig-1.gif

Edited July 17, 2021 by Ian J.

[Ian J.]

OK, version 3:

 

---

 

Batch 1 - busses requiring power of significant amps

 

Buss 3.1.1: DCC Track Power & Comms, 2 wires, +/-
Buss 3.1.2: DCC Powered Accessories & All Accessories Comms, 2 wires, +/-
Buss 3.1.3: 12V DC for Occasional Power Accessories only (point motors and the like, not lighting) (no Comms), 2 wires, +/-
Buss 3.1.4: 12V DC for Continuous Power Accessories only (for model lighting by LEDs, etc, not for point motors, etc), 2 wires, +/-

 

8 wires through Bulgin PX0551 8 way plugs/sockets, 6A per pin

 

---

 

Batch 2 - comms only busses (?)

 

Buss 3.2.5: Power District Boosters (SPROG to SBOOST) Comms, 2 wires, +/-
Buss 3.2.6: Power District Boosters (SBOOST) Common, 1 wire, -
Buss 3.2.7: CBUS H & L, 2 wires, +/-
Buss 3.2.8: CBUS Common (not sure if this is actually needed), 1 wire, -

 

6 wires through 8 pin din plugs/sockets, amps per pin not known, but presuming it's pretty low (1 amp total across all pins?)

 

---

 

Batch 3 - additional power busses to be implemented at a later date if needed

 

Buss 3.3.9: 16V AC Power Accessories (no Comms), 2 wires
Buss 3.3.10: 12V DC Continuous Power 2 (overall layout lighting by LEDs, etc), 2 wires, +/-

 

4 wires through Bulgin PX0551 8 way plugs/sockets, 6A per pin

 

---

 

There is a logic to why I've listed it this way. I've checked my existing supplies and I have Bulgin PX0551 plugs & chassis sockets (25 pairings) and 8 pin din plugs & chassis sockets (50 pairings) so I'd like to use them up if I can rather than buy new alternatives.

 

S&P has 12 boards to be implemented currently, 10 of which are fiddleyard (5 left, 5 right). I'm thinking of 3 power districts - PD1: fiddleyard left; PD2: fiddleyard right; PD3: scenic 'vignette' section. It might seem over-engineered but I am also thinking longer term with expansion possibilities where the number of boards between each end could number quite a few (anything from 1 to n, based on a general board size of 4'x2'), which is what a lot of my planning for this is about. This isn't just one self-contained layout, but a system to be able to be expanded and contracted as needed.

Edited July 17, 2021 by Ian J.
calrity

[Crosland]

4 hours ago, Ian J. said:

Specifically this image:

https://www.merg.org.uk/merg_resources/cbus/images/Fig-1.gif

 

That is just a diagram, it doesn't show any power connections at all. There is a technical Bulletin for CBUS wiring but you will need to be a member to see that.

 

You need a common 0V between all CBUS modules.

 

[Ian J.]

1 hour ago, Crosland said:

 

That is just a diagram, it doesn't show any power connections at all. There is a technical Bulletin for CBUS wiring but you will need to be a member to see that.

 

You need a common 0V between all CBUS modules.

 

 

OK, I used to have a membership many years ago. I'll have to see if I can renew it. I am unsure as to how such a common wire can cross power districts.

[Ian J.]

OK, I've rejoined MERG, and downloaded two documents about CBUS implementation and neither mentions how to handle electrically separate power districts. I have to presume then that CBUS cannot handle multiple power supplies for the modules, and must only have one, regardless of layout size. I find that difficult to believe, as there could be hundreds of CBUS modules in the stated max length of 500 metres. So how to handle that common 0V across multiple CBUS power supplies...?

 

Edit: I've posted a question on a relevant existing thread in the MERG forum, so hopefully that will answer my question.

Edited July 17, 2021 by Ian J.

[RobjUK]

11 hours ago, Ian J. said:

I have to presume then that CBUS cannot handle multiple power supplies for the modules, and must only have one, regardless of layout size.

 

You can have different power supplies for different CBUS modules, however all the grounds must be linked to keep the CAN bus voltages within an acceptable range for the CAN transceiver ICs on each module.

 

It's not ultra-critical, the ground links can be indirect through other wiring, just something so the different CAN modules are not totally floating. 

The driver ICs are designed so they will not be damaged if one part of the system is powered, as long as the ground (negative supply) voltage difference is not too great between devices.

 

One way is just to use screened twisted pair cable for the bus and tie the screen to the module ground at each device.

 

The bus should be twisted pair, if any significant length or running near any other cables that may have noise or inductive switching spikes. Again not all that critical over a few metres, if you are using individual wires just twist the two for the CAN bus together. Leave the ground link untwisted.

 

[WIMorrison]

There is a system that claims it will provide mm accuracy of positioning using triangulation, however it has been claiming this for a while and has yet to show anything substantive to back up the hype. From my digging it requires an additional board fitting to all locos and undertakes triangulation using sensors placed on the layout board. 

 

I also wonder if this is what DCC Concepts is starting to hint at?

 

http://www.railmagic.com/

 

 

[Ian J.]

I think I may have solved the 0V CBUS common connections. I think it's the same as the SBOOST psu common connection. The only thing I have to think about is how much amperage those commons (SBOOST and CBUS) need to be able to cope with. My understanding of such things is very poor, but I think they might need their own suitable plug/socket as the amps could get quite high in a large layout configuration scenario.

[Ian J.]

OK, I'm going to break my vow of silence on the multilateration (I think that's the correct term instead of triangulation) subject to post this link to a youtube video. It's not model railways, it's clunky, but presuming it's genuine, it shows the usage of RF for location tracking (in this case for a VR headset tracker). It looks pretty accurate to me:

 

 

Edited July 18, 2021 by Ian J.
modify link to for youtube video