Small number of LEDs don't turn off #184
Comments
|
|
Last ten, though it's a bit odd, it's almost as though they don't register
for the config. The highest number is right before they start.
What do you mean device wise? It's an Elegoo EL-CB-001 UNO R3 Board
ATmega328P ATMEGA16U2 with USB Cable for Arduino
https://www.amazon.com/dp/B01EWOE0UU/ref=cm_sw_r_cp_apa_i_72f.Ab09S9872
And
BTF-LIGHTING WS2812b 5m 60leds/pixels/m Flexible Black PCB Individually
Addressable Led Strip Dream Color Non-waterproof DC5V 16.4ft
https://www.amazon.com/dp/B01CDTEJBG/ref=cm_sw_r_cp_apa_i_33f.AbHT5WT85
On May 16, 2018 1:59 AM, "Patrick Siegler" <[email protected]> wrote:
- Are these the first or last 10 LEDs?
- Which device?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#184 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACK1j-Kw8CJt4T45P6nPkBvWDIW_NwC1ks5ty8AtgaJpZM4UAgDf>
.
|
|
I'm assuming you're using Adalight? How many LEDs are you running, total? And what is your baud rate? |
|
Yup. Actual count is 186 I think, but it's 189 in the program due to only
one side measurement. I've tried playing with that to no effect. Baud is
set at 460800.
…On Wed, May 16, 2018, 8:11 PM David Madison ***@***.***> wrote:
I'm assuming you're using Adalight?
How many LEDs are you running, total? And what is your baud rate?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#184 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACK1j3M1hQ_2kEkMK94-dAsVLw3v-4moks5tzMA_gaJpZM4UAgDf>
.
|
|
What do you mean "due to only one side measurement"? Are you using my driver code? If so, what happens if you let the LEDs idle for a minute? Do all of the LEDs turn off then? |
|
If I'm not mistaken it's 30 on one side and 34 on the other. Top and bottom
are separated so inequality numbers work, but sides are lumped together,
one of my sides happens to have a few more LEDs. It doesn't seem like this
has an impact other than the shifting of zones somewhat, and it doesn't add
up to the 10 trouble ones.
I am using your adalight-fastled reworking, along with prismatik.
On idle all other lights go off, but the 10 remain on.
…On Wed, May 16, 2018, 8:51 PM David Madison ***@***.***> wrote:
What do you mean "due to only one side measurement"?
Are you using my driver code? If so, what happens if you let the LEDs idle
for a minute? Do all of the LEDs turn off then?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#184 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACK1j17-qwzjkzZSvtOBjWj6C1TIw1FAks5tzMmPgaJpZM4UAgDf>
.
|
Then it's an issue with your LEDs, power, or wiring. |
|
So, went through and solved it. After two hours of subbing out strips, and
a lot of wasted leds, wire and curses, I can confirm it was definitely a
software issue. An erroneous value crept in to arduino code and that was
causing the hiccup. I find it interesting that they worked for zoning, but
not for turning off, but the more you know.
Total aside, but I two separate questions. First, any tips on update
rate/baud balancing? I've current got a huge amount of FPS variance, from
single digits to 50ish and I'd like to keep it higher/ more consistent.
Second question, is have you played around with Hyperion? I've liked this
version of Prismatik, but I'm interested in integrating the lights to my
smarthome system, and as I understand it that means either a new more
expensive board, or switching capture software and there's some manner of
Hyperion plugin that would do it. I haven't heard from anyone who's used
both, so I thought you might have insight.
Thanks for the support. I appreciate it and your work is great.
…On Wed, May 16, 2018, 9:49 PM David Madison ***@***.***> wrote:
On idle all other lights go off, but the 10 remain on.
Then it's an issue with your LEDs, power, or wiring.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#184 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACK1j1Blw1N4rZP5gnJO8TMcXAzQA6ttks5tzNcbgaJpZM4UAgDf>
.
|
|
Can you share what the problem was? Is there a bug in the Adalight code, or did you have a typo somewhere? Re: update rate / baud balancing: higher baud the better until you're device starts showing errors. Lowest grab rate possible until you saturate the bus with data, then your framerate will drop significantly. The equation here is a good place to start. Note that the reported framerate number in Prismatik will fluctuate wildly in the WinAPI mode, as it doesn't generate new frames if the data hasn't changed. I have not played around with Hyperion, and from what I remember it wasn't really built for capturing directly from a display (though that may have changed). Prismatik has an API and a plugin system, so if you're feeling adventurous you could write a smarthome plugin. Though you'd need to have the PC on for it to work. |
|
Adventurous but incompetent haha. Sorry if I wasn't clear, I typoed, or
more accurately copied a setup from a second device I set up and missed
changing one variable, in short the total led count was wrong, it just
manifested in a way I didn't expect and was off to a number that seemed
right.
I hadn't processed that update was only happening with changed data, but
that makes sense. I think I'm probably pretty close to the limit in that
case. I might play with bumping the baud rate up to the next level, but I
feel like that might be where I hit the wall.
I'll check out the API a bit more, but my depth extends about as far as
changing variables in functional code, not so much creating my own.
…On Thu, May 17, 2018, 12:36 AM David Madison ***@***.***> wrote:
Can you share what the problem was? Is there a bug in the Adalight code,
or did you have a typo somewhere?
Re: update rate / baud balancing: higher baud the better until you're
device starts showing errors. Lowest grab rate possible until you saturate
the bus with data, then your framerate will drop significantly. The
equation here
<http://www.partsnotincluded.com/ambilight/calculating-adalight-framerate-limits/>
is a good place to start. Note that the reported framerate number in
Prismatik will fluctuate wildly in the WinAPI mode, as it doesn't generate
new frames if the data hasn't changed.
I have not played around with Hyperion, and from what I remember it wasn't
really built for capturing directly from a display (though that may have
changed). Prismatik has an API and a plugin system, so if you're feeling
adventurous you could write a smarthome plugin. Though you'd need to have
the PC on for it to work.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#184 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACK1j8KepWWJ6wsBCwF8NkF-zF-3dLcOks5tzP5YgaJpZM4UAgDf>
.
|
|
Just to confirm, when bumping the baud rate, the same rate should go into
the serial speed in the arduino code, as well as within Prismatik config?
Bumping it up to 921600 doesn't seem to have had an impact, roughly 30fps
average. I haven't found a grab rate that substantially affects the claimed
fps either. 5-13 all turn out roughly the same, and going lower it only
drops by a few. Thanks.
On Thu, May 17, 2018 at 12:59 AM, Charles Uchendu <[email protected]>
wrote:
… Adventurous but incompetent haha. Sorry if I wasn't clear, I typoed, or
more accurately copied a setup from a second device I set up and missed
changing one variable, in short the total led count was wrong, it just
manifested in a way I didn't expect and was off to a number that seemed
right.
I hadn't processed that update was only happening with changed data, but
that makes sense. I think I'm probably pretty close to the limit in that
case. I might play with bumping the baud rate up to the next level, but I
feel like that might be where I hit the wall.
I'll check out the API a bit more, but my depth extends about as far as
changing variables in functional code, not so much creating my own.
On Thu, May 17, 2018, 12:36 AM David Madison ***@***.***>
wrote:
> Can you share what the problem was? Is there a bug in the Adalight code,
> or did you have a typo somewhere?
>
> Re: update rate / baud balancing: higher baud the better until you're
> device starts showing errors. Lowest grab rate possible until you saturate
> the bus with data, then your framerate will drop significantly. The
> equation here
> <http://www.partsnotincluded.com/ambilight/calculating-adalight-framerate-limits/>
> is a good place to start. Note that the reported framerate number in
> Prismatik will fluctuate wildly in the WinAPI mode, as it doesn't generate
> new frames if the data hasn't changed.
>
> I have not played around with Hyperion, and from what I remember it
> wasn't really built for capturing directly from a display (though that may
> have changed). Prismatik has an API and a plugin system, so if you're
> feeling adventurous you could write a smarthome plugin. Though you'd need
> to have the PC on for it to work.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#184 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACK1j8KepWWJ6wsBCwF8NkF-zF-3dLcOks5tzP5YgaJpZM4UAgDf>
> .
>
|
|
Yes, the same rate should go in the serial speed in the code as well as in the Prismatik config. You won't see the drops in the reported framerate from Prismatik. If the delay between frames is less than the LED latch time (~5.6 ms for 186 LEDs) frames will be silently dropped by the Arduino and the displayed framerate, i.e. what is actually being shown on the LEDs, will drop significantly (#117). If the bus is fully saturated, not only will your frames drop, but Prismatik will keep filling the PC-side serial buffer and you'll build up a delay between the rendered frame and when it is displayed on the LEDs. Although to quote Westworld: if you don't notice, does it matter? There is no solution to either of those issues at the moment, except for being mindful of them and configuring the device properly. This is also why I keep stressing keeping the # of LEDs low, although no one seems to listen 😐. If the dropped frames bother you the easiest thing to do is switch to another LED chipset that doesn't disable interrupts (APA102 e.g.). |
|
If it's just a matter of observed framerate than I simply haven't played with it enough to tell. My debugging on this go around has not involved much observation of the leds as opposed to seeing what showed as values within Prismatik. LED count is good advice, but it's virtually invisible until one really digs into this project, as with different chipsets. None of the instructables/blogposts/youtube videos mention overdoing it, nor that there's a functional reason to get a different LED set. I chose this one specifically because it was listed as 'one of the good ones' repeatedly. Little did I know XD. I suspect it's one of those things where the jump from casual project to enthusiast/nitty gritty side of it is too big. I'd consider myself reasonably technically competent, and psieg's walkthrough/experience was a bit intimidating. |
I'm not entirely sure whether this is a Prismatik issue, but about 10 contiguous leds are not turning off. Otherwise they behave normally, reacting to color, but they don't go off.
The text was updated successfully, but these errors were encountered: