I should be sleeping but this caught my attention. 
Way to go!
2 Likes
Just tried this, and unfortunately because I’m not using Blade Detect, only Blade ID, I’ve had to set BladeID to scan every second in case a new blade or charger is inserted. So when I add the speak define, it simply keeps blurting out announcements permanently. 
On a brief aside, since the Proffie is having to run BladeID so often in readiness for a new blade, is that taking up a load of processing power?
No.
It’s a fairly brief process and it only runs a few times per second, so the amount of CPU time used is very minor.
1 Like
Here’s how testing is going:
3 Likes
This looks amazing! 
Great work guys!
So is this just BladeID or are you also using Blade Detect in the video with the extra pin wired up?
The video is blade ID.
Using Blade Detect pin, it chooses one of the blade definitions and I haven’t looked into why yet, but for me it’s always blade_1
This is the BladeConfig:
BladeConfig blades[] = {
{ NO_BLADE, // blade = 0
WS281XBladePtr<0, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), // Main Blade
WS281XBladePtr<5, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), // HiltPCB
WS281XBladePtr<11, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5> >(), // Switches
SimpleBladePtr<AccentsLED, NoLED, NoLED, NoLED, bladePowerPin1, -1, -1, -1>(), // Pommel
SimpleBladePtr<CH3LED, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(), // Bluetooth
CONFIGARRAY(blade_0)},
{ 650000, // blade = 1
WS281XBladePtr<100, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), // Main Blade
WS281XBladePtr<5, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), // HiltPCB
WS281XBladePtr<11, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5> >(), // Switches
SimpleBladePtr<AccentsLED, NoLED, NoLED, NoLED, bladePowerPin1, -1, -1, -1>(), // Pommel
SimpleBladePtr<CH3LED, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(), // Bluetooth
CONFIGARRAY(blade_1)},
{ 40000, // blade = 2
WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), // Main Blade
WS281XBladePtr<5, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(), // HiltPCB
WS281XBladePtr<11, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5> >(), // Switches
SimpleBladePtr<AccentsLED, NoLED, NoLED, NoLED, bladePowerPin1, -1, -1, -1>(), // Pommel
SimpleBladePtr<CH3LED, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(), // Bluetooth
CONFIGARRAY(blade_2)},
};
I have swapped blade_1 and blade_2 in presets and element order in the blades array. Still selects blade_1 every time ¯_(ツ)_/¯
And what does SAY_BLADE_ID say?
Well, scanid , id, and blade presence all show the “BLADE ID:” of blade_2 at ~584000, and SPEAK_BLADE_ID says the same number.
Same with no blade in. all 3 methods roughly the same ~750000.
However, blade_1 has scanid and blade presence both report ~300,000, but the weird thing is that id reports only ~30,000.
So with the blades array as:
{ 28000,
................
CONFIGARRAY(blade_1)},
{ NO_BLADE,
................
CONFIGARRAY(blade_0)},
{ 575000,
................
CONFIGARRAY(blade_2)},
blade 2 is always chosen and at 28000, blade_1 was never chosen.
I edited blade_1 to use 300000 and then it worked!
So what’s the goal here anyway?
Are we expecting Blade Detect to also do a Blade ID thing and choose a close match on the blades elements?
Because it DOES,
which to me eliminates the need for Blade Detect wiring at all.
What would be the difference then between Detect and ID? Other than being able to hard wire a switch to enable the change.
“id” is an old command, and it shouldn’t be used anymore. I should probably just remove it. Since it doesn’t tear down the blades, and also doesn’t synchronize the scan with the ws2811 code, it produces crazy values sometimes.
Blade detect will become less important if blade ID will work well for the same function. Maybe blade detect will end up being more of a “core in chassis detect” instead? Either way, blade detect will still be supported going forward, and people may use it if they think it’s better.
We may also want to think about generic multi-function detection, making it possible to connect parts in any which way. Depends on what people are interested in I guess.
1 Like
@Sabersense try the latest ProffieOS from github, it should play bladein/bladeout/font now. For bladein/bladeout to work, one entry in the blade array needs to have the NO_BLADE label, and then you need a define like
#define NO_BLADE_ID_RANGE 1000,2000
Where the two numbers are the minimum and maximum blade ID values that should go to the NO_BLADE entry.
Which you obtain initially by looking at the serial monitor at preset change or just running scanid a few times and take the lowest and highest values you see reported (I did like 10-15 scans)
Usually you need some margins as well.
I usually record all the values for all the blades (and the no blade case) and then I put the cutoffs right in between.
So it returns 750000 in the no-blade case and 300000 in the highest case with a blade, I would set the no-blade range to 525000,1000000
1 Like
I’m good with this logic so long as like you wrote Blade Detect stays working going forwards. We went to the trouble of fixing it so it may as well stay for that use serving as a User Interface Effect like the core, Krayt Pearl, or Kyber Crystal is or is not in play.
Awesome work @NoSloppy ! A key question to reiterate though. I don’t need to go installing anything as far as resistors in the blade connectors or blade-side pcb’s correct? This new bit all operates off of value set reads (blade total resistance value) right?
@profezzorn @NoSloppy
Guys, this is just incredible! I really didn’t mean to create a load of work for people, though it sounds like Brian, you were ahead of me as always and were already a long way down this path. But I can’t express my gratitude enough. Thank you! 
So I’ve downloaded the ProffieOS GitHub Master and tried it, and it works brilliantly. Thank you again!
Tech notes to add though are:
-
With my setup, it doesn’t seem to play the font ident, only the bladein.wav, and it only plays the bladein.wav when the charge blade is fitted, When you remove the charge blade, it doesn’t play bladeout.wav, instead it plays bladein.wav of the blade array it’s switched to. Which actually is probably the most logical way of doing it. The thing in my case is I’m sharing no blade and normal blade as a single setting, and just using bladeid to identify the charge blade, so all good on that score. Which brings me neatly onto my next note…
-
Specifying an ID range works brilliantly, because you can make no blade and a normal blade (one without an ID resistor) both count as the same thing, then have a charge blade (that does include an ID resistor) count as a different blade. This might not suit everyone, but is perfect for me.
The ID numbers in my case were obtained by simply watching the Serial Monitor, as the config has the continual BladeID scans defined, so it just keeps on scanning every second:
#define BLADE_ID_SCAN_MILLIS 1000
#define BLADE_ID_TIMES 10
One thing I’m puzzled about though is values. In your posts above, and in Dmitry’s manual, you talk about scanid returning values in the thousands or hundreds of thousands, but I’m only getting values in tens.
Though they varied a little, perhaps plus or minus 1 between scans, these are the average figures I got:
No blade fitted - 82.40
Normal blade fitted (no ID resistor) - 87.50
Charge plug fitted (includes 22,000 ohm ID resistor between Ground and Data) - 53.30
When I tried using the decimals in the config, it threw an error, so I used the following for the define at the top to cover no blade and normal blade:
#define NO_BLADE_ID_RANGE 70,100
Then I used the blade array below for differentiating between blade states and specifying the charge blade:
BladeConfig blades[] = {
{ NO_BLADE,
// Main Blade:
WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
// Crystal Chamber:
WS281XBladePtr<1, blade4Pin, Color8::RGB, PowerPINS<bladePowerPin4>>(),
// Plasma gate 1:
SubBlade (0, 0, WS281XBladePtr<3, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin4>>()),
// Plasma gate 2:
SubBlade(1, 1, NULL),
// Emitter Back:
SubBlade(2, 2, NULL),
// 5mm Red LED:
SimpleBladePtr<RedLED<100000>, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(),
// Proffie Micro LED:
SimpleBladePtr<BlueLED<47000>, NoLED, NoLED, NoLED, bladePowerPin1, -1, -1, -1>(),
// Duel Strips:
SubBladeReverse (0, 3, WS281XBladePtr<4, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin5>>()),
CONFIGARRAY(presets) },
// Use for blade plug charging.
// Main blade must be data 1.
{ 53,
// Main Blade:
WS281XBladePtr<132, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
// Crystal Chamber:
WS281XBladePtr<1, blade4Pin, Color8::RGB, PowerPINS<bladePowerPin4>>(),
// Plasma gate 1:
SubBlade (0, 0, WS281XBladePtr<3, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin4>>()),
// Plasma gate 2:
SubBlade(1, 1, NULL),
// Emitter Back:
SubBlade(2, 2, NULL),
// 5mm Red LED:
SimpleBladePtr<RedLED<100000>, NoLED, NoLED, NoLED, bladePowerPin6, -1, -1, -1>(),
// Proffie Micro LED:
SimpleBladePtr<BlueLED<47000>, NoLED, NoLED, NoLED, bladePowerPin1, -1, -1, -1>(),
// Duel Strips:
SubBladeReverse (0, 3, WS281XBladePtr<4, blade2Pin, Color8::GRB, PowerPINS<bladePowerPin5>>()),
CONFIGARRAY(charging), "savechrg"}
Ultimately I guess it doesn’t matter what numbers the Proffie gives me as long as they’re entered back into the config correctly. But I am curious to know why my numbers seem to be so much lower than everyone elses.
But either way, the great news is IT WORKS!!!
If it’s a v2.2 board, it’s using SnapshotBladeID as the class which is not going to give you numbers based on the resistance really. If you can afford to use either bridged pull up or external pull up you’ll get better numbers with more flexibility ( distance between)
1 Like
Thanks Brian. That does make sense. Yeh, it is a 2.2 and I’ve not done anything in the way of wiring changes - all I’ve done is add the 22k resistor to the charge plug.
Interestingly I just checked blade ID again, as I had to make a new blade to go with this hilt, and this time it wasn’t showing BladeID scans every second in serial monitor, though it must have been doing them as it detected the charge plug correctly as before. To get the numbers I had to enter scanid, which worked fine, but It also returned unusual numbers of 54.40 for the charge plug, but 1,000,000,000.00 (my commas for clarity) for a normal blade and no blade. I’m guessing the GitHub Master must have a few changes re. how it handles that stuff in Serial Monitor compared to the release 7.13.
But anyway, it’s all working so I’m a happy padawan! 
github master is well on it’s way to become ProffieOS 8.x…
1 Like
NO_BLADE_ID_RANGE takes what you have in the range and returns 1 billion, so what you said makes sense it means it’s working. If you have another blade also close to the range, maybe adjust it down a little?
1 Like
@profezzorn I’m here trying to run this Blade ID experience from ground up, from the perspective of an average user with nothing set in place for it to work yet.
To set this up requires running scanid to get the measured value.
However, there’s a NELEM check in place that would prevent a report if the user hasn’t first uploaded with multiple blades elements.
It seems we could either just state in the how-to documentation to create multiple entries and upload that first (values not mattering yet, just to get them in the list to pass this check), or would just removing this check make more sense? (at the cost of some mem I suppose?)
Well, some people might not need to use scanid, because of you have a V3, board, a teensysaber board, or a V2 board with a pullup resistor, and then you can just use the resistor values and call it a day.
On the other hand, if you have blades without resistors, or are using the snapshot blade ID class, then you need to use scanid (or something similar) to establish the right values before you can use them.
So given that, is it better to:
- Write two guides, one with scanid, one without
- Write one guide, but with an optional sub-section for people who need to use scanid?
- Write one guide which always uses scanid, even if some people don’t need it?
Another consideration here is that the unpredictable nature of the snapshot blade id is that it could potentially generate the same blade ID for different blades, even if those blades have different resistors in them. That makes it hard to recommend this method unless you’re trying to add blade ID to an existing installation.