• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 64 subscribers
  • Views 623 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ27426: Learning cycle when device is in the market

leinho
Expert 1230 points
Part Number: BQ27426
Other Parts Discussed in Thread: BQSTUDIO, GAUGEPARCAL, , GPCCHEM, BQ27441-G1

Hello,

I watched this training video: https://training.ti.com/gauge-programming-fundamentals  and it looks like we should perform a learning cycle using bqStudio and update the RAM Values of QMax and Res Tables at

POR. This is for ROM based fuel gauges. I have the following questions:

- Would this be still needed if we confirm the CHEMID is correct using GAUGEPARCAL/GPC?

- What I have been doing with my prototype was to check for RA Update and QMAX update bit and when that occur, the host processor would request the QMAX and Ra Table to the gauge and store in its Flash

Memory. Then, if a POR occurs in the gauge, the values stored in the host's non-volatile memory would be transferred to the gauge. This would be like a continuous learning cycle for the gauge.

Would this work in order to be as accurate as possible following battery aging process?

Thanks for your help!

  • 0
    TI__Mastermind 24870 points
    Hello Leinho,

    Can you tell me more about your end application?

    GPCCHEM is the quickest and preferred method for the bq27426.

    You will need to re-program the chemID if you decide to use GPCCHEM each time the device is POR'd and having a GPCCHEM ID will be sufficient to keep track of the battery aging process.

    I would recommend you use a flash based gas gauge if you do not plan on having code on your host processor to do the ITPOR management for ROM based gas gauges.

    Thanks
  • 0 in reply to Kang Kang
    Expert 1230 points

    Hello Kang Kang,

    My end application is a pair of WiFi enabled headphones which has a non replaceable Lithium Ion Battery (600 mAh).  It will be part of a medical application. 

    So, you are telling me there is no need to store in flash memory the RA Table and QMax that is continuously learned by the gauge?

    I think I prefer to have the code in my host processor rather to have to flash the gauge during production. I actually have all this in place but wanted to confirm if this would be required. We did not use the GPCCHEM when selecting the gauge and we are doing that now to confirm the CHEM ID would be accurate enough for our battery. At this point, it looks to me that the ROM based type gauge would be the fastest solution. We currently have the BQ27441-G1 but we need one with input pin for the NTC (like the BQ27426).

  • 0 in reply to leinho
    TI__Guru* 76230 points
    He is saying there is a need to have NVM to store the continuously learned Ra and max.
    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Expert 1230 points
    Ah, ok. I did not understand that from his message. The only similar thing would be:

    "You will need to re-program the chemID if you decide to use GPCCHEM each time the device is POR'd and having a GPCCHEM ID will be sufficient to keep track of the battery aging process"

    One thing is to udpate the CHEMID because the default value might not match with our battery. And a different thing is the RA Table and QMax which requires a lot more coding. I wanted to know if it was better to update it continuously (using ResUp and QMaxUp) or to run the learning process only once, store this in NVM and send it to the gauge when POR'd.
  • 0 in reply to leinho
    TI__Guru* 76230 points
    continuously. As the battery ages Ra and Qmax will change. If you use the values from the learning cycle, you will have accuracy issues.
    thanks
    Onyx