Poll

Using a github repository with submodules

Fine, it gives the possibility to easily upgrade the script to newer dependencies
4 (100%)
A bit of a hassle, but I can get it to work
0 (0%)
I don't plan on to use git, so I would like a single download
0 (0%)
No need for these scripts, I use other tools
0 (0%)
No need for these scripts, automating is not my thing
0 (0%)

Total Members Voted: 4

Author Topic: Automated battery charging using a SDS1104X and SPD3303X(-E) - now on GitHub  (Read 374 times)

HendriXML and 1 Guest are viewing this topic.

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
This post is about how to use expensive gear to replace a cheap battery charger!

That and to showcase what can be done with some simple scripts. (I'll post them on GitHub.)

The idea is that later on only the SPD3303X will be used to charge a NiMH battery and to stop when full. The moment of a full battery can be determined by checking when the voltage drops when using CC. How much depends on the charging current, but with 1000 mA, 5mV should do the trick. This difference should be measurable in a reliable way using only the PSU.

But first I did some precise scope measurements. The charging graph is created using averages of 140 kpt, capturing those waves as fast as possible. (It uses AC-line triggering)

The script starts at 500 mV/div, but steps down to 50 mV, 5 mV, 500uV when there's no overflowed ADC value. Sample points where only reported in the lowest 500 uV vertical div with no overflows.

When there's an overflow, the VDiv will step up. Because the voltages change slowly this should be very rare (and the 2nd measurement after that will probably be a step down again). The last successfully measured voltage is taken as the offset (-).

This way it is possible to do measurements better than 100 uV resolution and has great noise filtering capabilities.

The absolute accuracy is mostly determined by the offset DAC of the scope.

The first image shows a zoom where the vertical grids lines are only 100 uV apart.
« Last Edit: November 08, 2019, 08:26:52 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 
The following users thanked this post: rf-loop, Performa01, tautech, tv84

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
Re: Automated battery charging using a Siglent SDS1104X and SPD3303X(-E)
« Reply #1 on: October 27, 2019, 04:31:27 pm »
I changed the script to have a slower H-Div and acquiring and averaging 1.4 Mpts. This makes the scope zoom even less noisy.

The script/scripting tool has no problem processing this much samples, the most time is used by the scope and the transfer of data.

The measured voltage by the PSU differs a few mV, but follows the scope line very nicely. To bad they limited the voltage resolution of the PSU to mV's.

But there's seems to be no problem in stopping at a 5 mV decline, this means only the PSU is needed to charge the battery and stop it when full!
« Last Edit: October 27, 2019, 05:25:45 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17869
  • Country: nl
    • NCT Developments
Re: Automated battery charging using a Siglent SDS1104X and SPD3303X(-E)
« Reply #2 on: October 27, 2019, 05:28:46 pm »
Why are you using an oscilloscope to measure the voltage? Just reading back the PSU voltage is simpler and way more accurate. The DC error in an oscilloscope can be as much as 3% and there can be non-linearities as well. The PSU OTOH is likely accurate to less than 1%. mV resolution is good enough for battery charging anyway.
« Last Edit: October 27, 2019, 05:30:22 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
Re: Automated battery charging using a Siglent SDS1104X and SPD3303X(-E)
« Reply #3 on: October 27, 2019, 06:00:46 pm »
Why are you using an oscilloscope to measure the voltage? Just reading back the PSU voltage is simpler and way more accurate. The DC error in an oscilloscope can be as much as 3% and there can be non-linearities as well. The PSU OTOH is likely accurate to less than 1%. mV resolution is good enough for battery charging anyway.
Thanks for the response!
If it is about relative voltages the graph show that the scope is a clear winner in showing the charging curve. That makes it a good candidate to check the voltage response of the PSU. With a 1 mV resolution that one is a lot more coarse. But still very usable and probably better in absolute terms. The differences are small.

Regarding the scope, is it technically hard to have an accurate offset dac? That one doesn't need to be fast..
But I don't know what is generally more precise dac's or adc's.
« Last Edit: October 27, 2019, 06:19:40 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 17869
  • Country: nl
    • NCT Developments
Re: Automated battery charging using a Siglent SDS1104X and SPD3303X(-E)
« Reply #4 on: October 27, 2019, 06:15:48 pm »
But I don't know what is generally more precise dac's or adc's.
Doesn't matter. It depends entirely on the specifications (ENOB, linearity).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
I've placed the scripts on GitHub.
https://github.com/HendriXML/XMLScripts-Project-BatteryCharging
Can be downloaded including the submodules via:
Code: [Select]
git clone --recurse-submodules https://github.com/HendriXML/XMLScripts-Project-BatteryCharging.git C:\BatteryCharging

The script "NiMH Battery charging using a SPD3303X.xml" uses only a PSU. The other script "Battery voltage measurement.xml" uses a scope to do the measurements.

The script are just examples, and will act as templates for other scripts in the future. But they show/explore the following principles:
  • Report sufficient information, the directory in which reports are saved can be set in the tool
  • Make important parameters configurable in a ini-file and report the used values back - so tests can be redone
  • Parameters are formatted with scales and units: like mV and ms etc. They can also be supplied in this way. So mistakes are less likely
  • The current status is frequently updated during the measurements
  • The measurements are reported in a separate report. Which can easily be copied and pasted in Excel

The "Battery voltage measurement.xml" is more advanced and shows how to program measurement ranges using objects, sorting them and use some state handling.

Both scripts use scaled integers (these start with conv-), these are implemented in script libraries which where "borrowed" from my BOM reporter scripts. But floating point versions of properties are available as well. The reason for this is that scaled integers are very well suited to transfer decimal based numbers without any loss or rounding errors. (Unless the pico resolution is not enough...) And I already had the logic to convert them from/to text.
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
Some screenshots to give an idea what it looks like.
« Last Edit: November 08, 2019, 10:18:35 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
A lot of the coding lines of the script consists of reading config, reporting and showing the current status. In a way that make them more complicated to read. But the more I use these script, the more I see this logging and documenting as very useful when structural experimenting is done.
The idea is to change the reporting directory on every run. Because the text that is written in the input tab is reported that could be used to comment on the extra conditions of the test run. With a proper script, experiments can be repeated more quickly and be documented meanwhile.

Even only if these kind of scripts are used to do the initial setup of devices and report what values where used they still offer a lot of benefits.

Also the scripts mostly use the object oriented wrappers around the SCPI communication, this makes it easier to parameterize stuff, but sometimes outputting SCPI commands works just as well. Especially when the wrappers lack the implementation of a command.
« Last Edit: November 09, 2019, 08:48:28 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 

Online HendriXML

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: nl
    • KiCad-BOM-reporter
The script that uses the scope is updated (and one of its dependencies).

One important parameter was not configurable yet: the bandwidth limit of the channel. Without it turned on, measuring at 500uV sensitivity is undoable. B.T.W. what sensitivities are used can be changed in the ini file section. Although that section is normally loaded from the script file, thar section can be imported using an command line option. This could "automate" switching between different configurations.
Also the script now only enables the channel that is used. In this way only a single value in the configuration needs to change when swapping physical connectors. That's a great benefit of parameterizing VISA interaction.
« Last Edit: November 09, 2019, 08:49:52 pm by HendriXML »
“I ‘d like to reincarnate as a dung beetle, ‘cause there’s nothing wrong with a shitty life, real misery comes from high expectations”
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf