FU-Dyson-BMS - An (Unofficial) Firmware Upgrade for Dyson V6/V7 Vacuum BMS

[ThunderBrain]

I registered EEVblog to say thanks! This is awesome work! Just wondering, is populating that R22 the only thing we need to do to make the voltage balancing work?

[tinfever]

I registered EEVblog to say thanks! This is awesome work! Just wondering, is populating that R22 the only thing we need to do to make the voltage balancing work?

Thank you! Balancing has not been added to the firmware so populating the balancing resistors on the PCBs that have the footprints already on them will not do anything, unfortunately. At some point I may add balancing functionality but I'm not 100% sure if or when I'll have the time to do this.

[Trimbles]

Thanks so much for doing this super cool project - my dead Dyson now lives again and is better than ever with higher capacity cells (Molicel P26A) and the new firmware. Cheers

[Joust]

• Dyson did not install these resistors. (They even designed the V6 board, PCB 61462, to support them. They just left them out.)

can we add these parts?  I'm looking at my board and i see the pads.
what parts can go in there?
datasheet looks to add 200ohms to the CBx pins
on the pcb it looks like an empty 0603 space , a space for a diode and then on most a 1k 0603 in series
From here the datasheet says that the i2c bus controls this but from an external controller and here ends my level of competence and into your domain
this sounds like it can only improve the pack performance if and only if handled correctly.
 <edit> obviously i didn't see your last reply about this. I hope you can update code later for this. I'll stay tuned. </edit>

great job tinfever
im waiting on my pickit programmer to apply your code.

[Hank]

Did I already thank you for your immaculate piece of work? If not, I'll do it now.
And now I'm at it, I've seen a lot of of vids about cleaning the filters, but just holding it under the tap ain't good enough, so I've separated the two parts in order to get rid of the crap, and there's a lot of that in there!

[MALE20]

Hi,

My V7 started reporting low battery and died. As I prefer to fix staff rather than buy new battery I successfully uploaded firmware (which I must say it is amazing). Tried to charge but no result batteries where to much off balance. I had have some good ones on hand from other project so I replaced all cells. Battery went on charge and after a moment I got 12 red blinks (CHARGE_ISL_INT_OVERTEMP_PICREAD). I tried again no result, so I took battery a part to check overheating left on charge no trouble. I got now good fully charged balanced battery pack but this time after a second of starting motor BMS indicated low battery. I checked voltages and all seems fine. Looks like BMS got some sort of fault. Any other ideas?

[tinfever]

Hi,

My V7 started reporting low battery and died. As I prefer to fix staff rather than buy new battery I successfully uploaded firmware (which I must say it is amazing). Tried to charge but no result batteries where to much off balance. I had have some good ones on hand from other project so I replaced all cells. Battery went on charge and after a moment I got 12 red blinks (CHARGE_ISL_INT_OVERTEMP_PICREAD). I tried again no result, so I took battery a part to check overheating left on charge no trouble. I got now good fully charged balanced battery pack but this time after a second of starting motor BMS indicated low battery. I checked voltages and all seems fine. Looks like BMS got some sort of fault. Any other ideas?

There is a lot going on in your post and I'm not sure I'm following all of it. I think I understood the following:

- After installing firmware and attempting to charge it, there was "no result", assumed to be due to batteries excessively out of balance.
- The battery cells in the pack from the previous then were replaced. Now the battery pack could charge but shortly after it showed an error code 12 (CHARGE_ISL_INT_OVERTEMP_PICREAD).
- You disassembled the battery and tried charging again, and now it charged successfully to completion. No other changes were made.
- Now when attempting to use the battery in the vacuum, you receive a low battery indicator after a second or so. All cell voltages measure fine when checked.

Is that all correct?

A few questions/thoughts for you:
- You said there was "no result" when you originally installed the firmware and tried to charge the battery. What exactly happened? What led you to determine the charging failed due to excessive cell imbalance?

- When you replaced all of the battery cells, did you solder the terminals to the battery cells by any chance?

I'm perplexed that you received error code 12. The ISL94208 has an internal temperature sensor and the PIC measures the analog value of that temp. sensor and converts it to the temperature based on the datasheet parameters. If the calculated temperature is over 50C and the pack is attempting to charge, it will produce that error. Thus, that error really should only happen if the ISL94208 is over 50C. This would strongly suggest that the ISL94208 was over 50C, which I can only think would be caused by charging the battery pack at too high of a current (If you use a bench PSU and charge it too fast, there is a diode near the ISL that will heat up a lot), or perhaps if you soldered the terminals to the battery cells instead of spot welding, that could significantly heat up the cells, which would then heat up the PCB and I guess could cause that error. That's just a theory though. Alternatively I guess the ISL94208 temp sensor could be faulty. It is possible that perhaps the 50C temp limit is too low for the ISL94208 due to that diode's proximity and heating during charging. All my testing was done with plastic battery shell removed so I may not have encountered that.

