BQ4050: bq4050 Companion Battery Charger ICs for JEITA compliance

Hi,

We will need more information about battery configuration and charging current. Many of our chargers our JEITA compliant.

Best regards,

The battery pack info is as follows:

Type: Lithium-ion 7.2V

Capacity: 10350 mAh (74.52Wh)

I may need to clarify the question a bit. It was my understanding that the bq4050 performed all the measurements and provided cell protection features that allow for JEITA compliance when paired with an appropriate charger, and that the charger did not specifically have to be JEITA compliant also. So in other words, the combination of the bq4050, and a charger that can regulate charge current based on monitoring from the bq4050 is what makes a charge/management system using the bq4050 JEITA compliant. 

I could be misunderstanding things, so please correct me if this isn't the case.

Thanks.

Hi, Thanks for sharing these documents. I have referenced the JEITA app note in trying to find a solution to this problem. Let me try to explain what I need a little better. I'm using a COTS battery pack. This pack consists of the battery management IC, bq4050, the battery cells, and misc. support electronics for the bq4050 operation. I did not design the pack and only have access to the pins mentioned. I'm assuming the bq4050 has been programmed with the correct protection/threshold features prior to my purchasing it. 

I need a charger that will work with this pack in a standalone mode that maintains JEITA compliance.

The app note says the following "The fuel gauge usually broadcasts the charge current and voltage information to the smart battery charger or keyboard controller for periodically setting the proper charge current and voltage. An SMBuscontrolled battery charger, such as the TI bq24745, can be used as a slave device to get the charge voltage and current information from a smart battery pack with either the bq20z40 or the bq20z45 fuel gauge."

The parts referred to in this sentence and the diagram in figure 4 are all obsolete. I'm assuming I can do something similar for my application, but it's not clear to me if I can simply connect any TI charger with SMBus to the battery pack to form a standalone solution or if I need a micro to act an intermediary.

It's also worth noting someone asked a similar question on the e2e board titled, "Battery charger with autonomous function". 

Yes, I've already seen this part and if I didn't have to interface a COTS pack I would consider it. But this will not work for the reasons I already mentioned in the previous post. 1) I don't have access to the battery pack thermistor 2) it does not have comms so I can't use the bq4050 monitoring features in tandem with this part. I need a standalone solution that uses a charger along side the bq4050 part OR if you don't offer a standalone solution I just need to know what IC is recommended for using the micro as a host for the SMBus. 

Hi,

For 2S Li-ion we have couple of JEITA compliant chargers. 

BQ25886 or BQ25883 (boost chargers)

BQ25792 (Buck-boost charger)

BQ24616 (buck charger)

I’m not sure what I needed to do differently to explain what I needed, but none of your responses have answered my questions.

I had no prior experience with SMBus, the bq4050, or any of your battery charging ICs before asking these questions which could be part of the problem. I took some time to research things and here is what I think I understand.

The bq4050 was not selected by me, but instead is designed into a battery pack I plan to use. I don’t have access to the cells in the pack or any thermistors monitoring pack temperature, only the positive and negative of the pack and the data lines for SMBus. The cells are configured as 2S2P.

The bq4050 has all the features and functionality to provide JEITA compliance when paired with the correct components (charger only in autonomous/standalone mode OR charger plus host processor if autonomous is not desired). Because the bq4050 is used inside the pack, the charger does not need to be JEITA compliant because it is just taking commands from the bq4050 or the micro for charging current and charging voltage based on the battery state. To make autonomous mode work, the bq4050 and battery charger must both be compliant to the SMBus standard, and the bq4050 must be setup for broadcast mode so that required charge voltage, charge current and other status/fault monitoring can be passed to the charger at regular intervals.

I also plan to have a host (msp432 micro controller). The SMBus standard allows for this and is explained in section 4.1 of the Smart Battery Data Specification version 1.1, but one of your app notes, SLUA475, suggests in that if a micro is to be used as more than a host that simply listens for broadcasted information from the bq4050 fuel gauge then broadcasting should be disabled. From section 1.2.2 it states “Because of this difficulty, most host systems do not recognize this part of the SMBus specification and, instead, act as the only master on the bus. Therefore, TI recommends that broadcasting messages be disabled for every application unless absolutely necessary.”

I’m not sure I understand what this means as it seems to be at odds with a valid operating approach shown in the SMBus Data Specification standard.

To answer the question I had about the recommended charger, I think that if autonomous mode is required and no host processor is present, then the only type of charger which will work is one which is setup to operate with SMBus rev 1.1.

If autonomous charging is not desired and the host processor is acting as the master, then any of your chargers where the voltage and current can be controlled via the processor will work to maintain JEITA compliance. This opens up the options to chargers that are not necessarily compliant with the SMBus standard. With this approach the processor will periodically ping the bq4050 for the recommended charge current/voltage according to the SMBus standards and pass the requested values to the charger to maintain JEITA compliance.

