That depends on the BMS. With FlexiBMS, once the charging has finished, you have to disconnect and reconnect the charger for the charging to start again.
Personally, I would never leave my charger connected over night; the less so with the board switched on. I never charge my board unattended.
yes
You would have to somehow ensure that connecting the charger switches your VESC on. DAVEGA is currently powered from VESC and can’t run without the VESC being on. Even if you powered it from another power source, it relies on the VESC to relay the communication to the BMS so it wouldn’t be able to do anything useful without the VESC.
Under normal circumstances (unless you’re testing/investigating something), there’s no need to have the VESC/DAVEGA on while charging. You want to check on your cell voltages before and after charging; not so much while the charging is in progress.
How does the davega keep track of wh/km and wh discharged/charged? I am wondering if I will be able to keep track of how many charge cycles I have put my batteries through, for my upcoming build. I roughly know how much Wh my pack is and will give me from 4.0v-3.2v. I am thinking I divide the total wh charged metric by my pack size.
I don’t believe there’s an accurate definition of a charge cycle. If you go for groceries around the corner and then recharge the board, is that a charge cycle? If you discharge to almost empty on one occasion and discharge 5% on another, is that two charge cycles?
DAVEGA gives you the total Wh and Ah discharged on the lifetime screen, which is a much more useful piece of information for estimating the battery deterioration than charge cycle count (regardless of how exactly you define it).
You can always convert it to the equivalent of full charge cycles simply by dividing by the battery capacity.
In my case, there’s 12S7P Samsung 30Q, which is 21 Ah at 43.2 V nominal voltage. That’s 907.2 Wh. Assuming 80% useable capacity = 726 Wh, and using the total Wh discharged = 40,470 Wh, I’m currently at an equivalent of 56 full charge cycles.
Just for reference…
The definition of a cycle is a discharge and recharge done at a selected nominal current level equal to the rated capacity of the cell. If the cell was discharged to 50% and recharged you would have to do that twice for it to be counted as one cycle.
As you noted though, there are all kinds of issues when trying to use some sort of cycle count to estimate pack aging. It’s much more useful to track capacity or run time loss as these are easily measured.
The manufacturers typically set a 20% loss of capacity as the “end of life” point for a cell. But depending on how it’s being used, and our tolerance for the loss of riding time, a pack could be used for a long time after this point.
Well, as long as the cells aren’t becoming ridiculously hard to keep balanced and the pack isn’t running too hot because of increased cell internal resistance. Everyone has to use their best judgement here. If the pack is acting weird in any way then replace the appropriate cells or retire the pack.
Yes this is exactly what I meant. Thanks but do I have to keep the power on for my board the entire time while charging every time to have the lifetime charged tracked?
No, the energy charged from the charger is actually not tracked since there isn’t a good way to do it in a general case. The “Wh in” is regenerative braking.
This is actually the same thing as the DAVEGA cable, only shorter (20cm). It’s great for either connecting the Flexi to a VESC or to connect two VESCs together.
26 AWG, silicone insulation, very flexible.
If you only need CANL and CANH, you can even separate the wires in the middle and make two.
Any chance we could get test firmware compatible retroactively? My boards with Davega I usually run the test firmware and end up just getting the boot screen. If the Davega doesn’t write to the vesc and only reads, is there danger in allowing it to attempt to read from incompatible firmware?
There’s a little bit of risk. Should Vedder decide that in 5.04, the COMM_GET_VALUES will get interpreted as COMM_EXECUTE_SELFDESTRUCTION, that could be a problem. Since the odds of that happening are fairly low I think it would be safe to assess the compatibility based on the major version only, i.e. all 5.x versions would be supported by default. I’ll think about it some more and if I can’t think of any other issue, I may implement that in the next DAVEGA FW release.
Unfortunately not. It doesn’t have CAN. BT connection is an option for the future but we’ll need to wait until there’s better BT support in micropython.
