search

gpstar81 / GPStar-proton-pack

GPStar Proton Pack and Neutrona Wand
https://www.gpstartechnologies.com
GNU General Public License v3.0
37 stars 8 forks source link

[Bug]: Overheat Issues in 84/89 #354

Closed Toy203 closed 1 month ago

Toy203 commented 2 months ago

What actions were attempted?

Triggering the overheat sequence while in 84 or 89 modes makes the cyclotron leds go out of synch and go on and off seemely randomly. Eeprom is correctly configured for my 36 frutto leds.

What actually happened?

https://youtu.be/4U4C8m3I3ZY

What was expected?

Should just slow down the rotation animation i guess? Or they should all blink together in synch at least.

Firmware Version

5.3.2

Mode in Use

Super Hero / Video Game

Notable Hardware

9 leds frutto pucks.

Homework Completed

nomakewan commented 2 months ago

In overheat, with fade enabled (which is the default setting), overheat should have them all in sync.

However, it would appear that the fix for the seizure-inducing color shifts during fade events has also caused the overheat animation to be out of sync. I'll look into it.

For now, since it's overheating which is an error state anyway, this erratic behavior can just be a "feature". But yes, 5.3.3 will have a fix. Along with that ring sim ramp up/down fix that's been on the back burner since 5.3.0.

Toy203 commented 2 months ago

Honestly yeah, I could also see it as a malfunctioning thing and doesn't look sloppy at all.

nomakewan commented 2 months ago

Should now be fixed in commit ffb493a.

nomakewan commented 2 months ago

Just to check back, did that commit actually fix the bug? I still won't be able to test on real hardware until later this month, so if you get a chance to test the new code, it would be appreciated.

Toy203 commented 2 months ago

Didn't check, will flash it in a sec

Toy203 commented 2 months ago

Looks like it's still present, i'm not sure what would be the regular animation, don't think i ever trigged it. Lights are still blinking out of synch. I can hear two identical overlapping sounds on Overheat end in 89, at 0:06. https://youtu.be/F5Ajxt-3CBs

nomakewan commented 2 months ago

And just to check, when you flashed you flashed from the Arduino IDE and not using the 5.3.2 binary in the binaries folder in the repo, yes?

Toy203 commented 2 months ago

Still learning the ropes on GitHub, might have used the wrong file, can you link it?

nomakewan commented 2 months ago

It actually didn't exist until just now. The new binary is now in the 5.3.3 branch's binaries folder here: https://github.com/gpstar81/GPStar-proton-pack/tree/v5.3.3/develop/binaries/pack

Toy203 commented 2 months ago

Yes, same as above as for 84 and 89 with the double sound overlap.

nomakewan commented 2 months ago

Iiiiiiiiiiinterdasting. I definitely hear the sound overlap but the sound shouldn't have had anything to do with the LEDs. So if that overlap was there, it should've also been there in earlier firmware. Hrm.

The alarm code for 84/89 is pretty basic, so I'm not sure why it would be out of sync like that (it literally just sets four timers, one for each lens). I'll take a harder look and try to trace it out. Thanks!

Toy203 commented 2 months ago

Sound thing might has been there for a while, I never use the pack in 84-89. Just thought of mentioning it since I just noticed it

nomakewan commented 2 months ago

Sound thing was indeed there for a while. I've tracked at least part of it down--it's more obvious in 1989 because the startup sound is so unique. But there's a wand startup version and a pack startup version of that sound, and due to the sequence of serial events between the pack and wand during overheat recovery, the pack both plays its startup and the wand plays its startup (and then commands the pack to play its startup sound too).

If you wouldn't mind performing a test for me, that would be helpful.

Disable Extra Neutrona Wand Sounds (EEPROM Config Menu Level 1 Option 1 Intensify). Does the weird overlap still happen at the end of overheating in '89, or did disabling Extra Neutrona Wand Sounds solve that part of the issue?

Toy203 commented 2 months ago

Will test it out tomorrow

Toy203 commented 2 months ago

Looks like it doesn't overlap two sounds with neutrona wand sounds disabled.

nomakewan commented 2 months ago

Okay, so it's definitely the thing I found with the wand sound serial calls on restart. I'll get those fixed while I'm in here messing with the cyclotron alarm code. Thanks as always!

nomakewan commented 1 month ago

Was finally able to get a bench pack LED setup going. I actually already fixed the sound bug with the wand sounds overlapping after overheat ends, so that's good.

The short of it is that the ramps between the four LEDs are not matching up. I can get them to start together easily, but once they're freerunning they go out of sync like when you try to match your turn signal with someone else's car's turn signal. I can see the values going out of alignment via the serial data debug. The thing is...I just don't know why that is happening.

I've got some theories on how to tackle it, and now that I have working hardware I'll be able to iterate a lot faster. Hopefully will have this tackled before the weekend's out. Thank you for your patience!

Toy203 commented 1 month ago

Glad to hear you finally got the testing hardware! Let me know if I can help in any way.

nomakewan commented 1 month ago

Okay! I've gotten the out-of-sync animation solved. Or rather, it's solved enough for now. The real problem I'm pretty sure is due to floating point error within the ramp library. It appears that the individual LEDs are not actually ramping at the same speeds despite having the exact same ramp calculation calls. This slight error will still cause the LEDs to be ever-so-slightly out of sync brightness-wise on occasion, but the overall animation itself will remain in sync, so this can be viewed as the type of error you'd see with incandescent bulbs.

Namely that two different bulbs may not have the same on/off illumination curves as they heat up and cool down. At least, that's how I'm going to justify not ripping the entire Ramp library out of this thing and rewriting the entire thing right here and now.

I've tested this on my bench setup and it looks good, but please do feel free to test. Note that you will of course need to update all of your devices in order to test it out. Here is the folder for 5.3.3 WIP binaries.

Toy203 commented 1 month ago

Will test it tomorrow and report back. "Solved enough" is the epitome of programming life.

nomakewan commented 1 month ago

Oh right, forgot to mention, but there are of course also new sounds as well, so for SFX to work correctly you'll need to update your SD cards as well.

Thank you as always for reporting these bugs! Every bug reported makes this project that much better for everyone.

Toy203 commented 1 month ago

Looks like somewhat resolved, although it's not so regular still. If it is a bulb problem, it's not worth looking into it too much imo.

https://youtube.com/shorts/g4Gh4xVp0TU

nomakewan commented 1 month ago

Yep, that's how it looks on my end too. I don't think it's actually a bulb problem, I think it's a problem with the Ramp library having floating point imprecision. This isn't a huge deal when you're doing things in a circle, but when you're trying to synchronize four elements at different locations around an LED strip, it becomes a problem.

The "bulb problem" comment above was just me justifying the imperfect fade by pointing out that if there were incandescent bulbs rather than LEDs, they might have similar behavior due to manufacturing differences.

So yeah, "good enough" for now. When the LED code gets tossed in the garbage bin and replaced come v6 we can come back and figure out a much better way of handling this animation. I already have an idea or two.