If I have misunderstood how your products are intended to operate in conjunction with the SMBus standards, please let me know.

Also, I would like clarification on the SLUA475 statement I mentioned above because I would like to operate in a mode where the bq4050 broadcasts information and where the host periodically requests certain battery status parameters that are not part of the broadcasted information such as the state of charge from the bq4050.

Thanks.

Hi Gabe,

Gabe Stout said:

The bq4050 was not selected by me, but instead is designed into a battery pack I plan to use. I don’t have access to the cells in the pack or any thermistors monitoring pack temperature, only the positive and negative of the pack and the data lines for SMBus. The cells are configured as 2S2P.

The bq4050 has all the features and functionality to provide JEITA compliance when paired with the correct components (charger only in autonomous/standalone mode OR charger plus host processor if autonomous is not desired). Because the bq4050 is used inside the pack, the charger does not need to be JEITA compliant because it is just taking commands from the bq4050 or the micro for charging current and charging voltage based on the battery state. To make autonomous mode work, the bq4050 and battery charger must both be compliant to the SMBus standard, and the bq4050 must be setup for broadcast mode so that required charge voltage, charge current and other status/fault monitoring can be passed to the charger at regular intervals.

Thanks for the detailed explanation of your system. Based on this description, the charger itself does not need to be JEITA compliant because the charger is only responsible for taking ChargeVoltage() and ChargeCurrent() commands from the MCU and/or gauge. Therefore, any 2s SMBus battery charger will work. Depending on what topology and architecture is desired, the following chargers could all be suitable:

• BQ24725A (buck topology, traditional architecture)
• BQ24770 (buck topology, NVDC architecture)
• BQ24800 (buck topology, hybrid boost architecture)
• BQ25710 (buck-boost topology, NVDC architecture)

A buck topology charger steps down the adapter voltage, so the adapter voltage must be higher than the battery's maximum charge voltage. On the other hand, a buck-boost charger can either step up or step down the adapter voltage, so the adapter voltage does not need to be higher than the battery's maximum charge voltage.

Please take a look at this article, which outlines the differences between traditional, hybrid boost, and NVDC architectures:

https://e2e.ti.com/blogs_/archives/b/fullycharged/archive/2016/09/19/understanding-battery-charger-features-and-charging-topologies

Gabe Stout said:

Also, I would like clarification on the SLUA475 statement I mentioned above because I would like to operate in a mode where the bq4050 broadcasts information and where the host periodically requests certain battery status parameters that are not part of the broadcasted information such as the state of charge from the bq4050.

Since I only support battery chargers, I will defer to a battery gauge expert to comment on this question regarding the BQ4050 broadcasts.

Thanks!

Best regards,

Angelo

Hi Gabe,

I have forwarded this thread to the battery gauge team. A gauge expert should be in touch shortly regarding your questions about the BQ4050 and SLUA475.

Thanks!

Best regards,

Angelo

I have not yet heard from anyone on the battery gauge team. Can you please resubmit the request. Thanks.

Hello Gabe,

the bq4050 supports JEITA, so if the charger supports gas gauge broadcasts then it can be used without an MCU. The following chargers could work with your system:

• BQ24725A (traditional topology)
• BQ24770 (NVDC topology)
• BQ24800 (hybrid boost topology)
• BQ25710 (buck-boost NVDC charger)

Sincerely,

Wyatt Keller

Thanks Wyatt, My questions about the charger/monitor combo had more to do with the SMBus standard. I have a list of part options so i don't need any help with part selection. I do need a better understanding of the information conveyed in you app note, SLUA475, regarding standalone mode/broadcasting and recommendations for using the micro as a host or as a master. 

It is this section (1.2.2) specifically that I need you to explain as it seems to contradict the SMBus standard. It says "This type of behavior is difficult to create for an SMBus engine implemented in firmware. It is easy to detect 50 µs of idle time, but the port pins used to create the bus must be switched to outputs, and the start bit must be sent. During this time frame, another master can actually take control of the bus. If another master controls the bus, the firmware-controlled bus does not detect that the bus is no longer busy, which causes arbitration to be lost.

Because of this difficulty, most host systems do not recognize this part of the SMBus specification and, instead, act as the only master on the bus. Therefore, TI recommends that broadcasting messages be disabled for every application unless absolutely necessary."

Based on this, it sounds like if you have a host in the system that needs to get information from the charge monitor that is not provided in broadcast mode, you should not setup the monitor for broadcast mode. But this doesn't seem to align with the SMBus standard which allows for this arrangement.

I'm trying to make the correct system decision, i.e. standalone mode where micro is host/master and periodically pings the battery monitor for info like percent charge remaining etc (this is my preferred approach) OR micro as master where micro grabs requested charge current/voltage and other stuff and then conveys those requests to the charger.

Thanks.