This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Difficulties in getting BQ34z100-g1 to measure initial QMax in learning cycle

Other Parts Discussed in Thread: BQ34Z100-G1, BQSTUDIO

I have been trying unsuccessfully to get the BQ34z100-g1 to go closed loop and get beyond learning state 4 in activating the Impedance tracking.

I was wondering if a TI employee could look at the log files and see what might be the issue.  It reports measuring the OCV at charge and discharge but the max error remains at 100% and QMAX never updates too.  The SLUA334B document and others like it imply that  max error should go to 3% on the first charging cycle and I do not see that happening.  The QEN and VOK bits seem to do what the document says they should be doing when doing an optimization cycle.  The SOC matches well when charging and discharging the QMAX value used, so that seems correct.  I read in some of the documents that starting it from a discharged state and issuing a reset is helpful, so that was done.  The battery is a Pb 12 Volt battery.

The first indication seems to be in the charging cycle when MaxError is supposed to go to 5%.

  • Richard
    I can review your log files tomorrow. Please attach them to this message. Also, please attach an srec file from your pack.
    Tom
  • Thanks. I attached the files through the link you provided before for sending data privately. The log file included did one full cycle and the initial part of the next cycle also has the MaxError not updating like what is included. So I expect to get the same result but will not know fully until tomorrow.
  • Tom,

    The data I provided yesterday was for the first cycle of a two cycle effort.  The second cycle like the first did not update QMax when completing or MaxError when the charge portion ran.  The data log I provided printed out all the registers and content of the flash into the same file so that  a complete record would be provided.

    I have similar cycles that recorded that plotted only the data that seemed key and stored in excel format.  I can provide that excel version if it would be helpful to see plots of voltage and currents during the charge and discharge cycle.  

    I can also provide the second cycle that goes with what I sent before.  It charged the battery back up and discharged it to see if the Learning mode would get past state=4 and got the same result as the previous efforts.

  • Tom,

    I was wondering if you had an success at seeing why the optimization cycle is failing?

  • Richard
    I responded off-line that I need the bqStudio log data to analyze the problem. Can you collect that data?
    Tom
  • The procedure for the optimization cycle tends to ask for turning on or off loads and charging based on for example OCV being taken or VOK changes. Since some TI documents said failures most often result from improper charge or discharge cycles I automated it to be sure the data was taken as recommended.

    I am going to re-parse the data I provided so that it matches the log file and gg.csv format bqstudio outputs and I think everything was logged would be needed to do that. I am fairly sure that would support your using any tools TI had written to import data in those data file formats.

    I do use bqstudio at times but can't access the bq34z100-g1 chip through I2C for automation while using bqstudio to log the data.
  • Tom,
    I sent the re-parsed data through the private channel. bqstudio can output the register values and also can auto dump the flash contents. I collected both of those in the original file and what I send was just the log of the register values. I am working on pulling the data for the flash out of the previously collected data and getting it formatted into the gg.csv format.
  • I sent additional parsed files thought the private channel. I also scanned to see if the logs showed the flash being changed during the optimization cycle and did not see any changes happening. Since I provided srec data, it does not seem helpful to send a lot of gg.csv files with the same data. if you have not looked at what I sent before, the files I just provided zipped up all the data for each battery in a directory for each. Hopefully that would make it easier for you to review the data and see if you can see why the optimization cycles are failing.
  • Tom,

    I was wondering if you got a chance to look at the files I provided?

  • Richard,
    I reviewed your files and will send a response off-line.
    Tom
  • Tom,
    If you sent your off line response already, I have not received it.

    I am fairly sure I have been able to successfully send data through the private channel but do not seem to be getting any return mail by that method since Dec 1st. On the 9th you said you responded off line when I asked before if you had already responded to something and I never saw that off line message. I spent some time trying to learn the posting system TI uses to see if I could access older off line results and did not see how that might be done. It seems those emails get sent directly to my normal email address.
  • Richard,

    I did respond off-line and here is the response. Your log files were good and the gauge would have updated, but the Flash Update OK Cell Voltage was set too high to allow the flash memory to update. I used a Mathcad program to create Qmax and Ra table values from your log data and I updated them in the attached srec file. I also updated the Flash Update OK Cell Voltage to allow future updates. You can load the srec and send the GAUGE_EN command. I also verified that your ChemID match is good. 

    Tom

    0100_0_16-bq34z100G1_griph.srec

  • Thanks, that helps a lot.