The light front and light rear pin needs some more detailled description. It is more a direction forward pin and direction backward pin that are going on/off. The funwheel community like it for lights offcourse but you can use it to whatever you want. They just give 3.3v depending on your direction your going.
1 Like
If you have a better image, I’d gladly use it 
1 Like
@Dunmer it’s in the newest release, thanks!
New release brings in updates from upstream VESC 
Tool and also supports both CheapFOCer2 version 0.9 AND version 1.0
5.02.beta.17
11 Likes
If you are going to be changing the default settings, I’d like to recommend setting the decoupling setting in FOC advanced to NONE/DISABLED.
3 Likes
What is the effect of this change? What are the benifits or changing the default?
Better performance in general. You can run some tests yourself.
Control Systems 101 explains why it shouldn’t even exist in the first place.
3 Likes
Got some links to any information that backs that up?
2 Likes
literally any control systems textbook’s section on feedforwards.
The “decoupling” parameter relies on the speed estimate, which is notorious for lagging behind actual speed.
The end result is that the PI current controller and “decoupling” start fighting each other.
5 Likes
Cool. I was not saying that I disagree with the suggestion, just trying to find out what it does and why we should change it.
I think most the defaults in vesc are well tested at this point and if were going to change things we should have good reason and lots of testing to backup these changes.
@Gamer43 Unfortunately, I don’t think your “because I’m right” style answers help with this. You may be right but you need to help others understand why.
20 Likes
It’s not really “because I’m right” it’s because it’s common knowledge in this field and readily available from many resources. The idea in my mind was that it would be very easy for someone to verify it by cross referencing said knowledge or resources.
But I do see your point in that I should point more directly to these resources. Since not everyone has an EE background or know where to access said resources.
I’ll try to be more helpful next time.
24 Likes
I wish it is the case, not so sure tho
Agreed and wish vesc dev was following this logic more 
4 Likes
A community fork is a good place to start running things as the community would like. I think Brian will be cautious and will operate a proper beta and stable model
8 Likes
We should probably add a forum category for topics regarding the VESC FW and configuration tool.
3 Likes
Regarding FW development, is there some tool to test new code or the last part of the iteration is always uploading the new FW into the VESC HW and test it there?
I ask this specially for early stage development, where one doesn’t know exactly what will happen with the new code and even if/when it reaches a specific code block.
I can imagine it’s not an easy task to work on such low level code that interacts directly with the HW and don’t have a more agile way to test it, if that is the case…
1 Like
Aside from testing it myself on a skate, the community is relied upon a lot to test firmware.
A tool that only a handful of small companies use and only a small number of folks are using to build PEVs with, is never going to financially support a company doing full time development with test suites and dynamometers.
I do test code on my own ass, and this should tell you a lot, because I highly value my ass. But this is one setup testing it in one way.
All the variESC software should be considered alpha- or beta-stage prototypes.
Maybe except for things like Ackmaniac 3.103 which has been rigorously tested and is essentially rock solid and bug free. But it’s missing virtually all the features that most folks are using now. This variESC Tool should be considered the opposite of that, move fast and contain all the bells and whistles.
I work on variESC Tool for free in spare time. I literally made it for myself and just released it in case it helps anyone else, because I suspected it might.
28 Likes
Hi, would this be the right configuration for testing the FW on a Flipsky 6.6 dual and a MakerX DV6?
#define HW60_IS_MK5
#define HW_SOURCE “hw_hd60.c”
#define HW_HEADER “hw_hd60.h”
I tried an old VESC Tool I had here and it says HW name is 60 (on the FW widget) for the FS 6.6.
So, I guess I should select none of the MK3, Mk4 or MK5, according to this snippet of code:
#ifdef HW60_IS_MK3
#define HW_NAME “60_MK3”
#elif defined(HW60_IS_MK4)
#define HW_NAME “60_MK4”
#elif defined(HW60_IS_MK5)
#define HW_NAME “60_MK5”
#else
#define HW_NAME “60”
#endif
Will try that and test.