Problem with define FETT263 MOTION WAKE POWER BUTTON

I’m separating this problem from my other active thread, for an easier handling.

With the FETT263_MOTION_WAKE_POWER_BUTTON enabled, when the motion detection is offline and you press the power button, the saber plays the boot.wav file as expected and resume motion detection.
However, immediately after the boot it starts playing hum.wav, without lighting up the blade.

20:49:11.164 -> Welcome to ProffieOS v6.5. Type 'help' for more info.
20:49:12.308 -> Battery voltage: 3.74
20:49:14.046 -> EVENT: Power-Pressed#1 millis=561780
20:49:14.046 -> EVENT: Power-Pressed millis=561780
20:49:14.215 -> EVENT: Power-Released#1 millis=561945
20:49:14.215 -> EVENT: Power-Released millis=561946
20:49:14.215 -> EVENT: Power-Shortclick#1 millis=561946
20:49:14.215 -> EVENT: Power-Shortclick millis=561946
20:49:14.352 -> EVENT: Power-SavedShortclick#1 millis=562081
20:49:14.386 -> unit = 0 vol = 0.50, Playing Fates/boot.wav
20:49:14.386 -> channels: 1 rate: 22050 bits: 16
20:49:15.962 -> Playing Fates/hum.wav
20:49:15.962 -> channels: 1 rate: 22050 bits: 16

The hum can be stopped by igniting the blade and turning it off.

For reference, this is my current config.

// Fencer

#include "proffieboard_config.h"

#define NUM_BLADES 2
#define NUM_BUTTONS 1
#define VOLUME 1000
const unsigned int maxLedsPerStrip = 144;
#define ENABLE_WS2811
#define ENABLE_SD
#define DISABLE_BASIC_PARSER_STYLES // required for memory saving and using built-in styles for ProffieOS Workbench
#define FETT263_TWIST_ON
#define FETT263_TWIST_ON_NO_BM
#define FETT263_TWIST_OFF
#define MOTION_TIMEOUT 1 * 5 * 60 * 1000 // hours * min * 60 sec * millis

#include "../props/saber_fett263_buttons.h"

Preset presets[] = {

    { "Fates;common", "tracks/mars.wav", //DeepSkyBlue
  	  StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Fates"},

    { "Shatter;common", "tracks/mars.wav", //DeepPurple
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Shatter"},

    { "Revenge;common", "tracks/mars.wav", //Red
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Revenge"},

    { "Bespin;common", "tracks/mars.wav", //Cyan Rgb<0,255,80>
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Bespin"},

    { "Corell;common", "tracks/mars.wav", //DarkOrange
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Corellia"},

    { "SmthJedi;common", "tracks/mars.wav", //Green
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Smooth Jedi"},

    { "RgueCmdr;common", "tracks/mars.wav", //Gold
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Rougue Comm"},

    { "Spitfire;common", "tracks/mars.wav", //Chartreuse
      StylePtr<InOutHelper<AudioFlicker<Red,Black>,400,800,Pulsing<Red,Black,5000>>>(), "Spitfire"}

struct AVRedLED {
  static constexpr float MaxAmps = 0.02;
  static constexpr float MaxVolts = 2.0;
  static constexpr float P2Amps = 0.01;
  static constexpr float P2Volts = 1.8;
  static constexpr float R = 150.0; // Resistor value
  static const int Red = 255;
  static const int Green = 0;
  static const int Blue = 0;

BladeConfig blades[] = {
 { 0,
	SimpleBladePtr<CreeXPE2RedTemplate<1200>, CreeXPE2GreenTemplate<510>, CreeXPE2BlueTemplate<510>, CreeXPE2WhiteTemplate<510>, bladePowerPin1, bladePowerPin2, bladePowerPin3, bladePowerPin4>(),
	SimpleBladePtr<AVRedLED, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(),
    CONFIGARRAY(presets) },


Button PowerButton(BUTTON_POWER, powerButtonPin, "pow");

As noted, the define just triggers RequestMotion(), so the hum is tied to something else happening not the define itself. Without this define when you press a button RequestMotion() is called but something else gets triggered, with this define RequestMotion() gets called but we just play a sound. So, there’s a bug somewhere with RequestMotion() or something related that becomes visible with the define in place, not sure what it could be though as I have never experienced. Is it possible it’s something in your font, what happens when you try a different font? I have a slight recollection of monophonic fonts having odd behavior, might be tied to that? It could still tie back to your original post, I just wanted to clarify the define itself isn’t doing anything differently other than skipping DoIgnition() when the motion is asleep.

Currently, hybrid font assumes that it will get motion callbacks. If that stops happening, some weird stuff happens. Like for instance, the hum might not fade in, fade out or stop properly. I’m wondering if this is maybe some artifact of not getting that callback?

Yeah, I have to defer to you on this. I haven’t actually experienced this on any saber at any point in time and the motion code is still a bit over my head, I just wanted to try to remove any “red herrings” in the mystery as it applied to that define.

Right. It seems weird that calling RequestMotion() can make this work again, since motion should already be requested…

Yeah, definitely a mystery. I seem to recall some similar things reported at different points during Beta testing but I don’t recall if it was ever recreated or the cause found. I still wonder if it’s somehow tied to specific fonts or something more specific to the saber itself beyond the config or OS but unfortunately I don’t have the knowledge how to figure it out, just going on guesses for the portions I do understand somewhat and what I encountered in developing my prop for OS6.

I did some tests with all fonts and I can say that your suspect was correct.

When using one of the default Proffie fonts after the boot sound there is no hum playing.

When using the other fonts (which probably are all hybrid in my SD) I get the hum after the boot.

I was readying through the Proffie documentation and found this interesting statement in the Proffie OS page:

“Note that in monophinic mode, the end of all sounds (except poweroff) smoothly join up with the beginning of the “hum” sound(s).”

I guess this might be the reason for starting the hum after playing the boot sound with hybrid fonts when triggering FETT263_MOTION_WAKE_POWER_BUTTON.

Perhaps it would be enough to add another exception for the boot file like it’s present for poweroff.

… and boot, and font… :slight_smile:

I tried to look into the code, but consider that I’m very basic and I could be totally in the wrong direction.

As far as I understand, when the FETT263_MOTION_WAKE_POWER_BUTTON is executed in the hybrid font case, it’s calling function hybrid_font.PlayCommon, passing the variable &SFX_boot.

Then, PlayCommon is calling function PlayMonophonic, passing &SFX_hum as secondary variable, which I suppose is the method used to concatenate a generic effect into the hum.

  void PlayCommon(Effect* effect) {
    if (guess_monophonic_) {
      PlayMonophonic(effect, &SFX_hum);
    } else {

Perhaps, to solve the concatenation with the hum when selecting the sound font, it would be enough to replace PlayCommon and use a different function to play the font file itself.

I suppose such function or method exists, but I wasn’t able to find it.
After all, at power-on the board plays the hybrid font boot file without concatenating the hum.

You are absolutely correct.
The prop should be calling PlayPolyphonic() in this case, not PlayCommon().

Nice sleuthing, I don’t have any monophonic fonts so I never would have experienced in testing. I’ve submitted PR for fix.

Definitely time for a v6.6 release. (probably this weekend)

1 Like