Let's talk about blade plug charging

[Sabersense]

Thanks guys.
I had a feeling there would be a little more to it than just sticking a battery in and off you go. But I’m excited by the concept.

While I’m here, I’ve been playing with charging styles and I think I’ve settled on this one:

ChargingStylePtr<Pulsing<Mix<BatteryLevel,Red,Red,DarkOrange,Orange,Blue,Blue,Green>,Mix<BatteryLevel,Rgb<50,0,0>,Rgb<50,0,0>,Rgb<50,13,0>,Rgb<50,19,0>,Rgb<0,0,50>,Rgb<0,0,50>,Green>,2200>>(),

It gives pulsing colours starting with red at low charge, through orange then blue, then when the hilt is fully charged, it goes to solid green without the pulse. I’m hoping that adding more steps like this means the green won’t show until right at the end when it’s completely, fully charged up. The style is very simple so pixel count won’t matter, meaning you can scroll to the blade preset manually if you prefer rather than using blade ID to find a separate blade preset (though that option is still there if you want it). Got a hilt plugged in as we speak to see what happens.

[notsabbat]

Im very excited that a working solution was found for this. This opens up a lot of possibilities for recharging the saber.

Heh; I just had an idea of making a saber holster with a recharge plug at the bottom hooked up to a much larger battery. You could charge your saber while walking the con.

Really looking forward to digging into this in a few weeks. Thanks for doing the heavy lifting Sabersense! And thank you Profezzorn for helping out!

[A_Rogue_Child]

Definitely report back how it works out for ya. Options are always great.

[Sabersense]

For me I think it gives more flexibility with chassis design. Kill switches are quite slim and fit in a smaller space than a charge port. This gives a lot more freedom in terms of how you lay out everything and is also better aesthetically as the switch can be done in such a way as to be much less visually intrusive.

[Sabersense]

I’ve been thinking about this some more and I have one last question: what does the reset pad do on the Proffie?

The reason I ask is that, as we’ve discussed, elegant blade-plug charging really needs to use BladeID to help the saber skip to a suitable charging preset. This in turn means you need a kill switch. (this is where my idea, discussed on another thread, of using the Batt + ring of a blade or blade plug to short power to the board would come in handy). Admittedly you can skip a switch if you have a removable battery, but if you have to take the battery out to boot the saber for it to find the charge preset, you might as well put the battery in a normal charger while it’s out which kind of defeats the elegance of the entire plan.

But if you could have a tiny tactile switch somewhere that would take up almost zero space which you could just press to initiate a reboot, I think that could work quite well. My question is, does the reset pad do this or is it only ever used in conjunction with the boot button for programming? And if it would work, how would you wire it - I’m guessing just have reset pad on one side of the switch and ground on the other?

Or is there another way to reboot? Could you do it with code, so a certain button combination would do it? Maybe hold both buttons down together for four seconds - or something similar that you would never get close to in normal use.

As always, any thoughts welcome.

[profezzorn]

You are correct, the reset button reboots the board when connected to GND.
(Or, more accurately, when it’s not connected to GND anymore…)

It’s entirely possible to do a reboot in the code as well. However, if your goal is simply to re-do blade ID, then you don’t actually need to reboot, we can just do what the “scanid” command does.

[Sabersense]

Whoa! OK, hang on…

So reset would need a momentary switch opposite to normal, i.e. push-to-break rather than push-to-make?

And for scan ID, are you saying we can just add a line to the prop so that a particular button combo runs scanid, finds that the blade fitted is the charge adapter, then switches to the appropriate preset? That would be pretty cool!

[Celemourn]

I thought I saw one of @Fett263 ’s new features being actively watching for blade changes and therefore the ability to do real-time hot swaps…. Maybe. Or maybe I’m imagining that I saw that. Might that be relevant to this discussion?

[Sabersense]

@Celemourn

Might that be relevant to this discussion?

Very! Think I’ll pay Fernando’s website a visit to see if I can find out more.

[Fett263]

Not sure what you’re referring to, none of the stuff I’m working on is related to physically changing the blades.

[Celemourn]

hmm, I wonder what it is I saw… I know it was a video, and it seemed to be active recognition of blades being swapped in and out…

Edit: Well, I can’t seem to find the video. Maybe someone else will remember it better. Anyway, this guy was demonstrating that he could insert a blade, and the saber made a recognition sound, and when he activated it it would use a different sound font depending on which blade it was.

[profezzorn]

@Sabersense

So reset would need a momentary switch opposite to normal, i.e. push-to-break rather than push-to-make?

As long as reset is tied to ground, the processor is frozen and will not do anything.

@Sabersense

And for scan ID, are you saying we can just add a line to the prop so that a particular button combo runs scanid, finds that the blade fitted is the charge adapter, then switches to the appropriate preset? That would be pretty cool!

yes, this is basically what “blade detect” does.

@Celemourn

Edit: Well, I can’t seem to find the video. Maybe someone else will remember it better. Anyway, this guy was demonstrating that he could insert a blade, and the saber made a recognition sound, and when he activated it it would use a different sound font depending on which blade it was.

That is entirely possible with blade detect.
The scanid code can be added almost anywhere though. It will turn all the blades and sound off, then restart everything though, so it’s best done while the saber is off. Some people set it up so that next/previous preset will also do scanid.

[NoSloppy]

@Celemourn

