Is a delay/wait required to stop LEDS from blinking after connecting a Wiimote?

I have implemented a specialized Bluetooth stack to connect a small microcontroller to a wiimote. After much trial-and-error, it seems that when first sending an output report to set the state of the wiimote user LEDs, a pause is needed or they will continue to blink? Has anyone else seen that? Here's what I've observed:

1) Once an HID connection is established, I originally attempted to cause the LEDs to cycle from LED1, then LED2, 3, 4, and repeat. I sent output report 0x11 with the single data byte holding the proper value (bits 4-7 representing LEDs 1-4, respectively, and bits 0-3 cleared). I then verified that the setting was received by the wiimote by sending output report 0x15 and reading the current state of the LEDs from the 3rd data byte of the reply input report 0x20 . The LED values in the received input report matched what I had set, but the LEDs kept blinking as if I had not set a value.
2) After experimentation, I determined that by slowing down the cycling through each of the LED settings the flashing would stop and the desired pattern would be displayed (at a slower speed due to the inserted delay). The delay needed to be something greater than 1/2 second between sending the next LED setting.
3) Further experimentation showed that if I send an initial LED setting and then delay (at least 1/2 second) before sending any others, I could remove the delay between any subsequent changes to the LED settings, achieving the pattern in full-speed - limited only by the speed of my BT stack implementation.

This seems to indicate there is some additional "initialization" time that must be observed after sending the first output report to stop the LED flashing.

Questions:

1) Has anyone else seen this?
2) Is it documented? (I did not find it anywhere. If not, should it be?)
3) Is there any known explanation for this?

Thanks.

* to clarify: I'm sending
a2 11 10; a2 11 20; a2 11 40; a2 11 80; repeat;