Using Blade Detect and BladeID at the same time?

I have a thin-neck build coming up with a removable core, and I want to use Blade Detect to tell the Proffie when the core is fitted in the hilt, then use BladeID to make the board differentiate between a normal blade and a charging blade plug.

I just wanted to double check that using both Blade Detect and BladeID at the same time is OK and won’t do any damage. I’ve used both in the past, but never at the same time in the same hilt.

This is the blade array I’m proposing. I’m also altering the nature of the blade array between different settings, so I can do animations in the Shtok blade connector on the core between the inner and outer rings of LEDs, though I’ve made sure to keep the total blade count the same. Note that Data 4 isn’t actually wired to anything - I just needed a dummy to get the blade count up.

Is there anything I’ve missed or any wrong trees that I’m barking up?

Thanks in advance.
:slight_smile:

BladeConfig blades[] = {
//  Chassis Fitted in Hilt:
{ 0,
//  Main Blade:
 	WS281XBladePtr<142, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Dummy Blade:
 	WS281XBladePtr<1, blade4Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Crystal Chamber:
    SubBlade (0, 0, WS281XBladePtr<2, blade2Pin, Color8::RGB, PowerPINS<bladePowerPin2, bladePowerPin3>>()),
//  Plasma Emitter:
    SubBlade(1, 1, NULL), 
//  Accent Red:
    SubBlade (0, 0, WS281XBladePtr<2, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5>>()),
//  Accent Green:
    SubBlade(1, 1, NULL), 
   CONFIGARRAY(blade) },

//  Chassis Loose:
{ NO_BLADE,
//  Shtok Connector 1:
    SubBladeWithStride (0, 14, 2, WS281XBladePtr<16, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3> >() ),
//  Shtok Connector 2:
    SubBladeWithStride (1, 15, 2, NULL),
//  Crystal Chamber:
    SubBlade (0, 0, WS281XBladePtr<2, blade2Pin, Color8::RGB, PowerPINS<bladePowerPin2, bladePowerPin3>>()),
//  Plasma Emitter:
    SubBlade(1, 1, NULL), 
//  Accent Red:
    SubBlade (0, 0, WS281XBladePtr<2, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5>>()),
//  Accent Green:
    SubBlade(1, 1, NULL), 
   CONFIGARRAY(no_blade) },
   
//  Charge Plug:
{ 53,
//  Main Blade:
 	WS281XBladePtr<142, bladePin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Dummy Blade:
 	WS281XBladePtr<1, blade4Pin, Color8::GRB, PowerPINS<bladePowerPin2, bladePowerPin3>>(),
//  Crystal Chamber:
    SubBlade (0, 0, WS281XBladePtr<2, blade2Pin, Color8::RGB, PowerPINS<bladePowerPin2, bladePowerPin3>>()),
//  Plasma Emitter:
    SubBlade(1, 1, NULL), 
//  Accent Red:
    SubBlade (0, 0, WS281XBladePtr<2, blade3Pin, Color8::GRB, PowerPINS<bladePowerPin5>>()),
//  Accent Green:
    SubBlade(1, 1, NULL), 
   CONFIGARRAY(charger) },
  
};
#endif

I’m not sure if anybody has tried a setup like this yet, however it is safe, it’s possible, but it may require some changes to the code.

There is a bunch of defines you need to use to make blade ID run all the time, and return NO_BLADE when no blade is found. The problem is of course that blade detect is also setup to use NO_BLADE when no blade is found.

IF I did things correctly, what will actually happen is that when there is no blade AND no chassis, it will return NO_BLADE + NO_BLADE, so you could use NO_BLADE*2 in your blades array for this case.

If that doesn’t work, let me know, post your config and we’ll make sure to fix it.

Two comments on the configuration fragment you posted:

This is not a blade ID and there is nothing in the blade ID code that will return zeroes. Not sure what you think this will do, but it’s probably not going to work the way you want.

The low value makes me think you’re using SnapshotBladeId (the default for v2 boards). If that work well for you, that’s fine, but adding a resistor and using PullupBladeID is sometimes more reliable.

Ah, OK, so I seem to have gone off piste somewhat with this one (Again? LOL!). Apologies Prof – I don’t want to cause you a load of work - I’d be happy to work with however it is at the moment and just adapt my plans.

But just for interest, I’ll report back with the results once I’ve done the install (probably later this week).

And yes, noted on the comments about values and PullupBladeID. :+1:

Thanks as always.
:slight_smile:

No, you would actually be saving me work, otherwise I have to try these things myself eventually.

It’s my intention that this should work, but since it’s never been tested, I don’t know if it does. Fixing the problems is actually a lot less work than the testing part, so I like it when people go “off piste”, as long as they don’t aim straight for the trees…

