This was a PM, but putting it here for public input.
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?
I see. Yeah, it did work, nothing crapped out. Although I was not doing any effects, just inserting and removing things to make sure the right blade array was being chosen.
There may be caveats, but I think the key might be to do it before this line:
If I remember correctly, once IsReadyForEndFrame() is true, that particular PIN is not transmitting, which means that we can call FindBladeAgain() if we want to.
The tricky part is that this class might have been deleted once we return from FindBladeAgain(), which means there is some hoops to jump through to make sure that it works properly.
There is also a possibility that calling findblade all the time will count as to the neopixels and cause glitches on the blade, but one step at a time I guess…
For anyone reading this, the latest to test would be
#define BLADE_ID_SCAN_MILLIS 1000
where millis is the blade ID scan interval.
If the blade ID comes out the same as before, it will do nothing. If it comes out different, it will do FindBladeAgain(), which will basically initialize the saber from scratch and load the right settings for the new id().
It will only work with neopixel blades, and it probably requires
#define SHARED_POWER_PINS to work.
“The force works in mysterious ways.”
NICE! I know a youngling and three people not running EditMode that could stand to use this option. I can’t jump in w testing r/n but let me know when things are ready, what props (or all props?) it’ll work for.
I saw in the POD that constant Blade ID monitoring will be a feature in ProffieOS7. And after reading some threads and code related to this, I want to be sure I understand it properly.
So with constant Blade ID monitoring, there won’t be any BladeID resistors necessary through #define SnapShotBladeID (in the blade or NPXL PCB connectors)? And there’s no wire required for Blade Detect? If constant Blade ID monitoring doesn’t need any resistors or Blade Detect, it would make it ideal for most of my installs.
Also, will this feature enable bladein.wav and bladeout.wav files to be played? Especially in thin-neck sabers, with PCBs in the grenade and emitter. My plan is to wire the NPXL LEDs in the grenade (or hilt) independently (V4 config), and the emitter NPXL LEDs in series (V3 config). If that would work, then this is the feature I’ve been looking for.
So it may work entirely without resistors, but it might not. For one thing, it depends on what you want to do. SnapshotBladeID is a hack, and the values it produces are not super-reliable, so it may not be possible to see the difference between different blades, but it should definitely be possible to see the difference between having a blade and having no blade.
Having resistors in the blade makes this better, and having a pullup resistor in the blade so you don’t have to use SnapshotBladeID makes an even bigger difference.
You should not need a blade detect wire.
I beleive bladein/bladeout should work with all of this without any changes, although I have not actually tested that.
One thing though: Blade ID does NOT work with having the emitter LEDs wired in series. Blade ID can only identify things it’s directly connected to.
I’d have to revisit my testing, but I do remember I was making it work with 3 stages with snapshotID;
chassis only (NO_BLADE),
insert chassis to/remove from hilt (emitterPCB),
and then blade in/out.
I have some blades with different lengths. And somehow, I once convinced myself that having Blade ID resistors in the hilts would be preferable (I now see that may not have been a smart choice). Disassembling all my blades just to add SMD resistors would be… quite a chore 
So that’s unfortunately not an option at the moment.
I did get Blade ID to work in a thin-neck with two Blade ID resistors. One in the grenade and the other in the emitter. The grenade PCB LEDs were in V4 config, and the emitter LEDs in V3 (it made the emitter a “part” of the blade, by wiring the 2nd data pad with the Blade ID resistor instead of the main pad). But that build had no constant monitoring, and required more wires than preferable. It certainly wasn’t ideal.
So if SnapshotBladeID is a hack, what would be the best approach to recognize different blades with no Blade ID resistors in them and have constant BladeID monitoring? Or would this hack be my best option (especially in thin-neck builds)?
SnapshotBladeID is your best bet.
SnapshotBladeID measures the capacitance of your blade, in addition to the resistance. And imperfections in the data resistor and in the first neopixel will usually make this a slightly different value for each blade.
It may not work, but it doesn’t hurt to try.
Okay. In that case, say I build myself another blade and put a Blade ID resistor in there, would SnapshotBladeID then recognize the two different blades much better (as they would then give much more different values)? And what if I give the data resistor in the grenade a different value than the one in the emitter (330 ohm vs. 470 ohm)? I figure that it would help SnapshotBladeID see more distinct values between the different state and blades. I could even try adding a resistor to the J-pad that enables the V3 config of the NPXL connector, though I don’t know if it that would mess up the data line itself.
So, SnapshotBladeID is a bit unpredictable, so you have to test things. Adding resistors to the blades will almost certainly help, not sure if any of the other things will do anything though…
I guess that adding a resistor in a new blade would help distinguish it from my current blade with SnapshotBladeID. The only thing I’m not sure of yet is whether it can distinguish between NPXL LEDs and blades, as I’d want to control the emitter LEDs separately from the main blade…
Although, will any of this matter if you use a Proffie V3 (since no additional components are needed for BladeID)?
The V3 doesn’t use SnapshotBladeID by default, but it can if you want it to.
I think the blade ID method used by the V3 is far more predictable than the SnapshortBladeID, but it may not be as good if your goal is to tell different blades without resistors apart.
How will the Blade ID method work for the V3? I get the sense it’ll be a bit different from what the V2 currently does.
It has two pins on the CPU tied to the “data 1” pin.
So it can use the pullup-resistors from one pin while using the analogRead on the other.
There is a blade ID class specifically for this:
#define BLADE_ID_CLASS BridgedPullupBladeID<bladeIdentifyPin, 9>
V3 boards will use this blade ID class by default.
For BladeID to work, you need to have Data1 going straight to the blade, you can’t put the Illuminated PCB in series before. So you’d need to do a V4 config in the Shtok PCB. And you can only ID the blade, not about changing hilts (I think @NoSloppy got around placing a resistor on Data1 in the hilt and then selecting the sums, but he’s got the details).
At least in theory, you should be able to configure your illuminated PCB in a parallel configuration, and with a resistor you may be able to even tell if the grenade section is connected or not. It’s all iffy and not well tested though, so YMMV…
I did get Blade ID to work in that scenario, in a thin neck hilt. The board recognized the different “states”, but I had to restart it every time. The only thing that setup lacked was the constant monitoring. I’ll look up the wiring diagram that was shared at the time.
The plan was to wire the grenade NPXL PCB in V4, and the emitter NPXL in V3. So the emitter LEDs would be a “short blade”, and through SubBlade I can add a 2nd “main blade”. The question is whether SnapshotBladeID would recognize those NPXL LEDs in the emitter, the main blade on top of it (so blade 2 = emitter NPXL LEDs + main blade) and another shorter blade (with potentially a Blade ID resistor in it).
Also, I don’t know how the Proffie V3 would handle this situation.