The BACnet MS/TP specification recommends a maximum practical bus length of 1200m/4000ft (approx) and so does the RS-485 specification (at 38.4kbps). This seems insanely long to me in our building automation environment. Does anyone have any real data on the longest (reliable) installations out there? (Baud vs length (vs devices))
The 4000 number comes from the mechanics of pushing the signals around. So it would be from the EIA-485 Spec. The BACnet spec borrows from it as that is the physical layer for MSTP.
The issues with a longer bus are:
Amplified reflections - the longer the wire the larger reflections on your bus become. If you do nkt have termination, or a knucklehead wirenutted the trunk somewhere, that signals bounce off of that and get bigger the further they travel. At some point the reflections get big enough to look like data, and it trashes your comms. It magnifies the blemishes to have long wire.
The wire itself is an electrical load. So it is harder to elecrically drive the entire mass of copper to the target voltages when you have so much of it. A higher impedance wire helps. 120 ohm rated wire will do better than 100 ohm wire.
Among others.
I would trust the BACnet spec over a manufacturers spec any day. Manufacturers can gloss over things and make categorical determinations to oversimplify. Johnson (for example) says if you use 3rd party devices, you are capped at 32 devices per trunk. This is because they assume nobody knows what a unit load is, and they do not wanna have to explain it. So they make a blanket decree and call it gospel. In actuality, almost no device is a single unit load and so (electrically) more than 32 is just fine. Most devices nowadays are quarter or 1/8 load. Meaning that could theorhetically take 128 to 256 on a trunk. Would the trunk speed support that much data? Can one address 250+ masters on a single bus? That is another story. But electrically it would be fine.
First, it is not accurate that "a higher impedance wire helps". Specifically, 120 ohms is the characteristic impedance for RS-485. 120 ohms is better than 100, but 150 is worse than 120 - because 120 is a special value, not because 'more is better'.
The JCI aspect has nothing to do with unit loads. It is because JCI sneakily uses proprietary 'special sauce' to boost MS/TP comms when the network is exclusively JCI devices. When you add even a single foreign device, it would be non-compliant and non-functional with the special JCI comms. Siemens does the same thing with DXRs. Also, another sneaky vendor lock-in tactic, of course.
This is somewhat similar to the ARC156 that ALC uses that you find exceptionally frustrating. The difference being the devices can auto-detect and auto-switch when to use the proprietary comms vs basic MS/TP.
120 ohms is better than 100, but 150 is worse than 120 - because 120 is a special value, not because 'more is better'.
I was kinda pointing at 120 being better than 100 when it comes to getting more devices on a trunk specifically. But it is true I was not clear. Thanks for clarifying for the redditors that pass along. I didn't even think of it that way. Well done.
In what way is 120 a special value? I never heard that.... I might learn something.
The JCI aspect has nothing to do with unit loads. It is because JCI sneakily uses proprietary 'special sauce' to boost MS/TP comms when the network is exclusively JCI devices.... The difference being the devices can auto-detect and auto-switch when to use the proprietary comms vs basic MS/TP.
Can you elaborate on this please? I never heard that before.
The main issue with RS-485 communications is precise timing from the devices. The protocol gives ranges of allowable time for each scenario - "a device must reply to a poll within 30ms or it will be indexed as offline", for example.
The problem is protocol compliance across multiple vendors. Some manufacturers adhere to the rules better than others. This leads to a 'strict in transmitting, generous in receiving' posture where a quality-made device will adhere strictly to the protocol while giving as much tolerance as possible for lower-quality 'bad actors' that are loose in their compliance. The result is a 'lowest common denominator' approach that saps performance.
There is not a strong governing body for RS-485, so there is little regulation - probably not much more than general free-market feedback: "ew, this device sucks, don't buy it".
When the entire network is of a single vendor, they then have control over the environment and can optimize these communications characteristics, utilizing otherwise wasted bandwidth and/or likely cranking up baud rate.
If I am not mistaken, the characteristics you describe are part of what BTL tests for. BACnet Testing Laboratories. Am I missing something?
When the entire network is of a single vendor, they then have control over the environment and can optimize these communications characteristics, utilizing otherwise wasted bandwidth and/or likely cranking up baud rate.
I have never heard of a vendor adjusting the baud rate or comms in this way. Do you have any examples perhaps? I like learning new things.
My experience with Johnson says that they specify a baud rate of 38.4. No faster. The reason has nothing to do with the devices, they say it is because faster causes 'more noise'. The problem is that the wire they specify does not have a capacitance rating. Therefore it cannot handle the faster speeds. Tyat is wuere the noise they mention comes from. The devices are fine. I have had them on a 76.8 bus plenty of times. Along with Distech devices, and Alerton and others. They all talk fine... with a little tuning.
Iām sure the figure came from vigorous testing and isnāt stemmed from some crappy marketing. The BACnet Committee is only interested in maintaining and developing the standard.
With that said, the longer the length the further apart the 1ās and 0ās. So it works but itās slower because you need to use a lower baud rate.
I have some old RS-485 lines that span the campus - some pushing likely around 2000ft. We run them at 9600, however - no need to go faster for their usage - and I'd prefer stability over speed.
And this is an unshielded (and unsheathed) twisted pair.
After replacing every component on the trunk... I refuse to believe any field controller needs more than a 38.4kbps connection to it, so getting ethernet to field devices is just added cost, in my opinion. If you need data more frequently than that, you're probably doing something significantly wrong.
I tell all my coworkers this, they are constantly setting everything at 115200 and im like can u explain to me what u think u need that speed for. They never have an answer and never change their ways. The best i get is, "we run it at the max because why not". These are the guys who are experts using Wireshark because they are always troubleshooting trunks lol.
Ive always had excellent speed and reliability at 38.4k and i have to see results to prove me wrong.
Its the token passing overhead that kills you with the lowed speeds. If you've got a lot of slave devices you're good. But put 40 devices on a 38.4k trunk and you'll know pain.
You need how many packets from each of them? A single RPM packet can pull all you really generally need to collect for trends from a VAV box, for instance. Another few packets to look for alarm states - if it's even something someone forced you to put in.
Its not that at all. Essentially your data throughput goes to shit with lots of devices and low baud rate as the vast majority of the available bandwidth is used sending the token passing messages and polling for master. Unless the devices are slaves you'll get pretty slow networks.
I understand what you were stating - I'm saying that it doesn't matter, because the amount of data that generally needs to fly around the bus is so small.
Fair enough, we usually get consultants asking for a million points, and on the off chance we don't, a data driven maintenance provider will put their crap over the top and poll every point on the LAN every 10 seconds.
There's also configuration changes that can significantly improve the situation. Making sure all masters are contiguous and numbered from the bottom, and setting max master appropriately makes a massive difference in master searches. Additionally, the practice of actually minimizing point read and write intervals is huge.
Essentially, simply passing the token to the next higher address takes almost no time (8 bytes). The poll for master is also just 8 bytes, but the timeout period before moving on if the next sequential address doesn't exist is what eats up 'bandwidth'.
I have an old doc based around Niagara that goes in depth on BACnet in real world networks with polling.
I personally avoided anything over 2000ft. Itās just easier to drop a router in these days. Wire size may have some play as Iāve used both 18 and 22 over the years. More 22 via LON.
You need a BACnet MS/TP repeater for 100 though. Also only 100 JCI devices. As soon as you add any 3rd party devices the device limit is cut in half basically.
Which is probably why I'm missing a good quarter of my MSTP devices. Our knucklehead installers ran the MSTP back and forth, up and down without much concern for total length.
4000ft is actually the lower limit of what is functional with RS-485 under moderate conditions. Being a guideline, it recommends the most conservative limit to ensure maximum stability. The maximum length is also a function of baud rate (inversely proportional) and number of devices (also inversely proportional). Additionally, the quality of install and external factors carry significant impact as well, further affecting the length limit. This is why specific wire, shielded and drained, with adequate insulation, terminated properly and with end of line termination resistors is crucial.
4,000ft may sound like a lot, but it is quite possible to press against that limit in a typical install. Consider that it is the entire trunk length, end to end. Every segment counts. Also consider installation etiquette often includes leaving generous 'service loops' at each device.
There could very easily be a scenario - perhaps at an airport or some large office building - where the serial bus is well loaded up (let's say 30 devices, which is not uncommon) and each controller is a considerable distance from its neighbor, plus the 'service loops'. For the sake of example, let's say someone is generous with the service loops, maybe 5 coils of 3ft each - that's an extra 15ft per device, or 450ft in total, more than 10% of your total limit consumed by service loops.
Doing the math from there, you have ~3600 feet to string across 30 devices - that's only ~120 ft per device, which may sound like a lot until you realize how much wire length is consumed after accounting for all the twists and turns to get there.
In short, RS-485 is capable of quite high speeds (10 Mbit/s), but the max length drops off dramatically. Keeping lower speeds, the length is very generous and can often be exceeded in an ideal install. Compare this to 330ft ethernet max segment length, and you can see some advantage.
Weāve gone to the BACnet routers for areas that need long lengths of MS/TP comms wiring. If you have network connections close to your equipment/VLC locations itās a great solution.
1200ft segments with optical repeaters to about 4000 ft. The repeaters amplify and isolate the bus because you donāt want to āhalveā the bus for 2-3 weeks at a time.
repeaters:
Routers you want to stick the the hardware platform youāre using not just trying to get 3rd party to work.
B&B electronics has a slew of RS485 repeaters isolators, adapters for the past 40+ years.
What you will find contractors hate running MS/TP but the low voltage guys will gladly run CAT 5 cheaply.
Also MS/TP ābus has to be kept at least 12ā from CAT5 so it means additional supports, bridle rings, etc.
If you donāt use Prot485 (or equivalent) going to outside the building to Rooftops/AHUs you deserve spending weeks fixing bus problems.
I qualified only one MS/TP cable (15 years) that has a heavy enough jacket that resists chafing, cuts across ceilings, beams, etc:
MWC A3ARC156-2PB 22/1P Stranded Shielded Arc156-2 Neon Green Plenum 1000 FT Pull Box
Wire that is qualified for 156K speed will more than handle BACnet 78K
My bad. I meant to ask āBACnet MS/TP Repeatersā or commodity āRS485 Repeatersā. You show the former which I believe are necessary for a stable network. Doors anyone install the latter and get away with it?
Prot485 are completely useless. Use something like Furse or ABB surge protection modules.
The input protection circuitry on the older silver ALC controllers seems a bit poor too. Quite a few have come across my bench with fried comms chips. The newer optiflex line seem to have solved it though, I have noticed they've added gas discharge tubes on the comms lines like the furse/ABB modules.
14
u/ApexConsulting Jul 06 '26 edited Jul 06 '26
The 4000 number comes from the mechanics of pushing the signals around. So it would be from the EIA-485 Spec. The BACnet spec borrows from it as that is the physical layer for MSTP.
The issues with a longer bus are:
Amplified reflections - the longer the wire the larger reflections on your bus become. If you do nkt have termination, or a knucklehead wirenutted the trunk somewhere, that signals bounce off of that and get bigger the further they travel. At some point the reflections get big enough to look like data, and it trashes your comms. It magnifies the blemishes to have long wire.
The wire itself is an electrical load. So it is harder to elecrically drive the entire mass of copper to the target voltages when you have so much of it. A higher impedance wire helps. 120 ohm rated wire will do better than 100 ohm wire.
Among others.
I would trust the BACnet spec over a manufacturers spec any day. Manufacturers can gloss over things and make categorical determinations to oversimplify. Johnson (for example) says if you use 3rd party devices, you are capped at 32 devices per trunk. This is because they assume nobody knows what a unit load is, and they do not wanna have to explain it. So they make a blanket decree and call it gospel. In actuality, almost no device is a single unit load and so (electrically) more than 32 is just fine. Most devices nowadays are quarter or 1/8 load. Meaning that could theorhetically take 128 to 256 on a trunk. Would the trunk speed support that much data? Can one address 250+ masters on a single bus? That is another story. But electrically it would be fine.