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

[tinfever]

  After much delay, I'm pleased to announce the release of:

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

GitHub Repo with much more documentation and info: https://github.com/tinfever/FU-Dyson-BMS

FU-Dyson-BMS firmware was developed from scratch to eliminate the "feature" in the factory Dyson firmware where the battery will permanently stop working if the cells ever go too far out of balance. It also provides several new LED codes so you can monitor the health of your battery pack.



Edit: Known issue you should be aware of:
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.

I don't want to have this post be a copy of all the info in the GitHub README but here is a little bit of info:

Revolutionary features:

• Cell balance LED indicator
• State of charge LED indicator
• Robust fault handling and logging
• Total runtime tracking
• Can be run in debug mode for near-real-time diagnostics
• Doesn't brick itself!
• Doesn't generate e-waste and try to take your money when your cells go out of balance!

Why you would want this:

• You want to vacuum your apartment but your cells became slightly out of balance because you left the vacuum off the charger for too long and now your vacuum doesn’t work (ask me how I know)
• You want to replace a bad cell in your battery pack
• You want to understand what your battery is doing and why.
• You don’t like feeling like a cash cow being squeezed for all you’re worth.

Compatible vacuums/batteries:

• Dyson V7 - Model SV11 - PCB 279857 - Compatible + Tested
• Dyson V6 - Model SV04/SV09 - PCB 61462 - Compatible + Tested
• Dyson V6 - Model SV04 - PCB 188002 - Compatible + Tested

Demonstration, disassembly, and programming guide:
Note: For the latest information, installation instructions, and any known bugs, please see the GitHub page: https://github.com/tinfever/FU-Dyson-BMS



And now a brief crusade against planned obsolescence:

Dyson vacuum batteries are designed to fail.

Here's why:

• Series battery cells in a battery pack inevitably become imbalanced. This is extremely common and why cell balancing was invented.
• Dyson uses a very nice ISL94208 battery management IC that includes cell balancing. It only requires 6 resistors that cost $0.00371 each, or 2.2 cents in total for six. 1
• Dyson did not install these resistors. (They even designed the V6 board, PCB 61462, to support them. They just left them out.)
• Rather than letting an unbalanced pack naturally result in lower usable capacity, when the cells go moderately (300mV) out of balance (by design, see step 3) Dyson programmed the battery to stop working...permanently. It will give you the 32 red blinks of death and will not charge or discharge again. It could not be fixed. Until now.

Credit:
DavidAlfa (Created I2C Library)
dvd4me (Helped with reverse engineering and provided continued support)


Please let me know if you have any questions or feedback! If you have a V6 or V7 vacuum battery, I'd really like to know if this works for you. 

[uer166]

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

Regarding:

Series battery cells in a battery pack inevitably become imbalanced. This is extremely common and why cell balancing was invented.

I wouldn't blanket-statement that, there have been as many, if not more packs killed by shitty balance BMSs, than packs that went out of balance in a system that doesn't implement it.
I'd rather have a well designed, safe, monitor-only BMS, with some high quality cells that would last a very long time (one example I came across are m365 10S scooter packs), than a badly designed balance BMS with same pack.

If you're doing a BMS design with full-on FMEA, it might be actually more reliable to not have balancing implemented at all, since by adding that you're creating a whole slew of single-component failures that would promptly kill a pack (FETs stuck short, drive failures, etc etc). It's all a balancing act (hehe), so just wanted to point that out. I've designed small BMS systems before, and actually regret implementing balancing on some of them in retrospect.

[uer166]

Doesn't generate e-waste and try to take your money when your cells go out of balance!

What does the firmware do exactly when they do go out of balance? Simply implement OV/UV protection only? Or do you expect to add those balance resistors and make a balance BMS out of it? I definitely see the utility in enabling cell replacement, but it's not clear how would the firmware fix the issue once the cells do go heavily out of balance.

[tinfever]

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

Regarding:

Series battery cells in a battery pack inevitably become imbalanced. This is extremely common and why cell balancing was invented.

I wouldn't blanket-statement that, there have been as many, if not more packs killed by shitty balance BMSs, than packs that went out of balance in a system that doesn't implement it.
I'd rather have a well designed, safe, monitor-only BMS, with some high quality cells that would last a very long time (one example I came across are m365 10S scooter packs), than a badly designed balance BMS with same pack.

If you're doing a BMS design with full-on FMEA, it might be actually more reliable to not have balancing implemented at all, since by adding that you're creating a whole slew of single-component failures that would promptly kill a pack (FETs stuck short, drive failures, etc etc). It's all a balancing act (hehe), so just wanted to point that out. I've designed small BMS systems before, and actually regret implementing balancing on some of them in retrospect.

You make a excellent point. I hadn't considered the additional failure modes cell balancing could bring, and I could see a scenario where perhaps in a previous generation Dyson implemented cell balancing, saw a high failure rate with it, and decided it would actually be more reliable to remove it. That would be a scenario where Dyson is not in-fact, the embodiment of pure evil. I will still maintain my opposition to them on the grounds that they didn't have to make the battery permanently stop working when the cells hit 300mV out of balance but were still within normal operating range. Although even that I could see as not being intentionally malicious.

Doesn't generate e-waste and try to take your money when your cells go out of balance!

What does the firmware do exactly when they do go out of balance? Simply implement OV/UV protection only? Or do you expect to add those balance resistors and make a balance BMS out of it? I definitely see the utility in enabling cell replacement, but it's not clear how would the firmware fix the issue once the cells do go heavily out of balance.

You are correct, OV/UV protection only. Charging stops when the max cell reaches 4.2V. Discharge is disabled when min cell reaches 3V. Thus when heavily out of balance, the pack would just have less usable capacity until manually rebalanced.

Unfortunately, and ironically, I haven't implemented cell balancing code because only one of the three PCB models I've worked on has the footprints for the balance resistors, and the other two models have the traces to the ISL94208 designed in such a way that the cell balance connections are shorted to the applicable cell measurement terminal so you'd have to cut those traces and add resistors somehow. They also used 1k resistors to the cells for the monitoring connections, which means you'd have a 1k resistor in your balance path causing very slow balancing unless you replaced that too. I'd initially planned on adding balancing until I saw they designed the board like this. The only thing I could do then was add a way for you to monitor the cell balance to determine when they need to be manually rebalanced.

While the cells could probably be very slowly balanced even with the 1k resistors in the balance path, and you could probably just put a direct short in place of the balance resistors because of that 1k, I'm also kind of burnt out on this project and I don't think very many people would go through that level of effort in hardware modding it.

A bit more background on these obstacles can be found here: https://www.eevblog.com/forum/reviews/dyson-v7-trigger-cordless-vacuum-teardown-of-battery-pack/msg3995477/#msg3995477

Given dvd4me in that same forum thread also figured out what EEPROM values to reset in the stock firmware to undo the permanent lockout, I'll admit this project doesn't actually provide a ton of extra utility.

[lern01]

Thank you very much for your hard work!!!
Can V8 use this firmware?

[suenbrad]

Thank you for your selfless sharing, just tried to get a V6 battery pack that has no flashing lights at all. Try to import the attachment FU-Dyson-BMS_V1.hex you provided. It's amazing that it can actually start flashing lights. At first I thought the protective plate was worn out for me. It turned out to be in a protected mode. Through your teaching, this battery has been resurrected. Let me balance its voltage and see if it can continue to be used normally. Because it has replaced the battery. If it can be used normally, I will report it to you, thank you.

The test results were very satisfactory. The battery is revived, the charging can also be charged normally, and the vacuum cleaner can also function normally.

[Marco]

If you're doing a BMS design with full-on FMEA, it might be actually more reliable to not have balancing implemented at all, since by adding that you're creating a whole slew of single-component failures that would promptly kill a pack (FETs stuck short, drive failures, etc etc).

If 4 200 mA FETs and level shifters in a switching power IC are a likely failure mode I fear for their process control. It's not like they burn any real power in the IC, it's all going into the resistors.

Any way, great work by tinfever, but this convinced me to keep buying Bosch.

[uer166]

If 4 200 mA FETs and level shifters in a switching power IC are a likely failure mode I fear for their process control. It's not like they burn any real power in the IC, it's all going into the resistors.

Well, in some cases it does matter. It's less about the process control, and more about random failures. Another thing to keep in mind is that by implementing balancing, you give the firmware full authority to permanently kill the pack. E.g. if it locks up, or there is a problem with the algo. If it's monitor-only it can be saved by say a reset, or a FW update, or not even have the bug in the first place since the code is more trivial with less dependencies.

If a balancing firmware discharges a cell bank to 0, there is no (safely) saving it anymore.

[tinfever]

I have found that the ISL94208 ICs seem to fail pretty frequently with the 3.3V regulator shorting to ground or otherwise failing to regulate. Now most of this is probably because I've been soldering on to live PCBs, probing things a bit too hard, and other means of abuse, but I did find it peculiar. I've had it stop working after soldering on programmer headers for the PIC, or after attempting to reordering broken I2C pull up resistors, etc. Usually soldering is involved. There was also the time I dropped a wire connected to one of the I2C traces on to the 24V battery output...neither the PIC or ISL survived that one haha.

Thinking about it now, I wonder how much of all it because even when the ISL94208 is asleep, there is still a little bit of active circuitry inside and when soldering I could be bringing it way over acceptable operating temp. Then again, soldering on the programming header is pretty far away and I saw a spark that time so I could have shorted something. I've also wondered if perhaps the battery pack is actually floating to a higher voltage and then when I touch the earthed soldering iron...ZAP? Probably meaningless but after that I started tying the battery 0V to earth GND before soldering when I didn't remove the PCB from the battery first.

Thank you very much for your hard work!!!
Can V8 use this firmware?

I'm not sure about V8 models. I just looked at some of the V8/SV10/PCB 180207 (I hate Dyson naming) photos posted dvd4me in the other thread (https://www.eevblog.com/forum/reviews/dyson-v7-trigger-cordless-vacuum-teardown-of-battery-pack/msg4035538/#msg4035538) as well as the schematics from someone else who reverse engineered that PCB (https://github.com/dr-mark-roberts/open-dyson-battery/blob/master/hw/docs/original_bms_v8_180207.svg). If you have that same PCB model, I think it should functionally work, however the LEDs will be nonsensical because the V6/V7 PCBs I've been working on have a single RGB LED, but on that PCB they replaced it with three blue LEDs and one red LED. It translates like this:

