I have a fader which connects via serial passes a value in depending on its position. I am looking at using this to control a light however due to the serial rate we only get around 5 messages per fade. As such I need to fill in the gaps on the fade.
My idea was to use the time stamp from the messages and its value to work out how long it took to get between the message values, then use this as the fade amount and time. However I need this to update in real time whilst the fader is moving. I am drawing a blank on how to achieve this and wondered if anyone had any idea how to approach this?
The implementation is not actually the tricky part, the tricky part is getting the requirement specification right. Do you want to try and predict what is happening into the future or do you just want to smooth out what has already happened in the past? Trying to predict into the future can be extremely difficult. For example you could have the situation when the fader is slid down and then, just after you get a serial value, it is pushed straight back up again. In that case the prediction will keep turning it down and will then suddenly get a new value and have to do a handbrake turn. If you just want to smooth out what has already happened then you will get a delay between the fader and what actually happens, which may or may not be noticeable.
So first you need to define exactly what you want the output to do based on the time-separated input values. Possibly it would be worth sketching some lines showing the fader input (which will be in steps) and what you want the output to do, remembering that the algorithm can only go on what it knows has already happened. Once you know that then it should be possible to sort out an implementation.
I don't know if this could give you any ideas but some time ago I built a basic controller with a few faders to change brightness of my LIFX bulbs. Even though the controller sent the changes much faster than "5 messages per fade", the bulbs controlled by UDP protocol could not keep up with the speed and the changes felt jagged.
To alleviate the issue, I added a change duration of around 200ms to each message. This is a firmware feature supported by the bulbs so the bulbs did a smooth transition based on each change internally. You didn't specify what kind of lights are you controlling and how fast the interface between Node-RED and the lights is so this was just an example based on the limited info.
