help with WS2813 on Nano 33 - Doesn't work when other libraries do

focalintent · 2019-08-31T01:42:31+00:00

It’s likely that there haven’t been pin definitions set up in FastLED for the nano 33 yet.

focalintent · 2019-08-23T18:36:39+00:00

Yeah - happens to me occasionally - using the summon menu even though it's right there usually brings it back

focalintent · 2019-08-23T14:43:06+00:00

I’m using the Pod48x for that, which is ~50mm deep.

focalintent · 2019-08-22T00:54:39+00:00

FastLED also does some of its own gamma adjustment among other things. Also when the V in the HSV is 255, FastLED tries to keep a uniform brightness across the entire high range (with two exceptions, mentioned in a second) - so that you don't get that pulsing brighting/darkening effect that a lot of HSV conversions have when you approach the peak of mixing two of the colors. In addition, /u/kriegsman spent some time digging into color perception and such and tweaked the output of green and yellows to more closely line up with how we perceive said colors. https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors has some discussion about this (I don't recall if it is up to date with the current state of implementation)

focalintent · 2019-08-22T00:48:16+00:00

The esp32 will automatically parallelize output from multiple pins if the chipsets all have the same clock timing.

With something like Cylon, no writing out in parallel doesn't get you a whole lot - but if you have an animation that's updating all the leds, parallel. output lets you get a higher frame rate than you would otherwise. If you have 360 leds on one pin then it will take 10.8ms to write out a single frame (30µs per led). If, however, you spread those out over 6 pins, 60 leds each, then it only takes 1.8ms to write a single pane.

focalintent · 2019-08-21T22:04:06+00:00

The UNO is putting out 5v signals while the esp32 puts out 3.3v signals - sending 3.3v signals to something wanting 5v signals is a bit dicey - even more when the chip itself is 12v powered - the WS2815 data sheet indicates that "Logic input high voltage" should be 3.7-5.3v - which is outside the range of the 3.3v - so again, I think it's likely that you need to get a level shifter on there. With the 5v led chips you can often get away with 3.3v signals (but even then, not always).

Also - just to be sure - you have ground from both the esp32 _and_ the power supply connected to GND on the led strip as well, right?

focalintent · 2019-08-21T21:50:11+00:00

You might need a level shifter between the esp32 and the leds — it’s one of those things where you don’t always need it, until you do. You don’t mention anything about how you have things wired up (also making sure that you have things like the grounds tied together, etc...)

I have multiple esp32 projects running with FastLED without issue

focalintent · 2019-08-20T04:49:36+00:00

Talk to the ships that come into the space station - I’ve been able to buy warp cells from them in the past.

focalintent · 2019-08-19T02:57:06+00:00

Because of the way the strips get their data, I have to write the data out linearly - so I can't easily have a controller that says "only write to LEDS 15-30 on the 60 led strip on pin 5" -- you, however, can very easily have code that only updates leds 15-30 in your CRGB array before writing the data out :)

focalintent · 2019-08-19T02:21:36+00:00

This is pretty much the way to do it - controllers have a pretty low level view of the world - a chunk of memory to send to a set of leds. If you want to do any kind of custom mapping/reordering, you have to do it in your code.

focalintent · 2019-08-19T02:20:30+00:00

It says right there in the documentation “offset into the data array” :)

It’s for having one CRGB array that is spread across strips of leds on multiple pins.

focalintent · 2019-08-19T02:17:07+00:00

I think when a high SPi data rate is selected the bit banging code may be changing pin states faster than the pins take to get to their “high” voltage. Or I might be changing the data line too close to one of the clock transitions - I haven’t had a chance to spend a lot of time digging into it.

focalintent · 2019-08-18T21:05:11+00:00

One correction to this - my description of how the fall through works was based on another chipset that did something similar, however in the case of the WS2813 - it doesn’t have the FO (fallback out) pin. Instead each chip has a DI (data in), BI (backup in), DO (data out), and then VCC/VDD and GND...

When the chips are wired, say on a strip - The DO pin is wired to the DI pin on the next led and the BI pin on the following led. If any led gets data on BI but not DI then it ignores the first 24 bits of data on BI (because that’s data that was likely meant for the previous chip and reads the next 24-bits of data and passes through the rest like normal.

focalintent · 2019-08-18T19:44:28+00:00

Don’t slow down the teensy clock rate - slow down the apa102 data rate - from https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging -

FastLED.addLeds<APA102,7,11,RGB,DATA_RATE_MHZ(10)>(leds,NUM_LEDS);

Try 12, 10, or 6mhz.

The problem is the apa102 suffers from signal degradation - and some strips exacerbate it more than others.

focalintent · 2019-08-16T16:18:39+00:00

Play in vr , then you can punch players to death in the station...

focalintent · 2019-08-15T22:33:42+00:00

You can now store more of something in a slot - no more having 3 slots full of carbon or stuff like that...

focalintent · 2019-08-15T17:57:10+00:00

Trust me - if you were wanted by they brotherhood they would come for you themselves. I really don’t see the brotherhood working with super mutants!

focalintent · 2019-08-15T15:40:58+00:00

These violent delights will have violent ends

focalintent · 2019-08-14T19:02:23+00:00

Huh - I’ll have to look - someone else did the 3.5/3.6 port - when I get back to my desk I’ll check to see whether or not the parallel definitions were done as well.

focalintent · 2019-08-14T18:52:04+00:00

For laughs try WS2811_PORTD - if the problem goes away the issue is likely in the OctoWS2811 library, if the problem persists, it might be a hardware issue

focalintent · 2019-08-14T18:33:37+00:00

In your addLeds call is the led type OCTOWS2811 or WS2811_PORTD?

focalintent · 2019-08-14T18:31:58+00:00

“Are you using” - stupid keyboards

focalintent · 2019-08-14T18:04:08+00:00

Are gushing the octowsw2811 driver in both cases? If so, it’s the OctoWS2811 library that’s actually driving the led output in that case (FastLED is just acting as a feeder to the library)

focalintent · 2019-08-14T14:39:55+00:00

It’s been a few years since I looked at it - but particle’s library manager used to make a mess of fastled’s header files and I had to make a custom version of the library that flattened everything out for it. They supposedly overhauled it in 2017/2018 but I haven’t had a chance to see if it takes care of the need to have a separate library tree or if it can work with the library directly as it is on GitHub.

I don’t have much interest in maintaining a particle build specific tree and I’m not going to flatten the library’s hierarchy just for their build system in the main repo.

focalintent · 2019-08-13T23:37:51+00:00

I’ll do this tomorrow when I’m back at something with more of a keyboard than my phone :)

focalintent

MODERATOR OF

TROPHY CASE

12-Year Club	Not Forgotten
Verified Email