Blade_id_scan_millis

1

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?

2

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

3

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)},
4

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

5

Any chance the Chassis insertion triggers a Blade Detect?

6

No blade detect wired.

7

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.

8

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.

9

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
10

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…

11

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!

12

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.

13

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 )

14

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. :slight_smile:

2 Likes