I don’t think so, but please correct me if I am wrong, maybe I missed something
1 Like
There’s the COMM_GET_VALUES_SETUP that returns values aggregated from all VESCs. You don’t get the individual VESC values though, only the aggregations such as max/min/avg/sum.
Edit: OK, not max/min/avg, only sums. And only for some attributes such as motor current or mAh discharged, i.e. those where calculating the sum over all VESCs makes sense.
1 Like
There a bigger chances for me to have understood wrong, but when I asked @Trampa how the Wand was gathering the data from all vescs that is what I understood
Or from one the Vedder videos
You can ask Ben about that. He aggregates the data, so that we get data across all VESCs. Some stuff is individual data, such as temp. On the Wand that is from the master VESC.
If you look into the VESC-Tool App, in the cockpit there are for example two current draw analogue displays.
One is aggregated, the other from the master. It depend on the screen you look at. The screen with the big tachometer shows aggregated values I think.
Yes I see now, thanks!
1 Like
Thanks. I’m getting to understand the VESC code. This one part is pretty clear. (Unlike other parts where it’s still Chinese to me. :)) I must say I’m highly impressed by the code. And I don’t mean just the fact it gets lot of things done very well. It’s cleverly designed, the structure makes a lot of sense and I like how he’s finding the right balance between the volume of code and clarity. There are some duplicated parts that could have been eliminated, but it would likely make the code harder to understand so I actually like he kept it that way. No over-engineering. Plus, I suppose software engineering is not even Ben’s primary background. Very impressive indeed. You’d better keep that guy in your company, @Trampa.
3 Likes
One thriving US company once said to Ben: You are the best driver developer we have ever seen.
Software is his thing, so I would say it his his profession.
I will forward your compliments! Benjamin is independent BTW. VESC-Project is his thing.
7 Likes
Quick couple of questions.
I am currently running 1.2 and it works great. I upgraded it via WIFI from 1.0. I notice that 1.3 is available and when I try to download it I get the following msg - “Unable to progress MANIFEST” . I did the boot trick to bypass the VESC data being run and tried again. I go to install after I select 1.3 and I get kicked out and the system reboots to 1.2.
Any Ideas?
Next question is related to my batteries and the value I should be listing. I currently have a 10s5P setup running efest 21700 purple 35a 3.7ah cells. Specs 120amp continuous, 18.5ah
capacity. If this is the case should I put 1850 for MAH and then play with the usable % to dial it in? I ask because my battery bar seems to go down way faster than actual usage so I suspect I need to correctly play with setting to dial it in or my 18.5 ah is not what I should start with.
Thank you all in advance.
Spacer work out for yah?
1 Like
18.5 Ah = 18500 mAh. Looks like you’re an order of magnitude off.
I’ve had the same problem with the wifi reported a few times. I don’t yet know why exactly that happens. I’m working on improving the memory management so that the updates could be done without a restart. That should fix it for you.
We now also have a tool for updating the FW over USB. There are just a few loose ends I want to address before making it public. I suggest that you don’t worry about the FW update for now since there’s nothing too exciting in 1.3.0 anyway.
1 Like
yeah Some M3x10 helped me to get the horses out.
1 Like
Awesome thank you for the reply this helps and I will be on the lookout for the FW tool. Thank you for the assist and the great tool product.
1 Like
So this is my biggest issue w my unit. Only happens when my ttl has all the lights hooked in.
No data. Just battery bar.
7 Likes
Does the screen freeze or is there a red dot blinking at the top?
If the latter, that would mean the UART connection breaks for some reason. How are the lights set up? Do you have a Metr module that you could plug to UART instead of DAVEGA and see if it also looses the connection when the lights switch on?
2 Likes
The red dot goes. I’ll check w my metr
1 Like
I ran the DAVEgaX solo for 15 miles today. No issues to report
1 Like
Hey @janpom
First awesome product. I don’t own one personally, but it’s still awesome 
I haven’t been following the thread intensely and I’m not 100% sure what DAVEGA can do, but I had an idea for something that I personally think would be really cool. It’s a battery recharge counter.
I’m doing the example for 10s.
So my idea is, whenever you turn on your DAVEGA, it looks at the current voltage. If the voltage is between 41,8V to 42,2V AND the voltage is higher than “voltage last time turned off”+1, then it adds 1 to the recharge counter.
I am by no means any electrical engineer or anything fancy, it was just an idea I came up with in my head. I’m sure there are some bugs if it even works, but if it were to happen 1 out of 100 times, then I still think it would be a nice feature. Not my decision though.
Just me thinking out loud and hoping it might be useful 
if not feel free to shoot me down 
8 Likes
This a good idea but why those voltages?
The other thing to consider too is if you turn your board off immediately after a ride, Davega won’t capture the battery recovering some of its voltage. Also writing on power of can be unreliable. Working 1 out of 100 isn’t desirable either as inaccurate reporting makes it somewhat pointless. Still these are all things that can be worked through!
I believe there’s already a field for battery cycle right? That field assumes full depth discharge and charge. I’m not sure if partial charge count is useful but I’m always for being able to pull more data points when possible Thinking about it, this could show how a user doesn’t always ride a battery till the very end 
1 Like
Hi, thanks for the kind words and for the suggestion. I have considered the recharge counter before and though it’s easy to implement, I decided against it. The main reason is that it’s not a well defined metric.
If you discharge your battery to 10% and charge it to 100%, most people will agree that’s a full charge cycle. But what if you discharge to 50% and charge to 100%. Still a full cycle? What if you discharge to 60% and charge to 90%? Should we count that? Should we maybe count that as a half cycle? Or a third cycle?
IMO everyone will have their own idea about what qualifies as a charge cycle. And if everyone has their own definition of the metric, it’s a useless metric.
Plus, DAVEGA already has something much better for keeping track of the battery wear – the total Ah discharged. Using the VESC’s built in Coulomb counter, DAVEGA knows how much energy you’re using and it remembers all of that. Also, you can estimate the number of full charge cycles from the total Ah discharged. For example, if your battery capacity is 10 Ah and you have discharged the total of 1000 Ah, you know you have done an equivalent of 100 charge cycles.
You may argue that it’s not the same whether you have discharged 100% 100 times or 50% 200 times and you would be right. But, DAVEGA also keeps track of the total Wh discharged. Then if you divide the total Wh by the total Ah, you get the average battery voltage, which is indicative of how low you discharge your battery pack.
I believe that the total Ah and total Wh discharged combined are a much better indicator of the battery wear than the (vaguely defined) charge cycle count.
13 Likes