THe problem is that on a V3 board bladeIdentifyPin is not actually the same as pin_->pin() (0 vs 1) those pins are tied together, but the code doesn’t know that apparently.
For now, I suggest hacking this by replacing bladeIdentifyPin with bladePin on line 291 and 256 while I try to figure out a correct fix.
No Blade ID resistor, no.
Should the values be so wildly different with and without defining SnapshotBladeID though?
I thought that was the default and therefore shouldn’t matter if manually defined or not?
Ok it’s working with the blade definitions set to 470 and 630.
Some kinks to iron out, like when inserting blade it’s switching to saber mode with power ON.
Also a million ID: printouts from this:
// Measure and return the blade identifier resistor.
float id() {
EnableBooster();
BLADE_ID_CLASS_INTERNAL blade_id;
float ret = blade_id.id();
STDERR << "ID: " << ret << "\n";
..............
I think we need a thing that is set when it switches to saber, and maybe that should call SaberBase::DoBladeDetect(false); so the saber starts OFF?
Also could use it to check whether or not to print out (and/or speak) the ID: and only do it if a switch just occured.
ok I left the BLADE_ID_CLASS undefined and went with an average of the values reported, 630000 and 750000 and that’s working.
The power ON when switching to saber is something else. I added a hum to the blaster font and same deal.
I’m submitting a PR to smooth out some of this BLADE_ID_SCAN MILLIS stuff based on my testing.
I have yet to fiddle further with the dual_prop integration and the presets starting in ON after using the blaster.
Past few days of coding and testing. just posting my test log here…for posterity?
Blade Detect / Blade ID Tests - 2 blades + no blade in hilt.
V3 board:
Measurements using default BLADE_ID_CLASS BridgedPullupBladeID
No blade = ~750000
Blade 1 = ~650000
Blade 2 = ~40000
Using NO_BLADE for no blade instead of measured resistance
Blade Detect - Only 40000 blade2 triggers a change. 650000 does not.
Blade ID Constant Monitoring - Only 40000 blade2 triggers a change. 650000 does not.
Blade ID original recipe* - Only 40000 blade2 triggers a change. 650000 does not.
* (no BLADE_ID_SCAN_MILLIS, read only at boot or "scanid")
Using measured value for no blade
Blade Detect - Works great, and with more than one blade too!
Blade ID Constant Monitoring - Works great! Blade1, blade 2, no blade, all correct.
Blade ID original recipe - Works great.
Summary - Using NO_BLADE mistakenly chooses blade 2 because 650000 is closer to 750000 than NO_BLADE (1 billion) is.
- Surprise! Blade Detect can use multiple blades too!
- Of course Blade Detect has the bonus of playing bladein and bladeout sounds, which is nice.
- Same results using dual_prop.h
V2.2 board w/ no Blade Detect wired.
Measurements using default BLADE_ID_CLASS SnapshotBladeID
Chassis only = ~595
Chassis in hilt = ~731
Blade 1 = ~135
Blade 2 = ~814
Measurements using BLADE_ID_CLASS BridgedPullupBladeID to TX pad.
Chassis only = ~730000
Chassis in hilt (no blade) = ~600000
Blade 1 = ~hmmm same ~600000 unfortunate. If it had ID resistor would be fine I'm sure.
Blade 2 = ~40000
Using measured value for no blade
Blade Detect - need hilt wired BD to test
Blade ID Constant Monitoring - Works perfectly
Blade ID original recipe - Works great.
Conclusion:
Works on both v2.2 and V3 boards, neither requiring a BLADE_ID_CLASS manually defined (defaults worked great),
but of course bridging data1<->TX pad and using BridgedPullupBladeID is much better with a V2.2 board.
No need to use NO_BLADE in the BladeConfig.
No real need to wire for Blade Detect anymore.
AND all of this with NO BLADE ID RESISTORS installed at all.
This is really nice! Up to now, I’ve wired for both Blade Detect and Blade ID. So it’s nice to know I can skip a wire and still be fine. I only have two questions:
If I read the log correctly, Blade Detect triggers bladein.wav and bladeout.wav. Does that mean that Blade ID Constant Monitoring won’t trigger these sounds (thereby still needing Blade Detect if you want those sounds)?
I’m planning on building more blades, but not all of them have ID resistors. What ID resistor values are recommended in such a case?
I have since made it do bladein/out sounds with Real Time Blade ID, as well as use the Voice Pack files for speaking the ID if SPEAK_BLADE_ID is defined… It’s just a matter of review and approval.
ID resistors are recommended in the 2k to 100k range, spaced out so there’s a decent difference from each other.
That said, I tested with 4 blades, and none of them have ID resistors in them. The measured values were varied enough on their own. Your milage may vary, so if it’s not built yet, it’s a good idea to add them.
In that case, I guess it’ll be available with the next ProffieOS update if it’s approved? And you’d only need to have the define SPEAK_BLADE_ID (and other real-time Blade ID defines) to get the bladein.wav and bladeout.wav sounds to play?
I see. My current main blades have no ID resistors. But I plan to add them to my new blades in the future. It’d be more a case of “better safe than sorry” haha.
Well, this was unexpected.
I have USB in with Serial Moitor open.
Adding / removing my kill key is triggering different values for blade ID, therefore doing bladein/bladeout.
I have to assume it has to do with the read calculations and the Battery power compared to USB power affecting the math.
I think that actually makes sense.
Without battery power, the neopixels won’t be powered, and without power, the data line sucks up power like a sponge, which affects the readout.
When the blade pixels are properly powered, their input is in high impedance (resistance) mode, which should affect the readings very little.