I just remembered that the reason I had to use the heat gun was because I mounted the chip backwards and plugged it in. Not sure why I didn’t think that would fry some of the ports. That’s probably what happened. I’ll toss it and try a new chip.
edit: Replace 841 chip and got same reset issue. So I tried a brand new board and new chip, also same odd reset behavior. Thinking I perhaps messed up build env, I reprogrammed the 1st one and it seems to still be working correctly. Blue double-blink w/ short red (bypass?) blink.
Could I have some bad boards from JLCPCB? They all program/verify fine, they just don’t run correctly without resetting.
edit: I plugged in failing board and now after the 8sec, the red light kinda of flutters/blinks but board doesn’t reset… like it’s stuck in a loop somewhere/perhaps interrupts.
edit: For clarification, all these tests are plugged into the USBASP programmer board, not hooked up to battery or serial at all.
Pretty sure these are actually trying to balance the USB programmer at 5v and causing voltage drop and reset. I’ll hook these to an actual LifePO battery and see how they act. I can’t do much more until my JST pins/wires arrive and hook them to the controller.
So, I’ve confirmed the problem was ‘watching’ the unit when connected to the USB programmer. The flickering red light was the unit going into temp bypass. If it’s wasn’t in temp bypass yet, the voltage caused a reboot. My current problem appears that units immediately try to balance, both when hooked to a programmer or connected by themselves to a controller.
At this point, there doesn’t seem to be a way to reprogram the chips now, since it immediately causes boot loops. Also, connected by itself to a real battery and controller, it quickly tries to balance and drops comms. I’ll try to get two setup, perhaps they will stop trying to balance.
What voltage is it trying to balance to when running in isolation?
I don’t even have enough time to fix the voltage reference chip or lower the bypass… ugg…
I may need to try the R2 fix above for the comms issue.
I think the problem was JLCPCB was out of the reference voltage chip so I swapped it out with another part as somebody else said it worked above. Actually, I just checked and my programmer has a jumper for 3.3 but was on 5v. Swapping that back over to 3.3v fixed the programming problem.
So, now I don’t know why it starts dumping when connected to my controller and battery? I know it’s reading voltage high, does it wait to dump until it sees a controller? I’ll try reducing the default bypass now with a reflash. I may need to reflash controller also. Is myConfig.Calibration the value I should change to get the new voltage correct? I can’t find the post above talking about swapping out the part. I’ll need to check BOM and my order to confirm the swapped part#.
Also, the thread on dropped communication was about noise from inverter. In my case, it drops communication when in dumping mode. Is that a known issue? I’m powering the controller from a USB battery pack right now.
Find out what part you had to swap to the voltage reference, once we know that we can take a look.
On the communication issue, what do you see, does the green LED “comms” light move up through the chain until the end and then no message is received, or does the LED stop at the module which is balancing ?
I’m only testing with a single module right now, so no chain. I changed the calibration to 1.61 which appears to be about right now and I’ve commented out the dump() to remove that variable for now. I’m going to resolder my serial cables to see if that’s part of the problem. Even without the dump(), I’m seeing comms constantly drop off and on, and completely unable to save configs in the few moments they are talking. Clicking identify seems green light a little sporadic blinking (guessing that’s comm related also).
this is the part I swapped out for C171854 - TL432CG-AE3-R
Interestingly, this comment said the voltage was reading low, but for me, it was reading much higher?
Not sure if the USB battery pack could be causing an issue, I have a DC-DC I can setup on the battery to power the controller if that may help.
The TL432CG-AE3-R is a 1.24V reference, the original part was a 1.25V reference, however I wouldn’t have expected you to need to change the calibration to 1.61 - normally its around 2.1 or 2.2.
The V4.21 modules have a simple resistor divider circuit (parts R3 and R4) values of 68K and 27K.
This should give a measurement range of 0 to 4.398V using a 1.25V reference, and 4.363V using a 1.24V reference.
Each “step” in the analogue to digital converter in the ATTINY (1024bits) corresponds to 4.29mV (1.25V reference) and 4.26mV (1.24V reference).
The code in the module does a simple multiplication to calculate the voltage like this…
raw_adc_reading * 2 * calibration
So if you had a cell voltage of 4.0 volt, the module should read that as 932, and the calculation would look like this (calibration is calculated as 2.145)
932 * 2 * 2.145 = 3998mV
Using your example, 4.0 volt, the module should read that as 938, and the calculation would look like this (calibration is 1.61)
938 * 2 * 1.61 = 3020mV
Almost 1 volt less. I’d suggest something isn’t correct on the boards you have. Can you check R3 and R4 have the right values on them?
What type of battery/cells are you connecting the modules to?
I have a single LifePO4 EVE 280Ah battery at 3.29v right now hooked up to a single module.
R3 and R4 look correct. On my last test, for a few cycles, the reported voltage was moving a bit from 2.7v to 2.68v… then settled back to 3.29v (which includes my adjusted calibration). I’m wondering if a created bad connection on something when using the heat gun.
Actually, I don’t have a very good connection on the battery terminals, but I didn’t think it would make that much of a difference… perhaps a bad assumption.
I did find this page ATtiny 841 Serial comms baud rate - Microcontrollers - Arduino Forum
Which talks about voltage affecting internal clock frequencies on the attiny. I’m curious without a common ground, how do these serial endpoints synchronize? I should check if I’m getting a clean 3.3v off my ESP8266.
Side note, I original forgot to set the DIYBMSMODULEVERSION in defines.h, but the compile lines below still went through and actually flashed. #if (!defined(DIYBMSMODULEVERSION)) #error You need to enable one of the DIYBMSMODULEVERSION define statements #endif
Voltage measured at the module header is correct, 3.28v
I soldered up headers on another module and comms are working fine (I haven’t tried with dump() enabled yet). I’ll need to double check on the first one. However, the inability to save appears to be from Chrome on Linux. It’s giving back an XSS format error (500) on POST.
Version 71.0.3578.80 (Official Build) (64-bit)
When I open in firefox, it saves fine. Also, the multiplier from ‘calculate’ for the new module on the webpage(module) also gives 1.608 and it looks perfect.
Edit: resoldered 1st chip, but didn’t help. Voltage started low, then went up. External temp was jumping around, 15,40 then settled to 0 (I don’t have an external sensor), and internal temp was at 26. Working module was showing 19.
If 1.608 gives my a reading from my battery of 3.29v then that means my ADC is converting a 1023 value. That means I’m at the top of my voltage range. What other chips on this board could cause an incorrect reading? I’ve confirmed R3/R4 and the 432CG part for the voltage reference. Could that have been damaged by using a heat gun?
Just an FYI, I haven’t yet put together my DIYBMS setup, but a bad connection to one of my Lishen 272ah cells was causing havoc with the whole bank, was not getting the capacity I expected. Fixing the bad connection to the battery and things got much more predictable.
You shouldn’t need to do this at all - the defines are in the platformio build processes, just pick the correct firmware for the board version you have - typically 4.21
Looking at the other user who is running the different 432 part, he had the opposite problem, and the calibration was over 4 ! I think the JLCPCB supplied parts are wrong or have incorrect voltage.
Can you take a voltage measurement of the 432 on the module? (its exposed on the sensor pin header)
Do you have a bench type power supply so you can run the module through the voltage range you expect and see where the limits are?
Voltage does affect the ATTINY clock frequency, which is why I use a slow baud rate of 2400 to communicate. Each module is electrically isolated from each other, so each module and ATTINY runs at the voltage of the cell its directly connected to.
I do have an experimental version with an external crystal, but the 4.21 boards are working fine for most people.
I did just buy a bench power supply actually. I’ll try that. I did measure the output of the 423 and got 1.26v off both pins from the same side. I haven’t looked at the sheet, not sure if that’s expected. I’ll need to grab my better meter, I was using a cheap one I had handy.
I checked with bench supply, and it actually is maxing out readings at 3.1V input.
Side note - If click the ‘calculate’ button multiple times the calibration value continues to drop. I haven’t looked at the code to see if this is just a javascript variable reuse issue. I’m assuming this isn’t sending any type of message to the module to do an actual calc.
Was there a resolution on this?? … I’m seeing VERY similar issues with a batch of V440 modules reporting low voltage and I’m running out of ‘multiplier’ room before it hits the limit of 5. In playing around with it I was able to get it to report a calculated value of 3.06 volts by increasing the actual value input in small increments. Anything over that value (3.06V) would generate a multiplier over 5.
Setup: ESP32 controller running the early April code release, V440 modules with a single lifepo4 (3.33V presently) cell for initial testing.
In the morning I’ll check the 1.25V ref and R3/R5 values …
I was concerned I’d done something fundamentally wrong. Since the minimum order for controllers was 5 boards I went ahead and ordered all the kit to build them all … I’ve got 4 working and they all do the same thing … along with 14 of the 20 functional monitor boards I’ve put together. So I’m hoping there’s a bad (wrong) part in all the modules.