Finally, my theory on why you are quickly seeing a low battery code when trying to use the battery is that the battery cells may have degraded and have too high of an ESR. This will cause the voltages to measure fine when no load is applied, but the voltages will drop drastically when a load is applied. If you attempt to use the vacuum with the max setting, this is MUCH worse. A V7 with no attachments draws roughly 3A in normal mode and 17A in max mode.

I would check the following:
- See if the low battery indicator comes even more quickly when attempting to use max mode.
- See if you can use a multimeter with a min/max capture function to capture the min voltage of the pack when applying a load or attaching the vacuum. You may have to use alligator clips to connect the vacuum to use as a load while still being able to measure the battery.
- Ideally, if you have any sort of electronic load, you can use a multimeter to measure the cell voltages while increasing the load. Watch if the cell voltages drop as you increase the load from 0 to 100mA, 200mA, etc.

More random thoughts:
I suppose it is also possible that the inrush current of the motor is exacerbating the higher ESR of the cells and tripping the under voltage cutout/ low battery indicator. There is a parameter in the firmware config.h file "#define CELLVOLTAGE_AVERAGE_WINDOW_SIZE 4" You could try to increase this to something like 16. (Keep it at a factor of 2) This will increase the averaging period for the cell voltages and possibly make it less susceptible to the inrush current causing problems will cells with higher ESR. This would be a pretty extreme change to make though so only do it as a last resort. I've done zero testing with that parameter to anything other that 4 so all bets are off and bugs are possible. Also, this may not help at all because I think when the averaging starts (like when you first turn on the vacuum) all datapoints that would be zero are discarded so you may still get a reading that includes the really low cell voltage during startup, and thus trip the low voltage cutout.

Hope this helps.

[MALE20]

- After installing firmware and attempting to charge it, there was "no result", assumed to be due to batteries excessively out of balance.
- The battery cells in the pack from the previous then were replaced. Now the battery pack could charge but shortly after it showed an error code 12 (CHARGE_ISL_INT_OVERTEMP_PICREAD).
- You disassembled the battery and tried charging again, and now it charged successfully to completion. No other changes were made.
- Now when attempting to use the battery in the vacuum, you receive a low battery indicator after a second or so. All cell voltages measure fine when checked.

Yes all correct

- You said there was "no result" when you originally installed the firmware and tried to charge the battery. What exactly happened? What led you to determine the charging failed due to excessive cell imbalance?

Let me correct a bit and put some more details. Prior to firmware upgrade I was not able to start motor at all due to in balance. After upgrade full charge was indicated within less then a minute when put on charge. When placed back in vacuum motor started for a second and indicated a low battery. Imbalance indicator showed a massive difference between cells. This confirmed my previous measurements and fact that batteries where not charging correctly pushed me towards changing cells. (I will probably check old cells separately).

I'm perplexed that you received error code 12. The ISL94208 has an internal temperature sensor and the PIC measures the analog value of that temp. sensor and converts it to the temperature based on the datasheet parameters. If the calculated temperature is over 50C and the pack is attempting to charge, it will produce that error. Thus, that error really should only happen if the ISL94208 is over 50C. This would strongly suggest that the ISL94208 was over 50C, which I can only think would be caused by charging the battery pack at too high of a current (If you use a bench PSU and charge it too fast, there is a diode near the ISL that will heat up a lot), or perhaps if you soldered the terminals to the battery cells instead of spot welding, that could significantly heat up the cells, which would then heat up the PCB and I guess could cause that error. That's just a theory though. Alternatively I guess the ISL94208 temp sensor could be faulty. It is possible that perhaps the 50C temp limit is too low for the ISL94208 due to that diode's proximity and heating during charging. All my testing was done with plastic battery shell removed so I may not have encountered that.

I used a Dyson battery charger at all times. Issue only occurred when the plastic cover was on. I do not have a thermal camera but I could feel a bit of heat from the PCB. Nothing excessive.  In the case of soldering batteries I tried to minimize exposure time and I pre-tin everything, and all plates were replaced with copper wick to keep everything low profile. I doubt that excessive heat could reach the IC.

 I had the same feelings about inrush current as this was my initial thought. I did some tests to check the output and I successfully ran a DC_DC converter with a 12V 380 mA fan I had on hand. I need to think about what else I got on hand to build a better setup to take some measurement.

Interesting thing happened by accident when I put the battery without a trigger mechanism (silly me). Motor has started and run in high suction mode. This is only achievable when the battery pack goes into sleep mode. I was trying to repeat the same using the trigger button but no success. I run the motor for 39 min straight, with no filter and no attachment fitted .
 Now I got the chance to replicate charring issues with a cover fitted.  I will let the battery pack cool down.

Once again I believe that inrush current is part of the problem. As a more scientific approach is required, I will try to build a setup and take some measurements later today.


Update 26/07

 CELLVOLTAGE_AVERAGE_WINDOW_SIZE change from 4 to 8 allows me to run high suction mode. Max suction mode is not working as measured voltage at peak is 19.76 before it cuts the power off. Increasing the average windows size does not help and high suction stops when size 20 is set. I am happy with the result as I only use high suction.

In terms of temperature I modified MAX_CHARGE_TEMP_C = from 50 to 59.I tried 55 but still caused a trouble. Part of the issue could be the silicon glue over the IC as this is another thermal barrier.

[tinfever]

...
Update 26/07

 CELLVOLTAGE_AVERAGE_WINDOW_SIZE change from 4 to 8 allows me to run high suction mode. Max suction mode is not working as measured voltage at peak is 19.76 before it cuts the power off. Increasing the average windows size does not help and high suction stops when size 20 is set. I am happy with the result as I only use high suction.

In terms of temperature I modified MAX_CHARGE_TEMP_C = from 50 to 59.I tried 55 but still caused a trouble. Part of the issue could be the silicon glue over the IC as this is another thermal barrier.

Thanks for reporting your results! I'm really glad to hear you got it working for you. 

I somewhat surprised that increasing the averaging window made a difference. The way the code works is that it keeps a log of the last X cell voltage measurements, where X = CELLVOLTAGE_AVERAGE_WINDOW_SIZE. Then when the code asks for the voltage of a specific cell, it sums all of the past cell voltages for that cell and divides by CELLVOLTAGE_AVERAGE_WINDOW_SIZE to get an average. The trick is that during initial startup, many of the past cell measurement data points will be zero, for example, the average of [4.1, 0, 0, 0] is 1.025V, which would instantly cause an under-voltage error. To avoid this, the code only divides by the number of number of data points collected (variable num_iterations) up to the window size. So the first time the data for a cell might be [4.1, 0, 0, 0], divided by 1, giving average of 4.1. Second time might have data [4.1, 4.08, 0, 0], divided by two, giving an average of 4.09, etc.

As you can see, increasing the averaging window size will smooth out voltage fluctuations, but only after all historical data points are populated. It shouldn't make any difference during startup (where startup = you just pulled the trigger, the BMS woke up, and needs to immediately enable the output if all safety checks pass).

I'd have to check some other time with the debugger, but the cell voltage history array probably has 2-3 data points collected before the output is enabled, just due to the number of times the main loop executes as it goes from init > idle > output_en states. There might also be a small delay since the code also waits for the ISL94208 to report the trigger is pressed, in addition to the PIC checking that input too. Perhaps increasing CELLVOLTAGE_AVERAGE_WINDOW_SIZE to 8 is just enough to keep a few more good data points in the average calculation, so the under-voltage cut out doesn't trip. I have no idea why increasing the window size to 20 would make things worse than setting it to 8 though.  I don't think it would be running out of RAM and I also don't think the calculation would be taking so long that the watchdog is kicking in.

I've briefly considered possible solutions to averaging-not-helping-at-startup issue, but I haven't come up with any great solutions.
Possible non-ideal solutions:

• Wait until the cell voltage history array is full before enabling the output, so any inrush current induced voltage drop can be averaged out by the other n-1 good data points
• Disable under-voltage protection for a short period after the output is enabled
• Maybe just lower the under-voltage cutout voltage for a short time after output is first enabled?
• Populate the cell voltage history will "normal" values like 3.6V for all array values that aren't collected yet. So the data might be [4.1, 3.6, 3.6, 3.6] instead of [4.1, 0, 0, 0]
• Add some delay to the under voltage cut out or require multiple consecutive under-voltage readings before kicking in.

Number 3 is probably the best option and might not be too invasive to implement.

Now that you have the vacuum working, if you feel like tinkering with it some more, you could measure your cell ESR by measuring the cell voltage drop and current draw of the vacuum simultaneously. For example, you are measuring cell 1, connect a multimeter to cell 1 and measure the no-load voltage. Let's say you measure 4.12V. Now you start the vacuum and measure that it is drawing 3.27A, and at the same time the vacuum is drawing that current, cell 1 measures 3.74V. You can approximate the ESR of cell 1 as the voltage drop / current. (V/I = R). So 4.12V-3.74V = 380mV / 3.27A = 116mOhm ESR of cell 1. I think I read this isn't the ideal way to measure ESR, but I think it's probably a good approximation. You could then calculate that if cell 1 has an ESR of 116mOhm, and you put the vacuum in max. mode and draw 17A, your voltage drop due to ESR would be 17A * 116mOhm or 1.972V! Meaning, your no-load cell voltage of 4.12V would drop to 2.148V! Those are all rough calculations, but that ESR calc would tell us that no amount of averaging will fix the fact that you can't draw 17A from this hypothetical cell and still have a cell voltage above 3V. You would want to repeat the testing/measurements for each cell, but you can apply the test load across the entire pack.

My long rant aside, another option you could tweak is to reduce MIN_DISCHARGE_CELL_VOLTAGE_mV to something like 2700 or maybe even 2500. This might help with both the inrush current voltage droops, and any cells with poor ESR in general.

Also, thanks for the information on the charging over-temp. I'm curious, what was/is your ambient temperature when charging? All my testing was done at 21C ambient and with the plastic case removed, so I could totally see issues like yours popping up when the case installed and with a higher ambient temp. Also, just to double check, did it take a few minutes, or at least like 30 seconds before you were encountering the charging over-temp error? That would also indicate it just heating up and I have the limit set too low. If it errors out instantly, that might be something totally different.



One last thing:

Interesting thing happened by accident when I put the battery without a trigger mechanism (silly me). Motor has started and run in high suction mode. This is only achievable when the battery pack goes into sleep mode. I was trying to repeat the same using the trigger button but no success. I run the motor for 39 min straight, with no filter and no attachment fitted .

Does this mean that somehow the BMS was asleep (LED turned off) but the output was still on? If so, that's troubling to me since it means somehow the output was enabled but all protection features would be off. That would mean there might be a serious bug in my code, since that shouldn't be possible.  Could you provide any more details on what exactly happened?

[Geoff-AU]

Super cool project! This makes me want to buy a Dyson and immediately reflash it.

Nah.  I don't want to buy overpriced junk.  This makes me want to make my own vacuum cleaner.  With beer and hookers, etc (thanks Bender).

But taking something you have already bought, that a manufacturer has crippled, and fixing it so you don't have to buy another one is a worthy effort.  Good job.

[MALE20]

Thx for advice I will try to build a setup to calculate ESR. I will need to wait till next week once I got PicKIt3 back to upload the firmware and try different options.

Does this mean that somehow the BMS was asleep (LED turned off) but the output was still on? If so, that's troubling to me since it means somehow the output was enabled but all protection features would be off. That would mean there might be a serious bug in my code, since that shouldn't be possible.  Could you provide any more details on what exactly happened?

There is no option to get output without a magnet present. That means if you forget the trigger mechanism as soon as you put the pack back in it got a contact and runs. Same can be replicated with magnet and trigger plastic removed.  Not sure how long does it take to pass all the safety checks but it must be ms as the output voltage can be measured almost instantly.

In terms of an ambient temperature I would say I had 23°C and faulty does not appear instantly as it takes a few minutes. I was quite confident increasing temperature as isl94208 datasheet indicates temperature range from -40°C to +85°C. I didn't want to go above 60 due to the colorations with discharge temperature as I am not sure how well that would fit with my new cells.

Cells fitted currently are LG INR18650 F1L 3.63V 3350mAh  4.875A Max continuous discharge
https://lygte-info.dk/review/batteries2012/LG%2018650%20F1L%203350mAh%20(Purple)%20UK.html

[tinfever]

There is no option to get output without a magnet present. That means if you forget the trigger mechanism as soon as you put the pack back in it got a contact and runs. Same can be replicated with magnet and trigger plastic removed.  Not sure how long does it take to pass all the safety checks but it must be ms as the output voltage can be measured almost instantly.

Interesting thing happened by accident when I put the battery without a trigger mechanism (silly me). Motor has started and run in high suction mode. This is only achievable when the battery pack goes into sleep mode. I was trying to repeat the same using the trigger button but no success. I run the motor for 39 min straight, with no filter and no attachment fitted .

That all makes sense regarding the missing trigger mechanism causing the output to be enabled immediately once the magnet is present. When this happened, was the LED turned on and solid blue while the output was enabled? When you mention that the motor ran for 39 minutes, when it stopped running, was that because the low battery cut-out kicked in?

This sounds like the BMS may have been functioning normally. 
This is my theory:

• Battery was assembled with no trigger mechanism so the output will enable as soon as a magnet gets close enough to the reed switch. (Just like you said)
• As the battery started to be slotted in to the vacuum, the magnet got close enough and triggered the reed switch. BUT the electrical contacts might not have connected yet. Thus the output is enabled, so the cell history data fills up completely with good data, and there isn't any inrush current voltage droop to trip the under-voltage cutout
• Finally, the battery is slotted the rest of the way in. The inrush current spike occurs, but the averaging mechanism works as intended because the cell voltage history is otherwise filled with good data points. Meaning, rather than a cell history of [4.1, 1.8, 0, 0] with an average (/2) of 2.95V (not OK), it might have been [4.1, 4.1, 4.1, 1.8] with an average (/4) of 3.53V (OK).

In terms of an ambient temperature I would say I had 23°C and faulty does not appear instantly as it takes a few minutes. I was quite confident increasing temperature as isl94208 datasheet indicates temperature range from -40°C to +85°C. I didn't want to go above 60 due to the colorations with discharge temperature as I am not sure how well that would fit with my new cells.

