Loading ...
Sorry, an error occurred while loading the content.

FW: [BACnetLighting] Specification for FADE/RAMP parameters

Expand Messages
  • David Ritter
    Apparently this didn t get received the first time so I am resending it. From: David Ritter Sent: Friday, March 18, 2011 10:29 AM To:
    Message 1 of 1 , Apr 1, 2011

      Apparently this didn’t get received the first time so I am resending it.


      From: David Ritter
      Sent: Friday, March 18, 2011 10:29 AM
      To: BACnetLighting@yahoogroups.com
      Subject: RE: [BACnetLighting] Specification for FADE/RAMP parameters


      Thanks Christoph,


      I have a couple of thoughts regarding DALI and how it impacts the BACnet Lighting Output object.


      The first is that the Lighting Output object is not a specific DALI interface object so we need not be constrained by the limitations of DALI functionality. For example, Fade Time in DALI has a maximum time of 90.5 seconds but in BACnet we can provide a significantly greater fade time with better resolution.


      Second, the way the fade and ramp operations are currently written in the Lighting Output proposal implies that the ramp and fade algorithms are executed internally in the Lighting Output object. For example, the ramp operation specifies adding the ramp rate to the tracking value each second. This description obviously needs to be changed to allow devices, such as a DALI ballast, to execute the ramp or fade itself rather than in the Lighting Output object. All operations specified in the lighting object also need to be decoupled from the Tracking Value property as this may be an actual feedback value read from the device.


      To answer Christoph’s question, I believe the correct answer is that the actual fade or ramp time executed is a local matter. The user may ask for 52 seconds but if the device can only support 45.3 or 64 seconds then you really don’t have much choice. An option for an implementer is to let short fades or ramps be handed by the external device (i.e., DALI) while longer fade times are executed in the Lighting Output. In the latter case the lighting output object would execute an internal ramp/fade algorithm and periodically send out the new level to the external device.





      From: BACnetLighting@yahoogroups.com [mailto:BACnetLighting@yahoogroups.com] On Behalf Of Christoph Zeller
      Sent: Wednesday, March 16, 2011 6:47 AM
      To: BACnetLighting@yahoogroups.com
      Subject: [BACnetLighting] Specification for FADE/RAMP parameters



      Hi guys,
      i was checking the dali-standard
      Given the fact that DALI does most of the applications in Lighting I assume that similar ranges would be sufficient for 99% of the jobs.

      Range is 0.7 to 90.5 seconds
      => therefore in BACnet 0.5 to 100 seconds with a resolution of 0.1s should be enough.

      RAMP-RATE (Dali calls it FADE Rate)
      Range is 2.8 to 358 steps/second
      if we round that to 1 to 100 I get:
      Range 1.1 to 140
      => I guess 1 to 140 with a resolution of 1 should be enough.

      If a BACnet to DALI gateway is implemented:
      Is it accurate enough to choose the closest DALI-FADE time?
      for example:
      in BACnet we specify 52s

      is it ok if such a gateway is using either 45.3s or 64s?
      These are the closest FADE-Times dali offers


      do we mandate that such a Gateway will have to make shure, that the FADE-time really is 52s (+- 0.1s perhaps?)

      If have not checked wheather such close tolerances are possible (in bussystems this might not be possible because of bandwith limitations when more than one fade should be executed simulatenously)

      regards Christoph

      Christoph Zeller
      Abt. NT
      Fr. Sauter AG
      Im Surinam 55, CH-4016 Basel
      Telefon +41 (0)61 695 55 55
      Telefax +41 (0)61 695 56 19

      This communication, and the information it contains is for the sole use of
      the intended recipient. It is confidential, may be legally privileged and
      protected by law. Unauthorized use, copying or disclosure of any part
      thereof may be unlawful. If you have received this communication in error,
      please destroy all copies and kindly notify the sender.

      Before printing out this e-mail or its attachments, please consider whether
      it is really necessary to do so.
      Using less paper helps the environment.

    Your message has been successfully submitted and would be delivered to recipients shortly.