Ohh, didn’t know it had to be a different signal, same as I used to do with Ackmaniac then? I’ll try and let you know
When the cat decides he can help you whilst your upgrading to FW5.0
Also doing the upgrade wireless over TCP Via Metr.
WERE LIVING IN THE FUTURE
7 Likes
OK so . . .
I had some issues doing the Vesc tool motor configuration wizard via the android app. I would go through until the actual motor detection then it would fail. Then tried via tcp from the computer and it was fine.
Smart reverse seem to be working as expected.
Tried tuning the HFI. it starts fine but then gets crazy jumpy as the speed increases. @Deodand tried to follow your tuning tutorial but it seems that, when connected via tcp, the graph plotting is slow. managed to get the first step done and then set the start voltage but couldn’t get the “handbreak” to work in vesc tool over TCP to continue the process.
Is there any way to do this tuning from the mobile VESC tool?
@rpasichnyk is it possible to do this tuning from metr without just blindly guessing parameters?
Dropped back to sensors and went for a ride. Not super hard but everything seems to be working correct. will charge up and go out again later.
4 Likes
Yeah it’s quit a bit of data getting dumped across the link right now for HFI plot. I will probably spend my time auto-configuring it rather than getting that plot to work over wireless, but right now I’m stretched a bit too thin getting everything ready.
What motors you running @ducktaperules? Maybe try 12-15 max and leave the other settigns if they are 6374-esque sized. Also what is the result of the terminal command inductance calibration?
https://www.vesc-project.com/node/1640
For those who haven’t noticed Ben uploaded a latest tool yesterday that has some bugfixes etc. There’s a new small ui bit to navigate CAN devices, a little bit smoother calibration routine and a few other bits and pieces. One cool thing Ben made is a terminal command to analyze hall sensors. This should be the last change involving anything related to features and from here we will only be looking to identify any weird behaviors etc.
I’ll investigate the concept of a third number at least on these test branches so we can track the small changes since there aren’t major releases.
6 Likes
I’m running maytech 6880 and I think I was getting readings of around 9.6 and 2.8
Just went our for a great ride. Everything feels like it should. Still don’t like smart reverse over standard reverse, maybe if I make it a little more aggressive it will be more acceptable.
1 Like
yeah I think its one of those if you don’t like it you never will. More aggression in duty cycle mode can get a little scary.
Should be good candidates for HFI then. (edit) Forgot how it was displayed that is normal.
4 Likes
@Deodand, what do you think about adding a PATCH number at the end of GET_FW_VERSION packet and just display it in VESC Tool ?
As many developments are made in paralell of testing, it’s a bit hard to track bugs.
I may give a hand on that if needed. 
4 Likes
Currently we have a Boolean value for is_test_fw. My thoughts were maybe to convert this to an integer test_revision, if it’s a zero then it’s the actual release if not then it’s just iterated each time we push changes.
12 Likes
Love this idea !
3 Likes
Even if they performed at only half that, it would still outstrip what the Unity can handle, and the same points would still apply, so I’m wondering why you’re trolling?
If you’ve ever seen any of my metr logs when I’m running the LiPos you’d notice the voltage line stays flat, which indicates I’m not getting voltage sag, and still below its C rating.
1 Like
Done it here (my little contribution to your awesome work) :
8 Likes
So this happened today. Is this related to the settings I quoted above, or maybe something like solder joints in the phase leads for motor 2?
1 Like
Were you braking hard when it happened?
1 Like
Accelerating.
1 Like
Thanks for reporting this. The unity previously had some issues with this fault that I ended up patching out by essentially disabling it from triggering. It would only seem to occur in extremely high draw scenarios and disabling the fault never seemed to damage anything. I believe that it was triggering based on an incorrect reading and not an actual over-draw because it was never accompanied with a failure or DRV fault.
I did some testing myself and was unable to trigger this on this new firmware, but it showing up here definitely has my ears up. The abs over current fault is somewhat redundant because the drv has builtin cycle by cycle current limiting that will trigger faster than the mcu in a high draw situation. I think I may just disable it again, I’ll test tomorrow some more to see if I can get it to trigger here.
What settings were you running?
6 Likes
1 Like
…and thanks for looking into it mate, we all very much appreciate your time and effort spent improving this.
1 Like
those settings are really, really, really high.
What battery and motors do you have?
-150A battery minimum will send you off the nose like Superman. Try -30A or -20A for that
4 Likes
Okay? This is what I’m riding with currently, I’m still okay. I’m on the Unity FWIW.
3 Likes