Using Blade Detect and BladeID at the same time?

[profezzorn]

@Sabersense

Detect and ID Take 2 - Pastebin.com

There is something wonky going on here.
You have:

#define NO_BLADE_ID_RANGE 668000,690000

(which is an oddly specific and fairly narrow range.)
You also have “mode 2”:

{ 660000.00,

These are very close, which is really weird.
My guess is that you set this up to avoid a problem rather than fixing it again.

The way this is supposed to work is that you specify a NO_BLADE_ID_RANGE that includes whatever value your ID function returns when there is no blade in. THen you would change mode 1 to be NO_BLADE*2, since both blade detect and blade ID will return NO_BLADE in that case.

Once this is set up correctly, ProffieOS will know which setups are “BLADE IN” and which ones are “BLADE OUT”, and that should make “bladein” and “bladeout” work properly. (Unless I messed it up, ProffieOS should already handle bladein/bladeout properly, but it won’t work unless you use NO_BLADE to tell it which styles are have blades and which ones do not.)

Right now it only plays bladein/bladeout if the IN/OUT status actually changes though, which might not be right when taking the chassis out of the hilt, right now it will play the font sound for that since we don’t have a “chassisin”/“chasissout” sound. That code can be changed though since it’s fairly new.

[Sabersense]

There seems to be some part of this puzzle I’m still not quite grasping. I’ve also done some more testing and have a couple more observations.

Firstly, Prof I think you’re right and that I might have been chasing my tail a bit with ID scans and may have had some wrong numbers. I now have the NO_BLADE define as:

#define NO_BLADE_ID_RANGE 990000000,1100000000

which does seem more reliable.

However, when I specify a NO_BLADE*2 in the blade array, ProffieOS loses the ability to distinguish between the chassis fitted but with no blade, and the chassis fitted WITH a blade. But it will still recognise the charge plug which has a 20k resistor fitted between data and gnd.

If I replace NO_BLADE*2 in the blade array with an id number from a blade scan performed with the chassis fitted but no blade fitted, (in my latest config below it was 636000) ProffieOS can now tell the difference between chassis fitted but with no blade and chassis fitted WITH a blade.

But it only works if the blade has a substantially different ID value from the no-blade state. I have an LGT blade which gives an ID of 32700 which is quite low, and ditching NO_BLADE*2 as detailed above works great as the hilt knows at all times what is fitted where. But I have another blade with KR strips which give a much higher id value of 658000 - which is fairly close to the chassis fitted number of 636000 - and it doesn’t like that at all and gets confused between which state it’s supposed to be in. (With more experimentation, it might be possible to fix that by using numbers closer to the extremes, like 630000 and 665000 respectively, but I haven’t got that far yet).

Given that things do tend to ‘flutter’ a bit in reality, I guess all of the above is expected behaviour, and being able to use either NO_BLADE*2 or a blade id number does give lots of flexibilty for different install options. Or is there something I’m still missing?

In terms of which wavs play for which action, fitting/removing the chassis does indeed always play bladein and bladeout wavs, which again seems correct to me as chassis fitting is utilizing blade detect. Fitting any blade however always plays the upcoming font ident as it utilizes bladeid.

Which again all seems correct to me, especially if you’re having different font arrays for different blades. But if you’re duplicating font arrays apart from a pre-font folder, it might be fun to have the option for blade fitting to play the bladein from that pre-folder, as you could then customize it to announce which blade had been fitted. But as I say, it’s just an idea.

Detect and ID Take 3 - Pastebin.com

[Sabersense]

Hold on - I think there are some other factors here.
Ignore the above post for now - will report back with an update shortly…

[Sabersense]

I think we may have been slightly at cross purposes, so just to clarify and to put the derived id numbers in perspective, my chassis has an 11 pin Shtok connector on the front of it, wired so that connector LEDs and blade data pin are in parallel.

The front section of the hilt has a second Shtok connector, this time a 7 pin eco version, again wired so that connector LEDs and blade data pin are in parallel. The blade detect wire is obviously only fitted to the connector on the main body to tell when the front section has been added.

When the chassis is together to complete the hilt, both Shtok connectors are linked together in parallel on their way to the main blade if that makes sense.

This diagram shows the layout:

I don’t know if it’s relevant, but part of my tail chasing has been tracked to the id command giving slightly different bladeid figures depending on whether the board was loaded with a config that ran scanid every second compared with one that didn’t.

You can see the below as a chart (hope that’s OK Prof, but the chart makes it easier to see the comparison). The command used in Serial monitor to get these numbers was simply ‘id’. The single numbers show that those numbers didn’t deviate very much between multiple id requests:

The only difference between configs was one had these defines added and one didn’t:

// #define BLADE_ID_SCAN_MILLIS 1000
// #define BLADE_ID_TIMES 10

One reason I’ve been struggling to differentiate the KR blade from no blade fitted is that there is an overlap of derived id numbers.

However if I leave out the line

#define NO_BLADE_ID_RANGE…

and then use only three modes (chassis alone, chassis in hilt with or without blade, and charge plug) then make the bladeid number in the blade array pretty low, but far enough from the charge plug number, then everything works as I want it. Blade detect tells the board whether the chassis is fitted or not, and the setup for hilt and hilt with blade is the same, but the charge plug is still recognized as different.

CONCLUSION

So for my money, and allowing for the fact that I appear to have grasped various sticks in this forest firmly by the wrong end, if any changes were to be made to this, I would say the following might be worth thinking about:

• Add a define so the user can select whether changes in bladeid status trigger the bladein wav to be played or the font wav to be played. Or maybe revert back to how I believe it used to be and just have it play bladeid by default, as I think my earlier request to play font wavs for bladeid might have been a bad call, due to the fact that the same functionality can be achieved with pre-font folders if people want it. Blade Detect would remain unchanged.

• If feasible, make the repeating bladeid scans switch off when the LED FETs power down after the Idle Timeout Delay has passed. Once the saber comes back to life and any accents start again, the scans restart. Though it occurs to me that this might not work on hilts with no accent LEDs. Hmmm…

As always I have no idea how easy, viable, desirable for other people or even possible these things are, but that’s my fourpennth on it.

Prof, I have a hunch I’ve raised more questions than I’ve managed to answer with all this, which wasn’t my intention, but if there is anything else you want me to do that might help with it, just let me know.

[NoSloppy]

id should be deprecated.
You should use scanid as it resets things and should give more consistent/accurate readings.

[profezzorn]

@Sabersense

#define NO_BLADE_ID_RANGE 990000000,1100000000

This doesn’t do anything, and I’m going to update ProffieOS to make this a compile error.
NO_BLADE_ID_RANGE has to use values below a billion.

@Sabersense

(hope that’s OK Prof, but the chart makes it easier to see the comparison).

The chart is technically within the rules, since it cannot easily be created with cut-n-paste.
However, it is possible to make tables, like:

	value without scanning	value with scanning
chassis	652k	674k-682k
hilt	564k-574k	639k-649k
charge plug	22.6k	22.6k
kr blade	537k-555k	656k-698k
lgt blade	32.7k	32.7k

(Use the … → raw post link below the post to see how this was actually typed in.)

Please consider using this next time.

IMHO, the problem here is the KR blade. It apparently does not have a blade resistor, and the pixels in it registers at very high resistance, which makes it basically indistinguishable from ahaving just the hilt connected. IMHO, if you want this to work, you 're going to have to either use SnapshotID, or add a blade ID resistor to this blade.

@Sabersense

fitting/removing the chassis does indeed always play bladein and bladeout wavs,

IMHO, this is not really correct since the blade isn’t actually connected. Also, ProffieOS doesn’t use the blade detect to decide whether bladein or bladeout should be detected, what it actually does is to look at the ID of the current config and checks if it is >= NO_BLADE or not.

Although, now that I’m thinking about it, I think maybe the logic should be something like this:

   int blade_state = id / NO_BLADE;
  int previous_blade_state = previous_id / NO_BLADE;
  if (balde_state == previous_blade_state) {
      // play font.wav
  if (blade_state < previous_blade_state) {
    // play bladein.wav
  } else {
     // play bladeout.wv
  }

This would mean that when you transition from NO_BLADE*2 to NO_BLADE, bladein.wav would be played. When you transition from NO_BLADE to an actual blade, bladein.wav would be played again (but maybe from a different font since the configs are likely different.)

Only if you transition between two values under a billion would it play font.wav.

It also means that you can set an id of NO_BLADE -1 if you want your no-blade ID to count as if it had a blade…

@NoSloppy

id should be deprecated.

I’m going to remove it.

[profezzorn]

@profezzorn

d I’m going to update ProffieOS to make this a compile error.

done

@profezzorn

@NoSloppy

id should be deprecated.

I’m going to remove it.

done

@profezzorn

I think maybe the logic should be something like this:

done

That means that if you get NO_BLADE*2 to work, it will no longer play the font sound.

[profezzorn]

PS: My recommendation is to put the KR blade aside for now and just try it with the LGT blade. Your IDs should be 22k, 32k, NO_BLADE and NO_BLADE*2.

[Sabersense]

OK, I think the fog is clearing! Finally I have it working the way you describe Prof. I’m so sorry I managed to make such a hash of this for so long, but I feel I’ve finally got there. Understood on the KR blade being close to the chassis in terms of readings too. I guess the proper way to do this is to have the chassis Shtok connector with no resistor, then have a resistor in the connector on the front section of the hilt to help distinguish between hilt open and hilt closed, then have another resistor on the blade etc. I’m guessing this would give well-spaced readings making everything work better.

@NoSloppy

You should use scanid as it resets things and should give more consistent/accurate readings.

Yes, it turns out using ‘id’ didn’t seem quite as consistent as ‘scanid’, so I think I’m now getting some more meaningful numbers which are translating to a more effective config. (I only used id because it didn’t show all the other stuff so was easier to compare several scans - I had no idea it was a little flaky). After some fine-tuning, I’ve settled on
#define NO_BLADE_ID_RANGE 500000,800000

And… ahem… I think the penny has finally dropped re. NO_BLADE*2 as well. I had it completely the wrong way round in my head, which meant my setup was also built the wrong way round. The new config is below and I think it’s now working correctly.

Detect and ID Take 4 - Pastebin.com

One minor detail - with this config, under the previous GitHub Master (ID: ce12a06a1e236b5101ec60c950530a9a4719a74d $), fitting chassis, blade or charge plug would always play blade in of the folder you were switching to, which all seemed logical (once the end user got it working properly… ahem!). Removing any blade or chassis always played bladeout from the folder you were switching to, which again made sense to me.

However under the latest Github Master downloaded this morning (ID: ce12a06a1e236b5101ec60c950530a9a4719a74d $), the blade in and blade out seem to have been reversed. The video below shows what I mean. So when you fit the chassis, it’s correct using blade detect, but when you fit a blade or charge plug, it plays bladeOUT from the upcoming folder, and when you remove a blade/plug, it plays bladeIN from the upcoming folder. But I’m guessing these are easily tweaked in the OS.

ID and Detect HD 1080p

So the only loose ends for me are:

a) The pipping on idle LEDs which seems to be caused by the constant scanid scans being performed. I’m guessing there’s no easy, or indeed any, fix for that other than using the BlackPower workaround;

b) The pros and cons of snapshotID compared to BridgedPullupBladeID. Everything I’ve read says that BridgedPullupBladeID is prefereable, but in talking about the KR blade being very close in resistance to no blade, you said:

@profezzorn

…if you want this to work, you 're going to have to either use SnapshotID, or add a blade ID resistor to this blade…

Does that mean SnapshotID is inherently more accurate and precise? And if so, what’s the advantage of using BridgedPullupBladeID other than the numbers generated being a little more inuitive?

Other than that, please accept my thanks once again for your patience on this one - sorry again that it was all a bit uphill.

[profezzorn]

@Sabersense

I guess the proper way to do this is to have the chassis Shtok connector with no resistor, then have a resistor in the connector on the front section of the hilt to help distinguish between hilt open and hilt closed,

You don’t need a resistor in the middle section since you’re using blade detect to detect when that section is connected or not. However, if you do have a resistor in that section, you can potentially distinguish all of these different configurations even without blade detect.

@Sabersense

However under the latest Github Master downloaded this morning (ID: ce12a06a1e236b5101ec60c950530a9a4719a74d $), the blade in and blade out seem to have been reversed. The video below shows what I mean. So when you fit the chassis, it’s correct using blade detect, but when you fit a blade or charge plug, it plays bladeOUT from the upcoming folder, and when you remove a blade/plug, it plays bladeIN from the upcoming folder. But I’m guessing these are easily tweaked in the OS.

I probably messed this up, will take a look later today.

@Sabersense

