LSOS v1.4 - how to make a high-end saber with only a single switch?

[Obi_1]

What you describe is a typical case of back-supply. If the chip is not supplied through its dedicated supply pins, but the digital lines are powered, the chip can draw its current from the digital lines. I also had this issue with the pixels, therefore when shutting down the pixels I make sure to have the DATA_IN programmed to a voltage to avoid back-supply. Its faint because a digital pin of the avrs can supply mas 40mA.
Funnily if you connect the GND signal of the pixels to the LS pins of the DIYino to avoid current consumed during idle state, then a low signal on DATA_IN will cause the back supply, because it reconnects a kind of weak ground to the pixels. So depending on your setup you have to consider where to connect your DATA_IN in idle (blade off) mode. IN your case writeDigital(DATA_IN, LOW); would fix the issue.

[Ridire Fíréan]

It seems maybe you're tying to do more with coding than with hardware, but what about a multi-direction momentary switch? 

Press forward for ignition, press backwards for deactivation, press left for blaster difflection, press right for blade lockup, back-back-down-forward for Yoda Death Blossom (hehehehe!).

[jbkuma]

I built a test saber so I could record a demo to my tweaks, but then I started testing some more ideas I had in saber construction as well, so I'm waiting on a few parts to finish up my latest this week.

It seems in my modified build of LSOS v1.4 the sound fonts with more than one "power on" and more than 8 (or more specifically 16) swing and/or clash sounds misbehave.  The fonts with 16 swing and clash sounds all failed to load their menu sound, and most of the other sounds wouldn't trigger.  Even the default Barelow font was misbehaved ocassionally, the menu sound didn't always play and the lockup sound would get stuck even when the visual mode switch back (one of my tweaks). 

After pulling my hair out for a few days, I realized my working fonts only had one ignition sound and 8 swings and clashes.  When I adjusted the misbehaving fonts to have only one ignition and 16 everything worked as expected.

Is this a known limitation? I don't believe anything I did should have changed anything related to the sound triggers.

[jbkuma]

It may be that my issues were mostly memory related.  I had 5 fonts loaded, then I added 3 more.  Things misbehaved quite a bit.  When I dropped it to 6 and 7 I was having similar issues to what I had before I took out some of the extra clashes and swings.  Back at 5 fonts and things work perfectly again.

Interesting to note: as long as the NR_SF#_FILES definitions are made properly, you can keep as many fonts as you want on the card and simply comment out or not enter in the fonts you are actually using.  I suppose you can simply eliminate the definitions and use continuous file numbering for the sound ranges as long as you've done it properly.  If you want to keep multiple fonts on and simply comment out what you aren't using, this might be the easiest way to keep a bunch of fonts and load what you want.

[jbkuma]

Among the tweaks I was planning on is a "mute mode" which I was planning to make a long press in standby.  I know it can be done through volume adjustment in the config menu, but there are times and places where it would be more convenient to quickly and quietly mute the saber.  I figure a quick double flash of the blade can indicate the mute mode was entered.

Does anybody have any interest or strong feelings about muting, or methods to invoke it?

[Obi_1]

No strong dislike, however it will affect one of the nice features, which is the audio controlled flicker. I.e. if the volume goes back to 0, the sound cannot be sampled again (or rather will return ~0) and therefore the blade will be static.
Speaking of which, I need still to scale the audio controlled flicker to that it becomes as much as possible independent of the volume. In current LSOS it works perfectly as long as the volume is in the upper range, so the delta voltage reading between the 2 SPK terminals is large. But as you start to mute, amplitude will decrease, and so will the visibility of the effect. So I need to weight the FX amplitude with the volume setting.

Anyway, I know that certain duelling groups need such a feature and it would be not difficult to do it, so why not? I just wanted to say that the volume influences FX's.
For LED strings I coded a pulse FX, which is independent from the audio signal, it could be taken for the mute mode to still keep the blade flickering. Or just apply random flicker.

[jbkuma]

Rather than wire the audio, I have been using my own flicker algorithm, so I hadn't noticed or considered that.

Part of my battery check feature requires setting the analog reference to internal. I think this might upset some of the feature as well.

[jbkuma]

Here are some of the tweaks I showcased in my Wejack thread Wejack - A prototyping & development lightsaber

