B3603 DC/DC Buck Converter mini review and how the SET key could be fatal...

[baruch]

I no longer have a unit with a stock firmware, can anyone check if the accuracy claims of the product are indeed met?

I'd be interested to know both the ability to control the voltage and to read its state so I'd like a test where a voltage output is tried at fine steps (0.01V) for some consecutive values (say 5.00 to 5.1 or even higher, as much as patience enables) and to measure externally if the voltage is really regulated at this accuracy.

I just tried to switch from 6.10 fixed point to 16.16 and this required 64bit temporaries and bumped the code to 10K. The firmware size at this time is already close to 8K even at 6.10.

[Rick Law]

I no longer have a unit with a stock firmware, can anyone check if the accuracy claims of the product are indeed met?

I'd be interested to know both the ability to control the voltage and to read its state so I'd like a test where a voltage output is tried at fine steps (0.01V) for some consecutive values (say 5.00 to 5.1 or even higher, as much as patience enables) and to measure externally if the voltage is really regulated at this accuracy.

I just tried to switch from 6.10 fixed point to 16.16 and this required 64bit temporaries and bumped the code to 10K. The firmware size at this time is already close to 8K even at 6.10.

Stay tune, I will have some numbers for you before the end of the day.  (Preping for a snow storm here...)

[Rick Law]

I no longer have a unit with a stock firmware, can anyone check if the accuracy claims of the product are indeed met?

I'd be interested to know both the ability to control the voltage and to read its state so I'd like a test where a voltage output is tried at fine steps (0.01V) for some consecutive values (say 5.00 to 5.1 or even higher, as much as patience enables) and to measure externally if the voltage is really regulated at this accuracy.

I just tried to switch from 6.10 fixed point to 16.16 and this required 64bit temporaries and bumped the code to 10K. The firmware size at this time is already close to 8K even at 6.10.

Stay tune, I will have some numbers for you before the end of the day.  (Preping for a snow storm here...)

Got some numbers now:
first column=selected
second column=what theB3603 shown as output
third column=UT61e measurement of output
delta=evaluated as nextVoltage-thisVoltage.

Set to   B3603   UT61E      Delta
1.93      1.92      1.9428      0.011
1.94      1.94      1.9536      0.011
1.95      1.96      1.9647      0.000
1.96      1.96      1.9647      0.017
1.97      1.96      1.9812      0.011
1.98      1.97      1.9922      0.011
1.99      2.00      2.0034      0.011
2.00      2.00      2.0145      0.011
2.01      2.00      2.0259      0.006
2.02      2.01      2.0315      0.011
2.03      2.04      2.0426      0.011
2.04      2.04      2.0538      0.011
2.05      2.05      2.0651      0.011
2.06      2.06      2.0761      
                  
4.93      4.93      4.944      0.011
4.94      4.93      4.955      0.006
4.95      4.94      4.961      0.011
4.96      4.95      4.972      0.011
4.97      4.98      4.983      0.011
4.98      4.98      4.994      0.010
4.99      4.98      5.004      0.006
5.00      4.98      5.010      0.011
5.01      4.99      5.021      0.011
5.02      5.02      5.032      0.011
5.03      5.02      5.043      0.011
5.04      5.03      5.054      0.006
5.05      5.04      5.060      0.011
5.06      5.06      5.071      
                  
10.93      10.93      10.943      0.012
10.94      10.93      10.955      0.006
10.95      10.94      10.961      0.011
10.96      10.96      10.972      0.011
10.97      10.96      10.983      0.011
10.98      10.97      10.994      0.012
10.99      10.98      11.006      0.005
11.00      10.99      11.011      0.011
11.01      11.00      11.022      0.012
11.02      11.02      11.034      0.011
11.03      11.02      11.045      0.011
11.04      11.04      11.056      0.005
11.05      11.05      11.061      0.011
11.06      11.07      11.072      
                  
15.93      15.91      15.948      0.011
15.94      15.94      15.959      0.006
15.95      15.93      15.965      0.012
15.96      15.95      15.977      0.010
15.97      15.96      15.987      0.012
15.98      15.97      15.999      0.011
15.99      16.00      16.010      0.006
16.00      16.00      16.016      0.011
16.01      16.00      16.027      0.011
16.02      16.01      16.038      0.011
16.03      16.04      16.049      0.011
16.04      16.04      16.060      0.006
16.05      16.04      16.066      0.010
16.06      16.05      16.076      
                  