Does that mean SnapshotID is inherently more accurate and precise?

No, SnapshotID is generally less precise, but it also uses a completely different method of identifying the blade, one that measures both the capacitance and the resistance of the blade together. This different method may produce non-overlapping values for the KR blade, which would mean that you don’t need to add a blade ID resistor to it.

However, it may not. SnapshotID is difficult to predict, you just have to try it to see what values it produces. (But those values shold be fairly stable, so the same blade should get the same value ifyou try it again later.)

[NoSloppy]

Did this thread enact changes that are affected by the order of blades in the BladeConfig?

I now have bladein and bladeout playing opposite for some reason when NO_BLADE is first like:

I have this

BladeConfig blades[] = {
{ NO_BLADE,
 WS281XBladePtr<8, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
 CONFIGARRAY(Ronin),
"00_noblade_save"},

{ 6500,
 WS281XBladePtr<128, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >(),
 CONFIGARRAY(Ronin),
"01_Ronin_save"},

inserting blade:

01:40:21.358 -> BLADE ID: 6378.29
01:40:21.358 -> blade = 1
01:40:21.358 -> WS2811 Blade with 128 leds.
01:40:21.358 -> Style RAM = 296
01:40:21.358 -> Scanning sound font: aa_JayDalorian/OdaNobunaga
01:40:21.392 ->  done
01:40:21.392 -> Scanning sound font: ProffieOS_Voicepack_The_Ronin/common
01:40:21.501 ->  done
01:40:21.501 -> Scanning sound font: commonBU
01:40:21.681 ->  done
01:40:21.855 -> Activating polyphonic font.
01:40:21.929 -> Activating SmoothSwing V2
01:40:21.929 -> Accent Swings Enabled.
01:40:21.929 -> Polyphonic swings: 7
01:40:21.929 -> Monophonic swings: 0
01:40:21.929 -> Accent Slashes NOT Detected: 
01:40:21.965 -> unit = 0 vol = 0.50, Playing commonBU/bladeout.wav

removing blade:

01:40:26.360 -> BLADE ID: 1000015936.00
01:40:26.360 -> blade = 0
01:40:26.360 -> WS2811 Blade with 8 leds.
01:40:26.360 -> Style RAM = 296
01:40:26.360 -> Scanning sound font: aa_JayDalorian/OdaNobunaga
01:40:26.435 ->  done
01:40:26.435 -> Scanning sound font: ProffieOS_Voicepack_The_Ronin/common
01:40:26.505 ->  done
01:40:26.505 -> Scanning sound font: commonBU
01:40:26.690 ->  done
01:40:26.899 -> Activating polyphonic font.
01:40:26.933 -> Activating SmoothSwing V2
01:40:26.933 -> Accent Swings Enabled.
01:40:26.933 -> Polyphonic swings: 7
01:40:26.933 -> Monophonic swings: 0
01:40:26.933 -> Accent Slashes NOT Detected: 
01:40:26.969 -> unit = 0 vol = 0.50, Playing commonBU/bladein.wav

But it made not difference moving NO_BLADE last?

inserting blade:

01:36:18.550 -> BLADE ID: 6404.27
01:36:18.550 -> blade = 0
01:36:18.550 -> WS2811 Blade with 128 leds.
01:36:18.550 -> Style RAM = 296
01:36:18.550 -> Scanning sound font: aa_JayDalorian/OdaNobunaga
01:36:18.587 ->  done
01:36:18.587 -> Scanning sound font: ProffieOS_Voicepack_The_Ronin/common
01:36:18.691 ->  done
01:36:18.691 -> Scanning sound font: commonBU
01:36:18.871 ->  done
01:36:19.051 -> Activating polyphonic font.
01:36:19.126 -> Activating SmoothSwing V2
01:36:19.126 -> Accent Swings Enabled.
01:36:19.126 -> Polyphonic swings: 7
01:36:19.126 -> Monophonic swings: 0
01:36:19.126 -> Accent Slashes NOT Detected: 
01:36:19.126 -> unit = 0 vol = 0.50, Playing commonBU/bladeout.wav

removing blade

01:37:16.714 -> BLADE ID: 1000015936.00
01:37:16.714 -> blade = 1
01:37:16.714 -> WS2811 Blade with 8 leds.
01:37:16.714 -> Style RAM = 296
01:37:16.714 -> Scanning sound font: aa_JayDalorian/OdaNobunaga
01:37:16.789 ->  done
01:37:16.789 -> Scanning sound font: ProffieOS_Voicepack_The_Ronin/common
01:37:16.860 ->  done
01:37:16.860 -> Scanning sound font: commonBU
01:37:17.037 ->  done
01:37:17.248 -> Activating polyphonic font.
01:37:17.319 -> Activating SmoothSwing V2
01:37:17.319 -> Accent Swings Enabled.
01:37:17.319 -> Polyphonic swings: 7
01:37:17.319 -> Monophonic swings: 0
01:37:17.319 -> Accent Slashes NOT Detected: 
01:37:17.319 -> unit = 0 vol = 0.50, Playing commonBU/bladein.wav

I see blade 0 and blade 1 change, but still the opposite sound playing.

Please tell me I’m just missing something dumb.
It’s been a while since I played with blade detect/ID.

[profezzorn]

@NoSloppy

Did this thread enact changes that are affected by the order of blades in the BladeConfig?

no

@NoSloppy

But it made not difference moving NO_BLADE last?

Because the order doesn’t matter.

The selection of bladein/bladout happens in hybrid_font.h based on the boolean “detected” argument to SB_BladeDetect().
If you’re using Blade Detect, then the argument to SB_BladeDetect() comes from your prop. The checked in version looks right to me though.

If you’re using blade ID polling, then the argument to SB_BladeDetect() is determined by the PollScanId function in prop_base.h, and the checked in version looks like it should work to me. (Last changed ~6 months ago.)

[NoSloppy]

Thanks for checking. I did bypass my prop and just try with the default saber.h with the same result. I’ll have to look into it tomorrow maybe.

[NoSloppy]

@profezzorn

If you’re using blade ID polling, then the argument to SB_BladeDetect() is determined by the PollScanId function in prop_base.h, and the checked in version looks like it should work to me. (Last changed ~6 months ago.)

Well I added some debug printouts to see what the values being compared are.
Are we sure the greater / less than aren’t reversed?

My blade is ~6500
NO_BLADE Is a billion.
If I had the blade in, then remove it, it’s answering true because a billion is greater.

Here’s PollScanID:

  void PollScanId() {
    if (find_blade_again_pending_) {
      find_blade_again_pending_ = false;
      int noblade_level_before = current_config->ohm / NO_BLADE;
      FindBladeAgain();
      int noblade_level_after = current_config->ohm / NO_BLADE;

      if (noblade_level_before < noblade_level_after) {
PVLOG_DEBUG << "* before < after apparently,  bladeDetect TRUE\n";
PVLOG_DEBUG << "* before = " << noblade_level_before << "\n";
PVLOG_DEBUG << "* after = " << noblade_level_after << "\n";
PVLOG_DEBUG << "* current_config->ohm = " << current_config->ohm << "\n";
PVLOG_DEBUG << "* NO_BLADE = " << NO_BLADE << "\n";
        SaberBase::DoBladeDetect(true);
      } else if(noblade_level_before > noblade_level_after) {
PVLOG_DEBUG << "* before > after apparently,  bladeDetect FALSE\n";
PVLOG_DEBUG << "* before = " << noblade_level_before << "\n";
PVLOG_DEBUG << "* after = " << noblade_level_after << "\n";
PVLOG_DEBUG << "* current_config->ohm = " << current_config->ohm << "\n";
PVLOG_DEBUG << "* NO_BLADE = " << NO_BLADE << "\n";
        SaberBase::DoBladeDetect(false);
      } else {
        SaberBase::DoNewFont();

This is inserting blade, then removing it:

03:07:56.337 -> BLADE ID: 6381.53
03:07:56.337 -> blade = 1
03:07:56.695 -> * before > after apparently,  bladeDetect FALSE
03:07:56.695 -> * before = 1
03:07:56.695 -> * after = 0
03:07:56.695 -> * current_config->ohm = 6500
03:07:56.695 -> * NO_BLADE = 1000000000
03:07:56.695 -> unit = 0 vol = 0.50, Playing commonBU/bladeout.wav

03:08:22.404 -> BLADE ID: 1000016064.00
03:08:22.404 -> blade = 0
03:08:22.748 -> * before < after apparently,  bladeDetect TRUE
03:08:22.748 -> * before = 0
03:08:22.748 -> * after = 1
03:08:22.748 -> * current_config->ohm = 1000000000
03:08:22.748 -> * NO_BLADE = 1000000000
03:08:22.782 -> unit = 0 vol = 0.50, Playing commonBU/bladein.wav

[profezzorn]

Duh, you are correct.
Fix pushed to github.