BLADE_ID_SCAN_MILLIS: new feature

profezzorn · August 6, 2023, 12:41am

Ah, I see the problem:

profezzorn/ProffieOS/blob/7edb8b3efb28b1ef8bc7cecd0f920924cdaa9db4/blades/ws2811_blade.h#L291


      
                if (!powered_) {
          	if (allow_disable_) {
          	  run_ = false;
          	  continue;
          	}
          	Power(true);
                }
          
          
      while (!pin_->IsReadyForEndFrame()) BLADE_YIELD();
          #ifdef BLADE_ID_SCAN_MILLIS
                if (pin_->pin() == bladeIdentifyPin && ScanBladeIdNow()) {
          	pin_->Enable(powered_);
          	SLEEP(1);
          	if (current_blade != this) goto retry;
                }
          #endif      
                pin_->EndFrame();
                loop_counter_.Update();
          
          
      if (powered_ && allow_disable_) {
          	power_off_requested_ = true;

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.

NoSloppy · August 6, 2023, 1:15am

Cool. Ok, well with that workaround, I get the PVLOG printout, but no switching without BLADE_DETECT_PIN defined.
using this mix:

#define SHARED_POWER_PINS
//#define BLADE_DETECT_PIN 10 //10 is Free3 which is how the hilt is wired
#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
#define DUAL_PROP_CONDITION (current_config != blades)

The blade ID is shown at every interval

// blade in with PVLOGs
21:08:54.015 -> ID: 635060.69
21:08:54.984 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:08:54.984 -> ID: 631499.81
21:08:55.992 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:08:55.992 -> ID: 633873.69
// blade out
21:08:56.987 -> ID: 745954.69
21:08:57.988 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:08:57.988 -> ID: 754013.19
21:08:58.975 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:08:59.010 -> ID: 744279.31

but again, no switching. Is it too far from NO_BLADE?

Interestingly, If I add the SnapshotBladeID<bladeIdentifyPin> define back in,
the ID numbers are more consistent and way different:

// blade in
21:06:30.629 -> ID: 629.00
21:06:31.592 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:06:31.625 -> ID: 629.00
21:06:32.580 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:06:32.615 -> ID: 628.60
// blade out
21:06:27.613 -> ID: 475.00
21:06:28.574 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:06:28.611 -> ID: 475.20
21:06:29.589 -> ********** now - last_scan_id_ > BLADE_ID_SCAN_MILLIS
21:06:29.624 -> ID: 475.20

no difference in values or anything if I change the bladeIdentifyPin to bladePin as in
SnapshotBladeID<bladePin>.

profezzorn · August 6, 2023, 2:15am

Yeah, you’ll need to use the values you see, not NO_BLADE.
NO_BLADE only works with blade detect.

Do you have a blade ID resistor in the blade?

NoSloppy · August 6, 2023, 2:23am

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";
..............

but, progress! thanks.

NoSloppy · August 6, 2023, 2:28am

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.

profezzorn · August 6, 2023, 2:29am

Yes SnapshotBladeID does not measure resistance, and the values are not even remotely comparable.

It’s the default on a V2 board.
On a V3 board the default is:

github.com

profezzorn/ProffieOS/blob/7edb8b3efb28b1ef8bc7cecd0f920924cdaa9db4/blades/blade_id.h#L104


      
            float id() { return 0.0; }
          };
          
          
// Define the default blade ID class.
          
          
#ifndef BLADE_ID_CLASS
          
          
#ifdef TEENSYDUINO
          #define BLADE_ID_CLASS InternalPullupBladeID<bladeIdentifyPin>
          #elif PROFFIEBOARD_VERSION - 0 >= 3
          #define BLADE_ID_CLASS BridgedPullupBladeID<bladeIdentifyPin, bladePin>
          #elif defined(PROFFIEBOARD_VERSION)
          #define BLADE_ID_CLASS SnapshotBladeID<bladeIdentifyPin>
          #else
          #define BLADE_ID_CLASS NoBladeID
          #endif
          
          
#endif  // BLADE_ID_CLASS
          
          
#ifdef BLADE_ID_TIMES
          #define BLADE_ID_CLASS2 AverageBladeIDNTimes<BLADE_ID_TIMES, BLADE_ID_CLASS>

This blade ID class tries to measure the actual resistance.

I think that’s because the blaster font didn’t have a hum, so it forced the power on?

NoSloppy · August 6, 2023, 2:43am

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’ll have to play with this more tomorrow.

profezzorn · August 7, 2023, 5:11am

A post was split to a new topic: Blade detect speed

NoSloppy · August 14, 2023, 2:46am

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.

NoSloppy · August 16, 2023, 1:06am

Ok I got it working with dual_prop too.

NoSloppy · August 19, 2023, 3:30am

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.

TheJediSmuggler · August 19, 2023, 4:32pm

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?

NoSloppy · August 19, 2023, 5:50pm

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.

TheJediSmuggler · August 19, 2023, 6:09pm

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.

NoSloppy · August 19, 2023, 6:34pm

Yes and yes.
Yes.

profezzorn · August 19, 2023, 7:40pm

If you mean 8.x, then yes.
If you mean 7.11, then no.

(This is new features, not bugfixes, so it will not be merged into 7.x)

TheJediSmuggler · August 19, 2023, 8:46pm

Cool. I’ll be looking forward to ProffieOS8

NoSloppy · August 27, 2023, 12:24am

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.

profezzorn · August 27, 2023, 3:20am

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.

NoSloppy · August 27, 2023, 8:47am

Cool.
Having LED2&3 line fall off in the chassis mashing also contributed probably!