It sounds like I just have that limit set too low. The reason I had set it as low as I could was because I considered that to be a backup temperature sensor for the battery cells. By making sure both the thermistor and the ISL temp sensor were in an acceptable charging temp range, I figured it would be safer. I didn't really consider the downside of that. I'll consider increasing the default limit in a future release.

Cells fitted currently are LG INR18650 F1L 3.63V 3350mAh  4.875A Max continuous discharge
https://lygte-info.dk/review/batteries2012/LG%2018650%20F1L%203350mAh%20(Purple)%20UK.html

That explains why the max power mode on the vacuum doesn't work!! 

The vacuum is trying to draw 17A from cells that are only rated for 4.875A! If you look at the 10A discharge curves in the link, you can see how the cell voltage drops from 4.2V to 3.6V almost instantly under a 10A load. Under a 17A load like the vacuum's max power mode, it wouldn't surprise me at all if they dropped to 3V or lower.

No amount of software will fix the fact that the cells aren't rated for the max power mode current. However, the good news is that your cells have a much higher capacity so you can run the vacuum in normal mode for much longer. The stock cells are only 2100mAh, so your 3350mAh cells should last almost 60% longer!

[Terry Bites]

FU FU Dyson you FC ! Triator and Enthusiastic Supporter of the CPC. Burn in hell with your overpriced hoovers!

[MALE20]

I am still happy with the result as I only use V7 in lowest mode, and cells I have been salvaged for free so can't complaint. Cyclone design and motor brushes does the magic and vacuum is up and running. Leaving in a dream

As I mentioned about this project to my colleague, he gave me one of his faulty/dead battery pack (same as mine). It seems like it will need new cells however on top of that Q3 mosfet is shorted. Should be easily fixed however parts are not available. The one I got fitted is different to the schematics but you can't get either of them. As I know you mentioned that you went thru couple mosfets during your test. Do you have any suggestions for adequate replacement for this strange pack?

PSMN1R0-30YLC

Update:
I haven't tried this but I found following tool for those who struggle with cover removal.

https://www.thingiverse.com/thing:3112717/files

[tinfever]

The MOSFET part number you mention, PSMN1R0-30YLC, is the same one I have in my V6 schematic. Although I do recall that I might have seen them use different MOSFETs on different examples of the same BMS board. They might just be using whatever is the cheapest and available at any time. Or they might have switched to a different/slightly better MOSFET, like the PSMN0R9-30ULD, on the later models to reduce failures? Who knows.

As for possible replacement parts, it is out of stock now but I ordered PSMN1R5-30YLC parts as a possible replacement, but I haven't tried using them yet. For all the MOSFETs I've blown, I had just scavenged the replacement MOSFETs from other BMS boards where I blew a different component! haha

You are absolutely right that replacement parts are hard to fine. I'd look for a part with a package name containing "LFPAK-56", make sure Vds - Drain-Source Breakdown Voltage is >= 30V, then get the lowest Rds-on you can find. Then, confirm footprint is at least similar to that of the original MOSFET PN, make sure it can handle short current spikes of at least 120A or so, and calculate I-squared-R losses for the Rds-on at 17A.

Not sure if Mouser is an option for you in in UK, but here are some contenders (not guaranteed to work, I just briefly looked at them) I see:

PSMNR90-40YLHX
PSMN1R0-40YLDX
PSMN1R5-30YL
PSMN1R7-30YL

Barring anything LFPAK-56 from Nexperia, you'd have to get more creative and just try to find anything with a package where the pins mostly line up with the footprint. It looks like manufacturers might be using "56" in the part number for similar sizes? You might be able to make FDMS8018 (Available on Farnell and others) from OnSemi work.

Also, if the MOSFET is failed short, check the fuse since that is probably blown too.

I'd also encourage you, and anyone else, to double check that the cells really need replacement before replacing them. On the 6 battery packs I've worked on, none of them had cells bad enough I think they'd need replacement. Your experience may differ though. Many of the packs did have a cell that was very low, like 1.5V, but that alone can just be fixed by very slowly charging that cell back up and manually balancing the pack.

[Joust]

SUCCESS!!!
Thank you tinfever!

my V6 original dyson battery failed. I opened it up and used my lab PS current limted to 500ma and charged each cell individually to 4.2v
when i hooked them back up the board immediately flashed red.

