ProffieOS v6.x ALPHA testing

ok. I’m going to try on a 1.5 board just for fun. What prop file are you getting this with?
(side note, the “wav player still referenced!” warning is interesting. )

I just plugged it into USB, it booted. Now it’ll sit here until morning.
So you’re saying I should do next preset, ignite, see if motion stuff works or not, then turn off and see if hum persists?

I’m using @Fett263 's prop from here:

So to trigger the issue, all I do is flash the saber, leave it powered but idle and just wait. Usually after an hour or so, the motion issue occurs.

1 Like

It’s the prop file.

I reflashed using the sa22c prop and after 8 hours the motion issue has not reoccurred.

Something in @Fett263 ’s prop is causing this motion issue.

Hmm, wondering if it’s the MOTION_TIMEOUT?

I may need to reset the saber_off_time_millis_ on a button press. @profezzorn thoughts

Submitted PR to reset the saber_off_time_millis_ when we do button press, once merged we can test.

1 Like

I was actually thinking along the same lines. If I remove the define and then test playing around.

It defaults to 15 minutes without the define actually, otherwise we were draining the battery unnecessarily. So if it is the cause resetting the saber_off_time_millis_ when the button is pressed should correct.

It’s possible that MOTION_TIMEOUT is what triggers the problem, but there is definitely something else going on as well, because the motion code ends up in a place where the LSM6DS3 class has locked the i2c bus, but isn’t actually using it. So when it tries to lock it again, it ends up in the “Oh, I just have to wait for the current request to finish first” path forever.

2 Likes

Is your saber connected to USB the entire time? I ran a test yesterday and overnight and couldn’t replicate. I’m wondering if the USB or computer may be the cause?
Just to rule out other variables is your board v1.5 or v2.2?
I tested on v1.5 board, left saber powered all day and checked at 1, 3 and 5 hours, then checked this morning from overnight and besides the gestures needing the reset for saber_off_time_millis (or for the saber to be ignited) I had no issues with any other functions.

No, not connected to USB, just sitting idle on the desk. I haven’t tried reflashing since your motion timeout update.

Odd, no this was without the update. The MOTION_TIMEOUT addition hasn’t been merged yet. So it’s version with Fredrik’s last addition 2 days ago.

I’ve made an improvement to the i2cstate command which will help narrow down the problem. In addition I’m doing some tests where I’m triggering motion timeouts over and over and over to see if I can trigger the problem.

2 Likes

I did some testing on a v1.5 board and it does NOT seem to be exhibiting any motion symptoms, even after leaving it sit for more than an hour.

I’m flashing four sabers with the latest update and I’ll let them sit for a couple hours and then test to see which exhibit the symptoms and which don’t.

  1. My usual test saber: 1 button v2 board, no recharge/kill, 1 blade
  2. Pach Store Fallen Fylte: 1 button v2 board, recharge port, 2 blades
  3. Crossguard v2: 2 button v1.5 board, recharge port + kill switch, 2 blades
  4. Entropy: 1 button v2 board, recharge port, 3 blades

entropy.h (6.9 KB)
fallen.h (94.5 KB)
kylo.h (29.5 KB)
mhs_1btn.h (127.6 KB)

Hello all!

I made a few tweaks to the one-button controls in fett263’s prop file. Everything seems to be working correctly on my saber. I changed the controls to enter the Preset Menu and to enter Edit Mode. My suggested controls would be:

Blade Off Hold PWR (parallel or up): Enter Preset Menu
Blade Off Hold PWR (pointing down): Enter Edit Mode

This also frees up Triple Click PWR so that Rehearsal/Choreography Mode can be added to one-button sabers! My suggested controls for that would be:

Blade Off Triple Click PWR (pointing down): Enter Rehearsal Mode
Select New: Turn Right and Click PWR
Cancel Overwrite: Click PWR
Cancel Rehearsal Mode: Double Click and Hold PWR
Save Rehearsal: Double-Click PWR
Blade Off Triple Click PWR (parallel or up): Enter Choreography Mode
Exit Chreography Mode: Double-Click PWR

As I mentioned, I’ve been testing this on my saber and everything seems to be working correctly. How should I go about sharing my edited prop file?

If I’m being honest it seems premature to be sharing modded versions of a prop that’s not finalized during Alpha testing. I still have outstanding changes and additions and we’re trying to get through Alpha and Beta testing. What you do with your personal saber is up to you but I think introducing modded versions into testing is only going to confuse or delay what we’re trying to do, plus there’s still fixes in play so your version will become outdated once they’re merged.
Also, if you have suggestions on controls based on testing and usage why not just put them in as feedback?

That’s fair. Sorry, I’m new to testing. My thought was to get it added to yours, but I didn’t want to suggest something that wasn’t doable or wouldn’t work well, so I wanted to test it out first.

With Alpha (and Beta) we’re trying to test everything in the OS, introducing more variables will complicate things, especially things not in the base OS.
As to my prop, there’s still features I have in the queue so the controls you’re trying to add may interfere with other pieces you’re not seeing yet. If after everything is finalized and released you want to change controls on things that’s all well and good but while things are still being developed, tested and in flux it’s just going to complicate things.
Once everything is done and tested if there’s reasonable alternatives I can take a look. Let’s get past Alpha and Beta first.

Understood. Thanks for clarifying. And thank you for everything you’re doing for OS6!

1 Like

I found another potential issue in the i2c/motion code that might be causing the gesture problem. The fix is fairly speculative, and since I don’t know exactly what’s causing the problem, it may or may not help. sa22c, please update and try again.

Here is the latest output on the ‘pre fix’ code. I’m reflashing now to see if anything changes.