blaster block setting tweak:
Config.h
166: #define BLASTER_FX_DURATION 300
166: #define BLASTER_FX_DURATION 150
181: #define BLASTERBLOCK_SUPRESS  400
181: #define BLASTERBLOCK_SUPRESS  100
There's a bit of overlap, but it works out fine.

Lockup on clash event deactivate on swing:
LightSaberOS.ino
673: ActionModeSubStates != AS_BLADELOCKUP
673: (ActionModeSubStates != AS_BLADELOCKUP or lockuponclash)// end lockuponclash event on a swing
This only interrupts the lockuponclash event, not the mode, and does not interrupt a manual aux-pressed lockup activation.  The mode is deactivated the same as in v1.4.

Shimmer on lockup:
Light.cpp Replace 755-763:

Code: [Select]

if (AState==AS_BLADELOCKUP) { //animate blade in lockup mode
  // gives 25% chance to flick larger range for better randomization
  int lockupFlick = random(0,39);
  if (lockupFlick < 10) {
        cRGB color;
    color.b = brightness * currentColor.r / rgbFactor;
    color.g = brightness * currentColor.g / rgbFactor;
    color.r = brightness * currentColor.b / rgbFactor;
    for (uint16_t i = 0; i <= NUMPIXELS; i++) {
      pixels.set_crgb_at(i, color);
    }
  } else if (lockupFlick < 20) {
    cRGB color;
    color.r = brightness * currentColor.r / rgbFactor;
    color.b = brightness * currentColor.g / rgbFactor;
    color.g = brightness * currentColor.b / rgbFactor;
    for (uint16_t i = 0; i <= NUMPIXELS; i++) {
      pixels.set_crgb_at(i, color);
    }
  } else if (lockupFlick < 30) {
    cRGB color;
    color.b = brightness * currentColor.r / rgbFactor;
    color.r = brightness * currentColor.g / rgbFactor;
    color.g = brightness * currentColor.b / rgbFactor;
    for (uint16_t i = 0; i <= NUMPIXELS; i++) {
      pixels.set_crgb_at(i, color);
    }
  } else {
    cRGB color;
    color.r = brightness * currentColor.r / rgbFactor;
    color.g = brightness * currentColor.g / rgbFactor;
    color.b = brightness * currentColor.b / rgbFactor;
    for (uint16_t i = 0; i <= NUMPIXELS; i++) {
      pixels.set_crgb_at(i, color);
    }
  }
} else {  //normal operation
  cRGB color;
  color.r = brightness * currentColor.r / rgbFactor;
  color.g = brightness * currentColor.g / rgbFactor;
  color.b = brightness * currentColor.b / rgbFactor;
  for (uint16_t i = 0; i <= NUMPIXELS; i++) {
    pixels.set_crgb_at(i, color);
  }
}
Here's the full version of the ignition function I'm using, which also fades and flickers.
Light.cpp Replace RampNeoPixel() funciton lines 929-966:

Code: [Select]

