The term "trash", in reference to dali is any packet that has incorrect bit lengths or quantities of bits. A device is required to "trash" their transmission if they think another device is speaking (or that its own transmissions are in error). It can also be the sign of device malfunction. If the line is seeing large amounts of trash blocks, dali functionality may be compromised.
The term "noise" refers to single bits of information that may be seen on the line. These bits are required to be ignored by all dali devices. This can often be the result of signal runs being close to switching devices that cause slight hiccups on the line. Unless there is a high prevalence, this may be perfectly acceptable.
Legitimate reasons you might see TRASH in the monitor.
If the trash is an answer to a query
It is common practice to use a broadcast query to look for devices to address or ascertain if there are more devices than 1 at an address (because a single answer, regardless of trash is information is a confirmation in this case). As multiple devices will begin a transmission to answer at slightly different times, in practice, you see the result of 1 or more devices trying to send their answer at slightly different times.
It should be noted that is not common to use broadcast queries on wired buses for anything other than addressing and clone checking.
If the device in question is a control device sending an event message
Control devices are frequently sending commands and thus, will occasionally collide. Dali priority helps with this (where devices are set to use different idle periods before speaking) but it does not completely remove it.
Reasons requiring more attention
The device transmitting sees its own transmissions as being outside the required lengths
Devices are required to listen to their own transmissions and measure their bit lengths. If they perceive that the bit lengths are out of spec, they are required to trash the command to indicate to all devices on the line should ignore this command. They will then try to speak again.
If the device transmitting has bad firmware
Dali transmission is not incredibly complex but it does require someone to not make mistakes that could lead to the device falling into a loop of erroneously transmitting incorrect data.
Dali line length is large or current too high
If the line length is particularly long, you may experience signal degradation that could cause issues with devices (particularly bus powered devices) that manifests as trash or rebooting devices.
Examples
In the image below, the controller can be seen struggling to get a command out due to trashing inbetween.
Similarly, blocks that look like this are essentially holding the network hostage. "Unsolicited reply" implies that the device trashing the line did not wait the appropriate time to begin a command transmission (ie, it transmitted trash and then transmitted further trash in the reply window that comes after each command).
Finding a trashing device
Identifying the source of network disruption can be challenging without extensive segmentation testing. In systems with numerous lights and peripherals, issues can lead to substantial costs.
As a result, our control system, being the most readily updatable component, often becomes the primary focus when troubleshooting. Our control system firmware, particularly regarding DALI functionality, has remained stable for nearly a decade. While it's not outside the realm of possibility that the controller could be the source of an issue, it is highly unlikely.
It is a common misconception that "resetting the breaker" and having the issue resolve is a sign that the controller is responsible. In practice, what that generally means is that the dali power is also connected to the same breaker and removing the dali power momentarily causes the bus powered devices to be reset out of a faulty state.
Even simply resetting the controller and having the issue resolve is not proof the controller is responsible - the controller stopping speaking may provide the devices enough time to resolve their issue.
You should always first consider the bus in terms of the products you are using, the differences between other lines and why this might be occurring. There may be physical differences such as signal wire, length, total bus current. There may be more of a certain device.
You may be able to learn something from watching a monitor and paying close attention to when the trash starts. This will only be useful if the trashing starts as a result of a query or command, though (which isn't particularly common).
For instance, this trashing occurs shortly after a broadcast of event scheme and potentially points to a control device possibly having issues as a result of a being asked to store a setting.
Comments
0 comments
Article is closed for comments.