Layout bus support

[davidcutting42]

From #66 -

Let's discuss what kind layout bus we're interested in developing. We have the possibility of influencing where the industry goes in the future with this, but we also want to remain as backwards-compatible as reasonably possible.

Layout bus technology requires, in most cases, new hardware.

[matt-vdv]

I know this is a little different, but it would be nice if there was a standard protocol for wired handhelds

[davidcutting42]

@matt-hu wired handhelds are kind of a legacy item at this point with all the WiFi throttles coming out. We could consider supporting LocoNet or Xpressnet to get support for some wirex throttles, but not everyone will be happy and you'll probably end up with crazy bloat

[habazut]

There is not "the" standard for throttles. I think these are the major players:

• X-Bus (Multimaus)
• LocoNet (Digitrax and other license holders)
• Z21 (LAN/Wifi protocol to the Z21)
• CanBus (Märklin *)
  All but the LAN based need a special bus hardware and then all of them need a interpreter and logic for that "language". To cram this into an Arduino may be possible but needs considerable programming and when the manufacturer of the throttle changes the protocol slightly in a firmware update to support problems. So I'd recommend to interface the throttle protocol on a "real" computer with standard software. JMRI has for example some of these components already implemented and can interpret and translate between different throttle protocols (at least to some extent).

Regards,
Harald.

(*) Different from the CanBus Zimo which is niche.

[matt-vdv]

Ok, fair comments. I suppose wired interfaces are really a legacy thing now and wireless should be the way forward...

[davidcutting42]

Somewhat true. Wireless technologies for throttles, but accessories need to be on a wired bus because they will jam each other up when you have a lot. They'll work in small layouts but it gets crazy in big setups.

…

On Sun, Nov 22, 2020, 6:04 AM Matt ***@***.***> wrote: Ok, fair comments. I suppose wired interfaces are really a legacy thing now and wireless should be *the* way forward... — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJWB3LOG6VHV6EGCGQ2M4GDSRED7RANCNFSM4T5O4F4A> .

[matt-vdv]

@davidcutting42 sorry, thats what I meant!

[marada1]

David, I would pose an argument on the wireless technologies. I am using NRF nodes and those nodes can control turnouts, accessories, signaling and block detection. And at a speed faster then serial is capable of. 2mps. I do believe there are other technologies out there as well.

[davidcutting42]

Not arguing that wireless stuff has its place. But in large setups, a technology like LCC can be used to reduce the number of wireless points you need to connect to. You could still have wireless stuff, just consolidated by some sort of bus. Also keep in mind that nobody really cares how fast the bus is running - we're not streaming video or anything like that.

All that said, we will need to support both the wired and wireless setups. It's just a question of which tech to back. Wireless stuff is easier to support, particularly if no extra hardware modem is required, hardware buses require you to choose and then stick with it.

[marada1]

The number of points could be debatable. If you consider that something like a nano by itself using i2c and pcf9685 boards can control in theory over 900 turnouts that shows the power available. My thought is that the base CS handle the engines and if needed, the DCC codes that other devices might need. Allow a buss, say a serial bus, to connect to the outside world. Let the outside world system control the functions of the devices. A proper system can handle everything from turnout angles to lighting systems being turned on or off to controlling routes. CS does not have to do that. All CS needs is to know what is what. Is it a turnout, is it a signaling system saying to stop an engine because of a conflict. All that overhead can be handled and only the info needed by CS sent to it. By the way, love the discussion. Just think, we are sitting here thinking about how we can improve and expand a hobby and make it so many more people get involved.

[grbba]

@marada1 Interesting The RF24 ( if thats the NRF you refer to ) is operating in the same frequencies as WiFi. How big is the density of RF24 emitters you can sustain without any impact on nearby WiFi networks and vice versa and even among themselves ? How many RF24 modules can i operate in // lets say on lets say 2m2 surface without having them shooting each other ?

[marada1]

I was concerned about interference as well but that does not seem to be a problem. There are around 200 channels available to use with the NRF2401 boards. As for density, in theory you can run over 1200 nodes in one network. The way we keep them from clashing with one another is by first in the transmit packet say which node the message is for and second, what function we are looking to do. If I knew how to embed a video I could show 5 nodes working together.

[grbba]

Send the video link on discord that may be easier. I am interested to see that one :) how do you address the nodes ? I guess they don't have an IP address :)

[VR-Architect]

Just wondering if this topic is still being discussed with LCC and EXRAIL out now? Personally, on a large layout, I would like to see physical cat5 wiring using Ethernet to wire all the accessories and switches. With LCC, it seems to need a CAN bus which can be expensive. With I2C we have distance limitations. Ethernet between the command station and remote IO-Extenders would be awesome.

[FrightRisk]

We have been working closely with LCC and you can find the status on that project in Discord. There is a channel just for #LCC we can make you a member of.

We don't have any real limitations with I2C. Depending on the configuration, there can be an issue with pullup resistance that you have to tune in some cases, but we can also work around that with a cheap I2C multiplexor board. We have EX-IOExpander which uses an arduino as its own accessory controller and extender. And we have tested using our RS422 extender board with CatX cable until we ran out of cable at 220 meters. Team member Henkk on Discord can give you the scoop, Paul also. We need to put all that into one simple tutorial page.

[VR-Architect]

We have been working closely with LCC and you can find the status on that project in Discord. There is a channel just for #LCC we can make you a member of.

We don't have any real limitations with I2C. Depending on the configuration, there can be an issue with pullup resistance that you have to tune in some cases, but we can also work around that with a cheap I2C multiplexor board. We have EX-IOExpander which uses an arduino as its own accessory controller and extender. And we have tested using our RS422 extender board with CatX cable until we ran out of cable at 220 meters. Team member Henkk on Discord can give you the scoop, Paul also. We need to put all that into one simple tutorial page.

Yes, please make me a member of the LCC channel. I am setting up a test board for our club layout. I would like to duplicate the work done with Henkk and Paul. BTW, I am happy to write the tutorial page too.