void RampNeoPixel(uint16_t RampDuration, bool DirectionUpDown) {
  unsigned long ignitionStart = millis();
  cRGB value;
#ifdef FIREBLADE
  for (unsigned int i=0; i<NUMPIXELS; (i=i+5)) { // turn on/off one LED at a time
     FireBlade();
     for(unsigned int j=0; j<NUMPIXELS; j++ ) { // fill up string with data
      if ((DirectionUpDown and j<=i) or (!DirectionUpDown and j<=NUMPIXELS-1-i)){
        }
        else if ((DirectionUpDown and j>i) or (!DirectionUpDown and j>NUMPIXELS-1-i)){
          value.r=0;
          value.g=0;
          value.b=0; 
          //heat[j]=0;
          pixels.set_crgb_at(j, value); // Set value at LED found at index j
        }     
      }
      pixels.sync(); // Sends the data to the LEDs
    }   
#else
  // turn on/off the number of LEDs required to keep up with the ignition timing
  for (unsigned int i = 0; i < NUMPIXELS; i = NUMPIXELS*(millis()-ignitionStart)/RampDuration) {
      //generate a flicker effect between 65% and 115% of MAX_BRIGHTNESS, with a 1 in 115 chance of flicking to 0
      int flickFactor = random(0,115);
      if (flickFactor < 65 && flickFactor > 0) { flickFactor = 100; }
     for(uint8_t  j=0; j<NUMPIXELS; j++ ) { // fill up string with data
      if ((DirectionUpDown and j<=i)){
        value.r = MAX_BRIGHTNESS * i / NUMPIXELS * currentColor.r / rgbFactor * flickFactor/100;
        value.g = MAX_BRIGHTNESS * i / NUMPIXELS * currentColor.g / rgbFactor * flickFactor/100;
        value.b = MAX_BRIGHTNESS * i / NUMPIXELS * currentColor.b / rgbFactor * flickFactor/100;
        } else if (!DirectionUpDown and j<=NUMPIXELS-1-i){
        value.r = MAX_BRIGHTNESS * (NUMPIXELS - i) / NUMPIXELS * currentColor.r / rgbFactor * flickFactor/100;
        value.g = MAX_BRIGHTNESS * (NUMPIXELS - i) / NUMPIXELS * currentColor.g / rgbFactor * flickFactor/100;
        value.b = MAX_BRIGHTNESS * (NUMPIXELS - i) / NUMPIXELS * currentColor.b / rgbFactor * flickFactor/100;
        }
        else if ((DirectionUpDown and j>i) or (!DirectionUpDown and j>NUMPIXELS-1-i)){
        value.r=0;
        value.g=0;
        value.b=0;     
        }     
        pixels.set_crgb_at(j, value);
      }
     pixels.sync(); // Sends the data to the LEDs
     // calculate the interval based on the RampDuration set in Soundfont.h and the number of pixels
     delay(RampDuration/NUMPIXELS);
    }
#endif
}Based on what we saw in Rogue One, the fading and flickering are perhaps non-canonical.  Either can be removed (which is how I originally shared it), but I think it really adds to the effect.  This bright effect is hard to notice on a 120 pixel blade, but it is what makes the single pixel tri-cree blade possible.
i / NUMPIXELS ramps the brightness for the ignition
(NUMPIXELS - i) / NUMPIXELS ramps the brightness for extinguish


In order to make the blaster blocks work with the single pixel blade I also inserted the following code:
Light.cpp Insert at 712: pixels.set_crgb_at(0, currentColor);
This is only necessary because my single pixel blade is actually just plugging in place of the pixel strips.  It slightly brightens the base of the strip blade, which I don't think is a bad thing really.

EDIT: the single pixel effects are also important if you want to use a pixel lighted blade plug without using a separate signal line!

[jbkuma]

With a few more months of experience since last time I researched the topic, I have a much better grasp of the challenges of battery reading, and why we can't acurately measure without a voltage divider and using the INTERAL 1.1v analogReference.  The DEFAULT  analogReference for a 5v board is 5v.  Except, if you are using anything less than 5v to power it, the value will be less than 5v.  Complicating it, a battery is a variable supply.  This means that analogReference(DEFAULT) is now variable.  If you set analogReference(INTERNAL) then you are refrencing 1.1v and can make accurate reads, as long as what you are reading is less than 1.1v.

The speaker output voltage for the DFplayer is 2v (according to my trusty multimeter), so we cannot use analogReference(INTERNAL) if we want to take analog reads of the speakers.  You can, in theory, switch between analogReference(INTERNAL) - 1.1v and analogReference(DEFAULT) - <5v, but the result can be somewhat unpredictable.

There are two possible solutions, in either case we'll still need a voltage divider to read the battery because you need a value under AVCC in order to actually read it.  Easiest is probably connecting the 3v3 pin to AREF and setting set analogReference(EXTERNAL). We should be able to get decent values within the practical operating range of the DIYino, Nano, DFplayer, etc.  Next, and perhaps more reliable, would be to use a voltage reference connected to AREF (such as this).

I have been using INTERNAL and connecting the battery + to A3 with a 470kohm resistor, and GND to A3 with a 100kohm resistor which will give about .67v at 3.7v input, drawing about 7ua.  The values can obviously be adjusted to give a broader width to read, but this should be accurate enough for our crude needs and more accuracy means more amps.

[jbkuma]

All of that being said, I've got a few ways I'm reporting my battery life at the moment.  I added a menu to the config which lights up pixel 0 red, yellow or green based on the value, then lights up 1 through NUMPIXELS in a red-yellow-green graph illustrating the battery life, and one of three sounds is played: "battery nominal," "battery diminished," and "battery depleted."