17.93      17.92      17.948      0.011
17.94      17.95      17.959      0.012
17.75      17.95      17.971      

-----

You may notice, the actual regulated voltage output is finer than the displayed voltage.  Each 0.01V higher results in the actual output going up by about 0.011V even while the displayed voltage may not have changed.

Flex evalued the PWM to be 13 bits.  With the ADC being only 10 bits, it follows that the displayed voltage not being as accurate as the PWM output voltage setting.

The 0.011V is puzzling yet.  The 13 bit PWM has 8192 steps.  The math there makes 12 bit seem more reasonable. 0.011V*4096=45(volt).

I was interrupted.

For unknown reason, (static discharge?), when I resume, my unit's LED gone dark!  On power up, a few random segment came on and then off.  But the unit seem to be controlling voltage still.  I can UP-arrow and see the voltage going up.  I think I did a factory result (based on memorized key-stokes), and the voltage went back to 5V -- But without the LED, I don't know what is going on.

So, I was going to see if it stays at that increment at higher voltage - but, with the unit dead, I will not be able to do much for now.

I have to figure out what to do yet.  Ideas?
On power up, a few (random?) segments of the LED do come on - quick sub-second blink, then goes dark.

Rick

[baruch]

I've got one unit with the display like that but it was one that I tortured mistakenly. I'm using it now with serial only control. I am thinking about getting a replacement led display and replace it but for now it's more hassle than it's worth.

I'm also using 12 bit PWM and the frequency matches the one you all measured previously in the thread. Their accuracy indicates for me not just the PWM itself but also the accuracy of the calculations that they do. From my simulation if I use 6.10 split I can only get 800 out of the 1000 values between 0.00v and 10.00v and if I use 5.11 I can get all 1000 values but then it will overflow during some other calculations.

What I did to check is to take the 1000 strings on input, convert to a number and generate the pwm counter value and see if I get different values, in the current 6.10 I only get 800 different values for the PWM so the accuracy of the output will be lower than the original firmware.

[Rick Law]

I've got one unit with the display like that but it was one that I tortured mistakenly. I'm using it now with serial only control. I am thinking about getting a replacement led display and replace it but for now it's more hassle than it's worth.
...

Yeah...  Oh well, time to hunt for another.

I think most likely it was ESD.  When I first got started I am usually well prepared doing things like discharging myself first.  After an interruption, I was preoccupied with trying to remember and then get back to where I was.  I think I got careless.

[bal00]

Perhaps I will dive into the alternative Arduino based control board.  Off hand, I think the 10bit ADC and 8bit PWM is going to be too limiting...

I ran into this issue when I replaced the top board with an Arduino. To get around the problem with the ADC precision, I use averaging in software to increase the precision. Works pretty well.

The PWM precision can be increased by combining two PWM outputs using a resistor divider network. Basically you have 'coarse' and a 'fine' PWM output with 256 steps each, effectively providing 16 bits of resolution, which is more than good enough in terms of precision.

[Rick Law]

Perhaps I will dive into the alternative Arduino based control board.  Off hand, I think the 10bit ADC and 8bit PWM is going to be too limiting...

I ran into this issue when I replaced the top board with an Arduino. To get around the problem with the ADC precision, I use averaging in software to increase the precision. Works pretty well.

The PWM precision can be increased by combining two PWM outputs using a resistor divider network. Basically you have 'coarse' and a 'fine' PWM output with 256 steps each, effectively providing 16 bits of resolution, which is more than good enough in terms of precision.

I did a "voltmeter" with the Arduino and I used ADC averaging to get about 11 and almost 12 bit like resolution.  Particularly with a "look up" technique I developed: using the averaged 10 bit as an index into a look up table (about 256x16-bit entries per "range" interpolated to the 1024 points) of measured voltage.  That took care of the op-amp imperfection very well since it was looking up a prior measured voltage in the table.  It uses a lot of ram however.

For DAC, I tried voltage divide and add before and that worked reasonably well.  Stability is a problem however...

All these add-on's to add resolution each brings in more and more stability problem.  I have not acquired the skill to solve them well yet.

I'm going to make/replace the controller with Arduino, but with so many things I like to try (>8bit PWM, 15bit ADC, etc)... Even the replacement is going to take a while to get here.

Mean time, I have to connect my other "PSU" just to keep going for the short term.  I already miss my B3603...

[baruch]

I figured a way to get the full 13 bit resolution of the PWM and now I get the full value range. I figured that my timer counter being 8192 is just a shift of 13 so I can avoid overflow by not shifting up 13 and down 10 but rather just do the entire calculation with an additional shift of 3.

The ADC on the face of it is a lost cause, it is only 10bit accuracy so I only get a change every 8 values of the PWM. Rick, I'd be interested to hear about your ADC averaging, I started to think about it and wonder if it's worth spending time to do it. I currently take a snapshot of the ADC and need to average it out anyway but originally wasn't planning to use fractions in that average.

I did some code size reductions and the code is now at 7860 bytes. It was at 8100 beforehand and got down to 7600 and then the new PWM accuracy took more space. I kinda like the serial text interface but not sure how long I can hold on to it in its current verbose state.

[Rick Law]

I figured a way to get the full 13 bit resolution of the PWM and now I get the full value range. I figured that my timer counter being 8192 is just a shift of 13 so I can avoid overflow by not shifting up 13 and down 10 but rather just do the entire calculation with an additional shift of 3.

The ADC on the face of it is a lost cause, it is only 10bit accuracy so I only get a change every 8 values of the PWM. Rick, I'd be interested to hear about your ADC averaging, I started to think about it and wonder if it's worth spending time to do it.
...
...

Hey, I am actually glad you asked.  This may be re-inventing the wheel, but I was so pleased with myself, as a newbie, figuring out a good way to do this...

First, here is a percent error graph so you can determine if this is worth the effort - and it will be a good amount of work!!!  The graph is measuring a capacitor discharge from 5V with an UNO with ATMEGA uncompensated, then measure it again using my board with my compensation at ranges 5V and below.   %Error is as compared to the UT61e reading of the voltage.  The black is the ATMEGA uncompensated, the different color plots are the different ranges I have (at different op-amp multiplier or resister divider).  By the way, I call it my "DinoMeter" because I was using a dinosaur era laptop for data logging.



This was first posted a year ago when I was even more of a newbie than today:
https://www.eevblog.com/forum/microcontrollers/an-implementation-of-atmega328-volt-logger-the-dinometer-a-learning-project/msg316233/#msg316233

Since the STM has only 8K flash, I am not sure it has enough RAM to implement this method.

In a nutshell, the method is to store the real world (DMM measured) voltage and use the ADC count as an index to a lookup table.  So, apart from LSB jitter, once it get the ADC reading, the program looks up in the table the stored DMM-measured voltage for the ADC reading.  So, in theory, as long as the ADC is consistent, you get the right voltage within math-accuracy.

Implementation is of course limited by RAM.  To reduce the RAM usage, rather than storing 1024 readings for the 10 bit ADC, I store about 400 readings at 16 bits each.

At low ADC, the graph is least linear, so compensation entries has to be frequent.  At higher ADC, the reading is more linear so compensation entries can be less frequent.  The table entry is continuous (1 entry per ADC count) till 250, and then 1 entry per 5 ADC count above that totaling 250+156 readings.

At ADC>1020, I have 2 ADC count per entry to make it easier to deal with overflow.  Reducing 400 entries to about 250 is feasible and (if memory serves) still give rather decent accuracy.

That totals 406 entries per range - each range being different voltage divider and/or different op-amp multiplier.  In my implementation, I had and 5 divider and op-amp multiplier choices, so in my "DinoMeter", it has 5 voltage range for collection for each ADC.

With that many ranges, I have to reduce the RAM need further.  I use 16 bit entries instead of a long or a float giving me ~ 4 digit math-accuracy.  I make use of the fact that (say for 5V range)

ADC_Translated voltage = ADC*5V/1023
should not be magnitudes off from DMM reading, the factor should be near 1.

If DMM reading is twice the ADC_translated voltage, the factor is 2.
If DMM reading is half the ADC_translated voltage, the factor is 0.5.

Now I have a much smaller magnitude number to deal with then if I store the exact DMM reading which could range from mV to 30V for my ranges.  I use the 16 bit unsigned int with implied decimal.
65535 => 6.5535, DMM reading is 6.5535 times the translated voltage
20000 => 2.0000, DMM reading is twice ADC_translated voltage
05000 => 0.5000, DMM reading is half the ADC_translated voltage

So, if the ADC is perfectly consistent, I get back exactly the DMM reading I stored when I calibrated the reading for that ADC - within math-accuracy.

This arithmetic method gives me 4 digit math-accuracy with 16 bit numbers, and any op-amp/voltage divider non-linearity issue are already taken into account since the correction makes it exactly what the DMM was reading within math-accuracy.

To account for LSB +- digit jitter, I collect multiple readings and average them.  If it averages to ADC=123.4, I interpolate the reading between ADC=123 and ADC=124 for ADC=123.4.

I was using a time-based average (average over 250ms) verses count-based average.  I don't recall how many ADC conversions the ATMEGA can do in 250ms, I think it was around 70 for most of my readings.

The collection of the calibration data is not difficult after I wrote the data logger.  I even made sure it skips a reading when the UT61E changes range as it has a habit of giving wild reading during range change.

I use a capacitor discharge and let it sweep the entire range slowly.  The discharge must be slow enough that I get at least 20 readings for each ADC count.  A JAVA program reads the ATMEGA and the UT61E.  I let it run overnight (and longer), the JAVA program fills my JAVA array [1024] for that range.   Now I know the average UTE reading for each ADC count.  An Excel spreadsheet takes the export of the array in text and automatically converts the five arrays of data into code which I insert after the PROGMEM:

