neopixel issues with RG 0.6 boards

jdlombardo

hello: i just received some new RG boards (hw 0.6 fw 1.3.6), and am having trouble getting existing neopixel code to work properly on them. 

using the most recent iOS sample app, with the neopixel set to GRB, Slow, GPIO - 0

selecting red gets a mostly blue with some red; selecting blue gets a very dim blue; selecting green gets nothing. turning off gets bright green.

something seems to have changed...! 

help please. thank you.

jdlombardo

...everything works fine on an older RG board (hw 0.5 fw 1.3.6)

Eric

Ah yes, the firmware needs to be updated to work with the new NRF52 soc on the 0.6 boards.  We'll get a firmware update out for you soon.

jdlombardo

thank you very much!

do you have an ETA? we have some customers waiting on these.

Eric

Right now, I'd say end of the week but I'll try to get a better estimate.

jdlombardo

very good, thanks!

Eric

We have a beta firmware release that fixes the NeoPixel issue.  Use MetaBase to update your firmware to 1.3.7.

jdlombardo

thank you. this mostly works.

 if the "driver speed" is set to "Fast" it works fine.

 if the "driver speed" is set to "Slow" setting the colors works, but turning the neopixel to "Off" does not entirely work; it ends up with a dim glow from the LED.

jdlombardo

addendum: this is on neopixels that should work with the "slow" setting. normally they do not work at all with the "fast" setting, so right now it is somewhat of an inversion of expected behavior. 

Eric

I'll pass this on to our firmware dev.  Out of curiosity, what strand model are you using?

jdlombardo

individual ones of these: https://www.adafruit.com/product/1558

Matt

@jdlombardo

Those neopixels should be used on fast mode (800kHz).  It looks like the latest driver chips do not have a slow mode at all anymore, so their normal is always our "fast".

Our timings were based on WS2811 slow and fast modes.  Fast mode is nearly identical to SK6812 (which Adafruit says all their latest gen neopixels use) in timing and should work just fine.

Are you seeing any issues in fast mode?

jdlombardo

@Matt ;

interesting, thank you.

fast mode works fine with 0.6 RG boards w/1.3.7 firmware. is only odd that the same neopixels need slow mode to work properly on 0.5 RG boards w/1.3.6 firmware  ¯\_(ツ)_/¯    it's easy enough to put a switch in the code to differentiate, so I guess all is ok. 

Matt

@jdlombardo

That is odd.  RG r0.5 could not generate as precise of signal for the fast mode due to its clock rate, though it would have been in spec to its original target (fast mode ws2811).  The slight change in timings on the SK6812 may have made the old fast mode out of spec.

If we continue to see any issues we may need to change the timing paradigm to make it more configurable -- the timings on WS2811/12/12B and SK6812 are all different enough that they are not necessarily compatible.

jdlombardo

@Matt ; 

thanks for the info. odd indeed.

FYI: in continued testing I'm seeing some more issues on the 0.6 boards w/1.3.7 

- in "slow" mode, red / green / blue work properly but after turning any of the colors on, the "turn off" command yields a dim green.

- in "fast" mode, the red and blue commands work but at reduced brightness. green works at full brightness, and off works.  trying other colors in code seems to indicate the reduced red / blue brightness is across the board, for example asking for pure white yields a greenish white. 

Matt

@jdlombardo

Lets focus on fast mode because slow is invalid for these new type pixel strands.

Regarding fast mode and reduced brightness, this should imply that the "1" code is an issue for the pixels to receive.

In your "pure white" test, do all LEDs in the strand end up having the same tone?  How repeatable is the result? (marginal timing should generally be inconsistent).  Green is the first color code to be transmitted which could have significance.

Any chance that you have a two channel oscilloscope and could capture one pixel's worth (24 bits) of signalling at the input and output of the first pixel in the strip?  This would help to quickly confirm whether the first pixel is receiving the intended color codes.

Otherwise, I can adjust timings slightly to be more inline with the SK6812 vs WS2811 (fast), but that would be more of a guess.  Note that the timings as generated on 1.3.7 should already be within spec with some margin.

Matt

I wanted to note this as well from the SK6812 datasheet, this is the only spec they have for brightness:

Could the doubled green intensity be working as expected?  Do you have a reference point for how "pure white" should look -- presumably using the old model RG.

jdlombardo

> do all LEDs in the strand end up having the same tone?  

not sure, i'm using a single-neopixel "strand". i can build an strand with multiple neopixels next week and see.

> How repeatable is the result? (marginal timing should generally be inconsistent).  Green is the first color code to be transmitted which could have significance.

it is perfectly consistent. 

> Any chance that you have a two channel oscilloscope and could capture one pixel's worth (24 bits) of signalling at the input and output of the first pixel in the strip?  This would help to quickly confirm whether the first pixel is receiving the intended color codes.

sadly, no oscilloscope! but i'd be happy to send you some of the neopixels i'm using if that would help. 

> Could the doubled green intensity be working as expected?  Do you have a reference point for how "pure white" should look -- presumably using the old model RG.

yes, i am using an older model RG as a reference (also an old R board). 

i've also tested with white, pure red / green / blue, and various color combinations (half red / half blue = purple, etc.), and all are affected equally. i don't have equipment to measure luminance, but in general it seems like the green portion is working at 100% while the red and blue are at about 25% as compared with the old versions.

it's possible that things were out-of-spec previously and now are in-spec? not sure. 

----------------

i had customer orders waiting, so i did an ugly hack to use slow mode when displaying colors, then deinitialize the strand, then initialize in fast mode to turn it off. shrug.