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.