New to Brickrail - number of connected powered up devices limit?

[Sebo848]

Hi,
First of all Huge Thanks for making Brickrail. I’ve been putting together a Lego train layout over the last few months and I came across Brickrail. So far it’s been super cool and having got it working its encouraged me to push the boundaries - however today I seem to have hit a wall.

I now have 5 technic hubs running a total of 16 switches and I wanted to have 6 maybe 8 trains running at the same time… today I worked up to having 4 trains, however it seems that when I try to connect more than 8 powered up devices the connection to the 9th device fails to connect. I can scan and see the hub however the program will not connect. I’m wondering if this is a limitation in Brickrail or a limitation else where? I’m running Brickrail in a VM on my Mac

[Novakasa]

Hi, great to hear brickrail is working for you at least to some extent, your layout sounds impressive!

Indeed, you are probably running into a limitation there, and I fear it is a limitation of your Bluetooth adapter. The way I understand it, there is no theoretical limit to the number of simultaneous BLE connections, but most adapters still have a limit that seems to be around 7-8 connections. I have yet to run into it myself since my tests only went up to 7 hubs at the same time on the integrated bluetooth adapter of a Dell laptop. I am not sure what the situation is regarding adapters that support more simultaneous connections. I think at some point there also might be a lot of interference between the devices, but I am not sure when this becomes relevant.

For scaling up a layout arbitrarily, bluetooth unfortunately is not the best choice, but it is what this project uses because it is the simplest to use with PoweredUp hardware.

If you plan on scaling up way higher than currently, you probably might want to take a look at MattzoBricks. They use Non-LEGO microcontrollers and other third party hardware for automation of LEGO train layouts, where most of the communication happens via WiFi. This should scale much better to a high number of devices. Unfortunately, a lot more tinkering with electronics and microcontroller configuration is needed from the user, as far as I know.

Other options for mitigating the issue might be:

• maybe not every switch is required to be motorized. With some clever use of one-way segments, you can essentially guarantee that some switches will never interfere with planned routes. They are allowed to be the "wrong" position when the train enters the switch "backwards". For example in the following screenshot, only the switches in red are actually motorized, because the "one-way" tracks limit the trains to only use the switches in ways where the position of the other switches does not really need to be changed. They are in a set position to make sure the other routes are possible.
  
  In this example, the motorized, marked switches control whether a train will essentially do the regular circle, or whether it will do a u-turn. Because of the positions of the non-motorized switches, only 2 switch motors are required here.

• Similarly, if you limit some circular routes to only one direction (via one-way tracks), the opposite facing switches do not need to be motorized.

• I could implement a way to make multiple switches be operated by one single motor. They need to be connected physically with the motor of course, but there are probably a lot of cases where it suffices if two neighbouring switches are always synced, if they point in opposite directions.

Regarding development of Brickrail, I am actually working on a re-implementation of it in another language and framework, which makes it easier to add new features. It is right now not released yet, but it already has most of the required features to automate a layout and already has a few new features that are not in Brickrail yet, like multiple hubs and motors per train. It will probably still have the same limit on bluetooth connections on your machine, but it will probably be easier to publish a MacOS version of it, and I am closer to implementing multiple switches controlled with a single motor on that version. I will keep this discussion in mind when developing it further.

[Novakasa]

Oh, one other point that you might not have considered:
When you enable control devices, the software will only connect trains that are not in a "train disabled"-block. This way, you can at least have more trains in the layout than can be physically connected. So while you cannot have 9 trains running at the same time, at least you can still have them added in the layout, and move the trains you want to keep parked somewhere into a disabled block in edit mode.

[Sebo848]

Hi Thanks very much for the super quick reply

I did some more research (googling) last night and it seems that one of the main limitations of the number of simultaneously connected devices to the BT stack is Windows itself - I am using a USB Asus BT500 dongle with my VM on Mac. As you say I fear from what I have read that there is no work-around. It seems like Windows will only allow one BT device to be active at a time. The other option could be to have 2 sessions running on 2 machines with 2 bluetooth devices but then how do you make the 2 systems talk to each other.... I am really getting out of my knowledge space, but do you think something like 2 Raspberry Pi devices with one BT controller each could be networked back to a centralised Brickrail program? Then for example one Pi could control switches and one Pi could control trains?

I will have a look into mattzobricks - my first idea was to try and use as much off the shelf lego parts/tech as possible - at least on the layout side.

I will try your suggestions for using a one-way limitation on some of the switches and sections to remove the need for them to be automated. In my current layout I actually had a plan to add another 5 switches so that I can have a railyard too... might need to put that idea on hold.

