While programming red lights i noticed that they where lightning green. So I changed the Code to NeoPixelColors.Green and then the lights where lightened red.

When I executed the source code below, I guessed that the LED will turn on in red because LEDColor = neopixel.colors(NeoPixelColors.Black) at line 9. However, the LED turned green.

function setLED (color: number) {
    strip.showColor(color)
    LEDColor = color
}
let LEDColor = 0
let strip: neopixel.Strip = null
strip = neopixel.create(DigitalPin.P0, 3, NeoPixelMode.RGB_RGB)
setLED(neopixel.colors(NeoPixelColors.Black))
if (LEDColor == neopixel.colors(NeoPixelColors.Red)) {
    setLED(neopixel.colors(NeoPixelColors.Green))
} else {
    setLED(neopixel.colors(NeoPixelColors.Red))
}

Source : https://makecode.microbit.org/_Pdf0pyWJg01i

However, when I removed the "else" part at line 11, the LED did not light up in red somehow.

Source : https://makecode.microbit.org/_Kmv4wkM7h718

I am wondering if this phenomenon is an implementation error or a defect.

• OS: Windows 10 Home
• Browser: chrome(ver 75.0.3770.142(Official Build)(64 bit))
• makecode.microbit.org version: 2.0.6
• Microsoft MakeCode version: 5.15.12
• microbit runtime version: pxtgc-0

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

I don't know Japanese, but it seems the ease brightness block has lost its value in the translation?

https://github.com/Microsoft/pxt-neopixel/blob/master/_locales/ja/neopixel-strings.json

The documentation for this package is not complete - right-clicking on 'help' for any of the NeoPixel package docs takes you to this very basic docs page, and many of the blocks have no help at all.

https://makecode.microbit.org/pkg/microsoft/pxt-neopixel

Given that this is an approved package, it must have gone through an approval process. Does the approval process check correctness and accuracy of the documentation?

This has surfaced directly into makecode.microbit.org so presumably it has passed the micro:bit Foundation's quality review process??

Could be ask the authors to complete the documentation for this package please?

Thanks!

We have Problems using the neopixel library because of missing math functions.
As a workaround we have to add

// notwendige Funktionen für das aktuelle Neopixel-Paket
namespace Math {
export function idiv(x: number, y: number) { return x / y }
export function round(x: number) { return x }
}

So I think we need this two functions in makecode ? ;-)

The values returned from the power() method appear to rise too rapidly as LEDs are successively lit. This value also tops out well before all LEDs in a strip have been lit.

Please see the serial output in this example: https://makecode.microbit.org/31482-02041-35523-64723

ledoffset is defined inside the power() method but never used. I presume that this variable should be used in the following line:
p += this.buf[i + j]; as observed elsewhere in the code?

Looks like Chinese localization reference was removed from the pxt.json and now the translation is not loaded when the editor is in Chinese

Simplest repeatable failing test: https://makecode.microbit.org/_h6z4oXJo0Tdd

let item: neopixel.Strip = null
item = neopixel.create(DigitalPin.P0, 20, NeoPixelMode.RGBW)
item.range(0, 10).showColor(neopixel.colors(NeoPixelColors.Green))

Expected Behaviour: Should see pixels 0 - 9 all green

Actual Behaviour: Pixels 0 - 6 are Green,Blue,Red,Green,Blue,Red,Green, 7-9 not lit (on simulator and on real RGBW neopixels)

(Switching between the other neopixel modes shows this working ok in GRB or RGB but not RGBW.)

Test Platform: Chrome 67.0.3396.62 and Safari 11.1, both on OSX 10.13.4

Neopixel-library seems to malfunction and cause issues with the internal mechanics of the microbit, if pause or forever-loop is not used.

Without neopixel-library:
When writing a code inside "run in background", and having everything inside a while(true), the code is reacting to button-presses and keeps track of time by using millis. For example, pressing a button that turns on a LED in e.g. pin1 for few seconds works fine.

However, after adding the neopixel-library and changing the code to use neopixels instead of LEDS breaks the functionality with reading pins and buttons. This extends to the radio as well, which ceases to work.

Curiously, inside "run in background" while(true), neopixels do work with millis alone. It is so far only when buttons/pins are used, or the radio is used, that the behaviour breaks.

Finally, if one adds pause(0) or moves the code to forever-loop, the code works and there are no issues (other than a very slow code due to the microbit itself). This, however, slows down the code to the point of being useless for reactive interactions.

There appears to be a dependency on block order for the neopixel package set brightness block.
Used on its own the block does not change the brightness of the LED.
If it is followed by a show colour block then the brightness changes. 
Additionally it only appears to change the brightness of the pixel that has been coloured.
This script:
https://makecode.microbit.org/_Ra5f7VR9xVXf
shows button A does not change brightness, button B does.
Initially reported to micro:bit support as issue 2678, Jonny suggested posting this directly here.

