BLADE_ID_SCAN_MILLIS: new feature

NoSloppy · February 6, 2023, 4:14am

From the 7.x pre-alpha thread, continuing here.

Well I was writing this whole long thing of what I was experiencing, but it’s all too erratic to even log.
It might be because of the way it’s wired (Data1->emitter NPXL PCB in parallel with main blade)
It might be it doesn’t like to work with SnapshotBladeID.
I bridged Data 1 to the TX pin, and the values are jumping all over the place and I get constant switching back and forth between preset banks.
So I’m standing down.
I think the proper test is actually using Blade ID resistors in the blade.

That said, I did notice that the scan just stops when switching… SOMEtimes.
And, it doesn’t seem to be running at boot, or cycling through presets. It needs to have a first ignition to start scanning?

baldusi · February 6, 2023, 5:06am

You mean a Shtok V3 in what Shtok confusingly named V2 configuration (parallel lines) or an ECO PCB?

NoSloppy · February 6, 2023, 5:12am

Like when using SnapshotBladeID, it WANTS to work.
It reads a constant same value once per 1000ms until I add the first change (which in this case is a removable chassis going into a hilt with an emitter NPXL PCB)
Then it keeps reading 2 different IDs, and it switches back and forth , and I get stuck in a loop.
Notice how there’s 2 ID readouts each loop once the resistance is added.
Why the second reading?

23:55:49.173 → id() ID: 728.00
23:55:50.194 → id() ID: 729.00
23:55:51.177 → id() ID: 728.00
23:55:52.180 → id() ID: 729.00
23:55:53.200 → id() ID: 729.00
23:55:54.186 → id() ID: 728.00
23:55:55.183 → id() ID: 728.00
23:55:56.192 → id() ID: 728.00
23:55:57.188 → id() ID: 811.00
23:55:57.326 → id() ID: 709.00
23:55:57.326 → blade = 1
23:55:57.326 → WS2811 Blade with 132 leds.
23:55:57.326 → Style RAM = 8
23:55:57.326 → Scanning sound font: aa_NoSloppy/PoliceSirenV1 done
23:55:57.326 → Scanning sound font: common done
23:55:57.401 → Scanning sound font: commonBU done
23:55:57.721 → Activating polyphonic font.
23:55:57.793 → Activating SmoothSwing V2
23:55:57.793 → Accent Swings Enabled.
23:55:57.793 → Polyphonic swings: 7
23:55:57.793 → Monophonic swings: 0
23:55:57.793 → Accent Slashes NOT Detected:
23:55:58.186 → id() ID: 813.00
23:55:58.293 → id() ID: 709.00
23:55:58.293 → blade = 1
23:55:58.293 → WS2811 Blade with 132 leds.
23:55:58.293 → Style RAM = 8
23:55:58.293 → Scanning sound font: aa_NoSloppy/PoliceSirenV1 done
23:55:58.331 → Scanning sound font: common done
23:55:58.403 → Scanning sound font: commonBU done
23:55:58.711 → Activating polyphonic font.
23:55:58.780 → Activating SmoothSwing V2
23:55:58.780 → Accent Swings Enabled.
23:55:58.780 → Polyphonic swings: 7
23:55:58.780 → Monophonic swings: 0
23:55:58.780 → Accent Slashes NOT Detected:
23:55:59.203 → id() ID: 811.00
23:55:59.313 → id() ID: 710.00
23:55:59.313 → blade = 1
23:55:59.313 → WS2811 Blade with 132 leds.
23:55:59.313 → Style RAM = 8
23:55:59.313 → Scanning sound font: aa_NoSloppy/PoliceSirenV1 done
23:55:59.352 → Scanning sound font: common done
23:55:59.385 → Scanning sound font: commonBU done
23:55:59.707 → Activating polyphonic font.
23:55:59.779 → Activating SmoothSwing V2
23:55:59.779 → Accent Swings Enabled.
23:55:59.779 → Polyphonic swings: 7
23:55:59.779 → Monophonic swings: 0
23:55:59.779 → Accent Slashes NOT Detected:
23:56:00.195 → id() ID: 811.00
23:56:00.301 → id() ID: 710.00
23:56:00.301 → blade = 1
23:56:00.301 → WS2811 Blade with 132 leds.
23:56:00.301 → Style RAM = 8
23:56:00.301 → Scanning sound font: aa_NoSloppy/PoliceSirenV1 done
23:56:00.334 → Scanning sound font: common done
23:56:00.403 → Scanning sound font: commonBU done
23:56:00.689 → Activating polyphonic font.
23:56:00.794 → Activating SmoothSwing V2
23:56:00.794 → Accent Swings Enabled.
23:56:00.794 → Polyphonic swings: 7
23:56:00.794 → Monophonic swings: 0
23:56:00.794 → Accent Slashes NOT Detected:

Here’s the BladeConfig for what it’s worth, with values for each state entered from what it got scanned as.

BladeConfig blades[] = {
{ 593, // ** CHASSIS REMOVED - SnapshotBladeID
  // { 736694, // ** CHASSIS REMOVED - BridgedPullupBladeID TX pin 9
  WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
CONFIGARRAY(nothing)}, 

{ 729, // ** CHASSIS INSERTED - SnapshotBladeID
// { 600000, // ** CHASSIS INSERTED - BridgedPullupBladeID TX pin 9
  WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
CONFIGARRAY(NPXL)}, 

{ 810, // ** BLADE INSERTED - HiltPCB and Main Blade in parallel - SnapshotBladeID
// { 500000, // ** BLADE INSERTED - HiltPCB and Main Blade in parallel- BridgedPullupBladeID TX pin 9
  WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
CONFIGARRAY(bladein)},

NoSloppy · February 6, 2023, 5:13am

Yes and maybe and… It’s a PCB that’s wired to data1 and parallels the signal to the center pogo.

baldusi · February 6, 2023, 5:25am

Any chance the Chassis insertion triggers a Blade Detect?

NoSloppy · February 6, 2023, 5:30am

No blade detect wired.

profezzorn · February 6, 2023, 5:30am

Is it stable when not using BLADE_ID_SCaN_MILLIS ?
If you run scanid while the blade is off, do you get a similar values each time?
Not running on boot sounds like a bug, I should fix that.

profezzorn · February 8, 2023, 4:57am

I checked in some fixes and optimizations for BLADE_ID_SCAN_MILLIS.
Also, I added a new define BLADE_ID_TIMES. It lets you tell ProffieOS to turn blade ID N times and take the average, which seems to be pretty much required to use BLADE_ID_SCAN_MILLIS, as the values are pretty noisy otherwise.

I did some testing with these settings:

#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin1>
#define BLADE_ID_CLASS ExternalPullupBladeID<bladeIdentifyPin, 33000>
#define SHARED_POWER_PINS
#define BLADE_ID_SCAN_MILLIS 100
#define BLADE_ID_TIMES 10

Please adjust according to your build, do not cut and paste blindly.

NoSloppy · February 9, 2023, 5:56am

Working great with SnapshotBladeID as far as recognizing blades and switching.
However, it’s crippling everything else.
For example, a pulsing Color When Off is about 3 slow stepped levels of brightness.
Can not turn on (no button event registered). Spamming the power button I got one to be recognized and it turned on, but then everything pretty much behaving like molasses and unusable.

// ------ Blade Stuff ------

#define ENABLE_WS2811
const unsigned int maxLedsPerStrip = 144;
#define SHARED_POWER_PINS
#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3>
#define BLADE_ID_CLASS SnapshotBladeID<bladeIdentifyPin> 
#define BLADE_ID_SCAN_MILLIS 1000
#define BLADE_ID_TIMES 10

profezzorn · February 9, 2023, 7:18am

Well, SnapshotBladeID apparently has a delay(100) in it, which is totally unacceptable when scanning 10 times.

I’m fairly certain that a 100ms delay is overkill.
I’m changing it to a delay(1), but please let me know if people have problems with blade ID…

NoSloppy · February 9, 2023, 6:59pm

ok so that fixes it for SnapshotBladeID.
Again, my setup is a bit unconventional for BladeID, yet probably a pretty typical wiring;
Data1 feeds the emitter PCB, which feeds the main blade in parallel.
No BladeID resistors installed.

Using SnapshotBladeID, these numbers fluctuate each time slightly.
With nothing connected (chassis only) = ~519
Chassis into hilt (so adding emitter PCB) = ~634
Add blade = ~720
This works perfectly, switching as expected, anytime, On() or Off().

When using BridgedPullupBladeID TX pin 9, I don’t get the separation between emitter PCB and Blade in.
With nothing connected (chassis only) = ~733000
Chassis into hilt (so adding emitter PCB) = ~630000
Add blade = same ~630000

So for this setup, SnapshotBladeID it is, and it’s all good!

profezzorn · February 9, 2023, 7:33pm

If you had a blade ID resistor in the blade, this might work better.
Most blade id implementations are focused on measuring resistance, but that doesn’t really change when you just add one more neopixel in parallel with the existing one. However, the RC value will change, which is what the snapshot id measures.

NoSloppy · February 9, 2023, 8:16pm

Understood, it’s just odd that having 16 LEDs on the PCB, then adding 132 additional doesn’t trigger a difference. Well, odd in the theory, but the execution of what’s going on it probably makes perfect sense.
All good.
Someone with BladeID resistor needs to test.
Maybe they can try this same setup and see the difference (I’m not opening this blade )

profezzorn · February 9, 2023, 8:26pm

Number of LEDs have little or no effect on blade ID.
Blade ID basically has no way of knowing anything about what is behind the first LED.
If SnapshotID is working for you, don’t worry about adding a blade ID resistor.

NoSloppy · July 31, 2023, 6:11am

Revisiting this as I am setting up a dual_prop based config.
Is this not going to work? I thought Blade Detect and Blade ID can work together.

With these defines:

#define SHARED_POWER_PINS
#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3>
 #define BLADE_ID_SCAN_MILLIS 1000
 #define BLADE_ID_TIMES 10

I get the error:
ProffieOS/props/dual_prop.h:29:29: error: 'blade_detected_' was not declared in this scope 29 | #define DUAL_PROP_CONDITION blade_detected_

profezzorn · August 1, 2023, 6:45am

The dual prop expects a blade detect pin right now.
That might be fixable, but for now, this is expected behavior.

NoSloppy · August 1, 2023, 6:51am

Maybe we put an #error saying as much then ?
Is it possible to check if #include "../props/dual_prop.h" was set?

profezzorn · August 1, 2023, 6:58am

Since the condition is changeable it’s not quite that simple.
You could try:

#define DUAL_PROP_CONDITION (current_config != blades)

(This assumes that your NO_BLADE config is first.)

NoSloppy · August 3, 2023, 8:05pm

Swapped Preset saber [] and Preset blaster [] arrays so that blaster is first.
Also swapped blade definitions in the blades[] array so that NO_BLADE is first.
Using BC saber file and blaster props.
Added #define DUAL_PROP_CONDITION (current_config != blades)

I get a problem with blade_detected_ in dual_prop.h :

ProffieOS/props/dual_prop.h:117:25: error: 'blade_detected_' is not a member of 'SaberBCButtons'
  117 |  Saber::blade_detected_ = true;
      |         ~~~~~~~~~~~~~~~~^~~~~~

My C++ fu is still not good with classes, members, inheriting, overriding, etc…

profezzorn · August 3, 2023, 8:14pm

Well, I don’t know if it will work, but, here is what I would try:

Change line 30 from:

#define DUAL_PROP_CONDITION blade_detected_

to

#define DUAL_PROP_CONDITION Saber::blade_detected_

Search and replace Saber::blade_detected_ with DUAL_PROP_CONDITION, except the two assignments. (line 118 & 125)
Add an #ifdef BLADE_DETECT_PIN around the BUTTON_BLADE_DETECT detect code. (line 115-131)