Let’s be fair here , Ben didn’t push that line of code, rubbing his hand menacingly, laughing in the background thinking it would be a bug. No developer does. It was a mistake.
Can any developer here truly say they’ve never made a mistake/bug in production before ever in their careers?
Asking Frank to change somethung is a waste of time, the man has never been wrong in his own eyes.
I think this is still a productive discussion though, I think there are good points to both sides. I think the number one answer though is just to manage it better during setup, and funnel more people toward the wizards when they open the app.
Correct. The answer is to make it part of the process that you have to go through in the wizard instead of it being “hidden” in the advanced section. It’s been mentioned 100 times by now so it’s clear a lot of people feel it needs addressing
Whilst I have your attention, are their plans to move the HFI frequency out of the human hearing spectrum? I think this will be key to driving adoption.
Most beginners don’t know, when they have a dual setup and don’t use the wizard, that they must activate the Can Status message 1_2_3_4, to get a working dual setup.
These are the issues.
I think when you use the phone app wizard for FOC it becomes obvious that this is the best path for easy setup and mostly “just works”. We just need to get users going there naturally when they open the app and make them more uniform on the PC tool as well.
I said the obvious. 
I figured it out yesterday in the app tab, when I configured my setup.
It definitely would be cool to do, maybe the next time Vedder and I meetup we can have a little Hack at it on the weekend. The downsides are you have to PWM at like 40 kHz and sample v0 v7, so it would probably only be possible with phase shunts unless you run 80 kHz which is a bit fast, not sure how much switching losses you’d see at that frequncy and it gets tricky because your ADC sample time starts to become relevant I think.
Maybe we can figure out a way to have it run at a greater fraction of the switching frequency, I’d need a whiteboard. There will always be some noise due to the spinning vector but I think this would be much less loud (not 100% sure)
Whoa there… battery limit is not the first step in the wizard, before motor detection?
Let’s also be fair here.
@Trampa pushed the release before it was time, before it was ever tested, endangering people’s lives, because they simply were too lazy to backport support for their newest hardware (VESC 6 MKIV) into version 4.
Change my mind that it happened for a different reason. Because it didn’t.
The honest truth here is that Trampa cares more about money than your health. If there was any other reason, maybe they’d have answered the repeated querying as to why it was released prematurely.
Nobody is arguing that bugs happen. Of course they do. But making last minute changes and then bypassing the entire community testing process because you need to list your new ESCs for sale today is a dick move. It’s plain, and it’s simple. It’s also reckless.
Was it Trampa or Vedder? I though vedder was in control of the Github.
Trampa is pulling the strings to my knowledge, with Vedder as an employee.
Let’s be fair here
Ben does the commit and push to master. Not Trampa.
Ben is his own man , not trapped in Frank’s Basement with a gun to his head if he doesn’t do what he says.
Is it frank that denies or approves Pull Request ? No it’s Ben after he comments why he will or won’t.
2 things here:
I agree , but again , that’s on Ben. Not Frank. Until I see Franks name on a commit or pull request for that specific Bug or Frank admitting that he wrote the code that caused the bug, that’s on Ben. Not Frank. He’s the committer. He’s the pusher.
Ben has chosen the communities he’s beholden to: His forum and pull request. We all know where Ben prefers, we’ve known this for years. If you would like your voice and request to be heard, everyone is free to go on either of the two. If not , you’ll have to compromise with either being heard by those working with Ben that also are here on the forum , or just not maybe be heard at all.
You are making a lot of leaping assumptions here.
This is a pretty unfair, unfounded, and potentially damaging accusation.
Can we please cool it with the hyperbole on this topic? It’s already been explained a dozen times.
Was it correct with 4.x firmware ?
It hasn’t been explained as the question I asked was never answered. There was lots of deflection around how, what, when, where, but never was “why” answered.
Does the mobile vesc tool show max/avg current and speed ? I can see real-time stats but not max/avg, not sure if I’m not finding it or it’s just not there
Serious question here, does the VESC implement overmodulation?
If my geometry is right, this increases effective voltage/duty cycle by around 10.3% (of the maximum duty cycle, i.e. 80% becomes 88.24%).
Stop barking, please.
You do want explanation ?
Go on the VESC Project forum and read Ben’s last post about this event.
I’m not agree with the way Trampa get their hands on VESC Project however what you’re doing is just throwing wrong statements or even lies.
So please, go on VESC project forum and read.