Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

nPM1300-EK + NRF5 SDK: Is It Possible?

Hey,

I'm currently working on a legacy project that uses the NRF5 SDK. Rewriting the project to use the nRF Connect SDK would be tedious, time consuming and likely to introduce more bugs, causing me to miss my deadline. Is there a way to use the NRF5 SDK to retrieve the SoC (State of Charge) value with a library or something?Sweat

I've found that the algorithm is implemented in the nrf_fuel_gauge library. Do I just need to include the libnrf_fuel_gauge.a library in my project?

Thanks for the help!!!

Parents
  • Hi

    No, the nRF5 SDK does not support the nPM1300 EK by default, but it is possible to implement on your own, but you will be on your own in doing so. Here is a non-zephyr example that supports bare metal operation: https://github.com/NordicSemiconductor/npmx-zephyr/tree/main/samples/fuel_gauge Note that this example uses Zephyr as a wrapper, but since the function calls all are independent of the Zephyr framework, it should be pretty straight-forward to port somewhere else.

    Best of luck and regards,

    Simon

  • Hi Simon,

    Thanks for the answer. I manage to make it work.( For anyone doing the same.)

    To make it work you need to include:

    - add the nrf_fuel_gauge.h header to your project, which is located in the zephyr drivers.

    - Tell the linker to include the library libnrf_fuel_gauge.a into your build, which is located at nrfxliby\nrf_fuel_gauge.

    - Add the battery model to your project, you can get it from nPM PowerUP.


    - Include the library like this:

        static const struct battery_model battery_model = {
            #include "battery_model.inc"
        };    
        
        uint32_t err_code;
        struct nrf_fuel_gauge_init_parameters parameters = {
              .model = &battery_model,
              .opt_params = NULL,
        };
        
        
        /* Store charge nominal and termination current, needed for ttf calculation */
        max_charge_current = 0.15; 
        term_charge_current = max_charge_current / 10.f;
        
        /* update the fuel gauge values */
        parameters.v0 = bms_end_data.voltage;
        parameters.i0 = bms_end_data.current;
        parameters.t0 = bms_end_data.temp;
        nrf_fuel_gauge_init(&parameters, NULL);

    - Call feul_gauge_process() to get the state of charge (SOC):

      uint32_t err_code;
    
      // read the bms parameters
      err_code = drv_bms_read_data();
      VERIFY_SUCCESS(err_code);
    
    
      delta_in_s = ((float)app_timer_cnt_diff_compute(app_timer_cnt_get(),ticks_latest_delta) / (float)TICKS_IN_ONE_SECOND);
      ticks_latest_delta = app_timer_cnt_get();
    
    
      static float soc = nrf_fuel_gauge_process(bms_end_data.voltage, bms_end_data.current, bms_end_data.temp, delta_in_s, NULL);
    
      return NRF_SUCCESS;

    What I don't understand is the delta_in_s. Is this representing the time that has elapsed between SOC measurements or is it just how fast I measure to use this delta for some other estimation?

    If I would go to low power for say 2 days then the delta_in_s would be very large as the SOC wouldn't be triggered, then I could get an overflow which would create an error in the estimate, right? 

Reply
  • Hi Simon,

    Thanks for the answer. I manage to make it work.( For anyone doing the same.)

    To make it work you need to include:

    - add the nrf_fuel_gauge.h header to your project, which is located in the zephyr drivers.

    - Tell the linker to include the library libnrf_fuel_gauge.a into your build, which is located at nrfxliby\nrf_fuel_gauge.

    - Add the battery model to your project, you can get it from nPM PowerUP.


    - Include the library like this:

        static const struct battery_model battery_model = {
            #include "battery_model.inc"
        };    
        
        uint32_t err_code;
        struct nrf_fuel_gauge_init_parameters parameters = {
              .model = &battery_model,
              .opt_params = NULL,
        };
        
        
        /* Store charge nominal and termination current, needed for ttf calculation */
        max_charge_current = 0.15; 
        term_charge_current = max_charge_current / 10.f;
        
        /* update the fuel gauge values */
        parameters.v0 = bms_end_data.voltage;
        parameters.i0 = bms_end_data.current;
        parameters.t0 = bms_end_data.temp;
        nrf_fuel_gauge_init(&parameters, NULL);

    - Call feul_gauge_process() to get the state of charge (SOC):

      uint32_t err_code;
    
      // read the bms parameters
      err_code = drv_bms_read_data();
      VERIFY_SUCCESS(err_code);
    
    
      delta_in_s = ((float)app_timer_cnt_diff_compute(app_timer_cnt_get(),ticks_latest_delta) / (float)TICKS_IN_ONE_SECOND);
      ticks_latest_delta = app_timer_cnt_get();
    
    
      static float soc = nrf_fuel_gauge_process(bms_end_data.voltage, bms_end_data.current, bms_end_data.temp, delta_in_s, NULL);
    
      return NRF_SUCCESS;

    What I don't understand is the delta_in_s. Is this representing the time that has elapsed between SOC measurements or is it just how fast I measure to use this delta for some other estimation?

    If I would go to low power for say 2 days then the delta_in_s would be very large as the SOC wouldn't be triggered, then I could get an overflow which would create an error in the estimate, right? 

Children
No Data
Related