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
{
"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
}
]
}
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.
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 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.
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 codeRegarding 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
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.
&& ((detect == NONE) || (full_discharge_trigger_error && detect == CHARGER))
&& detect != TRIGGER
Fabulous-Universal-Dyson firmware upgrade
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.
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.
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?
Yes, I recharged them a little