Lmao. Sexy stuff. I have a few of them laying around I think ima have to give them a go haha. I will definitely try to learn more about fail safe n all of that now that you mention how important that is
Thank you brother 
4 Likes
12 Likes
Thanks guys have my finger on this issue now I’ll have a patch out today to fix it. Really want to thank everyone in this thread for their contributions super helpful toward pinpointing the issue.
12 Likes
Holy shit 
. That looks painful my man. Glad you’re ok
No, the ~1.50ms where the board hits max speed is his idle.
5 Likes
I’ve got the issue pinned down actually. Basically increased traffic on the UART bus during logging with metr module is causing conflicts in different interrupt routines, the timeout is being triggered and reset but the current command to the motors happens afterward and routine is getting interrupted and not revisited to properly re-command motor currents.
I’ll have a solution out today in the mean time just don’t run logging and everything will run as normal.
22 Likes
To be clear, this is an issue specific to Unity being run with Metr module during data logging? Thanks for getting down to the bottom of things! 
6 Likes
Yeah been running the board for a while now… Even with remote off it never ran away =(
@Deodand I have the unity metr module so not sure if that changes anything or made it a culprit
2 Likes
Yes and will only occur with internal metr module not external. I made a change last FW to eliminate BLE dropouts, tested extensively and have ridden on FW for a month before release, but I only have external metr module. I did also send a pre-release to the metr guys for testing but it seems the bug is intermittent enough that it managed to slip through. I’ll be reverting this change I made and looking for a secondary avenue to address BLE dropouts.
It does also expose an interesting behavior with the PPM app timeout that needs to be patched out as well. The timeout should only be reset after sending motor commands out not on first reciept of ppm signal.
Probably should also get one of the internal metr modules for testing. It’s a really awesome accessory they made and I want to make sure it runs smoothly.
22 Likes
holeeeeee fuck dude. imagine if that had gone to some passerby’s legs.
also LMAO at the homeless dude
Holy shit. Glad you’re okay. That’s my worst fear of what could happen…
Really sucks your board broke… Hope you get out riding again soon!
People are weird. The dude at the end just starts recording. like wtf?
Looks like Roman was right with his concern about UART priority. Great that it will be fixed.
10 Likes
Please just let us know your address via PM and we will send you one for free. You are doing awesome work for the community @Deodand. Thanks a lot for that.
15 Likes
Yes I had my own concerns which is why I spent so long testing, but I was never able to trigger anything.
9 Likes
To add to this, I wouldn’t say all uart remotes are missing 2. The secondary failsafe is due to the nature of the pwm signal and isn’t applicable to uart control of VESC (unless you want a secondary #3 failsafe). Failsafe #1 can most certainly be a feature of uart remotes.
2 Likes
Thanks a lot for getting this issue fixed so fast and most importantly standing behind your work AND testing your work! That’s truly what matters even though there might be some small bugs (even though they still suck…). Thanks a lot for your work! It’s awesome!
and just for no confusion, I was also using the internal METR for the unity.
8 Likes
Maybe @rpasichnyk & @hexakopter could auto-beta you with any new hardware, given this symbiotic relationship and for this imperative need to protect rider-safety…just an idea.
Let’s see what happens with the Wand when the F/W is released. At that point we will have a very common scenario of Metr-Unity-Wand.
Throw in a DaveGA into that mix too
Also wondering if this is only a Unity fork concern, wondering what ESCs Metr use for testing. Obviously new module is Unity specific but this issue was not hit due to the recent F/W change.
Riders need you guys to collectively ensure rider safety stays at the forefront of technological advances & apart from corporate strategy and market share, we are going to plug yer stuff together right or wrong, we don’t even care if the plug fits!
Ps. I think we all really appreciate the openness and integrity displayed
6 Likes
My balls just shriveled up.
Don’t nano-x and siblings auto-bind on startup? And on top of that needs calibration after powercycle (brownout). Brr!
What’s the distinction? default baud rate? BTW thanks Jeff for looking at this at such high priority.
Jeff’s response is awesome, but you must be so pissed. I’m glad you got thrown off right away and didn’t sail full throttle into traffic.
Wondering if Enertion could find some generosity to help you rebuild.
So I always thought maybe I’m too paranoid, but fear of stuff like this is why I’m on 2.54 firmware on most of my boards. I rarely update the unity app and firmware. Was considering doing this one because of all the upgrades, but the tingle kept me from doing it. Thanks everyone for reporting your crashes with logs!
4 Likes
I mentioned this a while back.
1 Like
Hey thanks for hashing out the nuances as usual. I’m gonna get into it since if I’m confused I’m sure others are too.
What’s soft bind? 
I found blasto on youtube here
in comments he says
The nano-x does not hold the bind in it’s memory, every time you power off the board, the receiver will go through it’s auto bind procedure. The other day it took 2 mins for mine to bind, i do agree this is a little annoying, their firmware could be tweaked a little for it to bind faster. But at the moment that is how it is and it works, so does yours
so auto bind == soft bind? And happens on every boot?
And your procedure is hard bind, where the receiver and remote are paired permanently (until binding procedure is invoked again)?