V7 LED color | V8 LED
Red              | Red
Green           | Blue LED 1
Blue             | Blue LED 3
n/a               | Blue LED 2

So other than the LEDs being bananas, I think it should work functionally but I can't guarantee it of course. The thermistor connections and pull-up resistor appear the same as the V7, and the trigger/charger detect circuitry also looks the same, so I don't see why it wouldn't work. Please report back if you decide to try it.

Thought experiment on how hard it would be to add LED support for the V8:
As tempting as it is for me to try to fix the LED codes for a V8, I think it would require some non-trivial modifications to my LED handling code, which is kind of a mess as it is. I'd have to figure out how to detect that specific PCB version (perhaps by reading pin B0 going to the additional Blue LED 2? No ADC on that pin though.) and then probably add a translation section to my Set_LED_RGB function that everything calls, or have everything that calls that function include alternate handling for this PCB. It also looks like it may not even be possible for me to PWM both RB0 (Blue LED 2) and RB3 (Blue LED 3) without doing something weird like rapidly switching between the two in software. All this is possible, and might not end up being terribly hard, but it's probably more than I want to do right now. Especially since I'm quite afraid of breaking something in the code now that I've got the monstrosity working.

Thank you for your selfless sharing, just tried to get a V6 battery pack that has no flashing lights at all. Try to import the attachment FU-Dyson-BMS_V1.hex you provided. It's amazing that it can actually start flashing lights. At first I thought the protective plate was worn out for me. It turned out to be in a protected mode. Through your teaching, this battery has been resurrected. Let me balance its voltage and see if it can continue to be used normally. Because it has replaced the battery. If it can be used normally, I will report it to you, thank you.

The test results were very satisfactory. The battery is revived, the charging can also be charged normally, and the vacuum cleaner can also function normally.

That's awesome!  I'm really glad to hear it worked for you! It's feels fantastic hearing someone other than me actually got some use out of it!

[kevinlo]

Thank you for your selfless sharing, just tried to get a V6 battery pack that has no flashing lights at all. Try to import the attachment FU-Dyson-BMS_V1.hex you provided. It's amazing that it can actually start flashing lights. At first I thought the protective plate was worn out for me. It turned out to be in a protected mode. Through your teaching, this battery has been resurrected. Let me balance its voltage and see if it can continue to be used normally. Because it has replaced the battery. If it can be used normally, I will report it to you, thank you.

The test results were very satisfactory. The battery is revived, the charging can also be charged normally, and the vacuum cleaner can also function normally.

Dear suenbrad , where can I download the Hex file ? I look into GITHub , can't find out the Hex file.

Thanks
Kevin Lo

[kevinlo]

I have found that the ISL94208 ICs seem to fail pretty frequently with the 3.3V regulator shorting to ground or otherwise failing to regulate. Now most of this is probably because I've been soldering on to live PCBs, probing things a bit too hard, and other means of abuse, but I did find it peculiar. I've had it stop working after soldering on programmer headers for the PIC, or after attempting to reordering broken I2C pull up resistors, etc. Usually soldering is involved. There was also the time I dropped a wire connected to one of the I2C traces on to the 24V battery output...neither the PIC or ISL survived that one haha.

Thinking about it now, I wonder how much of all it because even when the ISL94208 is asleep, there is still a little bit of active circuitry inside and when soldering I could be bringing it way over acceptable operating temp. Then again, soldering on the programming header is pretty far away and I saw a spark that time so I could have shorted something. I've also wondered if perhaps the battery pack is actually floating to a higher voltage and then when I touch the earthed soldering iron...ZAP? Probably meaningless but after that I started tying the battery 0V to earth GND before soldering when I didn't remove the PCB from the battery first.

Thank you very much for your hard work!!!
Can V8 use this firmware?

I'm not sure about V8 models. I just looked at some of the V8/SV10/PCB 180207 (I hate Dyson naming) photos posted dvd4me in the other thread ([url]https://www.eevblog.com/forum/reviews/dyson-v7-trigger-cordless-vacuum-teardown-of-battery-pack/msg4035538/#msg4035538[/url]) as well as the schematics from someone else who reverse engineered that PCB ([url]https://github.com/dr-mark-roberts/open-dyson-battery/blob/master/hw/docs/original_bms_v8_180207.svg[/url]). If you have that same PCB model, I think it should functionally work, however the LEDs will be nonsensical because the V6/V7 PCBs I've been working on have a single RGB LED, but on that PCB they replaced it with three blue LEDs and one red LED. It translates like this:

V7 LED color | V8 LED
Red              | Red
Green           | Blue LED 1
Blue             | Blue LED 3
n/a               | Blue LED 2

So other than the LEDs being bananas, I think it should work functionally but I can't guarantee it of course. The thermistor connections and pull-up resistor appear the same as the V7, and the trigger/charger detect circuitry also looks the same, so I don't see why it wouldn't work. Please report back if you decide to try it.

Thought experiment on how hard it would be to add LED support for the V8:
As tempting as it is for me to try to fix the LED codes for a V8, I think it would require some non-trivial modifications to my LED handling code, which is kind of a mess as it is. I'd have to figure out how to detect that specific PCB version (perhaps by reading pin B0 going to the additional Blue LED 2? No ADC on that pin though.) and then probably add a translation section to my Set_LED_RGB function that everything calls, or have everything that calls that function include alternate handling for this PCB. It also looks like it may not even be possible for me to PWM both RB0 (Blue LED 2) and RB3 (Blue LED 3) without doing something weird like rapidly switching between the two in software. All this is possible, and might not end up being terribly hard, but it's probably more than I want to do right now. Especially since I'm quite afraid of breaking something in the code now that I've got the monstrosity working.

Thank you for your selfless sharing, just tried to get a V6 battery pack that has no flashing lights at all. Try to import the attachment FU-Dyson-BMS_V1.hex you provided. It's amazing that it can actually start flashing lights. At first I thought the protective plate was worn out for me. It turned out to be in a protected mode. Through your teaching, this battery has been resurrected. Let me balance its voltage and see if it can continue to be used normally. Because it has replaced the battery. If it can be used normally, I will report it to you, thank you.

The test results were very satisfactory. The battery is revived, the charging can also be charged normally, and the vacuum cleaner can also function normally.

That's awesome!  I'm really glad to hear it worked for you! It's feels fantastic hearing someone other than me actually got some use out of it!

Dear tinfever ,

I have three V8 battery pack on hand. Those will flash 4 time red light then 2 time blue light.(I open one pack of faulty battery and measure 6 battery , 3.712/4.060/4.054/4.074/4.091/4.105) I also have one pack of V8 battery pack that is work normally.
So that I can start to test it.
I can read the EPPROM data via PICKIT3. What is your suggestion for testing ?
I think two direction.
1) Read normal pack EPPROM and Read faulty pack EPPROM and try to figure out which data will trigger the red light lock.
2) Flash your FU-DYSON-BMS firmware . By the way , where can I download the hex file ?

Thanks
Kevin Lo

[kevinlo]

I just test on Dyson V8 BMS (PCB Version - 1802070-01/04)
Problem : Flash Red Light 4 times then Blue Light 2 times
Solution : Replace the new battery then flash the EPPROM data from 58 to 00

On my next faulty V8 battery pack , will flash tinfever 's new firmware for test on V8

[suenbrad]

Explained in the video

[kevinlo]

Explained in the video

Get it. Thanks
I found a interesting symptoms.
I have three Red Light V8 battery pack.
I open those of it. Those have same symptoms : one of cell is out of balance.
And the out of balance 's cell , always happen at Cell 1 position.
Suppose out of balance should happen randomly , but why those three pack only happen on Cell 1 position(Near reed switch) ?

[zhoukevin]

This is determined by Dyson's charging mechanism. He has no trickle charging. At the same time, when the highest voltage in the system meets the requirements, he stops charging. Therefore, the voltage at cell1 is generally low, resulting in imbalance!

[lern01]

I brushed your firmware in V8 today, it is working normally now, but after the work, the third blue light shows a little longer time, it would be nice if the time is shorter.I will report to you if there is any problem in use.Thank you again for your selfless dedication! 

[tinfever]

Explained in the video

Get it. Thanks
I found a interesting symptoms.
I have three Red Light V8 battery pack.
I open those of it. Those have same symptoms : one of cell is out of balance.
And the out of balance 's cell , always happen at Cell 1 position.
Suppose out of balance should happen randomly , but why those three pack only happen on Cell 1 position(Near reed switch) ?

I just looked in to this and I think I found a bug in the way my firmware interacts with the ISL94208 by sleeping after charging is complete. This will cause ~200uA current draw from cell 1 when the battery is connected to the charger, charging is complete, and then the firmware puts the ISL94208 to sleep while still connected to the charger. Overtime this bug will cause cell 1 to become imbalanced.

I was about to go on another rampage about this being the reason the battery packs are going out of balance in the first place, but I'm not sure this is actually an issue with the original firmware. I need to do more testing, but I'm almost certainly going to need to release an update for my firmware.

The issue:

The ISL94208 has a VBACK pin that connects to Cell 1 and is used for powering the logic in the ISL94208 while it is asleep. It should only draw a max of 3uA though while asleep. Looking at the discharge curve for a similar cell (https://lygte-info.dk/review/batteries2012/LG%2018650%20HD4%202100mAh%20(Orange)%20UK.html) I think we could estimate a 500mAh capacity discharge would drop a cell from 4.2V to 3.9V. 500mAh / 3uA = 166667 hours, or about 19 years. So back of the envelope calculations indicate it shouldn't be an issue. However, there are scenarios where more current can be pulled from VBACK when the WKUP pin is held high but the ISL94208 is asleep.



At first I didn't think that last sentence would be an issue. Then I realized, what happens when the vacuum is plugged in to the charger? The charger enables Q1 which pulls WKUP high (to roughly 17V). Then the ISL94208 wakes up, powers up the PIC, then the vacuum charges as normal until it is fully charged. Then the key thing happens: the PIC puts the ISL94208 to sleep while WKUP is still pulled high (because the PIC can't physically unplug the charger). Oops.

