The Power Issue That Isn't Power

ProffieOS
1

Working on a Kylo Ren in which I’ve used BladeID to distinguish between no blade/normal blade and a charging plug. But since I wanted it to play a sound effect to confirm which blade it had detected, I skipped ProffieOS 7.14 and used a previous GitHub version in which this feature had been added.

Unfortunately I think I found a gremlin, which I initially attributed to a power issue, but it seems it’s more related to BladeID. Replacing battery and replacing blade made no difference, but removing the blade fixed it, as did removing the BladeID part of the config.

So below is the observed behaviour of different OSs I’ve tried with this config:

7.14
All works correctly, but no wav file is played to confirm which blade has been fitted. This is correct behaviour for this OS.

Previous Github version:
Downloaded early January 2024:
Blade ID works and plays a wav file upon blade/plug insertion, but full blade white strobing lockup effects seem to trip the hilt - the blade suddenly goes out then immediately relights accompanied by the font ident wav playing. If I remove the blade it doesn’t trip. If I remove all the BladeID stuff from the config, it doesn’t trip. Tried using both pullupresister and snapshot ID with appropriate settings, but it didn’t make any difference.

Current GitHub version:
Downloaded today:
Blade ID works, wav file plays, and hilt doesn’t seem to trip, but the strobe lockup effect doesn’t display properly - it just lights up static.

No biggie for this install as I can use 7.14 and live with no wav idents, but thought I should flag it lest a gremlin finds it’s way into ProffieOS 8.
:slight_smile:

Config is here:

And serial monitor output during the trips is here:

Hope they’re useful.
:slight_smile:

2

Forgot to mention, the latest Github version threw an error with this line from the prop:

void SB_Effect(EffectType effect, float location) override {

Simply deleting the word “override” made it work, but I don’t know if that then had anything to do with the strobe lockup display issue mentioned above.

Again, thought I should mention it.
:slight_smile:

3

SB_Effect() won’t work if you just remove override.
You need to change it to:

  void SB_Effect(EffectType effect, EffectLocation location) override {

Not sure if that fixes any of your problems or not though.

4

Thanks Prof.

The plot thickens:

If I add your corrected line, the trip problem is back or possibly even worse (more rapid).

I also tried Fett’s prop, but still got the trip problem.

So to double-check it, I’ve again tried just deleting the word “override” from my original prop line, and it confirmed the earlier result: i.e. the trip problem seemed fixed but the lockup didn’t animate properly.

All very odd. :confused:

5

If it helps, this is the error I get with the normal “override” line in:

Arduino: 1.8.19 (Mac OS X), Board: "Proffieboard V2, Serial + WebUSB, SDCARD (SPI), 80 MHz, Smallest Code"

/Users/chrisandlindsey/Desktop/GitHub/ProffieOS/props/saber_chris_2_button.h:935:6: error: 'void SabersenseButtonsSA22C::SB_Effect(EffectType, float)' marked 'override', but does not override
  935 | void SB_Effect(EffectType effect, float location) override {
      |      ^~~~~~~~~
exit status 1
Error compiling for board Proffieboard V2.
6

First of all, I’ve made some changes to SB_Effect on github, which is why the changes is required. My guess is that SB_Effect triggers another effect in some cases, and without that, the lockup effect doesn’t work right.

The other problem seems to be that the strobe effect is managing to confuse the blade ID somehow.

Try moving this line:

Two steps up. This will print out the blade ID once per second, which might help you figure out what is going on by looking at the serial monitor.

7

Thanks Prof. Will try that when I get home later today.
However the BladeID number did show on the first serial monitor extract I showed above, and it read thus:

8. 14:22:57.894 -> BLADE ID: 1000000000.00

It appeared straight after the lockup started, although bladeID is running every second as standard with this config. I just don’t know why the number would change so wildly, especially since I’ve tried both ways of measuring BladeID and they both behave the same.

But anyway I’ll try moving the line you mentioned and will report back. :slight_smile:

8

OK, I tried that line to get the regular BladeID info on Serial Monitor, and this is how it turned out:

It’s dropping out AND displaying the strobing lockup wrong. (I think I may have been wrong before about the latest GitHub not dropping out - I think I must have had BladeID removed when I tested that yesterday).

I tried the above using both my normal prop with the ‘override’ line modded, and Fett’s prop as standard, but both wrong display and dropping out were present with both setups.

Not sure if that helps or not.
:confused:

9

Is TX and Data1 bridged on your board?
Do you have a pullup resistor on Data1?
What ID value ranges do you get with the blade attached?
What ID value ranges do you get with the blade detached?
The output that I see in the serial monitor doesn’t seem to match the config file you posted, can you post the config file you’re using now?

10

Yes, but the latest config uses Snapshot ID - I tried both systems and they were both the same.

That’s what the bridge mentioned above does isn’t it?

I haven’t checked since I reloaded this config today, but when I checked yesterday under snapshotID, it was around 88 with no blade attached or a normal blade attached…

…and around 53 with the charge plug attached. Though I can see that’s not what the serial monitor is showing in the extract above. I’ll need to check again tomorrow as my daughter is asleep in the next room so I can’t make any noise.

11

That’s weird, they really should produce very different numbers.

If you get similar values with or without a blade, then you cannot use NO_BLADE_ID_RANGE , as there would be no way to tell them apart. When the value is inside NO_BLADE_ID_RANGE, ProffieOS adds a billion to it, which is why you get huge numbers a lot of the time.

12

Sorry, when I say they were the same, I meant the dropping out and the lockup error were the same. The BladeID numbers were indeed very different and I set the respective configs accordingly. One thing I did notice was that with pullup resistor, the charge plug returned a BladeID number of around 10,000, but I was expecting something in the order 22,000 as that’s the resistor value I’ve wired in to it between data and ground.

This is actually what I want - I want the hilt to be the same with or without a normal blade and only switch when I fit the charge plug which I’ve wired with the 22k ID resistor.

In that case, the normal bladeID numbers in the most recent serial monitor extract are probably about right at 1000000064.00. However I notice there’s another bladeID reading of 118.90 just before that on line number 37, right before the blade turns off on line 43. A clue perhaps?

13

OK, let me start over somewhat:

Here’s the current config:

This config uses the latest GitHub OS, downloaded yesterday.
Override line in my prop ia modified as per above thread. However the prop doesn’t seem to make a difference as I get the same behaviour with fett’s prop, so the prop can probably be eliminated from the enquiry.

Config is set up with snapshotID. BladeID numbers are:

  • No blade - 1000000064.00
  • Normal Blade - 1000000064.00
  • Charge Blade with 22k resistor - 58.40

So that makes the current config pretty much correct in terms of BladeID settings - and indeed that side of it works as intended in terms of distinguishing between no blade/normal blade and the charge plug.

But this is the behaviour:

And this is the serial monitor that accompanies it:

14

Next up I tried the exact same config in the exact same OS, but with all the BladeID gubbins removed.

The result was that there was no dropping out and everything worked except the strobe lockup effect which displayed as pretty much static.

I have a hunch this all might be a long term fix which gets ironed out naturally as the GitHub master evolves, but as mentioned above, I thought I should flag it all.

Hope it’s useful.
:slight_smile:

15

Please try it again with the bridged blade ID, and remove NO_BLADE_ID_RANGE, as it is messing with the accuracy.

16

OK, here’s the updated config using PullupresistorID without NO_BLADE_ID_RANGE, and with the ID numbers fed back in to the blade array. The blade array has the NO_BLADE option removed and instead just has the BladeID values. I’ve tried so many options I can’t remember if I did it this way before, but given that the latest behaviour matches the third option on my original post, I think I must have.

Those new BladeID numbers are:

  • No Blade - 16683.48
  • Normal Blade - 16690.97
  • Charge Blade with 22k resistor - 9992.61

And here’s the new Serial Monitor output with the above config:

Behaviour is that it doesn’t seem to be cutting out, and everything works except the strobe lockup effect which is still animating wrongly.

So it seems NO_BLADE being determined by BladeID rather than Blade Detect might still need tweaking. But the only issue now on the install I’m working on is the incorrect strobe lockup display.

Hope something in there is useful.
:slight_smile:

17

I think this is the wrong conclusion.

  1. Your setup doesn’t require a NO_BLADE, because all you care about is “charge blade” vs. “not charge blade”, using NO_BLADE for that doesn’t really make sense.
  2. Your main blade doesn’t have a resistor, which means that detecting it with blade ID is not guaranteed to work.
  3. Previously you were using the snapshotid, which has somewhat weird behavior and can sometimes return the same value even for blades with different resistors. In general, the bridged version should be more stable.

So now that the saber isn’t switching presets all the time, we can figure out the strobe problem.
Looking at the style, I’m not sure what you’re trying to do though. Strobing at 50Hz is fast enough that it’s going to be hard to see what it’s really doing, and the speed of the style code will also affect how it looks.

18

I think the strobe is set lower than 50Hz on the affected blade styles (which are the ones with full blade lockups - the first few being preset numbers 2, 4, 5 and 6). The config has strobe frequency in the 20s and pulse length in milliseconds between 15 and 30. These were kind of arrived at by trial and error and they look something like this:

I’ll try to get a better comparison video tomorrow between how the strobe normally looks versus how it looks on this particular install - suffice to say it does look very different. It might be possible to code round it by maybe slowing the strobe down perhaps(?), which I guess is fine if we conclude that the new OS just handles these things a bit differently, rather than there actually being an issue somewhere.

As for NO_BLADE not being necessary, yeh, I agree. I think it crept in because under OS 7.14 and earlier, the hilt will only play a sound file upon insertion when NO_BLADE is in one of the arrays. Of course this changes under the new Master OS, but in trying different OSs and options, I think it crept back in at one stage as part of my experimenting.

19

OK, here’s a video comparison of the lockup strobe effect. I’ve locked the exposure settings on the camera so we don’t get misleading photographic artefacts.

I’ve shown two blade styles - an unstable red blade and a stable blue one. The same blade styles are used for both OSs, and the only difference between the two videos is the OS used.

And here are the blade styles:

Hope they’re useful.

:slight_smile:

20

I think I found the problem, fix is on github, please try it.

1 Like