So I went back to futzing with my Luke Hero saber to update it.
I have #define CONFIG_STARTUP_DELAY set to 15000 in my config so it gives me time to insert the speaker pod and install the pommel before boot.wav plays.
The saber was igniting because of SWING_ON gesture set.
I thought “Oh sure, the delay in the prop for SWING_ON gesture is set to 3000, that must be it.”
So I added this to account for the startup delay:
// Due to motion chip startup on boot creating false ignition
// we delay Swing On at boot for 3000ms
if (millis() > (CONFIG_STARTUP_DELAY + 3000)) {
FastOn();
Didn’t seem to work.
I then added some print statements to check the current millis (which it turns out is already right there in the EVENT line) 
// Due to motion chip startup on boot creating false ignition
// we delay Swing On at boot for 3000ms
current_millis_ = millis();
STDOUT.println("CONFIG_STARTUP_DELAY set to: ");
STDOUT.println(CONFIG_STARTUP_DELAY);
STDOUT.println("Current millis = ");
STDOUT.println(current_millis_);
if (millis() > (CONFIG_STARTUP_DELAY + 3000)) {
FastOn();
Pretty straight forward. Unless the current elapsed time is greater than 18000, it shouldn’t turn on…but it does. And this is the serial monitor output for when it happened:
17:03:20.745 -> Welcome to ProffieOS, Brian. Type 'help' for more info.:)
17:03:21.762 -> I2C init..
17:03:21.762 -> Motion setup ... done.
17:03:21.762 -> EVENT: Swing millis=16818
17:03:21.762 -> CONFIG_STARTUP_DELAY set to:
17:03:21.762 -> 15000
17:03:21.762 -> Current millis =
17:03:21.762 -> 16818
17:03:21.762 -> Ignition.
17:03:21.762 -> unit = 1 vol = 0.00, Playing a_LUKE/LS6/hum01.wav
I am going to check without the delay but WITH the print lines and see what happens, but …did I miss something simple? Seems like it’s not adhering to the condition.
Are you sure the ignition isn’t coming from somewhere else?
I would suggest adding another println inside the if statement to make sure that is what is actually happening.
Well these print statements are within the swing on case. So when there’s no false ignition on boot I don’t get them, Plus, when it’s running and I do a swing I get them. Plus, it says EVENT swing with the milliseconds. So I’m pretty sure 99%, that’s where it’s coming from. It doesn’t occur every time, but it does occur often. Also, the EVENT swing is always at 16xxx millis. I have three or four times logged at home I can check when I get there, but I think they’re within 100 milliseconds of each other.
99% sure isn’t enough when you’re trying to prove that something impossible is happening.
I think what is happening is different from what you think is happening, but without seeing all the code, it’s hard to be sure.
Thank you. You were correct of course. The if was not being met.
Looking closer, it seems the issue was that I inadvertently had deleted the
return true; from the end of the SWING_ON case.
As to why Ignition would happen without that I don’t know, but it doesn’t matter for now since adding it back where it belongs lets things to work as they should.
I also reverted to just a 3000ms delay to confirm that making it
(CONFIG_STARTUP_DELAY + 3000) instead does indeed help, and that is still true.
False ignitions without the change, so my PR stands.
Lastly, if the hunt is still on for WHY the motion setup…done is causing a swing event at boot, here’s the very consistent point in time at which they are occurring for me, maybe this helps narrow down what’s happening?
EVENT: Swing millis=16654
EVENT: Swing millis=16636
EVENT: Swing millis=16643
EVENT: Swing millis=16650
EVENT: Swing millis=16645
So what happens if you change CONFIG_STARTUP_DELAY?
Is it always occuring 16** milliseconds after the startup delay has passed?
Or is it always at 166** milliseconds after start?
^This^
No matter what startup delay is set to (including zero) the EVENT time is always ~1650ms…WHEN it happens.
Interestingly, it seems first power might have something to do with it.
I just reset 10 times via serial monitor and it didn’t happen once.
Conversely, if I unplug-replug USB to reset, it does it EVERY time.
To clarify, I unplugged-replugged the computer end of the USB cable. The saber is sitting idle on the bench untouched. So it’s not a difference where because I was moving the saber around fiddling with the USB insertion that the motion chip was busy handling gyro info.
This falls in line with the motion chip boot from initial testing on Swing Ignition in OS4. That’s why there’s a 3000 ms delay in my prop to prevent swing on after boot. Whatever process starts the motion chip it was occurring between 1500 and 2000 ms every time so for “safety” I’ve always had a 3000 ms check before triggering Swing Ignition. If the motion chip ever reboots (the timeout issue reported in OS5) we see the same Swing detection. I’ve always assumed the chip has a ramp up during initialization that is detected as a Swing by the OS.
166** millseconds is more than 16 seconds.
I know that the motion chip does something weird when you start it up, but I thought those problems occurred fairly quickly after resetting the chip, not 16 seconds later!
I think his 166** is from the addition of 15000 via his STARTUP_DELAY define
But you just said that STARTUP_DELAY didn’t matter?
Reading his previous post I believe it was 1600 ms without STARTUP or 16600 with STARTUP = 15000 unless I’m misreading.
Could you check?
(It’s bedtime for me though, so no hurry…)
@NoSloppy did I interpret correctly, you’re seeing the swing at 1600 ms without STARTUP_DELAY? This was “known” from when I first added the Swing On Ignition, that’s what generated the original 3000 ms check before allowing ignition, in my old tests it was between 1500 and 2000 ms so I went to 3000 to be “safe”. If this is the case, this is just a behavior of the motion chip starting up from how I understand it.
It’s been a while since I tested this, but I did see a problem like this too.
Not sure what causes it.
Yes. It’s ~1600 from actual startup.
The additional 15000 was my startup delay.
I had the wrong 1 of your 2 lines quoted, sorry.
Fixed inline above.
You asked
Initially, I quoted the second case and said “^this^”.
I had meant to confirm the first one.
Bottom line is it’s always an event swing on boot at ~1650 milliseconds when first applying power to the board, and occasionally when done with a serial monitor command to reset.
I recently found a small bug in the motion extrapolator, I don’t think it would cause this particular problem, but it might be worth a try to see if it’s affected at all.
1 Like