Now you have a VBACK power consumption of 200-250uA. 500mAh/200uA = 2500 hours. That doesn't sound so bad until you realize the vacuum will probably spend 99.9% of its life connected to the charger, fully charged and asleep...with no balancing circuitry to counteract this. 2500 hours = 104 days. OH DEAR.



A picture is worth a thousand words.


(This shows the current flowing from cell 1 in to the BMS board. Does not show any charger/discharge current that flows through the main terminals. I inserted a multimeter inline with the Cell 1 sense connection.)

Again, I'm not sure this is an issue with the original firmware but I'm currently thinking I'll release an update with the following changes:

• Have PIC go in to sleep mode after charging is complete but leave ISL94208 turned on. Then use the unplugging of the charger to trigger an interrupt-on-change in the PIC to wake it up.
• Reduce idle to sleep wait time from 30 seconds to 5 seconds at lern01's suggestion. There is really no reason the pack needs to be idle for so long before going to sleep.

Note: in the past when I've said "sleep" I've meant the PIC tells the ISL94208 to go to sleep, which then causes the 3.3V rail to be turned off, which totally removes power from the PIC. In the future there will probably be "PIC sleep" and "Total sleep", with total sleep being what I just described and what I've been using so far.

Explained in the video

Get it. Thanks
I found a interesting symptoms.
I have three Red Light V8 battery pack.
I open those of it. Those have same symptoms : one of cell is out of balance.
And the out of balance 's cell , always happen at Cell 1 position.
Suppose out of balance should happen randomly , but why those three pack only happen on Cell 1 position(Near reed switch) ?

I'm glad you found the hex file. It sounds like you also found how to edit the EEPROM data of the stock firmware to unlock the battery pack. This is the safer solution because you can backup the original EEPROM data before making any changes, and then restore it later if needed. As much as I'd love to see everyone using my firmware, unfortunately flashing new firmware is irreversible since the original firmware is code protected.

