›

LED command lag

jdlombardojdlombardo
edited August 2015 in iOS
(iOS API with RG board) 

The project I’m working on is about visual feedback in response to movement. The LED is responding to changes in the accelerometer, that all works nicely. but...

When using a solid LED, e.g. led setLEDColor, on each command there is a long lag where the LED goes dark for a moment before it responds to the command. It’s long enough to be very noticeable, and makes it impossible to do something like a smooth color gradient, or even to adjust to threshold changes without an abrupt shock. Am I doing something wrong? Is this normal? If it is, can it be adjusted in future releases?

Comments

  • stephenstephen
    This is expected behavior, so no you aren't doing anything wrong.

    The setLEDColor: method clears all the channels and then re-sets them to new values.  We certainly can adjust it in future release and have been thinking about ways to optimize the LED interface, but haven't gotten around to implementation yet.

    Maybe you could give feedback on some specific use cases you have in mind for us to consider when designing the interface.  Thanks!
  • jdlombardojdlombardo
    in the short term: it would be wonderful to change the behavior so that setLEDColor sets the new values immediately, without the extra clearing step.

    even without the clearing step, there seems to be a lag between the event and the LED change. there is a lot happening on the chip besides running lights, of course. but in my use case, LED responsiveness is the key feature, and thus is much more of a priority than things like sending packets to the phone. response time of a few milliseconds is preferred or required, if at all possible.

    also, there seems to be a command buffer or queue. when setLEDColor is called several times in succession it will execute each of the commands in turn, slowly.  be great to have the option, if not the default, that the newest command is the most relevant one, and to ignore what came before if it has not executed yet.

    in the long term, a couple of API changes would be helpful - to follow shortly.
  • jdlombardojdlombardo

    adding four arguments to both the FlashLED and SetLED methods could be very helpful and flexible.


    ——————


    bool SyncPattern [ only relevant if LED is currently flashing, no effect if LED Is solid or dark ]

    false = execute new settings immediately

    true = execute new settings on the next flash of existing flash pattern


    ——————


    bool SyncPulse [ only relevant if LED is currently flashing, no effect if LED Is solid or dark ]

    false = execute new settings immediately

    true = execute new settings on the next pulse of existing flash pattern


    ——————


    int Start (milliseconds)   [if LED is flashing, start is executed after sync]

    negative = new settings will be executed the number of milliseconds specified before previous LED command completes

    zero = new settings should be executed immediately

    positive = new settings will be executed after the number of milliseconds specified


    adding a delay period could be handy to help synchronize the LED to an external event, maybe something like motor control. on detection of event X, an external action is initiated, which takes Y milliseconds to begin - would be good to delay the LED indication to occur at the same time as the action.  on the other hand, initiating a pre-delay could add sophistication, e.g. fading a red channel in while fading a blue channel out. 


    ——————


    bool Dark   [only relevant if start is positive]

    false = existing LED state is maintained in start period

    true = LED is turned off during delay period  (like current behavior)


    in some cases a period of darkness between LED states will be helpful to catch attention during transitions, like a visual detent.


  • jdlombardojdlombardo

    one additional method would be a great help:


    SequenceLed ([item, item, item], repeat, pulse, sync, delay)

    the first argument is an array of flash or solid commands

    then a number of repeats and pulses, like the current flash pattern,

    then delay and sync as noted above

    the use case here is something like a heartbeat indicator once every few seconds, maybe to indicate charging - that’s easily done with a single flash pattern, now but it’s binary, state on and state off. maybe we want a more sophisticated heartbeat that starts with a blue color, then goes to red, then to blue, then fade out. that is not easily accomplished at the moment - but if we set that up as an array of commands, we can execute it over and over without any hassle.  or maybe it could be used for something like a spectrum display at a specific event  - flash red, orange, green, blue, all in sequence, like a visual ringtone for notification. that’s easily done line by line, but it could be interesting to set it as a pattern. if it only executes once, it’s just syntactic sugar; but it would be great to be able to easily repeat that sequence to catch attention if missed the first time.

This discussion has been closed.