V5.3.x/develop

[gpstar81]

-Adds support for the optional Inner Cyclotron LED Panel upgrade. -EEPROM LED Menu updated to add a toggle to enable the new Inner Cyclotron LED Panel. -Updated documentation.

[nomakewan]

Going over the new GB2 wand sound code, it likely needs corrections but I'd like some clarifications before making any changes.

In the film, the "GB2" startup sound in the courtroom plays when the vent switches are already switched on, and then they flip Activate to on. This was already partially correct in the code (and fully correct on standalone wands) as long as wand boot errors was disabled since the Proton Pack would play the GB2 start sound in this case due to the pack being told to turn on from the Activate switch. Simply switching the wand startup sound to GB2 in postActivation() would, in my view, correctly rectify the SFX mismatch issue here.

However, later in the film there is a second startup sequence which sounds closer to the GB1 startup, lacking the higher-pitched metallic sound heard in the courtroom scene. It's because of this scene that I think the startup sound for the wand (that is, switching on the vent switch after flicking Activate to on and the pack is already on) should be left alone as S_WAND_BOOTUP.

Thoughts?

[gpstar81]

Going over the new GB2 wand sound code, it likely needs corrections but I'd like some clarifications before making any changes.

In the film, the "GB2" startup sound in the courtroom plays when the vent switches are already switched on, and then they flip Activate to on. This was already partially correct in the code (and fully correct on standalone wands) as long as wand boot errors was disabled since the Proton Pack would play the GB2 start sound in this case due to the pack being told to turn on from the Activate switch. Simply switching the wand startup sound to GB2 in postActivation() would, in my view, correctly rectify the SFX mismatch issue here.

However, later in the film there is a second startup sequence which sounds closer to the GB1 startup, lacking the higher-pitched metallic sound heard in the courtroom scene. It's because of this scene that I think the startup sound for the wand (that is, switching on the vent switch after flicking Activate to on and the pack is already on) should be left alone as S_WAND_BOOTUP.

Thoughts?

I think the general consensus is in GB2 mode, people want that metallic boot up sound.

[DustinGrau]

I'm working on adding the new LED panel switch in the Attenuator web UI. And now that I'm seeing there's some open slots on the LED EEPROM menu, could it be possible to add a selection in there for the # of extra "cyclotron cavity" LED's beyond the cyclotron cake for the sparking effect? I had added that only to the UI but wasn't sure how to get the voice effects and button presses to cycle through numbers 0 to 30.

Before I test things out, I need to make some connecting cables for the inner panel and the lid lights since that's what we're adjusting. I got the Frutto 36-LED set and planned to test out how things fare with the larger # of LED's on that chain. That said, I've completely forgotten how this is intended to attach--does the panel go before the inner cake lights?

[nomakewan]

The way I was planning on implementing that selection was by doing a rotary selection. I was going to post this in Discussion once 5.3.x was out the door, but since you mentioned it I'll just post it here:

Menu Refactor (WIP)

The inner panel goes first, yes. It allows for much shorter, easier-to-manage wiring for the inner cyclotron cake.

I'm still working on fixing the GB1/GB2 wand sounds locally. There's still a few mismatches I'd like to get sorted out. For now I'll just have every single GB2 toggle be the exact same sound. I'll take a video though to show people what the different toggles are and see if they want to revert back for 6.x. (Like how GB1 has the "normal" and "short" startup sounds depending on which sequence you use).

[DustinGrau]

Ah, right, I see in the code it's in order: INNER_CYCLOTRON_LED_PANEL_MAX + INNER_CYCLOTRON_CAKE_LED_MAX + INNER_CYCLOTRON_CAVITY_LED_MAX

Now my memory is jogged. This will be the area I'm most concerned about with the FastLED library as I was encountering issues when I went too high with the LED count on that segment. I may have to either back off of the # of allowed lights for the cavity or rework that solution again. Either way, I'll need to do some extensive testing thought I planned to upgrade my pack to support the max # of new lights so it'll be the ultimate setup for testing (by comparison my bench rig is mostly stock Haslab stuff).

[DustinGrau]

Another question: with the inner cyclotron plate, can we still use the V3_Cyclotron_Switch_Mount_Plate model to work with the new LED PCB? And what was the diameter for the cliplites? I know I asked this before, but we should probably update the documentation with the recommended parts in the Light Switch Panel section of the guide.

Edit: I think I found the past discussion with Michael, and users would want the clear cliplights for a 6.35 mm mounting hole: https://www.mouser.com/ProductDetail/VCC/CLF_280_CTP?qs=%2FvU7ivDUWU8ViJ5YWUwpEg%3D%3D or https://www.digikey.com/en/products/detail/visual-communications-company-vcc/CLF-280-CTP/4515438?s=N4IgTCBcDaIMIBkBiB9MAOADCuAVACiALoC%2BQA

[nomakewan]

A user on the FB group got really good results using 24 LEDs of a 60LEDs/m WS2812B LED strip, though in his case he was actually replacing the inner cyclotron cake lights with those 24 LEDs. That way he could achieve a pretty decent "spinning sparks" effect without having to actually modify the existing code.

