Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 20 23:43
    dependabot[bot] synchronize #302
  • Jun 20 23:43

    dependabot[bot] on npm_and_yarn

    chore: bump sinon from 13.0.2 t… (compare)

  • Jun 20 23:43
    dependabot[bot] edited #302
  • Jun 20 23:42
    dependabot[bot] edited #302
  • Jun 20 23:42

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jun 20 23:42

    dependabot[bot] on master

    chore: bump eslint from 8.17.0 … Merge pull request #307 from aj… (compare)

  • Jun 20 23:42
    dependabot[bot] closed #307
  • Jun 20 23:42
    ajfisher commented #307
  • Jun 20 19:08
    dependabot[bot] assigned #307
  • Jun 20 19:08
    dependabot[bot] review_requested #307
  • Jun 20 19:08
    dependabot[bot] labeled #307
  • Jun 20 19:08
    dependabot[bot] opened #307
  • Jun 20 19:08

    dependabot[bot] on npm_and_yarn

    chore: bump eslint from 8.17.0 … (compare)

  • Jun 06 22:29
    dependabot[bot] synchronize #302
  • Jun 06 22:29

    dependabot[bot] on npm_and_yarn

    chore: bump sinon from 13.0.2 t… (compare)

  • Jun 06 22:29
    dependabot[bot] edited #302
  • Jun 06 22:28
    dependabot[bot] edited #302
  • Jun 06 22:28

    dependabot[bot] on master

    chore: bump eslint from 8.16.0 … Merge pull request #306 from aj… (compare)

  • Jun 06 22:28

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jun 06 22:28
    dependabot[bot] closed #306
KronKraken
@KronKraken_twitter
Untitled Sketch_bb.png
Would this work?
ajfisher
@ajfisher

@KronKraken_twitter Cool. Yep that will work.

Only thing to just keep an eye on is if you're getting weird drop outs on the nano it might be because the Uno isn't giving you enough supply. I haven't seen this frequently in this set up - it's more the specifics of the particular nano and uno that are in combination together.

If that happens then I'd just run a 5V line back from the end of the strip to the 5V pin on the nano and it will stabilise the supply

KronKraken
@KronKraken_twitter
Okay then! I'll just have to wait for the nano to arrive, and I shall share the results! Thank you very much for all the help!
KronKraken
@KronKraken_twitter
Oh hey! So it's been 3 days, and the nano has arrived and it works!
Finally!
ajfisher
@ajfisher
Awesome!
KronKraken
@KronKraken_twitter
Thankyou for all the help, without you I wouldn't have been able to do this.
Ben Shapiro
@bennytheshap
@ajfisher thanks again for your help! Lila got her sculpture working great.
big papa.jpg
KronKraken
@KronKraken_twitter
Hey any plans for the Ranging Feature to get implemented?
I'd really benefit from it
KronKraken
@KronKraken_twitter
or is there a documentation to the node-pixel protocol? I could work on it and make a pull request
ajfisher
@ajfisher
@bennytheshap Awesome!
@KronKraken_twitter so I started working through how it would all work but then got stuck into building tests and working on some performance things first before I started in on that.
Actually sorry - still 90% asleep and no coffee to my day yet.
That's SHIFT
ajfisher @ajfisher facepalm
ajfisher
@ajfisher
Okay so the way the ranging stuff should work is it basically you send a top and bottom ID and then a colour that you want to set them to. Protocol should probably looks like this:
0   START_SYSEX         0xF0
1   PIXEL_COMMAND       0x51
2   PIXEL_SET_RANGE     0x06
3   max 14 bit index of FROM pixel in strip LSB
4   max 14 bit index of FROM pixel in strip MSB
5   max 14 bit index of TO pixel in strip LSB
6   max 14 bit index of TO pixel in strip MSB
7   24 bit packed RGB FROM color value LSB
8   24 bit packed RGB FROM color value lower middle bits
9   24 bit packed RGB FROM color value upper middle bits
10   24 bit packed RGB FROM color value MSB
11   24 bit packed RGB TO color value LSB
12   24 bit packed RGB TO color value lower middle bits
13   24 bit packed RGB TO color value upper middle bits
14   24 bit packed RGB TO color value MSB
15   END_SYSEX           0xF7
Bytest 11-14 would be optional and I'd say don't worry about these just yet.
ajfisher
@ajfisher
Idea here is you send a ranging command and then tell it the index of the pixels you want to set from and to - I'd say this is inclusive so if it was 12 and 15 then pixels 12, 13, 14, 15 would all be affected.
KronKraken
@KronKraken_twitter
-snip- sorry i'm staying up later than I should so my mind is also a bit slow xd
I'll try that tomorrow, and I shall share the results
ajfisher
@ajfisher
No worries at all.