Unlike pxt-common-packages, there's no way to query a color of a specific pixel.

"In circuit playground, you have a block "pixel color at 0" which returns the colour of that light. Is this block available in micro:bit for strips that you add on? e,g. I want to know what colour light 4 is in my RGB strip?"

User request:
https://twitter.com/LMcUnderwood/status/1006204237834018816

The ShowRainbow block in the neopixel library seems to have broken in the last 3 weeks.

Simplest repeatable failing test: https://makecode.microbit.org/_aupazuXU3HiH

• Expected Behaviour: Pressing button A should distribute a rainbow across the LEDs.
• Actual Behaviour: Pressing button A sets all pixels white.

Further testing: If I switch to JS mode, open explorer, and change pxt.json to use “github:microsoft/pxt-neopixel#v0.6.2” instead of the 0.6.4 or 0.6.3 versions, the rainbow function behaves correctly again.

Test Platform: Chrome 67.0.3396.62 and Safari 11.1, both on OSX 10.13.4

When adding the neopixel-package on https://makecode.calliope.cc/, no program (even without using any of the packages blocks etc.) transferred to the calliope mini will work.

I'm thinking about creating a new block that would ideally be an array but visually it should look similarly to the 'show leds' or 'create image' blocks with a grid 10x10 of input fields. Any guidelines on how to get started or what would be the best approach to do that?

Hello,
I use the driver in a older Version on Calliope mini with hsl Colors.
In the old Version the hsl function has a export statement on this function.
The actuell version has a function called hslToRgb without export.

Why? I need it.

What's the problem?

I was writing program with MakeCode(JavaScript mode) and this package.
I finished coding and try to convert my program to block.
But when I look at block programs...i noticed. Value runs away!!!

What's it like?

like this image.

What kind of program were you writing?

There's JavaScript source code. (Sorry for comment written by Japanese)

//絶対これブロックに変換するなよ！！！絶対だからな！！！フリじゃないからね！！！！いやほんとに！！！！！
input.onButtonPressed(Button.A,function(){//ここはon/off切り替え処理です 基本いじらなくていいとおもふ
    if(!onflag){
        onflag++;
    }else{
        onflag=0;
    }
})
input.onButtonPressed(Button.B,function(){//明るさ調節 今は5段階にしてるけど調整したかったら調整してね
    if(brightness==20){//減らしていく値を変更したときにいくつで最大に戻すか
        brightness=100;//MAXは100です
    }else{
        brightness-=16;//16ずつ減らしていく
    }
})
let onflag=0,brightness=100,strip:neopixel.Strip=neopixel.create(DigitalPin.P1,9,NeoPixelMode.RGB);//初期化の翁
while(onflag){//onのときだけ実行されるやつら
    for(let l=0;l<=8;l++){//真ん中以外の制御
        if(l==4){continue;}//真ん中を飛ばす
        strip.setPixelColor(l,neopixel.hsl(randint(0,50),360,(input.soundLevel()/255*300+60)*brightness/-100+360));//大体赤～オレンジでランダムにしてる うるさいと暗くなります
    }
    strip.setPixelColor(4,neopixel.hsl(0,0,brightness*3.6));//真ん中の制御 白～黒にしてるけど文句あったら言ってね
    strip.show();//表示
    basic.pause(1);//1/1000秒のリアルタイム更新
}

Could you fix this? Thanks

How to add different languages?

Recently, the Chinese translation was added to the neopixel package. The translation in _locales/zh should be Traditional Chinese, but now in the _locales/zh is Simplified Chinese.

Simplest repeatable failing test: https://makecode.microbit.org/_YmYf9i6AzAxA

Note: This behaviour isn't visible in the simulator (perhaps because the simulator is only showing the number of LEDs configured by the create() call). In the real world this would only be noticed if neopixel.create() was called with a lower number of pixels than actually contained on the physical strip.

let lightStrip: neopixel.Strip = null
lightStrip = neopixel.create(DigitalPin.P0, 3, NeoPixelMode.RGBW)
basic.pause(1000)
lightStrip.showColor(neopixel.colors(NeoPixelColors.Red))
basic.pause(1000)
lightStrip.clear()
lightStrip.show()

Expected Behaviour (on real strip): Should see pixels 0,1,2 all red, only

Actual Behaviour (on real strip): As expected except pixel 3 is lit green and stays on after the clear()

Notes: I've tested with various configured lengths, whether 3, 15, or 60 pixels, the library call will always light this extra (last + 1) LED green. This discounts the possibility that the issue is simply a bad pixel in my hardware.

The block "set pixel color at" breaks if the input index is a decimal number. Please make it cast the input to integer. (For example the map block outputs decimals in the new editor)

To avoid floating point.

Neopixel extension pack can't switch language.

After i add Neopixel extension pack, when i switch language it can't change language.

As shown below. Is there any solution for this problem.