Hmm. Ok i tried that. It compiles, but It seems that it’s never doing the scan.
To debug, I intentionally removed #define SHARED_POWER_PINS but did not get the warning message.
I added a printout when the scan should run and do not see that either.
With BLADE_DETECT_PIN defined, it works as usual.
However, without BLADE_DETECT_PIN defined, still no dice (it just does nothing when inserting a blade).
To clarify, the goal here is to see if this dual prop can switch using the continuous Blade ID scanning without the need to wire up a latching BLADE_DETECT_PIN.
Here’s the part that doesn’t seem to be considered:
#ifdef BLADE_ID_SCAN_MILLIS
#ifndef SHARED_POWER_PINS
#warning SHARED_POWER_PINS is recommended when using BLADE_ID_SCAN_MILLIS
#endif
bool find_blade_again_pending_ = false;
uint32_t last_scan_id_ = 0;
bool ScanBladeIdNow() {
STDOUT << "********** Running ScanBladeIdNow()\n";
And these are the relvant defines:
//#define BLADE_DETECT_PIN 10 //10 is Free3
//#define SHARED_POWER_PINS
#define ENABLE_POWER_FOR_ID PowerPINS<bladePowerPin2, bladePowerPin3>
//#define BLADE_ID_CLASS SnapshotBladeID<bladeIdentifyPin>
#define BLADE_ID_SCAN_MILLIS 1000
// How many Blade ID scans to average
#define BLADE_ID_TIMES 10
#define DUAL_PROP_CONDITION (current_config != blades)
Ok, this is figured out.
In Arduino preferences, compiler warnings drop-down was set to NONE. Changing it to DEFAULT shows the SHARED POWER_PINS warning.
I updated the arduino_preferences image on the POD, as it was set to NONE there as well.
This is the first time i’ve ever changed it from the “default” , which is NONE, to DEFAULT.
Not confusing at all .
However, still not getting any scanning (and my printout never shows).
The only action is if BLADE_DETECT_PIN is defined then things work.
That’s a negative Ghost Rider.
Nothing happens, no printout.
Adding #define BLADE_DETECT_PIN back in makes it switch as normal, but no printouts still.
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.
.