$427 USD plus shipping from the UK plus duties for a 12S dual ESC that’s not really dual just two isolated ESCs on the same PCB.
If the 75 volt version had the same price tag I’d be in.
25 Likes
Luckily we have options 
Let’s not kid ourselves, we all love the form factor, the replaceable components, the two ESCs in one approach to dual, and most of all… that ass. We’re just seething with rage over this whole “VESC” ordeal and wish we weren’t so poor so we could shell out for this sweet ESC anyway.
20 Likes
You’re playing with fire m8
19 Likes
nail on the coffin there
I don’t really need another esc but I could swap the unity out.
Yeah pretty much
Wouldn’t it be safer to raise it to 100% if you answer no?
1 Like
Dual is always two ESCs in one housing, no matter how you look at it. The only question is: single or dual processor to control the two power stages and their driver chipset. This hole “one ESC for two motors” was marketing BS in the first place. It’s basically two ESCs on one PCB to cut down cost, which comes at the price of two ESCs going down if one side fails. We tried our best to combine the best of both worlds. A dual output ESC with separated power stages allowing service and repairs and footprint + cost reduction.
In addition to the HW, we also have to price in R&D and software development. That’s a big chunk of cost but it is unavoidable. Without advanced software, those devices are nothing but a paperweight. In the end the software for the ESCs and peripherals we all use is a full time job and can only be a full time job if the financial situation is sustainable. A project like the VESC-Project is not sustainable if we only see companies who produce cheap hardware and sell it with some small profit margin to keep their own ball rolling.
You stated that the day there would be a closed source solution that can compete with the VESC motor controllers, you would drop the VESC environment for your products. Even if that solution would exist one day, it would have to price in all the R&D work and would probably be quite expensive.
And feature requests would also be not realistic or very pricey to integrate. Personally I think a closed source solution for general purpose ESCs is nothing realistic when OS solutions already deliver what the VESC environment delivers today.
To answer your question: The 75V Version will be slightly more expensive, due to higher component cost. It won’t be that much, but a bit more.
9 Likes
Esk8 seems a small market for vesc-powered controllers tbh.
I’d like a dialogue option that also shows me exactly what is changed.
Like in games… there’s “hard mode: for the experienced” and “hard mode: +25% enemy hp, -20% damage”
2 Likes
That is the same thing. You choose the application and certain suitable pre-sets are made according to your application. In other applications other pre-sets would make more sense. There is simply no one solution that defines a safe basic standard for all environments. It all depends on the point of view. As @NuRxG stated: For mono-wheels things look completely different. In future we might see even new inventions that would hate a 85% pre-set or that would face safety issues with that pre-set. Before mono wheels existed, we did not think about them… Let’s see what the future brings us and what settings are required then.
4 Likes
It’s not the same thing at all.
One is having a default that has more physical safety for users of Type A and doesn’t perform as well for users of Type B. The other – is having a default which includes high risk of personal injury for users of Type A, and slightly better performance for users of Type B.
Defaulting to “less risk of personal injury” and then increasing the performance if the user isn’t Type A — is totally different (and better) than defaulting to “more risk of personal injury” and then reducing it if the user is Type A, which is what you are suggesting.
If the user doesn’t use the wizard or any other thing happens, the default should be less personal injury risk.
10 Likes
Aside from that, this is merely a “default default” than can even be overridden for each different hardware if they choose to, and even then it’s only a default and can easily be changed by the user or by a wizard.
It’s a no-brainer. Less personal injury risk is better than more personal injury risk. Convince me otherwise
1 Like
What you consider less risk can be more risk for others. That’s my point. So it’s best to have risk eliminating choices for each application. There are so many points of views and yours is only one of many. A monowheel that stalls because of 85% pre-set is not nice for the rider…
1 Like
While I can’t speak for other riders, I’d personally prefer stalling over supermanning.
Give your customers a survey and see what they actually want.
6 Likes
Fantastic you bring this up.
- Default to 85% Duty Cycle Current Limit Start and offer a way to increase/decrease it
- Default to 100% Duty Cycle Current Limit Start and offer a way to increase/decrease it
0 voters
8 Likes
Hmm,
where’s the “do a circuit analysis to identify minimum necessary sampling window and hard limit the maximum duty cycle to accommodate that value” option?
This is ESPECIALLY important on lowside shunt configurations.
2 Likes
ever heard of idiotproofing? an invention should always implement a way(s) of preventing injury or death, even if it means of reducing ones performance. not saying that any of us is idiot, but it should be considered in the first place, u never know who is using the software and also how they are using it
5 Likes
If you know the exact use case it would be simple…
Unfortunately you don’t know what those devices will be used for, so a setup wizard with the minimum of questions to answer is the way forward.
3 Likes
So then if you’re using a wizard there is even less reason to keep the unsafe defaults, not more.
But should someone configure it without the wizard, maximum safety over a marginal performance increase seems like a no-brainer. And those can all be changed anyway. But forgetting to change it should default to safest way possible.
2 Likes
What you consider unsafe is the safety for others and VS. Each application differs and there is simply no golden idiot standard. Your view is skate biased. This single setting is just one of many! Which combination do you personally prefer and which do others prefer in other applications? There is no golden standard that defines a perfect idiot safe base for everyone. The best way forward is to define a most idiot safe basic setup for each application And forget about a single biased point of view. You ask some questions and the most idiot base standard of settings is then loaded. And the point to start with is application neutral.
1 Like
Ask your customers, put up a survey on your website.
3 Likes