I'll share the code after I've confirmed my findings and polished things up a bit.

[Obi_1]

All of that being said, I've got a few ways I'm reporting my battery life at the moment.  I added a menu to the config which lights up pixel 0 red, yellow or green based on the value, then lights up 1 through NUMPIXELS in a red-yellow-green graph illustrating the battery life, and one of three sounds is played: "battery nominal," "battery diminished," and "battery depleted."

I'll share the code after I've confirmed my findings and polished things up a bit.

That would be more than welcome, you take a lot of load off my shoulders with that too. I struggled a bit with reading the battery voltage in my E11 blaster build, I programmed the PLU nicely, just to observe that they all always stayed lit...although I use a 5V DC/DC to convert the 3.7V to a stable, low ripple 5V and connect the battery to one of the Ax pins.
Funnily when I first tested the code I got a reading somewhere about 700, it came close to 3.7V, so I though everything was as expected. THen I left it to slowly discharge, I observed no reaction on the PLI. If I read it now, I got ~300, which is more than the 1.1V band-gap reference, so I honestly do not know what is measured there. Of course it could be that simply the wire was torn off the board, I need to check.

Regarding the SPK voltage, the audio amp will pull both SPK outputs to the vdd/2 volate, i.e. if you use 5V then to 2.5 in case no signal is present, if you supply with 3.7V, then close to 1.85V. So reading it should still work and for the audio controller flicker precision is not a requirement.

Did you find eligible sound for the battery status? If yes and they can be made public, I could include them in the config files, would make a great addition.

[jbkuma]

I used the text to speech generator mentioned in the LSOS readme From Text To Speech - Free online TTS service

[jbkuma]

I rethought how to activate the battery check for a better user experience, and I think the best place for it is the config menu initialization.

The way it works currently is to show a blade length meter which is 20% red, 20% yellow, 60% green, or a single pixel red, yellow, green.  I haven't done any coding for Luxeon or String sets, but that's easy enough.  The string blade would light off segments based on power, a tri-LED could be user configurable to allow for different LED configurations, or it could allow dimming (which would also work with single LED).

The verbal cues will be provided by 3 new config sounds "battery nominal, battery diminished, battery depleted" which can of course be changed to something else if desired.

Before I get back into working on this I'd like to know if anyone else has any thoughts on this.

[Obi_1]

I rethought how to activate the battery check for a better user experience, and I think the best place for it is the config menu initialization.

The way it works currently is to show a blade length meter which is 20% red, 20% yellow, 60% green, or a single pixel red, yellow, green.  I haven't done any coding for Luxeon or String sets, but that's easy enough.  The string blade would light off segments based on power, a tri-LED could be user configurable to allow for different LED configurations, or it could allow dimming (which would also work with single LED).

The verbal cues will be provided by 3 new config sounds "battery nominal, battery diminished, battery depleted" which can of course be changed to something else if desired.

Before I get back into working on this I'd like to know if anyone else has any thoughts on this.

Not much of a though, since it seems not to work for me at the moment, so if you have a working code to measure the battery voltage, kindly share. I think that the visuals can be programmed after the measurement method is confirmed to be working.

As for the visuals, I liked profezzorn's battery monitoring with neopixels, displaying a pulsing few-pixel long bar somewhere along the blade corresponding to the battery voltage between high and low limits. In my blaster I used the same as you proposed, green, yellow and finally red. Nicely lits up, but shows full charge until the board simply fails to power up due to a depleted battery...

[jbkuma]

I wrote a pretty lightweight and configurable graphing function, so changing that is pretty easy. The main trickery is getting it to play nice with the menu system. My last version worked really well using internal reference and reading off a voltage divider. I tried the 3v3 external reference method and that worked, but may not work well in the lower operating range.  This still requires a voltage divider, but allows the SPK inputs to be read without any other wiring. I haven't tried the 2.5v reference voltage yet, but it should work perfectly for this while solving the issues with the other methods.

The only case that should work without a voltage divider is when powering the board through Vin with a source sufficient to give a reliable 5v Vcc. That means a 7.4v pack, which is not ideal, or a boost converter providing at least 6v.

Fortunately, a voltage divider is very simple to make and fairly unobtrusive. Two high value, low power resistors and a bit of heatshrink are all you need, and they can be mounted snugly to the board.