You previously mentioned you had cell voltages of  3.712/4.060/4.054/4.074/4.091/4.105.
4.105V - 3.712V = 393mV min-max cell difference, which is absolutely enough to cause the original firmware to lock up. I estimate anything over 300mV is at risk the original firmware locking you out. As you already figured out, the safest route would be to charge the low cell up to 4.15V, let it settle down to probably 4.1V, backup the EEPROM data, and then make the EEPROM data edits you already found or the edits dvd4me found in the other thread if they are different (https://www.eevblog.com/forum/reviews/dyson-v7-trigger-cordless-vacuum-teardown-of-battery-pack/msg4028665/#msg4028665).

I brushed your firmware in V8 today, it is working normally now, but after the work, the third blue light shows a little longer time, it would be nice if the time is shorter.I will report to you if there is any problem in use.Thank you again for your selfless dedication! 

Thanks for the feedback! I'm guessing the third blue light is the one that is normally green on a V7 battery, so you are probably seeing the 30 second idle delay before the ISL puts everything to sleep. Reducing this is a reasonable suggestion since it really doesn't matter much so I'll probably include that in a future update.

[uer166]

I was about to go on another rampage about this being the reason the battery packs are going out of balance in the first place, but I'm not sure this is actually an issue with the original firmware. I need to do more testing, but I'm almost certainly going to need to release an update for my firmware.

That would be a massive whoopsie indeed, if it was there in the original FW. In a monitor-only BMS keeping the energy use across cells:

• Exactly equal
• Low

Would be top priority.. That's also one of the reasons I don't 100% like those all-in-one BMS ICs. Sometimes it's easier to cobble up a resistor network that loads and measures all the cells equally, than read 100 pages of datasheet only to realize there is some edge case somewhere.

[Bartman1001]

Hello, I appreciate your effort tinfever and other collaborators. Thank you all very much.

I got an 32 red light flash on my V6 (battery label SV09, BMS board version is 188002). I opened battery and manually charged each cell to 4.2V. Then I flashed your custom FW successfully. It worked. But when I try to run with fully charged V6 at Max setting, after 2-3 min later I get an 3 Blue flash as low battery. After a couple min later I tried to run again, and about 1 min alter I get an 3 blue led flash again. But when I try to charge V6 in station, 1 blue, 1 Yellow (unbalance cell I mean) and after those 8 red flash. That mean charging over current. I wait  a minute to try again but every time I got an same 8 red flash. Is this normal. Or a bug on FW. Maybe 2.5ms is too short to read over current situation.

[Kris0725pl]

Regards from Poland I got information about this project and purchase Pickit3 programator. I have 9 dead dyson v6 battery...and now i got fully working 3 dyson PCB! two is pcb 61462 and one is 188002 Im very chappy. Thank you very much for hard work! Kris...

Video on youtube from PCB 188002

[Bartman1001]

Hello, I appreciate your effort tinfever and other collaborators. Thank you all very much.

I got an 32 red light flash on my V6 (battery label SV09, BMS board version is 188002). I opened battery and manually charged each cell to 4.2V. Then I flashed your custom FW successfully. It worked. But when I try to run with fully charged V6 at Max setting, after 2-3 min later I get an 3 Blue flash as low battery. After a couple min later I tried to run again, and about 1 min alter I get an 3 blue led flash again. But when I try to charge V6 in station, 1 blue, 1 Yellow (unbalance cell I mean) and after those 8 red flash. That mean charging over current. I wait  a minute to try again but every time I got an same 8 red flash. Is this normal. Or a bug on FW. Maybe 2.5ms is too short to read over current situation.

I solved 8 Red flash issue. I added series resistor to charge port for reducing charge current. When I add 1.2ohm resistor it solved charge over current error. When I measured charge current, I get a max 800mA. Not even Close to 1.4A limit. So I ,ncrease to sense time from 2.5ms to 5ms in isl94208.c file (tinfever firmware). It solved now.

[dvd4me]

I'm glad you found how to edit the EEPROM data of the stock firmware to unlock the battery pack. This is the safer solution because you can backup the original EEPROM data before making any changes, and then restore it later if needed. As much as I'd love to see everyone using my firmware, unfortunately flashing new firmware is irreversible since the original firmware is code protected.

I know you worked so hard to come out with your release and you want people to try-it but also it's nice to make people aware of their choices, since we do not have a copy of the original FW. It seems to be quite a job to keep users happy and fix the bugs for different Dyson pcb implementation. As an example, for the SV10 which has 3 blue led level gauge it may need some tweaking.
I find time consuming to support people, even for just editing, some they erased their PIc load ( lucky they have you now) , now I dedicate my time to other projects like the restoring of the compatible PS3 Fat, bringing them from dead to "Evilnat" is quite interesting, without any "reflow " needed.
Cheers

[lern01]

Are you interested in V10?

BMS:BQ7693003   MCU: ATSAMD20E15A

I read the manual for bq769X0, When battery voltage imbalance occurs, the OV bit of SYS_STAT is written to the internal EEProm,reset SYS_STAT for internal EEProm is not enough（The status register bits are cleared by writing 1 to the set bit.  To clear all bits, write 0xFF to register 0x00）,the AFE requires control by the host to recover the system from the fault.  The host must turn on the FET controls after appropriate recovery delay or conditions.
https://www.ti.com/lit/ds/symlink/bq76940.pdf?ts=1654291412418&ref_url=https%253A%252F%252Fwww.google.com%252F
https://www.ti.com/lit/ug/sluub41a/sluub41a.pdf?ts=1654244422766

I also tried to replace the new BQ7693003, disconnect the microswitch and put it into the battery case(I also doubt whether there is a mistake in the steps of loading the battery box, just disconnect the microswitch is not enough). But the light is still red, indicating that FET needs to be opened by MCU.

Don't know how to make the MCU turn on the FET.

[tinfever]

Just as a brief update, I haven't abandoned this project and I'm still committed to making a few bug fixes to the firmware. I'm currently working through a different project and I'll loop back and work on this again, and reply to everyone, once that is completed, probably within a few weeks. Thanks for your patience.

[suenbrad]

Thank you for your efforts and waiting patiently for your good news

Just as a brief update, I haven't abandoned this project and I'm still committed to making a few bug fixes to the firmware. I'm currently working through a different project and I'll loop back and work on this again, and reply to everyone, once that is completed, probably within a few weeks. Thanks for your patience.

[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

[tinfever]

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

Thanks for the info. I'm glad you were able to get some more life out of the 188002 you rescued! 

I'm not sure why the python script didn't work when you tried it, but it might be a python install issue on your machine? Anyways, I took a look at your EEPROM data. The formatting was different than I've seen before so I took the opportunity to improve my script so it can now handle either of the EEPROM data dump formats you provided. I hope you don't mind that I also included your two EEPROM dumps in the GitHub repo as test examples for the EEPROM-parsing-script, just so I have examples of all the different EEPROM data dump formats the parser supports.

Here is the parsed EEPROM data for your BMS:

Code: [Select]

{
    "Firmware": "Tinfever FU-Dyson-BMS V1",
    "Total_Runtime_Seconds": 0.0,
    "Faults": [
        {
            "index": 0,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "None",
            "timestamp": 0.0
        },
        {
            "index": 1,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "None",
            "timestamp": 0.0
        },
        {
            "index": 2,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "Trigger",
            "timestamp": 0.0
        },
        {
            "index": 3,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "None",
            "timestamp": 0.0
        },
        {
            "index": 4,
            "error_meaning": [
                "DISCHARGE_SC_FLAG"
            ],
            "detect_mode": "Trigger",
            "timestamp": 0.0
        }
    ]
}
It looks exactly as you'd described. The output has never worked at all, hence the timestamp is always zero, and the DISCHARGE_SC_FLAG is being tripped both when the trigger is pulled, and just when the vacuum awake for any other reason (as shown in the detect_mode field).

Someone on GitHub has success with a PCB 180207 just like yours so I suspect there isn't a hardware difference at play here.

I'm thinking a hardware fault is most likely, unfortunately. It's interesting to hear that the original firmware was at least charging and very briefly enabling the output. I wonder if the original firmware isn't quite as obsessive as mine in checking for faults, and maybe they only check the ISL fault flags (and the output short circuit flag specifically) after enabling the output when the trigger is pulled, whereas my firmware just checks them all repeatedly no matter what.

If you wanted to, you could try disabling the short circuit protection to see if that gets it up and running again. It's not exactly the safest thing to do, but I am curious. In theory there is still the fuse so it might not catch fire if there is a fault with SCP disabled. In the firmware I also have the PIC manually read the discharge current shunt using the ADC and implemented a 30A current limit in software, so that function will still be active just as a last resort.

It's unclear whether it is just the SCP function that is damaged on the ISL, or if it will be everything relying on the DSENSE (discharge current sense) terminal on the ISL94208. It's possible that normal OCP is also broken but we haven't noticed yet because SCP trips first.

(Note: the following should be considered dangerous and increases the chance of fires and such. Please don't sue me.)

To disable SCP, you'd need to disable the ISL94208 function that automatically turns off the MOSFETs independently, and also disable the firmware function that checks if the SCP flag is tripped.

For the first part, I'd change line 35 in the isl94208.c file to "ISL_Write_Register(DischargeSet, 0b00010100);" This should disable the ISL automatic control of the discharge FET.

Then find line 782 in main.c that contains "ISL_Read_Register(Status);". Add a new line below it and insert "ISL_RegData[Status] &= 0b11111011;" This should effectively hide any SCP flags on the ISL from the firmware.

Then compile and download to the BMS.

If you start getting ISL OCP fault code 9, do the above steps but using "ISL_Write_Register(DischargeSet, 0b10010100);" and "ISL_RegData[Status] &= 0b11111001;" respectively. This will disable the ISL OCP functionality as well.

[cunningfellow]

I would say it is shagged.  I probed around the board and looked for obvious faults but none jumped out at me.

The vacuum cleaner is my mothers not mine, so I don't feel comfortable disabling any safety features.

Will just order a replacement battery.  Maybe from Lanplus as they claim to have aftermarket ones with with VTC6 cells.  Much preferable to giving any more money to Dyson.

Here are some shots of the PCB if that is of use for your documentation.

[Terry Bites]

Double FU Dyson- the traitor and double traitor.

[robca]

Thought experiment on how hard it would be to add LED support for the V8:
As tempting as it is for me to try to fix the LED codes for a V8, I think it would require some non-trivial modifications to my LED handling code, which is kind of a mess as it is. I'd have to figure out how to detect that specific PCB version (perhaps by reading pin B0 going to the additional Blue LED 2? No ADC on that pin though.) and then probably add a translation section to my Set_LED_RGB function that everything calls, or have everything that calls that function include alternate handling for this PCB. It also looks like it may not even be possible for me to PWM both RB0 (Blue LED 2) and RB3 (Blue LED 3) without doing something weird like rapidly switching between the two in software. All this is possible, and might not end up being terribly hard, but it's probably more than I want to do right now. Especially since I'm quite afraid of breaking something in the code now that I've got the monstrosity working.

Just wondering if having a build switch for V6/V7 and V8 would help. After all, for someone flashing a battery, would not be hard to choose the right hex file. I mean, runtime detection is a nice thing to have, but it's not like the battery type will change at runtime

If flashing both RB0 and RB3 LEDs is not possible, just flashing one is more than enough. Having a separate code path for the LED flashing for V6/V7 and V8 seems a low risk change and would add value

If there is any interest, once I get a V8 pack to experiment with I might submit a PR. But if you are not interested in the approach, no point in doing it

Did you ever have time to fix the first cell discharge issue? Not asking for a fix, just a status update. I discovered your project only now and plan to use it

[tinfever]

Thought experiment on how hard it would be to add LED support for the V8:
As tempting as it is for me to try to fix the LED codes for a V8, I think it would require some non-trivial modifications to my LED handling code, which is kind of a mess as it is. I'd have to figure out how to detect that specific PCB version (perhaps by reading pin B0 going to the additional Blue LED 2? No ADC on that pin though.) and then probably add a translation section to my Set_LED_RGB function that everything calls, or have everything that calls that function include alternate handling for this PCB. It also looks like it may not even be possible for me to PWM both RB0 (Blue LED 2) and RB3 (Blue LED 3) without doing something weird like rapidly switching between the two in software. All this is possible, and might not end up being terribly hard, but it's probably more than I want to do right now. Especially since I'm quite afraid of breaking something in the code now that I've got the monstrosity working.

Just wondering if having a build switch for V6/V7 and V8 would help. After all, for someone flashing a battery, would not be hard to choose the right hex file. I mean, runtime detection is a nice thing to have, but it's not like the battery type will change at runtime

If flashing both RB0 and RB3 LEDs is not possible, just flashing one is more than enough. Having a separate code path for the LED flashing for V6/V7 and V8 seems a low risk change and would add value

If there is any interest, once I get a V8 pack to experiment with I might submit a PR. But if you are not interested in the approach, no point in doing it

Did you ever have time to fix the first cell discharge issue? Not asking for a fix, just a status update. I discovered your project only now and plan to use it

I was kind of trying to avoid having multiple different firmware builds for different models, mostly just because it sounded like a hassle when releasing updates. Given that there have been no updates, that concern was probably a bit overblown. You're right that something like a #define wouldn't be a big deal and having two different hex files would also be fine.

If you're interested in adding LED support for the V8 model, by all means. I'd be happy to consider any pull requests.  The LED code is probably the most stupidly convoluted part of the code though, so I'm pretty concerned about not breaking what is currently (barely?) working.

I think the easiest way to do it might be to re-implement the existing LED.c functions in a way that the rest of the code can be left completely unmodified. Then the existing V7 LED functions could be included in a #ifdef, and the same for any V8 LED function re-implementations. That would be essentially zero risk for the V7 build, that definitely works at the very least.

Regarding the first cell discharge issue, I haven't fixed that yet. I still feel bad about leaving it like that but I try to focus on one project at a time, and that isn't it unfortunately.

[robca]

I think the easiest way to do it might be to re-implement the existing LED.c functions in a way that the rest of the code can be left completely unmodified. Then the existing V7 LED functions could be included in a #ifdef, and the same for any V8 LED function re-implementations. That would be essentially zero risk for the V7 build, that definitely works at the very least.

Yes, that was my idea (I had a quick look at your code). Implement changes only in LED.c, possibly using the RGB value to determine what to do with the V8 blue LEDs. No changes required to the rest of the code

Regarding the first cell discharge issue, I haven't fixed that yet. I still feel bad about leaving it like that but I try to focus on one project at a time, and that isn't it unfortunately.

Thanks for the update on the cell discharge, I understand about competing priorities out of curiosity, what would the code fix look like? (high level description). You say "BMS will go to sleep and put the ISL94208 to sleep after charging is complete.". What would the alternative to putting the ISL94208 to sleep be? I looked at the graph of the code states, but I'm not sure I understand what other state the ILS94208 could be in

[tinfever]

I think the easiest way to do it might be to re-implement the existing LED.c functions in a way that the rest of the code can be left completely unmodified. Then the existing V7 LED functions could be included in a #ifdef, and the same for any V8 LED function re-implementations. That would be essentially zero risk for the V7 build, that definitely works at the very least.

Yes, that was my idea (I had a quick look at your code). Implement changes only in LED.c, possibly using the RGB value to determine what to do with the V8 blue LEDs. No changes required to the rest of the code

Regarding the first cell discharge issue, I haven't fixed that yet. I still feel bad about leaving it like that but I try to focus on one project at a time, and that isn't it unfortunately.

Thanks for the update on the cell discharge, I understand about competing priorities out of curiosity, what would the code fix look like? (high level description). You say "BMS will go to sleep and put the ISL94208 to sleep after charging is complete.". What would the alternative to putting the ISL94208 to sleep be? I looked at the graph of the code states, but I'm not sure I understand what other state the ILS94208 could be in

IIRC, the WKUP pin on the ISL94208 is pulled high while the trigger is pulled or the charger is connected. The issue is that if the ISL94208 is put to sleep (which removes the VCC power from the PIC) while the WKUP pin is still pulled high (like currently happens when charging is complete but the charger is obviously still plugged in), then ~200uA can be drawn from the cell providing the VBACK pin. This may imbalance cell 1 after a period of months on the charger. The solution is to not put the ISL94208 to sleep when charging is complete.

Note: There is already a #define flag to disable sleeping when charge is complete, for other reasons I can't recall. However, then the PIC stays in the IDLE state and the current draw of the LED + PIC is enough that the battery will slowly discharge, hit the threshold, start charging again, and repeat. Thus, the battery cells would be cycled (and worn) slowly but constantly while just sitting on the charger, which isn't ideal obviously.

So, I think the solution is to leave the ISL94208 awake, have the PIC turn off the LEDs and go in to (PIC) sleep power mode, and then use the interrupt-on-change function of the PIC to wake it back up again when the charger is unplugged. Since I have serious trust issues, I'd probably just have the PIC do a full reset on wakeup so everything is definitely in a known state. Care may need to be taken with the existing watchdog timer setup which has some interactions with the sleep power mode from my brief skim of the PIC datasheet. After all of this, I'd ideally like to measure the current draw on all of the cells while the PIC is sleeping to make sure the battery pack can stay on the charger effectively indefinitely without any cell slowly draining. If the cells are draining with the PIC asleep, there would be nothing to wake up the PIC and have it enable the charger again.

There is a bit more info on this in a previous post, but you may have already seen this: https://www.eevblog.com/forum/projects/fu-dyson-bms-an-(unofficial)-firmware-upgrade-for-dyson-v6v7-vacuum-bms/msg4185037/#msg4185037

[robca]

Thanks again for the pointer to the description of the slow battery drain issue.

I read thru the thread, but somehow I didn't pay enough attention to that specific message, which I'm saving now for the future (once I understand the circuit and code better)

You've done an amazing job, thanks for your time and sharing it in an open source format

[rulof]

hello. I'm quite new to this. please tell me how can I make the temperature error reset when the charger is connected? as in the original firmware, after cooling, it starts charging itself.

[tinfever]

hello. I'm quite new to this. please tell me how can I make the temperature error reset when the charger is connected? as in the original firmware, after cooling, it starts charging itself.

The reason I implemented it that way, if I recall correctly, was that I didn't want it to be possible for an error to occur without the user knowing. If somehow there was an error that self corrected while the battery was on the charger, it would just resume charging and the user would never know.

Of course, I do understand where you are coming from. If you are using the battery hard, it might be within the safe discharge temperature limits, but too hot for the charging temperature limits, so if you immediately place it on the charger, you'll get that error.

I suppose an ideal solution would be to handle that case by allowing the battery to stay in the charging state, but not actually enable charging until the temperature has cooled down, and show the user a flashing yellow light or something. Possibly with a timeout of an hour or two so it isn't possible for the battery to stay in that state forever until the cells are depleted.

For now, here is a workaround:

If you replace line 641 in main.c, which is currently:

Code: [Select]

&& ((detect == NONE) || (full_discharge_trigger_error && detect == CHARGER))
with this instead:

Code: [Select]

&& detect != TRIGGER
that should allow the BMS to exit the error state while still on the charger. Of course, it will immediately go to the idle state, then the charging state, detect the temp as still being too high, and then go back in to the error state. It will do this loop for as long as the temp is too high for charging. However, once the temp is okay, it should start charging. I haven't tested any of this though.

I've attached a compiled .hex with this change if you want to try it. Again, I haven't done any testing so use it at your own risk.

If this doesn't take care of the issue, I'll need a lot more info about what you are doing when the error occurs, the exact error code, the reason you initially installed the firmware, etc.

[KalleMp]

Safety first.

I am glad the Fabulous-Universal-Dyson firmware upgrade is safety conscious.

Should it work too well it may attract attention and be GIVEN a bad reputation.

Call for Stopping Use of Battery Packs Manufactured by Shenzhen Ollop Technology Co., Ltd. Found in Rechargeable Vacuum Cleaners in Online Shopping Malls
https://www.meti.go.jp/english/press/2019/0809_001.html

[tinfever]

Fabulous-Universal-Dyson firmware upgrade

  I like that

[rulof]

Thank you so much. I will check how it will work and write the result.

Initially I have a V7, blinked red 32 times.
I charged each battery and flashed your firmware. Started working normally, running at a maximum of 4 minutes.

[rulof]

Checked, it works.  After cooling down, it starts charging itself, but it can again show an error in temperature, and so on a couple of times.
Of course, it would be ideal to add a timer after detecting a temperature error. about 40 minutes.
But you can use it like that.

[tinfever]

Thinking about it a bit, I wonder if the reason your pack is getting so hot is because the cells have aged and the ESR has increased in them. That might explain why you are the first person to run in to this. It would also tie in what you said about the battery running for about 4 minutes, probably either because the aged cells have reduced capacity, or just because the temperature limit is being hit due to high ESR.

[rulof]

Thinking about it a bit, I wonder if the reason your pack is getting so hot is because the cells have aged and the ESR has increased in them. That might explain why you are the first person to run in to this. It would also tie in what you said about the battery running for about 4 minutes, probably either because the aged cells have reduced capacity, or just because the temperature limit is being hit due to high ESR.

I totally agree.
But it works on the minimum mode for 26 minutes. This is more than enough.
I will change the voltage and temperature a little, I want to test how it will work.

[rulof]

Hello, I appreciate your effort tinfever and other collaborators. Thank you all very much.

I got an 32 red light flash on my V6 (battery label SV09, BMS board version is 188002). I opened battery and manually charged each cell to 4.2V. Then I flashed your custom FW successfully. It worked. But when I try to run with fully charged V6 at Max setting, after 2-3 min later I get an 3 Blue flash as low battery. After a couple min later I tried to run again, and about 1 min alter I get an 3 blue led flash again. But when I try to charge V6 in station, 1 blue, 1 Yellow (unbalance cell I mean) and after those 8 red flash. That mean charging over current. I wait  a minute to try again but every time I got an same 8 red flash. Is this normal. Or a bug on FW. Maybe 2.5ms is too short to read over current situation.

I solved 8 Red flash issue. I added series resistor to charge port for reducing charge current. When I add 1.2ohm resistor it solved charge over current error. When I measured charge current, I get a max 800mA. Not even Close to 1.4A limit. So I ,ncrease to sense time from 2.5ms to 5ms in isl94208.c file (tinfever firmware). It solved now.

Tell me more. I'm reading the firmware, but I can't figure out how to change the value by 5 m s?

[rulof]

Do I understand correctly?

to solve error 8, you need to change line 44

ISL_Write_Register(Set of chargers, 0b01001100);

in the isl94208.c file ?

[vidhome]

Hello Teenfever!
Thank you for the excellent work on the BMS Dyson firmware!
I have a 61462 SV03 board (it says so on the box). Worked fine, decided to check the balancing of the elements, opened and did not notice how damaged (shifted) resistor R27, then the Dyson firmware blocked and began to blink red 32 times. Changing the errors in the EEPROM did not give anything. I flashed your firmware, the LEDs are working, green blinks 6 times, blue, when the button is pressed, the voltage on the contacts is there.
The unbalance of the elements is 900 mv (18 times yellow), when installed on charging, green lights up immediately.
When I connect the vacuum cleaner and pull the trigger, I get 16 red blinks.
ISL_Write_Register(Discharge Set, 0b00010100);
ISL_RegData[Status] &= 0b11111011; - I tried your recommendations did not help!
EEPROM dump in the application.
Decryption
{
"Firmware": "Tinfever FU-Dyson-BMS V1",
"Total_Runtime_Seconds": 6.048,
"Faults": [
{
"index": 0,
"error_meaning": [
"ISL_BROWN_OUT"
],
"detect_mode": "Trigger",
"timestamp": 6.048
}
]
}
It is clear that this is ISL_BROWN_OUT.

Is this the verdict of ISL94208? Or is there hope?

[rulof]

Hello Teenfever!
Thank you for the excellent work on the BMS Dyson firmware!
I have a 61462 SV03 board (it says so on the box). Worked fine, decided to check the balancing of the elements, opened and did not notice how damaged (shifted) resistor R27, then the Dyson firmware blocked and began to blink red 32 times. Changing the errors in the EEPROM did not give anything. I flashed your firmware, the LEDs are working, green blinks 6 times, blue, when the button is pressed, the voltage on the contacts is there.
The unbalance of the elements is 900 mv (18 times yellow), when installed on charging, green lights up immediately.
When I connect the vacuum cleaner and pull the trigger, I get 16 red blinks.
ISL_Write_Register(Discharge Set, 0b00010100);
ISL_RegData[Status] &= 0b11111011; - I tried your recommendations did not help!
EEPROM dump in the application.
Decryption
{
"Firmware": "Tinfever FU-Dyson-BMS V1",
"Total_Runtime_Seconds": 6.048,
"Faults": [
{
"index": 0,
"error_meaning": [
"ISL_BROWN_OUT"
],
"detect_mode": "Trigger",
"timestamp": 6.048
}
]
}
It is clear that this is ISL_BROWN_OUT.

Is this the verdict of ISL94208? Or is there hope?

and each cell was charged separately?

[vidhome]

Yes, I recharged them a little

[erguro1973]

Hi! 

First of all my deep congratulations for all of the hard job that you did here, specially tinfever 

I know it's a little "off-topic"  but I post here because I think it could be interesting,  yesterday I opened a old DC35 battery, It´s also a 6 x 18650 battery but with a different BMS MCU

- Part number at battery case 17083-22 12
- Part number at BMS board   17522 01-05

I can confirm that the MCU in this BMS board is the ATTINY44-20MU 20-QFN-EP
After reading datasheet I connected my USBasp pogrammer to:

Pin 16  MOSI
Pin 20  MISO
Pin 13  RSET
Pin 1     SCK
Pin 8    GND
Pin 9     VCC (+5V)



I succesfully downloaded Flash + Eeprom but I don´t have enough knowledge in dissassembly these files to do something interesting as tinfever did

If someone it´s interested I can upload here

Best regards

[Momy]

Yes, I recharged them a little

Hi,

Same problem (SV03 battery).

[nikifena]

Hi guys. I missed somehow this topic, but I'm going to share with you my experience with those Dyson batteries. Mine was V6 if I'm not wrong.
I had Dyson vacuum cleaner with a bad battery, and then I brought a replacement. Soon I realized that the problem is with the firmware. It detects unbalanced batteries and stop working. Then it writes the error in the PIC internal eeprom. So, I connected the working battery to the pickit3 and lucky enough, the eeprom portion of the firmware was unprotected. I simply downloaded it and uploaded ONLY it to a non-working battery. Then the non-working just starts working.
I found that the eeprom is updated regularly after turning on/off cycles. Unfortunately, you know, the battery dies when the balancing is away from the original specs... A good solution of course was to change all cells.

Anyway, here is a working Eeprom. Keep in mind that you MUST program only the EEPROM part and skip the main code from programming!

[tamtamsh]

My Dyson V6 got a red flash error. It flashed 10 times red light. I detached the battery from the vacuum, it flashed blue and green which means the PCB was not locked. So I thought the motor had some errors, I bought a 2nd hand motor, it didn't work either. I have no way out, so I burned the author's firmware. It looks look, but we when I attached the battery to vacuum and pressed the trigger, it got 16 flashes of red light, the machine didn't work either. 16 red light means there is hard short circuit. I don't know how to get it resovled. Please give me your expertise advice. Thanks.

[rulof]

My Dyson V6 got a red flash error. It flashed 10 times red light. I detached the battery from the vacuum, it flashed blue and green which means the PCB was not locked. So I thought the motor had some errors, I bought a 2nd hand motor, it didn't work either. I have no way out, so I burned the author's firmware. It looks look, but we when I attached the battery to vacuum and pressed the trigger, it got 16 flashes of red light, the machine didn't work either. 16 red light means there is hard short circuit. I don't know how to get it resovled. Please give me your expertise advice. Thanks.

this is a strong voltage drop on one or more batteries. it is necessary to charge each separately. if it doesn't help, change the batteries.

[tamtamsh]

many thanks. Got it!

[tamtamsh]

I recharged my battery cells one by one, and got them at 4.1v. it works if I release the trigger and plug it to the vacuum immediately (when the light is blue). But if I plug the battery to the vacuum first, and then release the trigger, it got 16 red lights. What is wrong? Pls advise. Thanks a lot.

[rulof]

I recharged my battery cells one by one, and got them at 4.1v. it works if I release the trigger and plug it to the vacuum immediately (when the light is blue). But if I plug the battery to the vacuum first, and then release the trigger, it got 16 red lights. What is wrong? Pls advise. Thanks a lot.

severe battery wear.  when turned on, the voltage drops, the protection is triggered. you need to change the batteries. one person had a bad contact on one of the batteries, because of this an error occurred.

[tamtamsh]

many thanks. Is there a way to remove this protection in firmware?

[rulof]

many thanks. Is there a way to remove this protection in firmware?

it is possible to reduce the trip voltage. for example, up to 2.5 volts or less. but this is just for verification.

[berk]

DC35 or dc34 firmware send me

[bluesight]

I think I have this problem. I did your firmware update. Unfortunately, I may have done a short when fiddling the switch near the exposed posts. Firmware update successful with all blink/color codes working. Charge codes working. When in vacuum and pulling the trigger, I get the 16 red blink "brownout" code. Tested vacuum motor with external supply and it works. Did attach VDD at PIC program time. So multiple opportunities to glitch the ISL94208. If that's the problem, this post seems to indicate that the ISL can be reset (or not). I see in your code that you provide a reset segment...?

void ISL_Init(void){
    ISL_SetSpecificBits((uint8_t[]){WriteEnable, 5, 3}, 0b111);    //Set all three feature set, charge set, and discharge set write bits
    ISL_SetSpecificBits(ISL.FORCE_POR, 1);                          //Make sure the ISL is clean reset

So, is this the problem, and is it permanent or fixable?
Tnx!

For future reference, the dedicated forum thread would be the best place for questions like this: https://www.eevblog.com/forum/projects/fu-dyson-bms-an-(unofficial)-firmware-upgrade-for-dyson-v6v7-vacuum-bms/

If the battery is able to charge properly, I think the ISL94208 is working okay. I don't recall precisely what checks I run using the ISL94208 but I suspect at least one of them would fail if it wasn't operating. The PIC wouldn't run at all without the 3.3V from the ISL, and the ISL handles the multiplexing of all of the battery cell voltages so unless it got stuck reporting an identical valid result for every cell, the cell voltage checks wouldn't pass at all. Also, I just looked at the code again, the only way charging would work properly is if the ISL brown out check function passed, which would only work if the ISL is responding to I2C commands properly.

Please also check if the battery LEDs act normally if you press the button with the battery out of the vacuum with no load attached.

If that works fine, I suspect your battery cells have too high of an ESR and the load of the vacuum might be causing the cell voltage to drop enough to brown out the ISL. This is what rulof and I were discussing. I don't know what equipment you have but you could try to measure the battery ESR either with a battery tester, or by applying a known load and measuring the voltage drop. You could also try to measure the voltage drop on the VBACK pin of the ISL94208 during vacuum startup with an oscilloscope and see how far that voltage is dropping.

My current theory is that it is the inrush current of the vacuum triggering these errors on batteries with high cell ESR, but at least some batteries might be able to sustain the normal running current if we could ride through the inrush-caused-voltage-drop.

Moving over to this thread...
It looks like, indeed, the full set of 6 cells may be near-dead. They charge ok and read ~4.15 volts (individually fully charged...on a Hyperion EOS0606i RC charger/discharger). And my simple test was to run the vacuum head directly off the 6-cell series. That seemed to work fine for a 10 or so second test run. But when I now apply 1A load through the discharger, the drop is to about 3.95 volts. If my calculations are right...maybe 200 milli-ohm resistance.(?) Seems about 4X higher than it should be.(?) While ~24V might be enough to run the vacuum, maybe it is low enough for the ISL94208 to declare a brownout.(?) So, after all the fiddling, I may have to declare my pack defunct. Great learning experience...not a spectacular outcome...Oh well...

Thanks for the quick and useful response! Very nice work from you and the community...

A few personal practices...I shaved down the top and bottom tabs and shaved off the side tabs once I got the pack apart. Same for the "stalk" tabs. Made it less onerous to go in again. Also shaved down the "light pipe" sides (kind of to a point) for the same reason (instead of cutting in a slot). 

[bluesight]

OK...Just can't let it go...So, I found the drops on my light clip leads at 1A amounted to maybe .1V each (.2V total), bringing my internal resistance per cell to maybe 140 milli-ohms. Still nasty. Then I decided to connect with those leads from the pack (external) to the vacuum and "push the button" (on the pack). Voila, the vacuum worked! Voltage at the pack was ~23V. With the pack in the vacuum, still 16 red blinks (brownout). Final test, connect externally with heavy clip leads...NO GO...16 blinks.

What I think it means...? The brown out voltage/whatever setting for the ISL94208 is right at the edge for my pack. And maybe it is appropriately set conservatively. BUT...if there was a simple place (couple eeprom bytes preferably) to modify (lower) the brownout set point, it may be possible to run a marginal pack for a little bit longer. Just askin'...

[tinfever]

OK...Just can't let it go...So, I found the drops on my light clip leads at 1A amounted to maybe .1V each (.2V total), bringing my internal resistance per cell to maybe 140 milli-ohms. Still nasty. Then I decided to connect with those leads from the pack (external) to the vacuum and "push the button" (on the pack). Voila, the vacuum worked! Voltage at the pack was ~23V. With the pack in the vacuum, still 16 red blinks (brownout). Final test, connect externally with heavy clip leads...NO GO...16 blinks.

What I think it means...? The brown out voltage/whatever setting for the ISL94208 is right at the edge for my pack. And maybe it is appropriately set conservatively. BUT...if there was a simple place (couple eeprom bytes preferably) to modify (lower) the brownout set point, it may be possible to run a marginal pack for a little bit longer. Just askin'...

That's really interesting that it works with smaller test leads but not with heavier leads.

By the way, the brown out level isn't actually a setting, that error is tripped when the firmware notices the ISL94208 has reset itself without any other errors. Precisely when and why the ISL resets itself is still up for debate but it definitely isn't configurable.

My current theory is that on marginal cells, the inrush current of the vacuum causes the VBACK voltage of the ISL94208 to go too low and so the ISL resets itself. The inrush current of the vacuum can be up to 120A on startup for maybe 100us (I have scope shots somewhere but can't find them), but then in normal mode it might only draw 4A which should be fine.

If you have an oscilloscope, it would be really interesting to see the voltage drop on the VBACK pin during start up (relative to the negative terminal of the pack). The ISL94208 datasheet actually show a capacitor on that pin but that isn't implemented on the BMS boards.

I have attached an image with the measurement point off of R48 (next to the ISL chip) marked in blue, assuming you have a V7 battery.

[bluesight]

That's really interesting that it works with smaller test leads but not with heavier leads.

By the way, the brown out level isn't actually a setting, that error is tripped when the firmware notices the ISL94208 has reset itself without any other errors. Precisely when and why the ISL resets itself is still up for debate but it definitely isn't configurable.

My current theory is that on marginal cells, the inrush current of the vacuum causes the VBACK voltage of the ISL94208 to go too low and so the ISL resets itself. The inrush current of the vacuum can be up to 120A on startup for maybe 100us (I have scope shots somewhere but can't find them), but then in normal mode it might only draw 4A which should be fine.

If you have an oscilloscope, it would be really interesting to see the voltage drop on the VBACK pin during start up (relative to the negative terminal of the pack). The ISL94208 datasheet actually show a capacitor on that pin but that isn't implemented on the BMS boards.

I have attached an image with the measurement point off of R48 (next to the ISL chip) marked in blue, assuming you have a V7 battery.

I'm not actually "at home" with all my other tech stuff to do any sophisticated testing (meter and clunky clip leads here). I expect the light/long leads are presenting an approximately 100 milliohm resistance to the typical/full 120A startup current. So a lower current load to the batteries is seen at the board and higher instantaneous startup battery voltage...just enough to not set off the reset.(?) I think I'm probably done with attempting to resurrect this pack. Next step (if any) would be battery replacement. At least it is likely the board is in good shape with the new firmware.

[tinfever]

That's really interesting that it works with smaller test leads but not with heavier leads.

By the way, the brown out level isn't actually a setting, that error is tripped when the firmware notices the ISL94208 has reset itself without any other errors. Precisely when and why the ISL resets itself is still up for debate but it definitely isn't configurable.

My current theory is that on marginal cells, the inrush current of the vacuum causes the VBACK voltage of the ISL94208 to go too low and so the ISL resets itself. The inrush current of the vacuum can be up to 120A on startup for maybe 100us (I have scope shots somewhere but can't find them), but then in normal mode it might only draw 4A which should be fine.

If you have an oscilloscope, it would be really interesting to see the voltage drop on the VBACK pin during start up (relative to the negative terminal of the pack). The ISL94208 datasheet actually show a capacitor on that pin but that isn't implemented on the BMS boards.

I have attached an image with the measurement point off of R48 (next to the ISL chip) marked in blue, assuming you have a V7 battery.

I'm not actually "at home" with all my other tech stuff to do any sophisticated testing (meter and clunky clip leads here). I expect the light/long leads are presenting an approximately 100 milliohm resistance to the typical/full 120A startup current. So a lower current load to the batteries is seen at the board and higher instantaneous startup battery voltage...just enough to not set off the reset.(?) I think I'm probably done with attempting to resurrect this pack. Next step (if any) would be battery replacement. At least it is likely the board is in good shape with the new firmware.

Oops. I forgot to actually add my thoughts on why it works with the thinner leads. I wonder if it is the inductance! The inductance would slow down the inrush current spike so it wouldn't go as high. It looks like the thin leads are longer and had a larger loop area (positive and negative wires were further apart) so they would have more inductance.

[bluesight]

Oops. I forgot to actually add my thoughts on why it works with the thinner leads. I wonder if it is the inductance! The inductance would slow down the inrush current spike so it wouldn't go as high. It looks like the thin leads are longer and had a larger loop area (positive and negative wires were further apart) so they would have more inductance.

You mention that the datasheet recommends/shows use of a capacitor for the ISL chip. Have you tested, or is there a way/place to solder in, a capacitor to see if that helps? Again, I should stop fiddling with this...but...

[tinfever]

Oops. I forgot to actually add my thoughts on why it works with the thinner leads. I wonder if it is the inductance! The inductance would slow down the inrush current spike so it wouldn't go as high. It looks like the thin leads are longer and had a larger loop area (positive and negative wires were further apart) so they would have more inductance.

You mention that the datasheet recommends/shows use of a capacitor for the ISL chip. Have you tested, or is there a way/place to solder in, a capacitor to see if that helps? Again, I should stop fiddling with this...but...

No, I haven't tested it. I wish I had time to work on this project more but I don't.

Pin 16 on the ISL chip is ground so it'd probably be possible to connect a SMD cap off of R48 and then a small jumper wire to pin 16, or do a through hole cap between R48 and Pin 16 of the ISL, or do a through hole cap between R48 and the grounded pin of D3.

[bluesight]

It looks like the idea would be to solder in a 10uf, 16V tantalum ("flat") cap between the "top" of R48 and the chip ground bus (misc spots). I don't have a cap, and it's about $10 to get like 10 (Amazon). So, not the next thing on my list. Anyone with some caps lying around that might be willing to try it? Or send me single cap?

[tinfever]

It looks like the idea would be to solder in a 10uf, 16V tantalum ("flat") cap between the "top" of R48 and the chip ground bus (misc spots). I don't have a cap, and it's about $10 to get like 10 (Amazon). So, not the next thing on my list. Anyone with some caps lying around that might be willing to try it? Or send me single cap?

If you want to PM me your address, I can put some caps in an envelope and mail them to you, probably on Tuesday. Not sure how well ceramic caps will survive USPS in a normal envelope but we can try haha

[bluesight]

There might be a trick to route the "hot" (from P2) end of R48 to the 2nd battery's plus pad (P3). That would keep the voltage on VBACK higher (or burn it out maybe). I'm thinking about it...but I'm not sure I'm ready to try it.

[tinfever]

There might be a trick to route the "hot" (from P2) end of R48 to the 2nd battery's plus pad (P3). That would keep the voltage on VBACK higher (or burn it out maybe). I'm thinking about it...but I'm not sure I'm ready to try it.

The max voltage on the VBACK pin is 5V (See ISL94208 datasheet pg. 6 for max ratings). I wouldn't recommend that. Also, wouldn't that just directly short cell 2? Make sure you are looking at the schematics if you aren't already. They are in the FU-Dyson-BMS\hardware-info of the GitHub repo linked in the original post.

[bluesight]

There might be a trick to route the "hot" (from P2) end of R48 to the 2nd battery's plus pad (P3). That would keep the voltage on VBACK higher (or burn it out maybe). I'm thinking about it...but I'm not sure I'm ready to try it.

The max voltage on the VBACK pin is 5V (See ISL94208 datasheet pg. 6 for max ratings). I wouldn't recommend that. Also, wouldn't that just directly short cell 2? Make sure you are looking at the schematics if you aren't already. They are in the FU-Dyson-BMS\hardware-info of the GitHub repo linked in the original post.

From your GitHub diagram (and from the datasheet circuit), if the P2 side of R48 is popped, it is floating to VBACK, so no shorts. What I'd hope is that the 1K resistor will "protect" the VBACK input from the floating 8+V, but that is the risk. Safer would be to put in another resistor (maybe 1.8K to ground) to voltage divide, but that's a hassle and another part I don't have. And it still might drop too much. I see a couple caps (C3 and C4) on the VBACK "pin" in the schematic. My V6 board doesn't even have the pads to install them. I expect these were supposed to be the "filter" caps, as you previously mentioned. Hard to stop tilting at windmills....

[bluesight]

Well...for my "burn-it-up" test, connecting R48 to the ~8V line (P3) didn't (burn-it-up). But it also DIDN"T WORK. I get the 16 red flash brownout code. So it looks like VBACK wants to stay in range (3 to 5V?), and connecting back to P2 (~4V) continues to function. Grounding R48 also didn't work (stayed asleep, I assume). Final attempt will need to be the 10uF cap...someday...maybe...

[Slin75]

Bonjour monsieur, j'ai réussi à flashé le bms (228499) avec le tutoriel sur github (FU-Dyson-BMS), la led réagi correctement. Les cellules son correctement équilibré et la tension au bonne.
Le seule problème que je rencontre, quand j'utilise l'aspirateur en mode boost la batterie tiens que 10 secondes, l'aspirateur s'arrête.
Je le remets a changé tout est correct et je réessaye toujours pareil.
Pouvez vous m'aider je débute dans la programmation.
Cordialement.

[bluesight]

Longish story, but I wasn't able to test the capacitor-on-R48 theory. That leads to the rest of the story. So just yesterday morning, I decided to order a junk battery from Amazon. Then, later in the day, cleaning out the garage, I found a defunct scooter 36 cell battery pack...it was working, but  something went wrong with the electronics (the BMS). The batteries are bone fide CHY18650 2500mah Lipos and seemed to have good charge/discharge properties. I decided to scavenge 6 of them and do a full rebuild of the Dyson pack. After various bits of chopping nickel strips and slicing my fingers, I got the batteries out and in, and then needed to reconnect the R48 resistor back to the 4.2V power tab (P2). Well, it didn't work. I thought the surface mount resistors were kinda robust, but not against my clunker soldering iron. R48 opened. My last chance bit of luck was to find an old-fashioned 220ohm 1/4w resistor in some old potted electronics board. After chiseling it out and tack soldering it in (replacing R48), the pack actually worked (that is one robust resistor).

The refurbed pack did a 15 minute run, which seems pretty good. The board reprogramming is great, letting me know all is well at charge and at low battery discharge. Stayed pretty cool (maybe 100 deg at the end of the run). I think it's good!

Now I need to deal with the extra junk battery I ordered. Very cheap ($23 with 2 filters...maybe $14 after accounting for not needing to buy 2 filters). We'll see.

What I can't tell is if the install of the 220ohm resistor (vs the original 1K) might have solved the power-up sleep problem without the need for the capacitor filter. I'm not prepared to do additional research at this time...

Thanks for this thread, and especially to tinfever for the help and advice.

[tinfever]

Longish story, but I wasn't able to test the capacitor-on-R48 theory. That leads to the rest of the story. So just yesterday morning, I decided to order a junk battery from Amazon. Then, later in the day, cleaning out the garage, I found a defunct scooter 36 cell battery pack...it was working, but  something went wrong with the electronics (the BMS). The batteries are bone fide CHY18650 2500mah Lipos and seemed to have good charge/discharge properties. I decided to scavenge 6 of them and do a full rebuild of the Dyson pack. After various bits of chopping nickel strips and slicing my fingers, I got the batteries out and in, and then needed to reconnect the R48 resistor back to the 4.2V power tab (P2). Well, it didn't work. I thought the surface mount resistors were kinda robust, but not against my clunker soldering iron. R48 opened. My last chance bit of luck was to find an old-fashioned 220ohm 1/4w resistor in some old potted electronics board. After chiseling it out and tack soldering it in (replacing R48), the pack actually worked (that is one robust resistor).

The refurbed pack did a 15 minute run, which seems pretty good. The board reprogramming is great, letting me know all is well at charge and at low battery discharge. Stayed pretty cool (maybe 100 deg at the end of the run). I think it's good!

Now I need to deal with the extra junk battery I ordered. Very cheap ($23 with 2 filters...maybe $14 after accounting for not needing to buy 2 filters). We'll see.

What I can't tell is if the install of the 220ohm resistor (vs the original 1K) might have solved the power-up sleep problem without the need for the capacitor filter. I'm not prepared to do additional research at this time...

Thanks for this thread, and especially to tinfever for the help and advice.

If it worked after replacing all the cells and also changing that resistor, it was probably changing the cells that fixed it, and then the resistor value just doesn't matter much. Glad to hear you have it working though!

[duzycinek]

Hey, anyone have knowledge how to reset bms for dyson v10?

[davidmpye]

Hi!

Having been inspired by tinfever's work on this series of battery pack, I've started a project to do a similar replacement firmware for the v10 battery pack series.

I shall create a separate thread, because this one is to celebrate their work, not mine.   But assuming nobody minds, I'll post a link to my github project here:

https://github.com/davidmpye/V10_Dyson_BMS/

TL;DR - mostly done now, does work. Main downside - need to figure out a better way of flashing it that doesnt need the Atmel-ICE programmer.  If anyone fancies coming up with a way to get a Pi to do it with OpenOCD then we'd be on to a winner....

David

[duzycinek]

Great news, waiting for flashing method since got no Atmel-Ice

[tinfever]

Hi!

Having been inspired by tinfever's work on this series of battery pack, I've started a project to do a similar replacement firmware for the v10 battery pack series.

I shall create a separate thread, because this one is to celebrate their work, not mine.   But assuming nobody minds, I'll post a link to my github project here:

https://github.com/davidmpye/V10_Dyson_BMS/

TL;DR - mostly done now, does work. Main downside - need to figure out a better way of flashing it that doesnt need the Atmel-ICE programmer.  If anyone fancies coming up with a way to get a Pi to do it with OpenOCD then we'd be on to a winner....

David

That's awesome!

It looks like the PICkit 4 supports the ATSAMD20E15 so that would probably work too and maybe be a little cheaper?

[rulof]

Hi!

Having been inspired by tinfever's work on this series of battery pack, I've started a project to do a similar replacement firmware for the v10 battery pack series.

I shall create a separate thread, because this one is to celebrate their work, not mine.   But assuming nobody minds, I'll post a link to my github project here:

https://github.com/davidmpye/V10_Dyson_BMS/

TL;DR - mostly done now, does work. Main downside - need to figure out a better way of flashing it that doesnt need the Atmel-ICE programmer.  If anyone fancies coming up with a way to get a Pi to do it with OpenOCD then we'd be on to a winner....

David

That's awesome!

It looks like the PICkit 4 supports the ATSAMD20E15 so that would probably work too and maybe be a little cheaper?

Great news!!! I have a J-link.  he's definitely sewing.
I am ready to help in any way I can. I have serviceable and faulty batteries.

[davidmpye]

Hi tinfever,

Quite possibly - anything that supports SWD should be able to do it (though I'm not sure exactly what devices Microchip studio will talk to).

Good news though - I've proved that it *CAN* be done with a Raspberry Pi and its' GPIO pins and OpenOCD, so hopefully can produce a turnkey solution (eg SD card image) that should allow a Pi to unlock and reflash the pack without an more specialised equipment :-)

I'll create a separate EEVblog thread for it once I've finished the documentation - probably about a month til I'm ready 

David

[davidmpye]

I hope nobody minds, but to keep threads separate, I've posted a V10 thread for discussion/work on my V10 firmware :-)

It is here: https://www.eevblog.com/forum/projects/replacement-firmware-for-dyson-v10-batteries/

Best wishes,

David

[NeilP]

Following and will try as soon as my PICKit arrives

[mrjoda]

Hello, glad that I found this thread - Im trying to save my Dyson.

I have V8. It stopped working - dead battery after 5y of use.

I took it apart and one cell vas 3,8V instead of 4,2V. Ok then lets change the cell. MF! Dyson use some 20700 cells 3000mAh 10C (as far I could find info),

I had some new Sony VCT6 18650 cell so I soldered it as a replacement of the 20700 with little bit of 3M tape help. Dirty job but whatever.

However... It does not work suprisingly. The same problem. After 1 minute runtime indicator shows a flat battery. It seems to charge it somehow.

Im not sure how to continue.

I will try to replace the firmware in BMS. Its unusable so I can not brick it more    

[NeilP]

One of my boards here is a 188002, I think from a V6.  SV03

Picket 3 arrived and done what appears to be successful flash of Firmware of the V1 hex from may 2022..from GitHub. 

OK, so i did not follow instructions and balance the pack..I was too keen to see if i could make the thing flash, plus my balance kit is down the other workshop no in my living room

Do no believe this pack has a reed switch for a magnet..but maybe a Solid State device?  If so where on the board is it?  I simply ask because, the only reference to a solid blue I can find ..WHEN THE PACK IS NOT ON CHARGE is on the second page of this thread.

So i got the three colour lights to show it has your firmware.

Plug in to charger and get what appears to be a white flash followed by 8 yellow...the Balance indicator  for 50mV per flash.
So yet need to balance..


BUT ...once disconnected from charger and from the machine ...the Blue LED stays on ..constantly ..have left it 5 minutes now and it is still on


Cannot see any test telling me what SOLID BLUE when not connected means.  I have waved a few different old HDD magnets around the board with sheet of paper over the top to preventshoerign and no change in solid blue.



Yes, I'll balance the pack later and try charging again ..jsut thought i'd post this question now whilst I have moment.


Thank you

[NeilP]

AH ..the switch ..needs to be pressed!  I had it loose from the housing, so it was acting as if the grey plunger was permanently pushed.

Did basic balance with a light bulb  only 6 yellow flashes  now then blue charge light...seems to be all good now..jsut get it balanced

When pressed and release..4 green flashes, then constant green for a few seconds then it goes off. 

Got the Battery Medic balancing the pack now.

[tinfever]

However... It does not work suprisingly. The same problem. After 1 minute runtime indicator shows a flat battery. It seems to charge it somehow.   

After it shows the low voltage (flat battery) warning, I would see which cell is low voltage. One of them has to have hit the cutout, either due to lower capacity or higher ESR x vacuum current draw. Also, Since the cells in series in the battery pack, replacing one cell with the smaller 18650 might cause balance issues.

AH ..the switch ..needs to be pressed!  I had it loose from the housing, so it was acting as if the grey plunger was permanently pushed.

I'm glad you got it working. There is a magnetic reed switch on the SV11 batteries for V7 vacuums, but not for that PCB you have. If you look at the git repo, you can see it as a long black rectangle part in the photo attached.

[gold oxide]

Just put your firmware on a friend's V6 SV3 battery along with new cells. Works great.

[Lubiezny_kran]

First i want to say Hi as this is my first post.
I want ot thank u all for helping me to resurecte my battery pac.
 I curious if u herd of som one reverse engenering motor controlers for this vacs specificli for V8, as i got a heng of one and want to make fume extractor of of it.
And main cuestion is speed controll as this bastards ar plenty laud for that aplication, and i want ot taim them down.
 Sory for the gramar tho

[tinfever]

First i want to say Hi as this is my first post.
I want ot thank u all for helping me to resurecte my battery pac.
 I curious if u herd of som one reverse engenering motor controlers for this vacs specificli for V8, as i got a heng of one and want to make fume extractor of of it.
And main cuestion is speed controll as this bastards ar plenty laud for that aplication, and i want ot taim them down.
 Sory for the gramar tho

Sorry, I haven't heard of anyone reverse engineering the motor controller.

[zapta]

Looks like Dyson batteries are a common pain point. Another approach are adapters for standard tools batteries such as Dewalt and others.

[Lubiezny_kran]

The draw back i the fact id dos not fully discharge them.  Power tools bateries are 5 cell comonly and dyson one is 6 cels in series.  MOtor operating voltage is 25.2- 16.2v. And comon discharge cut off is 15v

[robca]

I have a Kobalt 24V tool set, and the Kobalt batteries are 6 elements. I got a cheap adapter off Amazon for Kobalt, and it works really well. Pretty sure Kobalt is available only in North America, though (Lowe's brand)

The 4000 mAh Kobalt battery is $70 and high quality. roughly half the price of the Dyson (which is 2800 mAh only). Kobalt also offers 2000 and 6000 mAh batteries. The best part is that if you have two Kobalt batteries, you can chare one while you use the other one.

Instead of a cheap Chinese Dyson replacement battery with unknown cells, the Kobalt is a much better option (esp if you can find the Kobalt charger used for cheap)

Right now Lowes has a deal with 2 4000mAh batteries and the charger for slightly more than a Dyson battery https://www.lowes.com/pd/Kobalt-KOB-24V-2-4-0AH-BATT-110W-CHRGR/1003139096

[sukiyakh]

你好 在这里学习了很多知识 也看见了很多文章 但是我是没看明白 我有pickit3.5 他是需要hex文件的固件 没看见这个固件在哪 我的是dyson v8 sv10

[tinfever]

你好 在这里学习了很多知识 也看见了很多文章 但是我是没看明白 我有pickit3.5 他是需要hex文件的固件 没看见这个固件在哪 我的是dyson v8 sv10

Translated via Google Translate:
Hello, I learned a lot of knowledge here and saw a lot of articles, but I didn’t understand it. I have pickit3.5, which requires hex file firmware. I didn’t see where this firmware is. Mine is dyson v8 sv10.

The hex file is located in the Releases section of the GitHub page, here: https://github.com/tinfever/FU-Dyson-BMS/releases

[PaWill68]

Dear tinfever.
dear sukiyaki asked for firmware for v8 sv10, your project for V6/7
I'm sorry for the stupid question. And how to compile HEX from the provided sources?

[tinfever]

Dear tinfever.
dear sukiyaki asked for firmware for v8 sv10, your project for V6/7
I'm sorry for the stupid question. And how to compile HEX from the provided sources?

Good point. Others have reported that the released hex file for V6/V7 will work on a V8 SV10 but the LED codes will be different or nonsensical.

If you want to compile the hex from source, you will need to download Microchip MPLABx and open the project. I think you can then just compile without extra configuration needed.

[PaWill68]

Thanks for the reply. I have already compiled in Ubuntu. But the file size was 40 KB, everything works, but the diodes are a complete mess.
I also tried to create an open-dyson-battery project. It is compiled without errors, but the size of the HEX file is 4 kbytes. After the firmware, the battery shows no signs of life.

[tinfever]

Thanks for the reply. I have already compiled in Ubuntu. But the file size was 40 KB, everything works, but the diodes are a complete mess.
I also tried to create an open-dyson-battery project. It is compiled without errors, but the size of the HEX file is 4 kbytes. After the firmware, the battery shows no signs of life.

40.5KB is correct. That is the size of my published version. This is due to the encoding. Intel .hex file is not a raw binary. You can open it in a normal text editor so I think it is ASCII encoded inside. I'm not sure what you mean about the diodes.

By the way, you shouldn't need to compile it yourself unless you want to make changes or are doing it out of curiosity.

[PaWill68]

the LED codes will be different or nonsensical.

Sorry, when I said diodes, I meant LED.
Can you explain to me why it is not possible to compile a working HEX from the project https://github.com/tinfever/open-dyson-battery

[tinfever]

the LED codes will be different or nonsensical.

Sorry, when I said diodes, I meant LED.
Can you explain to me why it is not possible to compile a working HEX from the project https://github.com/tinfever/open-dyson-battery

Ah, I understand now. That open-dyson-battery project is just an unchanged git fork I made of someone else's project. I can't remember why I forked it but I never did anything with it. You should ignore that.

[sukiyakh]

Thank you. Thank you very much for your help. I saw the file you sent. Thank you very much.

[m0nst9ra]

Hello tinfever! Thank you for helping ordinary people bring old Dyson batteries back to life. Such a question, my Dyson battery was blocked, but after disassembly it became clear that the cells were still in fairly good condition, and apparently the battery was blocked due to imbalance.
I flashed the PIC with your firmware, charged the battery, now the voltages of all cells vary in the range of 4.15-4.25V. But I ran into a problem..
The PIC does not allow startup and flashes blue 3 times, indicating that the battery is low. This is at any battery charge level.
What have I tried:
1. Replaced ISL, no changes
2. I checked all the voltages coming to the CELL terminals (ISL) 25-20.7-16.55-12.38-8.24-4.10+VBACK.
3. Checked the entire ISL binding.

--There is an interesting feature, when charging is connected, it flashes 82 times in red + blue, telling us that there is an imbalance of min-max, 82*50mV = 4.25V, so it does not see the voltage of any of the cells? I connected the oscilloscope to the AO ISL-PIC line, based on the oscillogram and firmware, no problem is visible. Maybe you have a guess what the problem is. Thank you very much!