Only the saber using both fett’s prop file AND the mhs_1btn.h config has the issue. I’m going to flash my other one button saber with the same config to see if it also has the same problem.

Battery voltage: 3.86
Battery voltage: 3.85
Cycle counting enabled, top will work next time.
Playing kestis/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
Ignition.
unit = 1 vol = 0.50, Playing kestis/out/out01.wav
channels: 1 rate: 44100 bits: 16
humstart: 1800
unit = 2 vol = 0.00, Playing kestis/swingl/swingl03.wav
channels: 1 rate: 44100 bits: 16
unit = 3 vol = 0.00, Playing kestis/swingh/swingh03.wav
channels: 1 rate: 44100 bits: 16
Audio DMA: 2.19%
Wav reading: 6.42%
Pixel DMA: 0.33%
LOOP: 1.06%
Motion: 0.00%
Global loops / second: 1831.93
High frequency loops / second: 2456.04
blade fps: 79.84
Acceleration measurements per second: 1650.94
Hybrid Font loop: 0.17%
WS2811_Blade loop: 7.66%
ClockControl loop: 0.69%
Booster loop: 0.46%
SDCard loop: 0.35%
Amplifier loop: 0.30%
LSM6DS3H loop: 0.35%
I2CBus loop: 0.19%
Parser loop: 75.34%
pow loop: 0.52%
SaberFett263Buttons loop: 2.44%
BatteryMonitor loop: 0.82%
Fusor loop: 0.31%
DAC loop: 0.07%
AudioDynamicMixer loop: 0.17%
MonitorHelper loop: 0.17%
Playing kestis/swingh/swingh03.wav
channels: 1 rate: 44100 bits: 16
I2CBUS: last_request = 4796413 (now = 4796413) i2c_detected_ = 1 used = 1
I2C STATE: 8
current: 536879528 id= 106 next= 0
LSM6DS3H: last_event_ 86252 LINE: 194
last: 536879528 id= 106 next= 0
LSM6DS3H: last_event_ 86252 LINE: 194
Motion requested: 1 (millis() - last_motion_request=10704)
Whut? :fusordump
Battery voltage: 3.85
 Accel={0.85, -0.17, 0.41} (0.95) Gyro={-8.60, -2.21, 35.26} (36.36) down={0.28, -0.47, 0.70} (0.89) mss={5.53, 2.96, -2.89} (6.91)
 ready=0 swing speed=35.33 gyro slope=38.04 last_micros_ = 87252639 now = 507941329
 acceleration extrapolator data:
 START=86111407 samples=20 S(t^2)=ovf sum={2.73, -9.20, 17.81} S(.)={370028.59, -1247589.12, 2414705.25}
 start_copy=86111407 avg={0.14, -0.46, 0.89} slope={0.00, 0.00, -0.00} avg_t=135576.41
 86241827  {0.13, -0.47, 0.90}
 86242434  {0.13, -0.46, 0.89}
 86243040  {0.14, -0.47, 0.89}
 86243647  {0.14, -0.46, 0.89}
 86244254  {0.14, -0.46, 0.89}
 86244860  {0.13, -0.47, 0.89}
 86245467  {0.13, -0.46, 0.89}
 86246073  {0.13, -0.46, 0.89}
 86246680  {0.13, -0.46, 0.88}
 86247289  {0.14, -0.46, 0.89}
 86247893  {0.14, -0.45, 0.89}
 86248500  {0.14, -0.46, 0.89}
 86249106  {0.14, -0.46, 0.89}
 86249713  {0.13, -0.46, 0.89}
 86250320  {0.14, -0.46, 0.89}
 86250926  {0.14, -0.46, 0.89}
 86251533  {0.14, -0.46, 0.89}
 86252139  {0.14, -0.47, 0.90}
 86252746  {0.14, -0.46, 0.89}
 86241221  {0.13, -0.46, 0.89}
 ready=1
 gyro extrapolator data:
 START=86111419 samples=20 S(t^2)=ovf sum={-7.69, -87.16, -40.77} S(.)={-1044644.13, -11816117.00, -5518597.50}
 start_copy=86111419 avg={-0.38, -4.36, -2.04} slope={-0.00, 0.00, 0.00} avg_t=135576.91
 86241840  {-0.31, -4.27, -1.77}
 86242446  {-0.31, -4.15, -2.87}
 86243053  {-0.37, -4.64, -1.28}
 86243659  {-0.37, -4.46, -3.30}
 86244266  {-0.37, -4.21, -1.46}
 86244873  {-0.37, -4.46, -2.87}
 86245479  {-0.49, -4.33, -1.40}
 86246086  {-0.31, -4.58, -2.32}
 86246693  {-0.49, -4.09, -2.20}
 86247302  {-0.37, -4.39, -1.53}
 86247906  {-0.37, -4.15, -2.99}
 86248512  {-0.49, -4.58, -0.92}
 86249119  {-0.55, -4.15, -2.93}
 86249725  {-0.24, -4.64, -1.04}
 86250332  {-0.37, -4.39, -2.99}
 86250939  {-0.24, -4.64, -1.34}
 86251545  {-0.55, -3.85, -2.20}
 86252152  {-0.49, -4.64, -1.77}
 86252758  {-0.37, -4.15, -1.46}
 86241233  {-0.31, -4.39, -2.14}
 ready=1
Playing kestis/swingl/swingl03.wav
channels: 1 rate: 44100 bits: 16
unit = 1 vol = 0.50, Playing kestis/in/in01.wav
channels: 1 rate: 44100 bits: 16
No sounds found: pstoff
Battery voltage: 3.86