ONE MAN ARMY

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.

🎛️ B1–B4 Case Commands

B1–B4 bits are part of each frame’s data in a ZLEDS animation. When a frame starts with a value between 1 and 15, these bits trigger a built-in command instead of lighting up LEDs directly. These commands let you adjust playback behavior on the fly, such as brightness, speed, or fade style, all within the animation itself.

Case 1 through 14 commands will still display LEDs based on the values from L1–L40, allowing each frame to both light up and adjust playback characteristics.

Case 15 is reserved for advanced instructions. In this mode, the LEDs from the last non–Case 15 frame remain lit while the new frame uses its L1–L40 data exclusively for internal control actions like memory jumps, loop logic, or playback rules.

This allows sequences to adapt dynamically as they play, giving you professional-looking results without needing external controls.

🟠 = Bit ON, ⚪ = Bit OFF

💡 PWM Brightness (L1–L4)

⏩ Playback Speed (L5–L8)

🌅 Fade In (L9–L10)

🌇 Fade Out (L11–L12)

🧠 Memory Slot Jump (L13–L16)

🎞️ Mini Loop Start Frame (L19–L24)

Marks which frame should begin the mini-loop. Must be paired with a valid repeat count (see next table), or this command will be ignored.

Value	L19–L24	Description
0		No action
1		Start loop at Frame 1
5		Start loop at Frame 5
17		Start loop at Frame 17
33		Start loop at Frame 33 (maximum supported)

🔁 Mini Loop Repeat Count (L25–L32)

Defines how many times to repeat the mini-loop. If set to 0, the mini-loop command will be ignored.

Value	L25–L32	Description
0		Disable loop
1		Repeat 1 time
3		Repeat 3 times
16		Repeat 16 times
255		Maximum repeat count

⚠️ Disclaimer

All B1–B4 CASE commands have been tested extensively. However, due to the open-ended way these commands can be combined, there may still be unintended results.

The ZLEDS system does not currently include safeguards to prevent conflicting command combinations. Using multiple CASE commands in quick succession or applying them improperly may result in:

• Flickering or frozen LEDs
• Unexpected brightness or speed shifts
• Playback glitches or controller confusion

Tip: Test your custom sequences thoroughly before live use.

Back-to-back CASE commands may stack or override depending on the effect. For example, increasing brightness followed by instant off may cancel the visual change. It’s best to space them between visual frames for smooth playback.

Yes, multiple CASE commands can be used across a sequence. However, poor combinations or improper order may cause glitches or unwanted behavior, especially without visual frames between them.

Yes. CASE commands are stored as part of the animation sequence in memory, just like visual frames. Each one counts as a frame and is executed during playback.

A frame is interpreted as a CASE command when the B1–B4 bit pattern matches a value from 1 to 15. These are reserved and treated as instructions rather than LED output data.

Not currently. The app does not have built-in safeguards or validation for unsafe combinations. It’s recommended to test your sequence carefully and avoid stacking multiple CASE commands without purpose.

⚙️ CASE 15 Overview

• Triggered when B1–B4 = 1111 (🔴🔴🔴🔴)
• The frame must include at least 5 bytes total
• Bytes 1–4: Fixed structure (bank, timing, brightness, etc.)
• Byte 5 (L command byte): Determines the specific CASE 15 behavior
• Additional bytes may be used depending on the command

🧠 What makes it different?

• CASE 15 uses additional bytes in the frame to define dynamic behavior
• It’s essentially a mini-program embedded in your animation
• This enables advanced logic such as:
  • Looping a range of frames (mini-loops)
  • Switching memory slots mid-sequence
  • Overriding brightness, speed, and fade temporarily
  • Triggering timed or reactive lighting effects

⚠️ Important Notes:

• CASE 15 is powerful but risky if misused
• If the data bytes are missing, invalid, or misaligned, you may experience:
• – Skipped frames
• – Frozen LEDs
• – Unstable or broken playback
• No app safeguards are currently in place, so test carefully

📘 CASE 15 Command Table

🧩 Example:

You might use CASE 15 to loop frames 2–6 three times, or to temporarily dim all LEDs during a strobe effect.

Yes. Unlike standard CASE commands (1–14), CASE 15 is designed to combine multiple dynamic instructions into a single frame.
Each command uses different bits in the extra data bytes, so they don’t conflict.

Example:
One CASE 15 frame can simultaneously:

• Start a mini-loop
• Set temporary brightness
• Adjust fade-in/fade-out timing
• Switch memory slots

The extra bytes after the 🔴🔴🔴🔴 header are divided into bit fields, like so:

If you set values in multiple fields, the controller will apply all of them during that frame.

No strict order is required. The firmware applies all configured fields within the frame in a logical sequence:

1. Playback settings (speed, brightness, fade)

2. Loop setup

3. Memory slot switch (if any)

4. Continue to next frame

Only the fields that contain non-zero or valid data will be applied.
For example, if only L5–L8 (speed) is set and everything else is zero, only the speed override will take effect.

CASE 1–14 perform a single, fixed effect like changing brightness or speed.
CASE 15, on the other hand, is a multi-function instruction frame that can apply several effects at once using extended bits. It behaves more like a “control program” inside your sequence.

Yes, but the effect depends on where it appears. For example:

• A fade or brightness override placed before a visual frame will affect that frame.

• A mini-loop placed at the end of the sequence may do nothing if the loop target is out of bounds.
  Always test placement carefully.

The sequence may become trapped, repeatedly looping frames.
To prevent this:

• Always verify the loop end is reachable

• Don’t stack loops within loops

Yes. You can combine:

• Fade Out setting (L11–L12)

• Memory Slot switch (L13–L16)
  This allows you to create smooth transitions between sequences across banks.

Yes. While there’s no dedicated “strobe” bit, you can simulate it by:

• Rapidly alternating brightness with looped frames

• Setting fade times to instant

• Combining mini-loops with short-duration frames

• Use the ZLEDS Bit Editor app to build one command at a time

• Start with brightness or speed overrides (safe effects)

• Test on a short 4–5 frame sequence before expanding

• Avoid using loop counters without a clear end

CASE 15 is powerful, but it follows strict rules to avoid playback errors. If these conditions aren’t met, the controller will ignore the command and continue normal playback.

🔄 Mini-Loop Rules:

• ✅ Starting frame must be 2 or higher
      Frame 1 is reserved for header/timing and cannot be looped.

• ✅ Starting frame must be less than the total number of frames in the sequence
      You can’t loop beyond the end of the animation.

• ✅ Mini-loop count must be at least 1
      If the loop count is 0 or unset, the mini-loop is skipped entirely.

🧠 Memory Bank Switching Rules:

• ✅ Target memory slot must already contain a saved sequence
      If the selected memory bank is empty or invalid, the switch is ignored.

⚠️ Why these rules matter:

These checks prevent the controller from crashing, freezing, or repeating empty data. Always validate your CASE 15 frame structure and test your sequences before deploying them in a final setup.

⚠️ If your switchback frame contains a Case 15 command, it will be ignored during playback.