Point being though, if he managed to achieve a really good looking effect with 24 LEDs, then reducing the max for the cavity to 24 should be okay.

[nomakewan]

Here are the latest changes I've committed:

-MODE_SUPER_HERO Ion Arm Switch change Now if you physically move the Ion Arm Switch while in MODE_SUPER_HERO, you will always get the sound effect for the switch (Afterlife/FE only) but the actual OFF/ON function will only trigger if the switch is moved to the appropriate position. This prevents the switch from becoming "reversed" if it is left in the "ON" position when the user turns their battery on. However, for those building custom packs which do not have an Ion Arm Switch, this does not in any way affect the ability to turn the Proton Pack on and off from the Neutrona Wand. It only affects physically toggling the Ion Arm Switch.

-MODE_SUPER_HERO/MODE_ORIGINAL erroneous voice prompt fix Fixes the Proton Pack erroneously playing "Video Game Modes" and "Cross the Streams" voice prompts when switching between MODE_SUPER_HERO and MODE_ORIGINAL while the Video Game Modes are enabled in MODE_SUPER_HERO.

-Standalone Neutrona Wand MODE_SUPER_HERO/MODE_ORIGINAL firing mode fix Due to a misplaced vgModeCheck() standalone wands were not correctly switching back to video game modes (if enabled) when switching from MODE_ORIGINAL to MODE_SUPER_HERO.

-Proton Pack stream check optimization The Neutrona Wand actually handled all appropriate firing mode and stream changes when changing prop modes and so it was redundant to have the Proton Pack code checking this. The one exception is if a Proton Pack has no Neutrona Wand connected but does have an Attenuator connected that commands it to change modes, in which case it now handles switching to Proton Stream properly.

-Smoke SFX randomizer fix The code which determined which random smoke sound played during smoke events had an incorrect maximum value, meaning the final sound effect never had a chance of being played.

-Quick Vent duration change Previously, Quick Vent was designed to only run for 4 seconds, but had a bug where the smoke would only run for 4 seconds but the vent sequence would run for half the overheat timer duration for that power level. Per user request, this has now been changed so that both the smoke and the sequence would run for either half of the overheat timer duration or 2 seconds, whichever is longer.

[DustinGrau]

I would very much like to test out the panel lights myself and make sure everything works. I need to make some new connecting cables first which meant clearing my workbench of another project. I made headway with finishing the 36-LED cyclotron lights last night and will move to the panel tonight.

[DustinGrau]

Got everything hooked up, but found some glitches with the sparking effects. I'm trying to work through the sequencing and also made some new variables to help with the start/end for each set of inner cyclotron devices. Need to test things out further with more configurations but likely not to finish tonight.

[CrisisFilms]

With all the changes being made to the inner cyclotron lighting, what are the chances of adding in support for this 45 LED ring for the cake? https://www.amazon.com/gp/product/B08GPCB7K3/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&th=1 With a 120mm outer diameter I had to make some adjustments to my 3d printed cake, but it looks much better than the 35 when testing as the LEDs are mostly hidden by the inner details of the cake while still lighting up nicely. Unfortunately with the setting for 35, there's a big section that never comes on.

[DustinGrau]

@CrisisFilms There would need to be concessions made on what you really want to do with the kit if the inner (cake) count is increased. I'm running into a limit with how many LED's can be supported before the time to update all the LEDs causes problems with the interrupts, and can manifest as glitches with the serial communications. If there were an option for a higher count on the cake, then that could exclude the ability to add the "sparking" lights outside of the cake, or severely limit the number of lights you can adopt for that feature.

[CrisisFilms]

@DustinGrau I've been on the fence about adding the sparking lights to my setup anyway, so I would be ok with leaving them out, if it means getting the 45 LED cyclotron. I'm not sure how or if you would want to handle that sort of compatibility issue though.

[DustinGrau]

@CrisisFilms It's not likely to happen on this update as we've already got a lot in here to get cleared and tested. But put the request out there on the Discussions page as a request so we can track it.

[DustinGrau]

Code has been updated to support the arduino-esp 3.0 release for the boards library in Arduino IDE. You will need to update to all the latest libraries and boards before the compile will suceed. This applies to the command line as well once the IDE is updated. No adverse effects appear on the ESP32 device so far, though program memory usage is now up to 91% due to all of the new features added. My hope is that this may bring some enhancements to the wifi capabilities.

[nomakewan]

Okay. I've finished testing out some changes to the 36-LED array but since they still need a little work (ramp up/down and idle are okay, but once the overheat multipliers kick in we seem to be hitting a wall) I will put those changes into a separate PR that I will open after this one has been merged.

Hoo boy FastLED sure has a lot of compiler warnings with ESP32 v3.0.x. I did open a PR to fix the deprecation warnings on the HT16K33 library though since that's a really simple fix.

[nomakewan]

@DustinGrau could you sanity check something for me? In ProtonPack.ini, in the function innerCyclotronRingUpdate(), there is a switch statement for the cyclotron speed multiplier. In the current code it's on line 3836.