had to order a pickit programmer which took a while and then had a bit of difficulty getting the pickit3.10 sw to recognize it. (hint MS likes to be rebooted.....(*#^@$(^!@&^        )

After that all went by the numbers.
then got the greeted with RED GREEN BLUE flashes...YAY
Thanks again
</edit>
while waiting for my pickit programmer i could not help wondering why it would not be a good idea to charge each cell individually. i mean even with the addition of the cheap single cell charge modules freely available. often advertised as "TP4056 Lithium Battery Charger Module Charging Board With Protection Dual Functions Li-ion" if fed 5v independently they could charge each cell with its own source and sense mechanism. would that not alleviate any imbalance possibilities? im just a lowly technologist so i think in practical terms but it seems only logical to me. am i missing something?
<edit>

[tinfever]

SUCCESS!!!
Thank you tinfever!

my V6 original dyson battery failed. I opened it up and used my lab PS current limted to 500ma and charged each cell individually to 4.2v
when i hooked them back up the board immediately flashed red.

had to order a pickit programmer which took a while and then had a bit of difficulty getting the pickit3.10 sw to recognize it. (hint MS likes to be rebooted.....(*#^@$(^!@&^        )

After that all went by the numbers.
then got the greeted with RED GREEN BLUE flashes...YAY
Thanks again
</edit>
while waiting for my pickit programmer i could not help wondering why it would not be a good idea to charge each cell individually. i mean even with the addition of the cheap single cell charge modules freely available. often advertised as "TP4056 Lithium Battery Charger Module Charging Board With Protection Dual Functions Li-ion" if fed 5v independently they could charge each cell with its own source and sense mechanism. would that not alleviate any imbalance possibilities? im just a lowly technologist so i think in practical terms but it seems only logical to me. am i missing something?
<edit>

I'm glad it worked for you!

That's an interesting idea regarding charging each cell individually, although honestly it probably isn't practical.  At first thought I could picture having a micro-USB port on the side of the battery that powers an array of the TP4056 boards that each charge and monitor one cell. However, and admittedly I'm not very familiar with the TP4056 IC, I don't think that would work because each cell+charging IC would need to have it's ground isolated from all the other cell circuits. I bet the TP4056 electrically connects USB input ground to the cell negative terminal, so trying to operate multiple ICs would have the negative terminal of multiple cells shorted together...and since one cell's negative terminal is another cell's positive terminal... I fear the magic smoke would be released.

In theory you could maybe have MOSFETs that connect and disconnect the positive and negative inputs to each TP4056 IC, and then have some timer circuit that cycles through them so only one TP4056 is connected to the USB input at any given time, but that's all getting quite complicated. I guess if you are going to switch things like that, you'd might as well use a single TP4056 and then switch in the correct battery terminals.

The more realistic solution, barring me or someone else adding software support for balancing and then you just soldering on balancing resistors, would probably be to just get a 6-cell balancing board from Aliexpress for like $2 and connect that in place. Not nearly as fun of a solution to think about though! 

(Note: I haven't actually tested one of those balancing boards from Aliexpress so I can't guarantee there wouldn't be a voltage conflict or idle current draw issue with permanently installing one of those.)

[Joust]

i thought of that...
quick ohms test indicates that USB ground is NOT connected to cell charge negative.

ill run some testing on a simple two cell pack from something using to of the TP4056 boards i got in a pack of 10....
at the very least, they can be used to independently charge cells to get them closer to their peers....

my dyson pack is giving me 5 green flashes

[tinfever]

i thought of that...
quick ohms test indicates that USB ground is NOT connected to cell charge negative.

ill run some testing on a simple two cell pack from something using to of the TP4056 boards i got in a pack of 10....
at the very least, they can be used to independently charge cells to get them closer to their peers....

my dyson pack is giving me 5 green flashes

That would be really interested if they were isolated somehow. I can't see how they would do that though since my, admittedly weak, understanding is that you'd have to use a transformer or some sort of circuitry to boost the positive charge voltage 4.2V above the negative charge voltage. The TP4056 might be switching on the negative side though as part of it's protection circuitry, which means the USB ground and cell negative connection might not show as connected until it tries to charge a cell.

Regarding the 5 green flashes, assuming you are referring to the flashes that show after you release the trigger, that just tells you roughly how fully charged your battery pack is. 5 green flashes = min cell voltage between 3.8V and 4.0V If you want to check the balance level, watch the number of yellow flashes when you plug in the charger. Each yellow flash is 50mV of cell imbalance between the highest and lowest voltage cells. Since you said you used a bench power supply to charge each cell to 4.2V, your cells should be very well balanced. Assuming the cells are all in good condition, they may very well stay decently balanced for years.

[tinfever]

I just added a message to the GitHub and the original post here regarding a known issue with my FW I don't want anyone to be surprised by:

The BMS will go to sleep and put the ISL94208 to sleep after charging is complete. This may create a small but noticeable current draw on the cell connected to VBACK on the ISL94208. This means over the period of months, I think the cell connected to VBACK may slowly go out of balance compared to the other cells. This is not damage in any fashion, but since we can only charge the entire pack in series, any discharge of a specific cell will inevitably cause an imbalance. An imbalance can be fixed by manually charging the imbalanced cell back up to match the others. As a workaround for this issue, I'd recommend not leaving the battery connected to the charger 24/7. Again, no damage will occur, but one of the cells may be discharged slightly and need to be rebalanced. I'll fix this as soon as I can, no ETA though.

[Joust]

i guess i didnt RTFM....lol my bad
i'll have to make a charger to check imbalance since original is lost.

i powered up two of the TP4056 boards on two separate USB cables.
even though they measure megaohms when off , when powered the two seem to have solid voltage reference wrt one another. i did not connect ones + to the others - as i was confident that would release the magic smoke.

i'll dangle a multipin connector out to force balance when needed for now.
perhaps when you implement balancing i can change it. I'd be happy to work with you on this project but im no programmer. Im a old school technologist. i have surface mount rework setup.

I looked at aftermarket BMS boards with balance but as you said that would get the machine going but would be selling out
its fun to tinker. i've already spent 10x the effort and cost of a replacement battery but again, that is not fun at all.

[cunningfellow]

I just reflashed a Dyson V8 battery with this firmware (knowing the LEDs would be screwy)

However I just get 10 red flashes constantly which indicates "DISCHARGE_SC_FLAG".

Page 24 of the ISL94208 datasheet details how to recover from this condition.  I had a quick look at the code to see if that is implemented.  I could not see that is was.

Does anyone know if this condition is automatically reset?  Is my BMS board actually faulty and is constantly tripping the overcurrent condition even without anything plugged in?

Tnx

[tinfever]

I just reflashed a Dyson V8 battery with this firmware (knowing the LEDs would be screwy)

However I just get 10 red flashes constantly which indicates "DISCHARGE_SC_FLAG".

Page 24 of the ISL94208 datasheet details how to recover from this condition.  I had a quick look at the code to see if that is implemented.  I could not see that is was.

Does anyone know if this condition is automatically reset?  Is my BMS board actually faulty and is constantly tripping the overcurrent condition even without anything plugged in?

Tnx

A few questions and thoughts:

What was the initial reason you loaded the firmware? How was the battery operating on the original firmware?

Does charging work? If you let the battery go to sleep completely (LEDs off after 30 seconds idle), and then plug in the charger, do you get the same 10 blink error code? Does it occur immediately? Does the battery ever get to the idle state where the green (or equivalent on the V8) LED is solid, such as if you wait out the error code blinks?

Could you tell me what the PCB number of your BMS board is? There is more than one PCB for the V8 batteries (like all the models), so it is possible your PCB might be different that the one others have tested with.

If you are able to, it would be helpful if you could do the EEPROM dump and error decoding procedure as I show in the YouTube video, and post the results here. Then we can be 100% sure that is the specific error being tripped.

It is odd that you are getting a tripped SCP error, because I believe that limit is set so high as to be nearly impossible to reach. And also you don't have anything plugged in! haha. This is just some random unrelated thoughts: the next lowest SCP level is 100A IIRC but that was too low and would get tripped during normal vacuum startup. In my testing short circuiting the terminals of the battery and then pressing the button, I don't think I ever saw the short circuit current go above maybe 140A from what I remember. This is actually a problem because it means the SCP detection is useless and everything relies on the much longer timescale OCP protection. I think this is the reason that shorting the outputs actually tends to blow up the MOSFET, rather than have the protection kick in. Effectively the SCP current level of 175A for 190us is never reached, but the OCP limit of 50A for 2.5ms takes too long to be reached. Thus, 120A for 2.5ms is what the MOSFET may experience, and if your battery cells are in good shape, they'll push even more short circuit current, and then the MOSFET blows up. I just dug up some of my oscilloscope shots of the output terminals shorted while also measuring the voltage across the main FET. In one example, the FET experiences a Vds of 10V at a current of 125A for 2.13ms. Considering the SOA of the FET calls for a max of 90A for 1ms at 10V Vds, this is definitely outside the SOA.

Regarding recovering from the short circuit flag on the ISL94208, I think you might be referring to this sentence from the datasheet:
"The external microcontroller can turn on the FETs at any time to recover from this condition, but it would usually turn on the load monitor function first (by setting the LDMONEN bit) and monitor the LDFAIL bit to detect that the overcurrent condition has been removed."

The first thing the ERROR state in the firmware does is clear the FET control register turn off all of the MOSFETs, even if they are already off because of the SCP trip on the ISL94208. Also, since the status bits on the ISL94208 are automatically cleared when the register is read, and the main loop reads them each cycle, there is no need to clear them manually. Thus, no matter what happens during the error handling, the only action necessary to clear the fault is to try again. In effect, releasing the trigger and waiting for the error code to be shown three times, should bring the BMS back in to the IDLE state with a solid green LED, then pressing the trigger again will just try to enable the output again obviously. Nothing more is needed. Although, if you let the BMS go to sleep after 30s, on start up the ISL94208 is explicitly reset by the firmware so that should cover that base too.

You are correct that the load monitor function is not implemented. The reason for this is that the load of the vacuum is always present, and the BMS is what is used to switch power on and off to the vacuum when you pull the trigger. If LDMON were implemented, the only way to "remove" the load would be to physically remove the battery from the vacuum, since the vacuum has no other electrical disconnect.

[cunningfellow]

I had earlier yesterday rescued an  SV03 - PCB 188002 so I knew your firmware at least worked for that undocumented case

I was just hoping that the broken V8 one I had was just a software/firmware bricking not a hardware fault.

What was the initial reason you loaded the firmware? How was the battery operating on the original firmware?

On original firmware the vacuum would pulse on a tiny amount of time and then the battery would just flash red.  This ON pulse was much shorter than the length of time the motor would run/pulse on a normal blocked vacuum.

Hooking the motor terminals straight to a 6 cell pack and the motor starts and runs and does not draw excessive current.

On original firmware charging would work.  It would indicate full with all its blue LEDs.  Measuring the cells they all seem full and balanced.

Does charging work? If you let the battery go to sleep completely (LEDs off after 30 seconds idle), and then plug in the charger, do you get the same 10 blink error code? Does it occur immediately? Does the battery ever get to the idle state where the green (or equivalent on the V8) LED is solid, such as if you wait out the error code blinks?

No matter what I do.  Wait for the lights to stop flashing - then press the button.  Wait for the lights to stop flashing - then plug in the charger.  Have the pack out of the vacuum and magnet on reed switch - the depress the internal button.  It still just gives 10 red blinks.  No other LED action is ever present.

In fact as soon as the MPLAB ICD4 makes a relay click indicating that it has finished programming the red led flashing starts.

Could you tell me what the PCB number of your BMS board is? There is more than one PCB for the V8 batteries (like all the models), so it is possible your PCB might be different that the one others have tested with.

180207-01/04

If you are able to, it would be helpful if you could do the EEPROM dump and error decoding procedure as I show in the YouTube video, and post the results here. Then we can be 100% sure that is the specific error being tripped.

When I try run the parsing tool I get "ImportError: cannot import name _remove_dead_weakref"

I will attach the dump here.

It is odd that you are getting a tripped SCP error, because I believe that limit is set so high as to be nearly impossible to reach. And also you don't have anything plugged in! haha. This is just some random unrelated thoughts: the next lowest SCP level is 100A IIRC but that was too low and would get tripped during normal vacuum startup. In my testing short circuiting the terminals of the battery and then pressing the button, I don't think I ever saw the short circuit current go above maybe 140A from what I remember. This is actually a problem because it means the SCP detection is useless and everything relies on the much longer timescale OCP protection. I think this is the reason that shorting the outputs actually tends to blow up the MOSFET, rather than have the protection kick in. Effectively the SCP current level of 175A for 190us is never reached, but the OCP limit of 50A for 2.5ms takes too long to be reached. Thus, 120A for 2.5ms is what the MOSFET may experience, and if your battery cells are in good shape, they'll push even more short circuit current, and then the MOSFET blows up. I just dug up some of my oscilloscope shots of the output terminals shorted while also measuring the voltage across the main FET. In one example, the FET experiences a Vds of 10V at a current of 125A for 2.13ms. Considering the SOA of the FET calls for a max of 90A for 1ms at 10V Vds, this is definitely outside the SOA.

Regarding recovering from the short circuit flag on the ISL94208, I think you might be referring to this sentence from the datasheet:
"The external microcontroller can turn on the FETs at any time to recover from this condition, but it would usually turn on the load monitor function first (by setting the LDMONEN bit) and monitor the LDFAIL bit to detect that the overcurrent condition has been removed."

The first thing the ERROR state in the firmware does is clear the FET control register turn off all of the MOSFETs, even if they are already off because of the SCP trip on the ISL94208. Also, since the status bits on the ISL94208 are automatically cleared when the register is read, and the main loop reads them each cycle, there is no need to clear them manually. Thus, no matter what happens during the error handling, the only action necessary to clear the fault is to try again. In effect, releasing the trigger and waiting for the error code to be shown three times, should bring the BMS back in to the IDLE state with a solid green LED, then pressing the trigger again will just try to enable the output again obviously. Nothing more is needed. Although, if you let the BMS go to sleep after 30s, on start up the ISL94208 is explicitly reset by the firmware so that should cover that base too.

You are correct that the load monitor function is not implemented. The reason for this is that the load of the vacuum is always present, and the BMS is what is used to switch power on and off to the vacuum when you pull the trigger. If LDMON were implemented, the only way to "remove" the load would be to physically remove the battery from the vacuum, since the vacuum has no other electrical disconnect.

Yeah - I also thought it strange the SCP would be tripped even before plugging in the battery to vacuum motor/body.  Looks like it is time for a new pack from Dyson or maybe a new BMS off aliexpress.

[cunningfellow]

I noticed the format I had for the EEPROM dump was not the same in terms of whitespace - so here is a version that matches the sample ones