2 switches with one motor is an interesting idea - I have a couple of back to back switches (in green in the image) where this could work. I guess only the exit switch, in the direction of travel, must be set to the correct direction - the entry switch can be either way so this could work. Mechanically linking 2 switches in a back to back configuration to one motor I don't see being a problem - I'll have a look at this for sure I would need some extra parts to make this but that's no issue.

Due to space limitations I have currently built my layout vertically, I have 3 layers of track ( I had a vision to go for 4 - but the bluetooth limit is putting the brake on that right now) in the layout I have 2 vertical banks of switches where there are 3 switches stacked vertically on top of each other each. The switch in blue in the image has 2 more stacked vertically on top of it. Potentially these could all be linked to 1 motor - could be an interesting lego mechanical challenge to see if that could be built - then the controller would have to be much more about timing especially if there are multiple trains moving at the same time on different levels.

BTW on the few occasion (before I change them :-D ) I've managed to get my layout and train all full setup and working the random automation function you have created is awesome. It's so much fun to watch the trains ride around the layout and you don't know what's going to happen next... for me the random mode is a killer feature, I love it!

I have a few more I think simpler quesiton not sure if you want me to carry on in this thread or start a fresh one per topic?

[Novakasa]

but do you think something like 2 Raspberry Pi devices with one BT controller each could be networked back to a centralised Brickrail program? Then for example one Pi could control switches and one Pi could control trains?

In theory, yes, it would be possible to abstract away the bluetooth layer so it could be distributed via network to multiple devices. But I am not sure how big you could scale this up before you get bluetooth interference between all the devices anyway. In the long run, it could be something to look at though, will keep it in the back of my mind.

I will have a look into mattzobricks - my first idea was to try and use as much off the shelf lego parts/tech as possible - at least on the layout side.

Yeah, the main goal of brickrail definitely was to make automation as easy as possible without having to get into too much 3rd party stuff and other electronics. This is only possible since the PoweredUp system and Pybricks. But of course this comes with the present limitation.

The switch in blue in the image has 2 more stacked vertically on top of it. Potentially these could all be linked to 1 motor - could be an interesting lego mechanical challenge to see if that could be built - then the controller would have to be much more about timing especially if there are multiple trains moving at the same time on different levels.

If switches are linked with one motor, the software would only ever let one train at a time pass the linked switches. In practice, I would probably implement a general lock on all linked switches if one train uses them, which would mean the train on the layer above would have to wait for the linked switches to get unlocked if a train on the lower train is using the lower switch. Since brickrail only knows the positions of trains very roughly, it would lock them until the train has entered it's target block. So in practice, there might be a lot of waiting around or even deadlocks if the linked switches are not on a shared route.

BTW on the few occasion (before I change them :-D ) I've managed to get my layout and train all full setup and working the random automation function you have created is awesome. It's so much fun to watch the trains ride around the layout and you don't know what's going to happen next... for me the random mode is a killer feature, I love it!

Very nice to hear, really glad it worked as intended. BTW, on my in-progress re-implementation, I am working on a schedule feature where you can basically create time-tables for trains, with abstraction for multiple blocks being part of a single Destionation (= multiple platforms per station). This was something that @TekyTeky requested.

[Novakasa]

I have a few more I think simpler quesiton not sure if you want me to carry on in this thread or start a fresh one per topic?

Let's keep this discussion about the bluetooth connection limit, feel free to start new discussions even for very small questions.

[Novakasa]

I added a short note about the connection limit to the README for now.

[Sebo848]

ok Great lets keep this thread for the BT topic

[TekyTeky]

Hi Guys, the number of BT connections has always been a topic of discussion, for me ever since I used BAP.
I found that the BT Stack is also dependent on the amount of RAM plus if it was a Broadcom device on the PC.
I used to only be able to connect to 7 devices on a basic WinPC, then discovered if I used a PC with 16g of Ram I can get up to 10 now.
The creater of the Brick Automation Project used a VM on a Mac with a seperate BT dongle and got upto 14 devices.
I tried Parallels on my Mac with the same dongle, but couldn't get beyond 8 devices so went back to the WinPC.
I use the 4 port Technic hub for my switches and usually only 3 trains at one time.

[Sebo848]

Hi @TekyTeky - I did think about a miniPC at one point, but at the time i didn't want to have to maintain another computer setup. Right now I'm running Parallels on my Mac and getting 7/8 max device connections - the 8th device is pretty sketchy to be fair. I like what @Novakasa has suggested with optimising the switches with 1 way blockers and also the dual switch idea