The way I'm reading it, since you can only hit this switch statement if the multiplier is greater than 1, this means the default statement will be used if the multiplier is higher than 6. This can in fact happen if overheating is enabled for the current power level and the system year is Afterlife or Frozen Empire. The automatic speed increase for Afterlife and Frozen Empire can only go to a multiplier of 6, but the overheat-related speed increase triggered by the wand sending W_CYCLOTRON_INCREASE_SPEED can go up to 9.

So it looks like if the multiplier goes to 7~9, it will cause the inner cyclotron to be slower than a multiplier of 2? Is that right, or am I missing some math elsewhere changing how the LED update speed reacts?

[DustinGrau]

@nomakewan that sounds correct--the lack of additional cases would mean anything more than 6 would fall back to the default. Though the questions I see now are 1) is there a case where the multiplier goes that high or can we just cap it at 6, and 2) why do we bother with a case statement within a check that ensures the multiplier is > 1 when I thought "normal speed" is always 1...so the else would never get called. I think we need a case for 0 just as a precaution (the variable is an unsigned byte). I'm going to make that change, plus collapse the logic to make 2/3 the same (which they are already) and 4/5 also the same. That makes 6/7/8/9 also the same and our potential maximums.

[nomakewan]

@nomakewan that sounds correct--the lack of additional cases would mean anything more than 6 would fall back to the default. Though the questions I see now are 1) is there a case where the multiplier goes that high or can we just cap it at 6, and 2) why do we bother with a case statement within a check that ensures the multiplier is > 1 when I thought "normal speed" is always 1...so the else would never get called. I think we need a case for 0 just as a precaution (the variable is an unsigned byte). I'm going to make that change, plus collapse the logic to make 2/3 the same (which they are already) and 4/5 also the same. That makes 6/7/8/9 also the same and our potential maximums.

To answer your questions:

1. The multiplier can go beyond 6 if you are in Afterlife or Frozen Empire and the current power level has overheating enabled. In that case, it can go to 9 instead of being capped at 6.

2. The multiplier will always be 1 at normal and will never ever be 0. It is set to 1 in the header and every reset function resets it to 1. The valid values are 1 through 9, with 7~9 only being achievable in Afterlife or Frozen Empire when overheating is enabled for the current power level.

However if you want to remove the if statement for greater than 1 (which was there just to make sure that adjustments were only made if you were in a faster-than-idle state) and make case statements for 0 and 1 that assert the normal values that's totally fine too. Just have to shift the default and then make explicit definitions for 7~9.

[nomakewan]

Whoops. I forgot that stylesheets want American spelling. Thanks for the fix!

With the weird INO, might be worth correcting the batch compile script to not output it? Or is it necessary for something in the background?

[DustinGrau]

Whoops. I forgot that stylesheets want American spelling. Thanks for the fix!

With the weird INO, might be worth correcting the batch compile script to not output it? Or is it necessary for something in the background?

Yeah, was still testing things out when I realized I missed more "backgroundColour" items :)

The new bin file must be a side effect of the new Arduino-ESP 3.0 library so I'm removing it after the compile.

[nomakewan]

Okay, big change finally pushed, sorry for the delay. This change will require updating your SD card as some of the sounds included in an earlier commit turned out to be duplicates, and others turned out to be direct replacements. So since there was a bit of rearranging, I would recommend wiping fresh and reloading.

This of course only applies to testing from this PR, since the final release to end users will merely be a drop-and-replace update.

I believe I've found a way to get the power level transitions on the wand to actually be smooth and want to try that out, but I probably won't have time until Monday. Tomorrow night at the earliest, but we'll see. For now, try this out. Everything should be much, much closer to how it looks and sounds in the films.

[Toy203]

Can test it on Monday if needed, let me know.

[nomakewan]

Ahahaha, so while implementing the semi-auto vibration stuff I found a rather large bug in how the menu vibration is handled. I was pretty sure it was working before (it was tested when the async timer was first implemented) but I guess at some point the code got messed up.

EDIT: Yep, got messed up by the last commit when I removed the boolean guardrails. Those guardrails are only necessary to cover up bad code that was entirely my fault. Fortunately the fix is as easy as reversing the conditional logic, so no big deal.

Fortunately fixing that bug should likewise fix the fact that the semi-auto changes aren't working at the moment (vent light still doesn't increase in brightness, no vibration occurs). Even if they had worked though tying the vent light to vibration was still a bad idea (because we want to jump the vent light even if the user has vibration disabled). So yeah.

Stand by, let me finish working through the vibration issues.

I did test my theory on crossfading the power level idle sounds but it did not work, so I have abandoned it for 5.3.0. I can come back to it for the v6 development cycle.

[nomakewan]

There we go, finished all the fixes and tested them all on my bench setup.

[nomakewan]

Literally was just testing this morning, found an issue, and just fixed it. With this last nagging piece done, I too am ready to sign off on it for 5.3.0.

The cyclotron refactor can go into 5.3.1, sure. It's not a huge enough issue to bother fixing with right this second, especially since we already have people in the wild with those Frutto Inner Cyclotron Panels that need this firmware ASAP.