Anyway, this guy was demonstrating that he could insert a blade, and the saber made a recognition sound, and when he activated it it would use a different sound font depending on which blade it was.

Sounds like it was me, but I was doing it while the blade was running.
What you described is standard BladeID use.

These 2 threads are from when I was dabbling with code to make it “always sensing” blade changes.
https://crucible.hubbe.net/t/blade-id-hack-low-no-priority-at-all-just-being-curious/2094

Log into Facebook

[notsabbat]

That first link “doesn’t exist or is private.”

I would like to read more about that as well. Im taking a look at the Proffie support page now.

[NoSloppy]

Sorry, it was in a PM, not a thread.

@NoSloppy

Disclaimer - totally off-the-cuff experimental and likely might take up resources, be a bad idea in general, etc… but is working in testing by adding/removing any blade,
even a NPXL PCB first (detects the change), then add a blade on top of that (2nd change detected)
(They’re wired in parallel)
No BLADE_ID resistors are installed anywhere.

If you have bladein.wav, it will play that when detected.

Used these defines:
#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3>
#define BLADE_ID_CLASS SnapshotBladeID
#define BLADE_ID_MONITORED

Edited the prop’s void Loop() to start like this:

BLADE_ID_CLASS_INTERNAL blade_id;
  void Loop() override {
    PropBase::Loop();
    DetectTwist();
    DetectShake();
#ifdef BLADE_ID_MONITORED
        if (millis() - last_blade_id_ > 2000) {
          STDOUT << "BLADE ID: OLD =  "<< looped_blade_id_ << "\n";
          blade_id.id();
          last_blade_id_ = millis();
          STDOUT << "BLADE ID: checked = "<< blade_id.id() << "\n";
          if (looped_blade_id_ > blade_id.id() + 100 || looped_blade_id_ < blade_id.id() - 100) {
            STDOUT << "BLADE ID: DIFFERENT ***** do something here\n";
            // beeper.Beep(0.5, 1000);
            FindBladeAgain();
            SaberBase::DoBladeDetect(true);
          }
          looped_blade_id_ = blade_id.id();
        }
#endif
    Vec3 mss = fusor.mss();
..................

and initialized these at the bottom

uint32_t last_blade_id_ = millis();
uint32_t looped_blade_id_ = 0;

Might need to be tweaked per setup:
ENABLE_POWER_FOR_ID’s bladePowerPins are your blade’s LED pads.

• The id() +/- values.
• The 2000 delay adjust to taste.
• The detected values set in the BladeConfig.
  Use something reasonable based on what it shows in Serial Monitor for “BLADE ID: checked” for each state.
• You can kill the beep if you use bladein.wav instead.

Terrible?

This allowed for 3 different Preset states to be chosen.
a. Chassis only
b. Chassis slid into hilt
c. Main blade inserted

@Profezzorn replied wisely:

It’s not terrible. It’s in fact a pretty good idea, but I’m surprised this doesn’t crap out completely when you turn the blade on.

Blade ID can’t work at the same time as you’re transmitting data, so we would need to find a way to do this id check between data transmissions when the blade is on.

Also, style-wise you should probably just call blade_id.id() once and save it’s value in a local variable instead of calling it over and over again…

Doing something like this could be brittle and annoying. Imagine if it suddenly re-started everything every time you did a clash or something, but it could be pretty if/when it worked.

[Celemourn]

Was there a video to go along with this? I swear I saw one somewhere, but I can’t find it now.

[baldusi]

I’m sorry for necromancing this thread. But I’m currently building a bladeplug charger and have a wiring question.

I’m using an USB-C TP4056 module. Those have two outputs: Battery and OUT. As I understand it from the module’s page here, the OUT will simply pass through whatever input voltage it has. Thus, from an USB-C port, it should get 5V.
But the problem is that according to this page, the module expects less than C/10 current (it’s not clear if the module’s 1A setting or the battery’s actual C, I’m assuming the setting) to cut the charge. When we enter through the NPXL port, we can’t circumvent the power of the Proffie. But I could with the LEDs on the module (I use 10 5050’s).
So, and here comes the question: can I wire the WS2812B to the OUT line, while using the Data line from the Proffie (which I guess is using the same GND as BAT rather than OUT?
To put it Graphically: Should I do A:

or B:

[profezzorn]

My guess is that B- and DOUT- are actually connected to form a common GND.
If that’s true, then A is probably the better wiring scheme.
Just make sure to turn off any other blades and don’t play any sound while charging, and the proffieboard power draw should be small enough that the charger will be happy and turn off when done.

With a little bit of extra trickery, it might be possible to use the “charging” led pin on the board to drive a FET, and that fet can disable power to the pixel strip when charging is done.

[baldusi]

Apparently they use straight pass through:

If I understand correctly, the DW01A and the FS8205A are protection circuit and MOSFET and thus can be considered as “common” ground. Am I right?

[baldusi]

On a related note, since I’m still using 6.7 with no patches, I’m using the following preset:

	{ "PwrCell;common", "tracks/mars.wav",
		&style_charging,
		StyleNormalPtr<BLACK, BLACK, 300, 800>(),
		StyleNormalPtr<BLACK, BLACK, 300, 800>(),
		"Blade Chrg\nLevel"}	
};

With PwrCell only containing a boot01.wav (or font01.wav). If I take out the “; common” and just put a “” on the track parameter, that should disable all sounds?