How does luminaire performs adaptive dimming based on ambient light?

[John]

Hi,

Test and verify Bluetooth Mesh NLC functionality based on the NCS 3.2.4 and 54L15 by using mesh light ctrl example.

1. Modify the following configurations in the prj.conf of the light ctrl example:
   CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_ON=60
   CONFIG_BT_MESH_LIGHT_CTRL_SRV_LVL_ON=32768
   CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_LUX_ON=700
   Flash the modified example to the 54L15, provision it using the nRF Mesh app, enable OCCUPANCY MODE, and configure the Light LC Server to subscribe to group address 0xC000.

2. Use a Sensor Server to publish an occupancy message to group address 0xC000; the LED on the light ctrl board will be turned on.

3. Use another Sensor Server to publish ambient light messages to group address 0xC000, sending once every 2 seconds with a 25 Lux change each time, but the LED brightness does not change. Change the sending period to 1 second and then 100 milliseconds, but the LED still does not respond.

How to verify that the luminaire performs adaptive dimming based on ambient light?

[Edvin]

Hello,

Sorry for the late reply. I was out of office on Friday.

Are you still using the project that I gave you before the summer in one of your other tickets? It did respond to the brightness change, didn't it? When did it stop doing that?

Are you still bypassing the PI regulator? If so, what does your own regulator look like at this point?

Best regards,

Edvin

[John]

Hi Edvin,

Sorry, we had a long holiday for our country's National Day.

I'm not using a PI regulator and NLC standard for my own light adjustment. We have a mapping table between light brightness and ambient light intensity. For example, below 100 lux, the light is at 100% brightness; below 200 lux, the light is at 90% brightness. The sensor is configured to publish to the group when the ambient light changes by 30 lux. After the devices in the group receive the message, they complete the light adjustment within 1 minute. If a new ambient light intensity message is received within this one minute, the new message is used and the dimming is completed within 1 minute. The dimming time needs to be long enough. If the dimming time is too short, for example 2 seconds, it will cause a breathing-light problem, which is a very bad experience.

Yes, I'm currently using the example you gave earlier to simulate the sensor publishing ambient light messages, and using the default light ctrl example in NCS as the light to receive the messages.

The main reason is that some lighting manufacturers use the NLC standard. If we use our own solution, it won't be compatible with them.

So I want to understand in depth how far NLC can go in adaptive lighting adjustment, and at the same time I want to see what the phenomenon of NLC's adaptive lighting adjustment looks like.

In short, I want to see whether NLC can truly achieve adaptive dimming in real-life usage scenarios.

Best regards,

John

[Edvin]

Hello John,

Ok. It is still a bit unclear to me what you are testing, and what is not working. 

Perhaps you have an application that you can send that reproduces the issue you are seeing? And some instructions on how to test it?

Best regards,

Edvin

[John]

Hi Edvin,

I want to test the NLC's constant illuminance regulation function. When it receives an ambient light message, it should perform adaptive light adjustment. The light adjustment might be very fast, or it might be very slow, but as long as a change can eventually be seen, that's fine.

1. Currently, I am using the light ctrl example, with CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_ON=1800 configured, so that the LED stays ON for 30 minutes. I have verified that after receiving an occupancy message, the LED turns on.

2. After the LED turns on, I use the example you previously provided to trigger the publishing of ambient light intensity values via a button, publishing once every 2 minutes, with each change being 100 lux.
   For example, starting from 400 lux up to 1000 lux. According to the constant illuminance regulation principle, the LED brightness should change, but in reality the LED brightness does not change.

Best regards,

John

[Edvin]

Hello John,

Sorry for the late reply. I was out of office for a period.

There is one important detail in how the Light LC server sombines the regulator output with the configured lightness. The regulator can't reduce the lightness below the state machine's configured lightness level. In the On state, this floor is controlled by CONFIG_BT_MESH_LIGHT_CTRL_SRV_LVL_ON. It's default value is 65535, so if you are using the default sample with only CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_ON changed, the output will remain at the maximum level regardless of the regulator output. 

Your original value of 32768 will also be a minimum level, although it should still allow changes above that level.

Can you try adding these to your prj.conf:

CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_ON=1800
CONFIG_BT_MESH_LIGHT_CTRL_SRV_LVL_ON=1000
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_LUX_ON=700
CONFIG_BT_MESH_LIGHT_CTRL_REG_SPEC=y

The low CONFIG_BT_MESH_LIGHT_CTRL_SRV_LVL_ON is intentional to give the regulator some room to control the brightness.

Can you please check:

Even though you build in these configs, they may be stored from provisioning and configuring the device earlier. Make sure to erase the device, and add it back in after completely erasing and flashing the device. (nrfutil device --recover will erase it).

Verify that the ambient light sensor messages arrive on the device.

Try with a large step in the reported lux level. If the occupy sensor has switched the device into the On state, publish e.g. 400 lux, then a jump to 1000 lux, and then 400 lux again, to see if this large jump makes the device respond.

If there is still no change in the light level, please share everything I would need to reproduce this on a couple of DKs, including instructions on how to reproduce what you are seeing.

Best regards,

Edvin

[John]

Hi Edvin,

I make the occupy sensor switched the device into the On state.But in the ON state, the LED is not at a brightness of 65535, but at a very low brightness of 1000.

When the sensor publishes 200 lux, the LED immediately turns on at a brightness of 65535. When the sensor publishes 1000 lux, the LED brightness drops to around 1000 after about 3 seconds, and it does not turn off completely.

When the sensor publishes 500 lux, the LED turns on at a brightness of around 36000 and reaches a brightness of 65535 after about 1500 ms. When the sensor publishes 1000 lux, the LED brightness drops to around 1000 after about 3 seconds, and it does not turn off completely.

If the LED device is reset, the LED turns on at a brightness of 1000. This should be related to CONFIG_BT_MESH_LIGHT_CTRL_SRV_LVL_ON=1000.

It appears that the regulator can adjust the brightness according to ambient light, but the adjustment is too fast. Is it possible to change the adjustment time for the LED from off to the maximum brightness of 65535 to 1 minute or longer, so that the breathing-light phenomenon will not occur?

Best regards,

John

[Edvin]

Hello John,

Yes, you can slow the regulator's reponse. Your observations also confirm that the regulator is now adjusting the brightness. The output stopping at 1000 is expected because that is configured the minimum lightness in the On state.

There are two different mechanisms to distinguish:
1: State transition timing, such as CONFIG_BT_MESH_LIGHT_CTRL_SRV_TIME_FACE_ON, controls the transitions into the on state.

2: Regulator response controls the adjustments to changing the sensor readings while already in the On state. The speed depends on the PI coefficient, not a configurable fade duration for each received measurements.

The default coefficients in NCS v3.2.4 are:

CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KPU=80
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KPD=80
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KIU=250
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KID=25

The propotional and derivative coefficients contribute an immediate response to the illuminance error. The integral coefficients, KIU and KID contribute adjustments over time. Reducing both types will make the response gentler.

As an experiment, try setting them to something much lower, like:

CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KPU=1
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KPD=1
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KIU=2
CONFIG_BT_MESH_LIGHT_CTRL_SRV_REG_KID=2

Also, make sure that the previously stored values don't override the new ones. You should see a significant change in behavior. Try these, observe the change, and then experiment with the different parameters to see if you can find a behavior that suits your desired behavior.

Best regards,

Edvin