Delay in individual strip mode #104
Labels
No labels
Core
Fixed
Godot
HardwareIssue
LEDS
Networking
Problem
SoftwareIssue
duplicate
enhancement
good first issue
help wanted
invalid
on hold
question
reminder
todo 🗒️
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
squatnet/ArduinoStuff#104
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When in individual strip mode, the delay assignment causes issues.
this is not noticable on most patterns, but becomes very apparent with the strobe.
as it takes an average of the four values of the delay on the pattern of each strip, when a fast pattern (strobe for example) is called alongside other slow patterns, it will have a noticeable affect on the speed of the pattern.
strobe doesn't look anything like a strobe, when it is the only strobe, until Tim<70(ish).
I don't have an elegant solution n mind. any thoughts?
Strobe was pulled following #102....
Seems to me that this whole thing is taking far too long and still isnt fixed.
I see 3 solutions that aren't going to take another week (that we dont really have)
Agreed it's a ball ache, my suggestion is to remove strobe from individual strip mode. Should be best if both worlds as everything else is working as intended.
I think we need to decide what the pros and cons are of all three options
and make an informed decision.
On Tue, 11 Jun 2019, 08:23 kieran-boyle, notifications@github.com wrote:
Strobe and delays are working fine on full mode.
All is working on individualStripMode strip mode other than the above issue
I think my suggestion would do the trick (add strobe is the only pattern with a large difference in delay time.) Your solution send to work ok for other patterns.
I will plug her in and check for any other outliers at Rios shortly.
Send like the simplest solution which retains as much functionality as possible.
Should literally be a case of removing it from the second switch case, and change in app to ensure parity?
Sounds good to me. Can we just say replace it with another pattern (not
even a new one) so for example it will call sinelon or something instead.
Whatever works boss. I'll be over after work today to finalise godot app
changes and such.
On Tue, 11 Jun 2019, 08:44 kieran-boyle, notifications@github.com wrote:
Yeah of course that will be simple as. We will have a play when I see you later then mate.
If I find time i'll pull out or re-write the old strobe, long before this
discoworker came about we had a less impressive but much simpler strobe
knocking around...
On Tue, Jun 11, 2019 at 9:03 AM kieran-boyle notifications@github.com
wrote:
Aye we did. May well be hanging around in the old version of strips code ~
DV1
On Tue, 11 Jun 2019, 10:05 Riiio, notifications@github.com wrote:
I would of thought that the exact same issue would present itself. problem being that a strobe needs a high refresh rate to strobe, this is much higher than the refresh rate of the other patterns.
This is not a problem when only playing one pattern at a time, but if running multiple patterns it can cause issues.
I don't see how this would fix this problem?
please note simple strobe is now working exactly as expected other than this timing issue.
When we rebuild it from the ground up we can make it use whatever delay we
like.
On Tue, 11 Jun 2019, 11:24 kieran-boyle, notifications@github.com wrote:
To be absolutely clear, simpleStrobe, strobeCore, strobeDraw will just not
exist as we will do it completely differently. Stop worrying about it. It
doesnt work right, it doesnt work. Make things simpler not more
complicated.
Move to close this.
On Tue, 11 Jun 2019, 11:26 W45T3 G45H, squatn3t@gmail.com wrote:
i am very confused. what doesn't work right with them?
i have had it well and truly tested last night after i fixed the issue?? other than the delay issue that i have created?
When I was testing the other day it was rebooting the MCUs in both
individual strip mode and all strips mode. Sometimes when strobe phase 0
was called, sometimes as soon as the pattern after was called. Removing it
fixed it and I just feel it's time being wasted at the moment. Many more
things to. Tine better spent elsewhere. If you can make it work, nicely by
the end of play today (obviously ignoring when we are running in
iStripMode) sure, cool. If not then it's being ripped out because it doesnt
play nice with delay, iStripmode, other patterns, and takes up way too
much memory anyway. If it's easier to remove and rebuild at a later date we
should do that. Very much feels like time is being wasted on this.
It works or it doesnt. It sort of works is it not working. Let's stop
wasting time on this one file now, get it working as well as possible and
then stop messing with it.
When it comes to DV3 most of the istrip code may well be unnecessary as
fastLed apparently just supports it according to Rio. Sane with variable
delays, FastLed apparently supports it.
We'll investigate more in DV3 but really think your time will be better
spent developing the 8x8 boards than putting any more time into the strip
code.
On Tue, 11 Jun 2019, 11:31 kieran-boyle, notifications@github.com wrote:
as stated inline, this was caused by no -1 after passing LEDEnd. now fixed..
issue did not present on compile, only able to isolate when i had a working MCU, as i have stated it took me a whole 10 minutes to isolate. i think you are getting worked up over nothing mate.
i will remove from individual strips and remove Tim function, again this is ten minutes of work. will then have a working 8x8 which i will be working on from that point.
worry not everything is ticking along fine.
I'm just aware that this single file of 1500 lines of code has had more
revisions and more time spent on it than any other part of the project.
Time much better spent elsewhere.
As I said previously if it works great. If not it's been going on for far
far far too long now so let's simply remove the offending pattern. If its
removed from one mode it should be removed from the other. Patterns play
nice or not at all. Delay plays nice or not at all.
Theres plenty more to do... let's put I2CFastLed.ino to bed finally?
On Tue, 11 Jun 2019, 11:49 kieran-boyle, notifications@github.com wrote:
Yeah it had been the sole thing I have been working on.. If course it has had the most revisions I have been learning haven't I.
The strobe is a really cool pattern. It is working fine. I really don't see what the issue is with the solution I have stated above????
Did you see my latest commit?
It's basically unreadable on my phone since smashed the screen. I will
check it out later today
On Tue, 11 Jun 2019, 12:01 kieran-boyle, notifications@github.com wrote:
no worries, 2 small fixes was all it now works great, no undefined behavior.
Same with that message detailing the need for -1 it was right on the
cracked bit of my screen....
On Tue, 11 Jun 2019, 12:03 W45T3 G45H, squatn3t@gmail.com wrote:
:D ballaches mate hahaha
This is sorted yeah? time to close?
Yeah it's sorted well enough. Still underlying issue but as they mostly have similar delay (now strobe removed) they will behave ok.
From: Squatnet notifications@github.com
Sent: Thursday, July 11, 2019 11:04:29 AM
To: Squatnet/ArduinoStuff
Cc: kieran-boyle; Assign
Subject: Re: [Squatnet/ArduinoStuff] Delay in individual strip mode (#104)
This is sorted yeah? time to close?
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHubhttps://github.com/Squatnet/ArduinoStuff/issues/104?email_source=notifications&email_token=AG3GL2VPHOCQGPKPKMK3RM3P64AS3A5CNFSM4HWWOFE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWGTYY#issuecomment-510421475, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AG3GL2UMZHUMCAALEXFFGF3P64AS3ANCNFSM4HWWOFEQ.