Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Modules go into bypass when programming at 5v

Hello, another big thanks Stuart! I got my parts and tried to solder (iron!) the chip on the module board. First one was iffy, but did work. Second one had a solder bridge which I tried to fix. Board starts up, does the green/blue led double blink… then after a few seconds later, blue blinks, red lights up for 2 seconds, starts to fade, and the board/chip resets. I may have damaged a trace between two of the pads or using a heat gun to remove/reattach the chip may have damaged the board. Thoughts? I do have 4 spare module boards and I’ve ordered some solder paste from above comments, but do I need to be really careful with the heat gun? Should I use the paste with light touch soldering iron?
This is harder than I thought it would be :slight_smile:

P.S. I think it’s damage between pin 5/6
edit: I was able to put some flux/paste on it and it looks like it cleaned up fine. Pins/traces appear fine now. I can program it fine, but it still does the boot loop. Is it possible I damaged something with the heat gun? I tried not to overheat it, but the board did get too hot to hold once it melted the solder.

Its really difficult to tell - are all the boards behaving as mentioned or just the one? Did you change any of the components when ordering from JLCPCB?

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.

Are you not programming these boards using a 3.3v usbasp programmer?

At 5v the board will start to bypass and that will draw more current than the usb will support, dragging the voltage down and causing reboots.

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.

Hi, glad the programming is now sorted out.

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?

That isn’t correct, something is definitely wrong here, comms issues should be very rare.

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 https://forum.arduino.cc/index.php?topic=356448.0
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.

The XSS error simply means that you need to refresh the web page.

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.

1 Like

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.

Ok, for a precision reference I would expect better. My (now unavailable) 432 is bang on 1.24V.