// the low is for the low adc reading from 0 to 248
extern PROGMEM   prog_uint16_t CalDataLow[4][5][249] = {
{  // Start of A0
   // Start of A0 x-24
// Dataset Series number A5C1  (-24X check sum 1015.67648024476 TableSum 4009641)
 {  0,// A0@-24:1  (691231.190000)
  0,// A0@-24:2  (691231.190000)
  0,// A0@-24:3  (691231.190000)
  5612,// A0@-24:4  (131123.094922)
  9513,// A0@-24:5  (131123.094922)
…
  9962,// A0@-24:246  (131123.042149)
  9961,// A0@-24:247  (131123.042040)
  9961,// A0@-24:248  (131123.041933)
  9961},// A0@-24:249  (131123.041828)
…
…


So on, so on.  You can see that my Arduino A0 with opamp/voltage divider at -24x, when ADC0=246, the correction factor is 9962.
So, the real world voltage from DMM was  (246*(-24V)/1023) * (9962/10000)


//
// the high is for ADC reading 250 and up, 1 entry per 5 adc reading
extern PROGMEM   prog_uint16_t CalDataHigh[4][5][156] = {
{  // Start of A0
   // Start of A0 x-24
// A5C1  (-24X check sum 1015.67648024476 TableSum 4009641)
{  9961,// A0@-24:250  (131123.041721)
  9961,// A0
…
  9222},// A3@-1x:1022  (131125.015115)
   // Start of A3 x1
// A5C1 (with 5*675K discharge)  (1X check sum 1036.06042214359 TableSum 4173638)
{  10065,// A3@1x :250  (131128.140130)
  10064,// A3@1x :255  (131128.135438)
  10063,// A3@1x :260  (131128.134753)
  10060,// A3@1x :265  (131128.134113)
  10058,// A3@1x :270  (131128.133444)
  10059,// A3@1x :275  (131128.132815)
  …
For Arduino A3 when op-amp/voltage divider is at 1x with average ADC3= 272.15, my DMM voltage would be:
DMM_volt at 270 = (270*5V/1023) * (10058/10000)   call this V270
DMM_volt at 275 = (275*5V/1023) * (10059/10000)   call this V275
DMM_volt at 272.15 = is 2.15 over 270 and below next reading at 275

So, V 272.15 = V270+(V275-V270)*2.15/5

As to how well (or not) the compensation do, you can see the data I collected about a year ago.   I actually doubt you have enough RAM to do it at the same level.  I can dig up my Excel sheet, and do an analysis on if you cut the table down to 1/2.:

Say every other ADC entry up to 248, then one entry for every 10 ADC count after

If I recall, down to 256 total entries per range was still giving me good numbers with Excel analysis - I did analysis by using the real adc count for the skipped entries, compare to the interpolated value for the skipped entries, the delta would be the error penalty for skipping.  But when I was done with the program, I still had RAM left so I expanded the table size to use up as much of the remaining flash space as possible.

Rick

[baruch]

@Rick, that's very interesting. You are able to get a very high accuracy with that system but it will be unmanageable for this project since any user will need to do such calibration and not everyone has a serial logging multimeter.

I just checked and if I take 64 samples and divide the sum of the samples by 8 I get pretty good results with about 0.5% error and I get what seems to be 13 bit accuracy for the ADC which matches the PWM accuracy without a measurable impact on latency of the measurement (it is well below one second to measure all three different values: vin, vout, cout).

The accuracy above is for a linear approximation with full accuracy of the PC, what will be the accuracy for the fixed point calculation I do not know.

[Rick Law]

@Rick, that's very interesting. You are able to get a very high accuracy with that system but it will be unmanageable for this project since any user will need to do such calibration and not everyone has a serial logging multimeter.

I just checked and if I take 64 samples and divide the sum of the samples by 8 I get pretty good results with about 0.5% error and I get what seems to be 13 bit accuracy for the ADC which matches the PWM accuracy without a measurable impact on latency of the measurement (it is well below one second to measure all three different values: vin, vout, cout).

The accuracy above is for a linear approximation with full accuracy of the PC, what will be the accuracy for the fixed point calculation I do not know.

Yeah, my method is an attempt to remember and then produce a second presumably higher accuracy device.  It will require a lot of work and of course a "higher accuracy device" to calibrate it against.

As to: "The accuracy above is for a linear approximation with full accuracy of the PC, what will be the accuracy for the fixed point calculation I do not know."

You may know this already, but just in case: change it to mV first to get better math accuracy.

One thing I found with various ATMEGA experimentation is: I am better off using LONG and perhaps even LONGLONG (64bit) integer multiply it by an implied decimal, do the math, round, then scale back the implied decimal, cast it back down.  It will be faster and more accurate.

Let me try to show exactly what I mean:
//
// mV instead of V, now I have 3 digit more accuracy than volts
// For 4 digit 00.01V is really a centiVolt
//
unsigned long    sumOfAdc;
uint8_t    sampleCount;     // up to 100 samples without overflow
//
// this whole thing could be one statement, broken out to show the steps.
int8_t  rangeV=40;  // here I am pretending 40V being the range
unsigned long    milliVolt = ((1000*40V * sumOfAdc / 1023) / sampleCount;
unsigned long   centiVolt = (milliVolt +5)/10;    // now scale it to centi with rounding
unsigned int   uintCentiVolt= (unsigned int) centiVolt;
//
// here is one line
// uintCentiVolt =(unsigned int) ((unsigned long) (((((1000UL*40UL * sumOfAdc / 1023UL) / sampleCount) +5UL)/10UL);

//
// note: unsigned long max = 4,294,967,295
// in this line: (1000*40V * sumOfAdc / 1023) / sampleCount
// 100 ADC sample is 100*1023 max, so max value before divide is 1000*40*(1023*100)
// lucky for us, this max = 4,092,000,000, which will just fit in the unsigned long.

In one of the experiments I did, I did the implied decimal not by 1000, but by 100000 and use longlong for the last multiply (x1000000) and the first division onward,  I switch to long as soon as I know the number should be ok as LONG for the rest of the division.  Even with LONGLONG, it was still faster than floating and with less lost of accuracy compared to floating.

[Rick Law]

Since my controller board LED went dark, I am forced into action.

I got an Arduino to do the controlling function.  I reprogrammed the PWM timers to do 13 bits matching the 1.94-ish KHz  PWM for stock controller but at 5V which I have to scale to the stock's 3.3V  (good that I did the measurement for @Flex, now I found that data useful too with my unit gone-dark).

I am for now using the ADS1115 (15bit ADC).  I am using code fragments from my other projects to set/display, so, the Arduino doesn't understand B3603 function.  Instead of setting voltage or current, I set the PWM count directly via a 5-tac-switch keypad.  But bottom line is it works but not well.

It is controlling the voltage at 13 bit resolution and the 15bit ADC display it correctly with V=aX+b where the slope and intercept is hard-coded right now, the voltage looks good... but:

The "not well" part is: it has an oscillation that I have to hunt down.  Small (+-6mV) but measurable that my DMM is cycling such as 12.345V to 12.351V.  This oscillation is way smaller than the typical noise level, but both the DMM and the ADS 1115 measurements show a clear oscillation there that was not seen with the stock controller.

This could be I am not doing PWM right.  I am try to learn the in's and out's there trying to figure things out myself there.  So I am not posting what I did (yet) to avoid suggestions for now.

I have some ideas where my oscillation may came from.  As to if I can solve it and how soon...  Also, I think I have to wait for a working unit to compare - I am seeing more noise than I remember, but until I have a working unit to cross check...

Rick

EDIT:

My suspicion was proven correct.  My LCD screen is updated every 300ms and during update, serial data is also send.  This is what caused the oscillation, either LCD, serial, or both.  Change the update timing, and the frequency of the oscillation changes.  I can set the update to 10 seconds, and it stayed stable for most of the 10 seconds until the end when refresh occurs.

I must say, I feel a little silly tracking down a small (+-6mV) oscillation on top of noise that is ten times the size; it just bugs me to see the DMM doing a count down when measuring something that is suppose to be fixed.

[baruch]

The nice thing about the STM8 is that it does the PWM completely in hardware, it has specific pins it can control like that but then all I needed to do was tell it how much to count (8192) and what to compare against (calculated value) and it will go off to do that and then it doesn't matter what I do in my main loop the PWM is not affected.

[Rick Law]

The nice thing about the STM8 is that it does the PWM completely in hardware, it has specific pins it can control like that but then all I needed to do was tell it how much to count (8192) and what to compare against (calculated value) and it will go off to do that and then it doesn't matter what I do in my main loop the PWM is not affected.

The ATMEGA also has one 16 bit timer doing the PWM - not sure if it is direct hardware or micro-code inside the MCU.  Two of the Arduino PWM pins use that 16 bit timer, the rest has 8 bit timer.  I am using the pins with the 16 bit timer to create the 13 bit PWM.  So in theory, after I set the registers and tell it to go, it should also be set and forget.

I think the PWM is counting fine but the wave form is affected.  There could be jitters that I cannot observe with my scope.  It could also be because of the other activity (power draw), it is not forming the wave well - such as a slight drop in peak or a slight increased rise time.

Then again, it may be I am totally wrong with how I handle the PWM at the register level.  As I said, I am trying to learn how to modify the PWM beyond Arduino's 8bit pwm with AnalogWrite.

I suspect the Serial.print more because I have seen Serial activity having a negative impact on ADC with poor USB power.  Even while I am using external power, the added activity there could have power draw that made the impact.  It could also be the I2C activities with the LCD screen.  It could be either or both.

Instead of using a resistor divider to drop the 5V PWM to 3.3V for the B3603, I switched the resistor divider to a resistor+zenor.  I was hoping it was simply a peak issue.  Had it been that, the zenor should kill it by setting a lower peak for all.  The zenor approach cuts my delta a bit - I think.  (Not sure if it is purely due to power condition changed from yesterday such as washer is not running).

I am not sure if there is anything I can do yet, I will have to chew on that.  May be altering the timing of how I do the serial and the i2c.

This really is silly however.  The regular noise level is at least 10x that 6mV now down to 3mV or 4mV.  I feel silly worrying about it.  But it is so annoying to see what is suppose to be a fixed voltage just constantly counting 1.232, 1.233, 1.234, 1.235, 1.232, 1.233, 1.234, 1.235, 1.232 .....

It occur to me, this would bore anyone to death...  I am going into details that I don't think anyone cares...  Since I already typed it, might as well post it.

[Asim]

I am so tempted to rework my portable rechargeable power supply based on B3606 and do my own top board now.

https://www.eevblog.com/forum/projects/my-portable-rechargeable-power-supply-(mod)/msg562574/

above is a post I created sometime ago showing off the power supply

[Rick Law]

I am so tempted to rework my portable rechargeable power supply based on B3606 and do my own top board now.

https://www.eevblog.com/forum/projects/my-portable-rechargeable-power-supply-(mod)/msg562574/

above is a post I created sometime ago showing off the power supply

re: "I am so tempted to rework my portable rechargeable power supply based on B3606 and do my own top board now."

Are you planning on using the stock STM or an ATMEGA/Arduino?

[Asim]

I am so tempted to rework my portable rechargeable power supply based on B3606 and do my own top board now.

https://www.eevblog.com/forum/projects/my-portable-rechargeable-power-supply-(mod)/msg562574/

above is a post I created sometime ago showing off the power supply

re: "I am so tempted to rework my portable rechargeable power supply based on B3606 and do my own top board now."

Are you planning on using the stock STM or an ATMEGA/Arduino?

An arduino, what I am thinking about is an oled display to show Iset,Vset,Vout,Iout & the important thing to me which is battery charge % as I want it to be a portable rechargeable device so the charge % of the lithium battery pack is very important. my problem is software though ( not that great on coding I consider my self a hacker not a coder).
I would use push buttons for the controlling.
I am planning on using 16 bit DAC & ADC to have as accurate results as possible. double sided PCB with SMD components at the bottom such as atmega328, DAC,ADC. the top side would only be for the user interface.

That's the plan anyways. I am busy at the moment, but i will get into it

[Rick Law]

...I got an Arduino to do the controlling function...
...The "not well" part is: it has an oscillation that I have to hunt down.  Small (+-6mV) but measurable that my DMM is cycling such as 12.345V to 12.351V.  This oscillation is way smaller than the typical noise level, but both the DMM and the ADS 1115 measurements show a clear oscillation there that was not seen with the stock controller...
...I must say, I feel a little silly tracking down a small (+-6mV) oscillation on top of noise that is ten times the size; it just bugs me to see the DMM doing a count down when measuring something that is suppose to be fixed.

Finally, got that licked...  My controller (on breadboard) is as stable as stock. 

After confirming my initial suspicion that the oscillation may be screen refresh related, I narrow down and then identified the problem.  All these time, I thought it would be the Serial.print, but it was the 20x4 LCD's power consumption.

During screen refresh, the many lcd.print was affecting power level enough to cause the PWM to be ever so slightly different than normal.  Consequently, the V-Set-In is affected resulting in V-out change.  A mere 12mV-ish (+ and - 6mV), but it was bugging the daylight out of me...

Now that narrows my choice of display if I am going to make a new top-board. But I am please that if I do decide to make one as I likely will, it can be as stable as the stock on.

[Rick Law]

I am so tempted to rework my portable rechargeable power supply based on B3606 and do my own top board now.
...

...Are you planning on using the stock STM or an ATMEGA/Arduino?

An arduino,
...my problem is software though ( not that great on coding I consider my self a hacker not a coder).
...I am planning on using 16 bit DAC & ADC to have as accurate results as possible. double sided PCB with SMD components at the bottom such as atmega328, DAC,ADC. the top side would only be for the user interface.
...

16 bit ADC/DAC would be awsome.  I was considering using my ADS1115 which really is a 15 bit but advertised as 16.  It is really 15 bit counts with a sign bit for differential.

Keep us posted.  It sounds very interesting.

[Asim]

@ rick, what is your setup? Which arduino are you using? Are using any Ecternal DAC or ADC?

[Rick Law]

@ rick, what is your setup? Which arduino are you using? Are using any Ecternal DAC or ADC?

Right now it is still on breadboard.  Initially it was on a bare ATMEGA made to behave like an UNO.  As of today, I switched to a NANO V3 (CH340G, not V3 with FT232RL which I also have but with connectors not suitable for breadboard).  The switch is because I wanted to get things physically closer to avoid noise as I hunt for the oscillation.  NANO is compact enough to allow me to cut out a lot of wire length at least for now.

I am using ATMEGA for everything except ADC.  I want to see how far I can go before I finalize the components.  For ADC I am using the Adafruit ADS1115 to test how far I can go on the sense-side.  I know I wont be happy with the ATMEGA ADC.  I would use ATMEGA ADC if other things are less well than expected - in that case I would not waste a good ADC on something unsatisfactory.

For PWM, I am bypassing the Arduino standard PWM and manipulate the ATMEGA's PWM registers directly so I can use the 16 bits Timer1.  So, I am using Arduino's pin9 and 10 on Timer1.

Might as well touch on this:With the change away from the 2004 LCD, I am using a Nokia 84x48 monochrome LCD, graphical but doing text only. Very fast, but uses more RAM than I like.

My software is code fragments from different prior projects - not design for this at all.  For example, to set CC or CV, my code merely allows me to enter integer(s) via a 5-key tac-switch keypad.  So I enter selected voltage as PWM timer count - awkward but works during this feasibility study phase.

In the final implementation, I may switch back to "home-made-UNO" with optical isolator for the TX/RX and an off-board USB on the other side of the isolator.  When I was collecting data for current shunt temperature, I observed what may be a problem caused by this set up:
- Two ATMega (or Arduino) connected to one PC to collect combine data
- one ATMega connected to an external device powered by the B3603
- another ATMega tied to the ground via the B3603 internal pins
When I was pulling around 1-2A, the difference between the external ATMega ground and the internal-pin-grounded ATMega were different enough for me to have some negative volts where there shouldn't be any.  I am not sure this is real problem yet, but I know to prepare for it.

This is my environment for now, but as you can imagine, I am still experimenting so it will change again.

Rick

[baruch]

@Rick, I know I'm interested in these thoughts of yours, feel free to share. I ramble on anyway :-)

I've switched to using mV and mA for measurement and it definitely improves the accuracy and also my grasp on things. I still use fixed point for the calculations. I got the PWM and ADC working again after this change and now need to figure out the calibration. There is some code to test the calibration with values I measured, for now I don't know what to set the expected values to. Still need to work on that.

Help and advice on the code is always appreciated!

[Rick Law]

...
 and now need to figure out the calibration. There is some code to test the calibration with values I measured, for now I don't know what to set the expected values to. Still need to work on that.

Help and advice on the code is always appreciated!

You are ahead of me.  I am still at the (last step of) feasibility study part - confirming that I can control with my own controller board.  Now that I think it is working on a breadboard, I need to transfer it to a proto-board (soldered) so it is stable enough for software development.

I have not put much thought into calibration yet.  My gut feel is while the stock software's method seem good (with improved UI), my guts said the thing is not going to be so linear that calibration at two points will do it.  2-points assume perfect linearity which is doubtful.  But I have not yet collected the data to tell me how many points would be adequate - perhaps the thing is linear enough for straight-line approximation.

Once I get my ATmega based controller board, I will join you in the quest for a good calibration method.

[baruch]

I've just taken data I collected previously and it includes the ADC value and what the multimeter read (a Mastech MS8250B). The data is quite perfectly linear in fact. There are obviously some errors but the linear approximation is very strong and continuous throughout the range. I attached it here so you can play with the same data as well.

I also attach a graph of the ADC value at the X axis, the measured voltage in Y axis and a green line of the linear function: ((0.0056395173454*x)-0.593524886878)

[baruch]

One thing to note is that different point pairs will generate a different linear function and some may have more errors than others. The right way to solve this is to use more than two pairs, probably at least five and probably the optimal number is 10 pairs and use a least squares estimate and find the best match with the least error for all collected points.

The problem with this is would be that it is time consuming and takes quite a bit of effort, both from the operator and the code. I will easily get into overflows and may even trigger watchdogs. I think I'll leave that to the user to perform so I will support the two point calibration for those who don't mind the accuracy too much and if someone wants full accuracy I'll provide an external script that will take all the different measurements and do the right thing and feed the final answer to the device.

In fact, it should be possible to write yet another script that will communicate with the B3603 alternative firmware and with a serial-capable multimeter and perform the calibration completely automatically. It can even measure it at the full range and with all data points to get the lowest possible error.