Clear LED pattern

I know the LED commands are play, pause, and stop.  How do we clear a pattern?  When we click the save button I'm assuming that's just adding the current color to the pattern.  Is there a way to reset the pattern?

Comments

  • Clearing channel data is embedded in the stop command.  When you send the stop command, you can either just stop the pattern or stop and and clear the pattern.  

    The current firmware (v0.4.1) does not support clearing individual channels, clearing is done in bulk.

  • @Eric

    This is Eric, working on the Windows Portable Class library. 

    Do you have a document that documents the LED operation, as in how the buffer is built and how the commands get interpreted and turned into actions?

    -thanks in advance
    -e

  • I have that, but it explains nothing about the thing is supposed to work.  It just shows you the interface.

    Three is actually a snippet in the app as well, and then there is some small amount of data (units and ranges) in the Java docs.

    So I'll just ask questions .. sorry about this (I'll separate into posts)


  • @Eric thanks for trying to help.  I have a lot of questions on how LEDs are supposed to work.
    I don't have an Android or iOS device and we need docs anyway.  I'll write the thing up when
    I understand it and put in the Windows code.

    It should take only 15 minutes to type some answers, so please bear with me.

    // this guy sets up the 15 byte array the controls something having to do with LED's                   

    public ChannelDataWriter setColorChannel(final ColorChannel color) {
    public ColorChannel getChannel() {

    I think we only have one color per channel, but can we set up multiple channels and then play them all?

    like this:
    set up channel with color red
    set up channel with color green
    set up channel with color blue
    play red
    play green
    play blue
    (maybe play with "autoplay" set ?)

    In that case, how much behind the red channel should the green and blue end up being, since t
    he time to start the channels is not infinitesimal?

    {note that I tried this and it didn't seem to work this way}

    High intensity measured when?  I don't understand the time context.
     
     @Override
     public ChannelDataWriter withHighIntensity(byte intensity) {
                                    
    // Does the sequence go:

    // Start
    // delay by withPulseOffset mS
    // Set to low intensity
    // rise during rise time, until at set to high intensity
    // Stay here during pulse duration time
    // Drop during fall time back to low intensity?
    // loop for each repeat count to "Start"

    if that's the case WHAT happens, when I don't set something?  Does 0 mean "ignore the setting",
    such that if I don't set a rise time, the thing turns on immediately to high intensity?

    if I don't set a offset time then 0 is used?

    if I set a 0 repeat count, nothing happens?  I think I saw documentation that a repeat of
    255 means forever.

    Is there a special value for turning on the LED and leaving it on?

    As for units, it looks like there are 32 levels 0-31 for each intensity value and
    time units are documented as mS.  The input seems to be an signed short, but then
    the data is packed as if it were the full 16 bits.  Does a positive vs negative
    input have an effect or is the input really just taken as the unsigned version
    and the max is 64k instead of 32k?
     
    What does "Keep it set to flash for now" mean  below?  Are there other settings?
     
     @Override
     public void commit() {
     channelData[0]= (byte)(color.ordinal());
     channelData[1]= 0x2; ///< Keep it set to flash for now
     
    and then there is play with "Autoplay".   What is "autoplay"?
    is it the opposite of "resetChannels", and starts all the channels?

    public override void play(Boolean autoplay)
    {
        writeRegister(Register.PLAY, (byte)(autoplay ? 2 : 1));
    }

    public override void pause()
    {
        writeRegister(Register.PLAY, (byte)0);
    }

    It looks like this method can stop the sequence, but it can also stop ALL the channels,
    with one command.
               
    public override void stop(Boolean resetChannels)
    {
        writeRegister(Register.STOP, (byte)(resetChannels ? 1 : 0));
    }

    -thanks
    -e

  • Just one more question, I hope @Eric will answer soon.

    What is the meaning of withHighTime and withPulseDuration?  Not sure how they fit into the pattern I outlined above.  Kindof thinking my outline above is off somewhere.

    Please?

    -e

  • Looking at the above, and now the code again, I see that my

    play red

    play green

    play blue

    scenario is wrong.  We can only play or pause or stop the entire thing, not one channel at a time.

    That makes my other question about the offsets in time between the channels obsolete.  Sorry for not investigating that fully before asking.

    -e

  • The LED is programmed to act like a square wave.  The pulse starts at 0, rises to the high value, stays high for some time, then falls to the lower value, staying at that lower value for however much time remains for one pulse.  Each piece of the wave can be configured to be as long or short as the user wants.  

    All values are treated as unsigned values in the firmware.  
  • Thanks, Eric.

    Even so, a lot of unanswered questions above.  If you want to just add the answers to the somewhat muted Android code comments, go ahead, or answer here.

    -thanks
    -e

    • Each channel has its own settings, independent of the others
    • Play starts the programmed patterns for all channels, you don't individually play them
      • autoplay means the pattern begins immediately after being programmed
    • 0 has no special meaning
    • In Java, every variable defaults to 0, null, false, etc. unless otherwise initialized to another value.  So if you don't specify anything, then it is 0.
    • There is a blink mode available but that is just a special case of having rise and fall time fixed at 0ms
This discussion has been closed.