Nine times out of ten when an integrator rings us about a C-Bus segment that’s behaving like a haunted house — lights that fire half a second late, switches that work until they don’t, units flickering in and out of a Toolkit scan — the culprit isn’t a faulty unit at all. It’s the two quiet jobs every segment relies on and that nobody thinks about once commissioning’s done: the network clock and the network burden. Get either of those wrong and the whole physical layer turns unreliable, even though every device looks fine on the wall.
This one’s pitched at fellow integrators and licensed techs. The C-Bus pink Cat5 itself is low-voltage SELV, but the output units and power supplies live in the switchboard, so anything behind the panel is licensed-electrician work under AS/NZS 3000 — our team handles that side. The diagram below shows the common C-Bus unit types and where the clock and burden functions typically live, so you’ve got a mental map before we start poking.
What the clock and burden actually do
C-Bus is a peer-to-peer network — there’s no central controller barking orders. For messages to be timed and arbitrated correctly, the segment needs a shared heartbeat and a defined electrical termination. That’s what these two functions provide.
The system clock
Every C-Bus segment needs at least one unit with the system clock function enabled. The clock generates the timing reference all units use to coordinate when they may talk on the bus. With no active clock on a segment, you get exactly the kind of mess people describe to us: no operation at all, or erratic, intermittent operation where some commands land and others vanish into the ether.
Best practice is to enable the clock on more than one unit per segment — commonly two or three — for redundancy. C-Bus negotiates a single active clock master from the candidates; if that unit loses power, another steps up automatically. A segment running on a single clock unit works fine until the day that unit drops off, and then the customer rings you wondering why the whole house went stupid overnight.
The network burden
Every segment needs exactly one network burden — a defined impedance placed across the bus that conditions the signal and sets the line characteristics. The magic number is one. Not zero, not two.
- Zero burden: signal reflections and ringing on the line, marginal comms, units that struggle to be seen.
- One burden: stable, clean comms — what you want.
- Two or more burdens: the bus gets over-loaded, levels sag, and reliable communication falls apart. More is emphatically not better here.
Recognising clock and burden trouble
The symptoms overlap, which is why this category catches people out. Watch for:
- Intermittent switching — a group works most of the time but occasionally needs two presses.
- Random non-response — units that ignore commands for a while then come good with no obvious trigger.
- Units appearing and disappearing in a Toolkit scan — scan the network twice in a row and the unit list changes. This is the classic fingerprint of a marginal physical layer.
- Delayed or laggy operation across the whole segment — often points at clock arbitration problems.
If you’re seeing voltage and unit dropout symptoms as well, don’t rule out the power supply and cabling side — a starved segment behaves similarly. But clock and burden are where we always start because they’re the cheapest things to confirm.
Diagnosing it with C-Bus Toolkit
Here’s the sequence we run on site. Have Toolkit connected via your network interface (PCI, CNI or 5500PCU) before you start.
- Scan the segment. Run a full network scan in Toolkit. If units appear, disappear, or the count differs between consecutive scans, treat the physical layer as suspect rather than chasing individual unit faults.
- Check the system voltage. A healthy C-Bus segment sits around 15–36V DC, typically up the higher end with a 5500PS feeding it. Sagging voltage points at undersized power supply or too many burdens loading the line.
- Confirm the clock count. In the unit properties, check which units have the system clock function enabled. You want at least one active, ideally two or three for redundancy. Zero is your fault. If you’ve got a clock enabled but it’s the only one, enable it on a couple more units while you’re there.
- Confirm exactly one burden. Walk every unit on the segment and check the Network Burden setting. On modern units this is a switch or a software/DIP setting. You’re confirming one — and only one — unit has the burden enabled. If you find two, turn one off. If you find none, enable it on a single appropriate unit (the power supply or a central output unit is the usual home for it).
- Check across bridged networks. If the system uses a Network Bridge (5500NB) joining segments, each segment needs its own clock and burden. A very common trap is duplicate clocks bleeding across a bridge, or two segments that were each commissioned correctly in isolation now fighting each other. Scan each network separately through the bridge and verify clock and burden per segment, not for the system as a whole.
- Re-scan and observe. After correcting clock and burden, scan twice more. A stable, identical unit list across repeated scans is your sign the segment is healthy again.
Modern units: the burden switch
On current-generation hardware the burden is usually a labelled Network Burden switch on the unit, or a setting exposed in Toolkit’s unit properties. This makes life easier than the old DIP-switch hunt, but it also makes it easy for two units to end up switched on if a segment has been extended or had units swapped over time. Whenever we add a unit to an existing segment, confirming the burden hasn’t accidentally doubled is part of the standard checklist.
The same applies after any rework: if someone replaced a faulty output unit and the replacement shipped with burden on by default while the original unit elsewhere already carried it, you’ve now got two. That single oversight produces exactly the “it was fine, now it’s flaky” call we get so often.
A quick mental model
Think of the segment like a single conversation in a room. The clock is the person keeping time so everyone knows when it’s their turn to speak — you need at least one, and a backup is sensible. The burden is the acoustic treatment that stops everyone’s voice echoing — you want exactly the right amount, because none means chaos and too much means nobody can be heard. Get both right and the room runs smoothly; get either wrong and it descends into the intermittent nonsense your customer’s complaining about.
If you’d like the official background on C-Bus network design, Clipsal’s own resources at clipsal.com cover the system topology in detail. For the deeper Toolkit workflow, our C-Bus programming guides walk through scanning and unit configuration step by step.
When to call us in
If you’ve confirmed one clock, one burden per segment and healthy voltage and the segment still scans inconsistently, the next suspects are cabling faults, mismatched segments behind a bridge, or a genuinely failing unit. That’s where we bring the meter and the patience.
We’ve sorted more flaky C-Bus segments than we can count, and it’s almost always something simple once you know where to look. If you’re a Melbourne homeowner or a fellow integrator stuck on a clock or burden problem, get in touch via our contact page — our team’s happy to take a look and get your network talking properly again.
— Adam and the DUKE Electrical Group team
Frequently asked questions
How many system clocks should a C-Bus segment have?
At least one enabled clock is required for the segment to operate. Best practice is to enable the clock function on two or three units per segment for redundancy, so if the active clock master loses power another takes over automatically. Zero clocks results in no or erratic operation.
What happens if a C-Bus segment has two network burdens?
Two or more burdens over-load the bus, causing levels to sag and reliable communication to break down. Every segment needs exactly one burden — zero causes signal reflections and marginal comms, while multiple burdens make the network unstable.
Why do units appear and disappear in a Toolkit network scan?
Units that change between consecutive scans are the classic symptom of a marginal physical layer, most often caused by a missing clock, the wrong number of burdens, or low system voltage. Treat it as a network-level fault rather than chasing individual unit problems.
Can an end-user change the clock or burden settings?
No. Clock and burden are commissioning settings configured by the technician in Toolkit or via a switch on the unit. They are not end-user adjustable, so if a segment that worked has gone flaky, confirm nobody has altered these in software.
Do bridged C-Bus networks share one clock and burden?
No. Each segment joined by a Network Bridge (5500NB) needs its own active clock and its own single burden. A common fault is duplicate clocks bleeding across the bridge or two correctly-commissioned segments fighting each other once joined.