1 Like

This does indeed work. If you Look at the Kota Saber I did on youtube (Peacekeeper’s Amory) I made it such that the crystal is removable. The board detects if the crystal is there or not (Blade Detect), and then it determined what crystal it was. I had a clear and a blue crystal. Clear was ID’d to light up green with a pixel, and the blue crystal automatically changed it to blue.

1 Like

Thanks PA. I just had a look and yes, that is the kind of functionality I’m aiming for.
Beautiful install too! I can only imagine how long it must have taken to fettle the 3d printed metal parts to get the interlock working nicely. Great job. :ok_hand: :clap:

Oh you have NO idea haha. And even so it has to be messed with again as I am having a few CNCd in the near future.

Let me know if you run into any snags with the config and I can share mine and see if I have my wiring diagram.

1 Like

Many thanks. Much appreciated.
Will let you know how I get on. :slight_smile:

OK, I’ve been running some tests, and with a nudge from PeaceKeepersArmoury to confirm I’m on the right track (thanks PKA), I think I’ve got it working apart from one small bug, though I think that bug can be coded around with a blade style if needs be. More on that shortly.

The OS used is the Github Master.

But I’ll run through the MO…

The config was built with three blade arrays which were, in config order:

  • Complete Hilt
  • Chassis Only
  • Complete Hilt with Charge Plug

The config I used is below, and the hilt was wired, and config set with the
#define BLADE_ID_CLASS BridgedPullupBladeID<bladeIdentifyPin, 9>
and Data 1 bridged to TX.

The blade connector in the chassis does NOT have a resistor between Data and Negative, but DOES have the Blade Detect pin wired to Aux2,Button3 which has been added to the config. The Blade connector in the main blade emitter also does NOT have a data/neg resistor. The only resistor used in the whole shebang is the charge plug which has a 22k resistor between data and neg.

With the board connected to a computer but powered by the battery, I got the following scanid numbers:

  • Complete Hilt 666750.56
  • Chassis Only 1000671744.00
  • Complete Hilt with Charge Plug 22642.32

For ease of determining which array I was on, I set the accent LEDs as follows:

  • Complete Hilt Blinking White (though looks blue reflecting on the tape on the video)
  • Chassis Only Blinking Red/Green
  • Complete Hilt with Charge Plug Single green pip every five seconds

The video below shows it all as it stands.

You can see that essentially it all works. The only bug is the fact that the crystal and plasma gate seem to pip, presumably in time with the constant Blade ID monitoring. Since I’m using the BlackPower add on for the charge plug, I’m guessing it might be possible to code it so those FETs stay powered but don’t display anything, which I have a hunch might fix it. But I haven’t got as far as making that work yet, and it does feel like a workaround rather than a fix.

I thought it might be caused by having the crystal blade style use InOutHelper, but removing that style didn’t make any difference.

Anyway here’s the video:

And here’s the config:

Hope they’re useful.

1 Like

Oh, I forgot to add, Prof, I tried the NO_BLADE*2 thing in the blade array but couldn’t make it work. Although it seems it’s not necessary. :slight_smile:

Nice!
In my experience, the chassis connection worked as a blade ID value, so I didn’t need to ALSO do a blade detect wire.
The announce is nice. Did you do custom bladein/bladeout.wavs and then prepend a “common” folder for them onto the presets’ font search paths?

Shouldn’t there be four cases? (chassis, hilt, blade and charge plug ?)

I think it’s because this define is used wrong:

#define NO_BLADE_ID_RANGE 999000000,1100000000

NO_BLADE_ID_RANGE is supposed to be the range returned by your blade ID class when there is no blade inserted, but before NO_BLADE is added to it.

From your measurements above, I guess it should be something like:

#define NO_BLADE_ID_RANGE 600000,800000

The crystal chamber / plasma gate thing is kind of weird. I wonder if they just power up with a color? If you just give them power, no data, do they come on?

I thought about trying that, but it just felt like having in effect a “Chassis in/out” hard wired, then a “Which blade is fitted, if any” as blade ID would be more robust. But that’s probably all in my head. LOL!

I did indeed. Just one folder that only contains bladein and bladeout wavs referenced before the font folders for when the front end is fitted worked a treat. Thanks for the tip on that one. :pray: :+1:

I guess in theory yes, but I want it to work with normal blades with no additional resistors. Plus I was happy for the assembled hilt and the assembled hilt with normal blade to work the same - it was only with the chassis exposed or the charge plug fitted that I wanted things to be different. Although now you mention it, I didn’t actually try it with a normal blade to get scanid values. I should probably do that to make sure they’re in the same band as hilt fitted but no blade.