So by way of some additional information.

What you'd do is the following:

Depending on how gnarly you want to get there is probably an optimisation in here which is to build a byte array of memory that is the range you're after and then simply memcpy it over the range in the *pixels array. But deal with that later.
ajfisher
@ajfisher
Then on the Node side you're pretty much doing the same thing with a new method eg: strip.range(m, n).colour(rrggbb)
If you note the above you can see I've added a range intermediary there because I think API wise there's a bunch of things we could do on a range for example shifting and cycling across a range of pixels as you sort of do on a Strip already
but don't worry too much about that at this point, it's just pre-planning on the design
KronKraken
@KronKraken_twitter
So I got something working
But I've been having some difficulties implementing it in a way where the rest of the API can relate to
like to use .range().shift()
Also didn't get why you want to add a second value to the colors
So for now I think it'd be better if I don't submit a pull request
ajfisher
@ajfisher
Have you got it in a branch and I can have a look?
The rationale for the second color value was so you can interpolate between the start and end pixel across the values - eg make a rainbow in one line of code or just gradient blend between points etc.
But start with simple single colour applied to all the pixels in the range and that will be awesome - much of that stuff was so it's documented so we can go back to it as well.
Eric Brearley
@ebrearley

I just spent the weekend installing LED bling into my kitchen. Maybe a little bit to the dismay of fiancé - but hey she knew that this was part of the deal when she met me :p! ANYWAY!

The setup is a strip of approximately 300 SK6812 RGBW LEDS, controlled by an Arduino MEGA (so i wouldn’t have to worry about memory constraints).

It already looks pretty good (native Adafruit RGBW test sketch)!
http://imgur.com/Ezx08bs

I’m a web dev by day, which means i have grand plans for controlling the setup remotely. Web control, native app, wifi switches - the works. And it turns out that there’s a bit of groundwork to do.

node-pixel needs me (or someone) to:

  1. Add support for the SK6812 protocol (ajfisher/node-pixel#73)
  2. Add RGBW to the supported colourspaces (ajfisher/node-pixel#64)

And while i’m at it, add back the interchange configuration option (ajfisher/node-pixel#93) - I have a MEGA, what even is small memory capacity? ;)

I’m a newbie (one day into it now) to the world of microcontrollers, interchange, backpacks, loading firmware. Send me your un-newbie-ifying reading recommendations please! In saying that, I won’t be doing anything quickly, and I will be asking for help.

So, hI! And be speaking to you guys soon!

Eric Brearley
@ebrearley
First step is done, I have flashed my arduino with the node-pixel firmata and written a simple test app in node. The RGBW SK6812 strip lights up and it's showing a sequence of what looks like W, RGB and WR. the leading pixel is green.
IMG_1478.JPG
IMG_1477.JPG
(oh i'm showing full white, 255,255,255)
I can address each pixel individually, win!
Eric Brearley
@ebrearley
I'm assuming that this will be resolved with the addition of the RGBW colourspace
I also want to be able to address 300 pixels on a single data line, so adding that to the list too
ajfisher
@ajfisher
Apologies for tardiness on reply - I did see this yesterday but we're mid cut-over week on site launch! Love the gif and reflection in the mirror.
So I don't have any of those LEDs to play with but if you change the byte order in nodepixel config did that fix it for you?
ajfisher
@ajfisher

nvm you probably can't fix that until you pad out the white channel. You could potentially hack that in the firmware to simply pad that byte with a zero for the moment.

In theory if you bump this to 4 it should pad out the last byte as well.

https://github.com/ajfisher/node-pixel/blob/master/firmware/src/libs/ws2812/ws2812.cpp#L15

Eric Brearley
@ebrearley

No probs! I'm enjoying it! I'll try to implement it nicely tonight if I have time (instead of hacking it in) and send you a pull request. But i might resort to the hack on account of not really understanding a great deal of what I'm doing.

I was thinking of comparing the latest adafruit library and porting across node-pixel again to update it. I wouldn't mind the setBrightness() method. Although I'm sure it's not included already for a good reason.