That’s pretty much what I tried initially, but I found that when I lit the blade, even with no blade fitted, the Proffie seemed to get confused and started bouncing in and out of different blade states. If it helps, I can try and replicate that issue and send a video of what happens, because I agree - 600000 to 800000 feels like it should work for the values given.

Yeh that’s what I thought. The fact that they work fine when the crystal/plasma gate are told to light up or do something suggests that leaving the FETs powered but with no data instruction to light up would indeed solve it - I just ran out of time last night to try it. Am I right in saying that as I’m using the BlackPower setting in CONFIG_STYLES that I can simply specify BlackPower as a blade-off colour in a bladestyle and that that will leave the FETs powered up?

You can’t just lump states together, unless those happen to have similar ID values though.

A blade with no resistor will almost certainly generate an ID value differently from having no blade connected at all. (Although that difference might be pretty small if you have pogo pin LEDs hooked up in parallel)

Rather than avoiding doing it right, we should fix it.
What values do you get from scanid when you have it set up this way?
(test all four states!)

BlackPower should leave everything powered, but that goes for everything that lives on the same FETs. With a blade inserted you would drain the battery in hours in standby mode.

However, if you have different states for blade in and blade out, then you could make sure that BlackPower is not used when the blade is in. After all, you can’t see the crystal chamber when the blade is connected, right?

With you on points Prof.
Will go through it all when I get home from work today and report back.
:slight_smile:

If the crystal chamber pips are being caused by the Proffie constantly scanning the blade id, doesn’t that mean that with the hilt assembled, the pips will keep going, albeit unseen, which will also drain the battery? I’m assuming the the frequent scanid process keeps going after the LED time out delay kicks in?

True, but the scan process only turns on the power for ~10ms at a time.
So it still uses 100x less power than turning on the power all the time.

1 Like

Update:

Done a few more tests and I think I’ve nailed it…

Firstly, defining BlackPower as the blade off state for the crystal chamber and plasma gate does indeed stop the crystal blipping in time with the continual id scans. I realised I also forgot to add a resistor to that data line (data 2) but I added a 470 ohm resistor today and it’s made no difference to the blipping. But as you suggest Fredrik, it’s only matters when we can see the chassis, so it’s easily coded around. The only other note is that on presets where it happens, the blipping doesn’t stop with the LED timeout, but as I say, no biggie.

Secondly I’ve now added 4 blade states - full config below - along with a more accurate NO_BLADE_ID_RANGE define line. Although I did find that omitting that line didn’t seem to make any difference to how it all worked.

FUNCTIONALITY
So adding the front section of the hilt relies on Blade Detect, while adding a blade in the emitter, whether it be a normal blade or a charge plug, relies on BladeID.

BEHAVIOUR

  • Add hilt front end Plays BladeIn wav of font it switches to

  • Remove hilt front end Plays BladeOut wav of font it switches TO (not the font it’s just left)

  • Add normal blade Plays Font wav of font it switches to

  • Remove Normal Blade Plays Font wav of font it switches TO (not the font it’s just left)

I reckon this all very logical and makes sense for the standard operation of the OS - at least for the installs I tend to do.

BUT…

Forgive my being a Michael Scott for a moment - especialy as I asked on another thread for blade insertion to play the Font wav - but Prof or Brian, could you point me towards the file I need to edit to make it play the Blade In wav on blade insertion, as that would work better for this particular install.

Michael

Or taking that idea further, is it worth having a define for it perhaps? Something like

#define BLADE_ID_PLAYS_FONT
or
#define BLADE_ID_PLAYS_BLADE_IN

OK, I’m just throwing it out there, so feel free to ignore. As it stands right now, the standard setup we’ve got working is excellent.

Scott

Sincere thanks again guys - I am perpetually in your debt.
:pray: :pray: :pray: :slight_smile:

The files available to play are subject to what font has been scanned. It can’t hold onto the file that was, nor guess what the file will be as you switch states.
You could simply flip the sound and the name, where a bladeout sound gets named bladein.wav just to suit your switching better?

Yeh I completely get the logic of it playing the files from where it’s going, not where it’s been. It’s more that it plays the font ident of the new font, rather than the bladein effect. If it played bladein, you could, as you suggested before, have a pre-font-folder common folder with a custom blade ident for that preset array. If you had the blade styles the same on each preset array apart from that pre-font folder, it shouldn’t use much more memory, but you could have a blade-in wav in the pre-folder stating which blade had just been fitted.

But like I say, I’m being ludicrously picky now. But the bottom line is, the system works great! :pray: :+1: :muscle: