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

[neslekkim]

Nothing new, but I found the product pages from the manufacturer, at least it looks so:
B3603
http://www.mhinstek.com/product/html/?106.html
B3008:
http://www.mhinstek.com/product/html/?108.html
400w:
http://www.mhinstek.com/product/html/?110.html

No support pages, no nothing.. atleast I expected download links for the manuals there, but still the link from this page points to mhinstek.com for the pdf:
http://www.banggood.com/B3603-Precision-CNC-DC-DC-Digital-Buck-Module-Constant-Voltage-Current-p-946751.html

[baruch]

@neslekkim, I found on that website a download section with manuals, even English translations for the B3606 and B3606. They don't have any new information there though.

[flex]

I just calculated all the output pin values, They all line line up quite well with bal00 measurements:

Iout_set=Iout_sense=16*(0.01V+Iout*0.05)
Vout_set=Vout_sense=16/15*(31mV+0.068*Vout)
Vin_sense=Vin/16
CC=2.91V and CV = 0.45V

In case someone is wondering why there is an offset: Even through the MCP6002 is an rail to rail Input/Output opamp, the Output can't reach 0V and VCC (see datasheet). The offset just is a workaround to this problem.

I also attached an updated schematic with more annotations and a scan of the calcualtion for Iout_sense and Vout_sense (don't have time for LaTeX at the moment).

btw: For simplification I left the small voltage drop of the shunt (which mainly depends on the current, but also temperature) out of the sense voltage calculation.

Update: I forgot the resistor R18 of the top board. With it the CC voltage increases to 2.91V. and unlike I claimed some posts ago the resistor has a use: it increases the voltage to better fit inside the high level voltage. (not strictly necessary, because VIH=0x7*VDD to VDD+.3mV)
Update2: just added the inductor values and fixed the IC numbers of the opamps.
(I think I should just upload them with a version control system. That way I wouldn't need to update these forum posts  )
Update3: forgot to recalc the CV voltage for the first update.

I'm somewhat fumbling on this topic but what would be the best way to control the PWM vs the voltage/current setting vs the output sense?

Should I do a feedback loop between the outputs and the pwm? Find some calibration and let it be?

I wouldn't create a digital feedback loop. That loop would be rather slow. Rather trust the calibration. (I think that is also what the orig firmware does)

@Rick Law or anyone else with an scope: Could you check the PWM frequency at pin 4 and 5? I don't have any scope nearby.

1.293K Hz based on my Rigol DS1052E

That is interesting. I think we can assume that the pwm timer of the stm8 is running at the max freq of 16Mhz. That would mean the pwm timer counts to 16Mhz/1.293kHz=12374.

[Rick Law]

@Rick Law or anyone else with an scope: Could you check the PWM frequency at pin 4 and 5? I don't have any scope nearby.

In an earlier post (where I purposed using header pin numebrs) I said no visible TxD/RxD connects HeaderPin 15 and 16 (Rx/Tx) to the MCU's Rx/Rx.  I found the traces connecting them to UART1 RxD and TxD.  I reedited that reply also to avoid confusion.

They are also in my schematic

So, in so far as I can see, your schematic for the buttons is confirmed; AND they are indeed strange.

thx for checking. This is an interesting design choice.

Sorry, didn't mean to ignore you!  Been busy.  Good that Asim got that taken care of with his scope.

I removed the shunt today and upgraded it to a Vishay/Dale 75ppm shunt.
I will have some hard data to share in a few days.  (Doing 8 hour runs, so just one pass per night, 8 minutes FAN on, 35 minutes FAN off cycle to log how shunt readings change as it heats up at particular current.  I do not have equipment to measure shunt temperature. )

In setting up for the run, during the pre-run tests, I noticed the (from fan cool to no-fan max) swing was half what I saw with the stock shunt at 1.6A.  This is less improvement than I had hope.  So the stock shunt is not as bad as I had thought.  I'll post the data when I got that done.

[baruch]

@flex, in the schematics the formula seems to involve a mA value and what seems to be fractions of a volt. Am I reading it right?

For example the Iout says: Iout_sense = 16 * (10mV + 0.05 * Iout),
The code translation for me would be: Iout_sense = 160 + 0.05 * Iout
I hope I'm not mixing up units...

I built some code to drive the 7-segment display and hit again the 8K limit, the floating point code I currently use takes about 4KB of that so I'm now reeducating myself on fixed point arithmetic and converting the code from float to fixed point. I'm also incorporating already the defaults as you calculated, we'll add actual calibration as well so the parameters above (16, 10) are values that can be changed online.

[flex]

@flex, in the schematics the formula seems to involve a mA value and what seems to be fractions of a volt. Am I reading it right?

For example the Iout says: Iout_sense = 16 * (10mV + 0.05 * Iout),
The code translation for me would be: Iout_sense = 160 + 0.05 * Iout
I hope I'm not mixing up units...

You got me there. I was a sloppy and left the units out. I'll fix that. See attachment for the units. I'll also add the units to the schematic.

I built some code to drive the 7-segment display and hit again the 8K limit, the floating point code I currently use takes about 4KB of that so I'm now reeducating myself on fixed point arithmetic and converting the code from float to fixed point. I'm also incorporating already the defaults as you calculated, we'll add actual calibration as well so the parameters above (16, 10) are values that can be changed online.

Sounds good to me. I hope you can get it into 8K flash. Not sure if you should use the theoretical values as default. Maybe we should average over the units in this forum. But with calibration, this isn't too important.
@Rick Law that sounds interesting. The position of the shunt is too bad. Otherwise we could try to put something like the MP915-0.050-1% as shunt.

[Rick Law]

@Rick Law that sounds interesting. The position of the shunt is too bad. Otherwise we could try to put something like the MP915-0.050-1% as shunt.

Indeed!   To achieve better stability, it would be better to move the shunt than to just upgrade it.

Interesting to note that (as shown in Flex's schematic) pin 9,10 verses 11,12 do not connect to same ground.    The initial pin decoding in banggood.com has header pin 9,10,11,12 as ground, but they are not the same.

(@Flex, what is extra D stands for in the "other ground" GNDD vs GND)

With the shunt removed, you can see the trace that connects the low-end of the shunt to GNDD at header pin 11,12.



I took a picture of it because with the "under the component" traces - easy to forget once the component get back on and covers it again.

Rick

[Rick Law]

Ok, I upgraded my shunt with the Vishey WSL2R0500FEA, a 75ppm shunt.  The improvement is measurable but far below what I had expected.  This points to two possible explaination: (1) The stock shunt is better than I had thought, and/or (2) the location of the shunt is too awful for it to cool.

I think the stock shunt is probably 150ppm.

Before we look at the new graphs, let's refresh our memory on the two baseline graph/data with the stock shunt posted on 2/4/15.





Using the same setup to let the shunt heat up at 1900 or 1600mA, which takes about 20 minutes to heat to equilibrium, and cools it by fan and it take just over 5 minutes for it to cool to equilibrium.  I set the no fan heat up for 35 minutes, and fan cool down to 8 minutes.

Below are the new data with the Vishay shunt.  You can see that the max/min swing is about half.
@1900mA-2000mA
Vishay shunt swings 2006 to 1973 = +-33
Stock shunt swings 2009 to 1954 = +-55
@1600mA
Vishay shunt swings 1613 to 1592 = +-21
Stock shunt swings 1628 to 1591 = +-37

[new 1900 picture]


[new 1600 picture]

Note also, at near 2.0A, one should run a fan at the voltage regulator.  It gets very uncomfortably hot bear 2A.

The low improvement is disappointing.

Rick

[baruch]

I switched over the code to fixed point, I needed 32bit arithmetics so there is some space in that now but I dropped the code size to 5KB and I can now fit the display driver for the 7-segment display. It works ok, I currently update the digit data too often so a flicker is visible at the lowest digit when it's on the edge. That should be easy to fix I guess with only updating the display not too often.

I didn't manage to use the buttons properly so far, I suspect now it is because the pin is also a SWIM pin and there is a flag to make it usable for the software. I'll give it a try tomorrow.

I also didn't manage to control the on/off led button and as such can't really enable/disable the output properly. I tried all the pin configurations and it hardly changes. There is some change so I'm affecting something but it's not a 0V to 5V, more like 0.3V. The led anyway stays on all the time for me. While I can't properly affect the led if I put the Iout and Vout set pins to on (no pwm) I get voltage out of the unit, still didn't try to draw current from that though.

[flex]

(@Flex, what is extra D stands for in the "other ground" GNDD vs GND)

It's for digital ground. I was looking for another GND symbol an thought digital ground would suit, since it is only used for the (digital) display. Feel free to suggest any other name.

I also didn't manage to control the on/off led button and as such can't really enable/disable the output properly.

In theory, all you have to do to enable the on/off led and the regulator is to set PB4 to output GND.

[baruch]

I also didn't manage to control the on/off led button and as such can't really enable/disable the output properly.

In theory, all you have to do to enable the on/off led and the regulator is to set PB4 to output GND.

I tried all the possible combinations that I can find, I set it to output HIGH, output LOW, input and also played with the open-drain/push-pull. The red led is always on no matter what I do. Output control works by setting the Iout and Vout pins high, the OE pin seems uncontrollable. Obviously I'm doing something wrong since the original firmware does control it somehow.

[baruch]

Current state of things:

• I do not control the Output Enable pin, but it doesn't seem to matter. No idea how it comes. It is always at 0V no matter what I do on the pin.
• I can control the 7-segment display and it shows data consistently and nicely
• I can control the CV/CC led, still didn't get to test CC condition to be sure of the full loop
• I can measure with pretty good accuracy the Vin, Vout and Iout based on the theoretical numbers. I didn't attempt to calibrate my own unit yet.
• I can control the PWM for the voltage and the current, this is not at all calibrate so the random I use and the output are off by a factor or so but it seem to work and only needs tuning

This is now pretty close to being a minimally functional serially controlled power supply.

EDIT: I have two units, one supposedly damaged in parts but where OE is 5V and one supposedly good where OE is always at 0V. I'll try the new firmware on the old and supposedly damaged unit and see what happens, this will happen tomorrow. The damaged unit had been injected 17V to the top board and then once plugged in reverse. the 7-segment display doesn't seem to work properly and there was some problem with output regulation after it was plugged in reverse.

[Rick Law]

@Rick Law or anyone else with an scope: Could you check the PWM frequency at pin 4 and 5? I don't have any scope nearby.

1.293K Hz based on my Rigol DS1052E

I have been wanting to replace the interface on that module. with the pinout mapping provided I think I can do it.

my Ideal interface would include OLED display to display Vset,Iset,Vout,Iout. one rotary encoder with built in switch to vary the set voltage and current ( switch to change from voltage to current and vice versa) . one push button to switch the output on & off. 2 leds for CC & output ON.

I think 1.293K Hz is wrong!

I hooked up my scope (6022BE) and took a snap shot of pin4 and 5.  I have a frequency of around 1.946KHz (with typical occasional 6022BE jitter from 1.937 to 1.947 but mostly 1.946).

To double check, I connect my UT61E to it, and it confirms a rock solid 1.945KHz.

To triple check, I connect my UDB1308S function gen and use the frequency counter, a rock solid 1.945KHz.

So, if I am a betting man, I would place my bet on 1.945KHz.

Asim, would you double check?

Thanks
Rick

Edit:  Just an interesting FYI... a coincidence - like the B3603, the UDB13xx cheap function generator is also a MingHe product.  I guess they specialize on economy stuff.

[flex]

@Rick Law I think you are correct. I also have an UT61E (but forgot about the frequency function until you mentioned it). It shows for my unit 1.937kHz.

That is also more reasonable. Since ld(16Mhz/1.945kHz)=13 Which would mean 13 bit PWM.

EDIT: I have two units, one supposedly damaged in parts but where OE is 5V and one supposedly good where OE is always at 0V. I'll try the new firmware on the old and supposedly damaged unit and see what happens, this will happen tomorrow. The damaged unit had been injected 17V to the top board and then once plugged in reverse. the 7-segment display doesn't seem to work properly and there was some problem with output regulation after it was plugged in reverse.

OE is supposed to be at 5V until the mcu program sets the output low. Great to hear that your firmware is making progress.

[baruch]

I have one top-board with faulty 7-segment and one top-board where the OE is always low. I have PWM control now but the calculation is off by what seems like a factor of 5 or so. The code is on github if someone wants to review my math. It's been a while since I needed to worry about integer overflows and to tread carefully in numerical analysis.

I have ordered another B3603 unit so I will have another hopefully fully working one but due to the chinese new year the unit wasn't shipped yet and it will be at least three weeks after the holiday is over before I have a chance to get it so for now I can either develop the display or the pwm control.

EDIT: Direct line to review, the functions are control_voltage() and control_current(), can be found at https://github.com/baruch/b3603/blob/master/stm8/main.c#L532

[Asim]

HAHAHA,
I don't know how i typed that frequency. I meant to say 1.923kHz. this is what my unit shows.

the frequency doesn't matter that much as far as I know as it will be filtered to an average voltage that will control the Iset & Vset.

[flex]

the frequency doesn't matter that much as far as I know as it will be filtered to an average voltage that will control the Iset & Vset.

Yeah there is a low pass filter. But for 1.293kHz (T=773us) the filter isn't as good as for 1.923kHz (T=520us). It has significant more ripple. I attached my simulation results.

@baruch I think the problem is:

Code: [Select]

tmp *= 73<<10since sizeof(int)=16, this will overflow. Try this instead:

Code: [Select]

tmp *= 74752;//73<<10;The same for

Code: [Select]

tmp += (33<<10)/1000;it also overflows 16 bit signed int. Instead use:

Code: [Select]

tmp += 34;//(33<<10)/1000;
I haven't checked control_current, but I suspect the same mistake.

[baruch]

@flex, it works now!

I can control the voltage and it is pretty good even without calibration I get one digit after the dot of accuracy. Still haven't tested the current part, I'll need to find a led or something that I can use in a current limited mode.

[flex]

Great to hear. Just a note on your commit message:

Fix integer overflow issues
The default type is uint16_t and some of the fixed numbers were
overflowing that, giving the explicit number makes the compiler use a
larger integer type and corrects the calculation.

That isn't technically correct. The default type of literal integer constants in c is int. Further the size of int is compiler (platform) dependent (2 byte in this case) and signed. If a constant is too big to be represented as int, the compiler uses the next bigger one like long int. You can influence this behavior with the suffix u and l.

[Rick Law]

I am kind of "out of the game" now...  I am not familiar with how to program this MCU.

Any suggestion on what you think is best for an Arduino guy to get started with programming the STM?

Thanks
Rick

[baruch]

I'm not an Arduino guy nor an STM guy. For my day job I develop C for PCs for clustered systems so MCUs are a new game to me :-)

Unlike the Arduino there is no fancy library that does all the hard work for you, actually there is but due to space limitations and license uncertainty I prefer to avoid it. So I'm developing in raw C with the raw registers.

There are two main documents that I refer to near constantly, one is the overall reference which can be found in the git repo at doc/CD00190271_RM0016_STM8_Reference_manual.pdf and the other is the STM8S003 details at doc/DM00024550_STM8S003F3_Datasheet.pdf I also consult the STM8 application notes where relevant and google for how to do specific things but there is maybe one or two sites that have the information I need.

The other part to know is to build and install, I use sdcc to build so you should have that installed, the makefile will do the rest for you in that regard. For some reason stm8flash, the linux flash utility, doesn't work for me anymore so I resort to having a Windows VM on my Linux which runs the STVP (Windows programmer software) and I use that to program. I needed to expose to Windows the STLinkV2 and used google to find how to do it.

If you have questions just ask (here or on email), I tend to do these things in small bites. I suggest that you decide what you want to work on and I can help guide you along the way. I try to make the code fairly well documented and hopefully easy to read. You can find it all at https://github.com/baruch/b3603/

[baruch]

BTW, there are also requests/ideas to create another top-board with more features. If you're interested in hooking an Arduino and write code for it that would be interesting and useful as well. It may also provide more validation around the sense and control circuits too.

[Rick Law]

I am a C guy started with C with machines with 48K ram (Atari800), so bare-bone library and small-space coding is not an issue for me.  I am not sure about handling the MCU since Arduino has been doing it for me.  I also don't have tools to flash the STM.  So, I am not sure if messing with the B3603 control board is a good "first step".

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...

Thanks for the pointers however!  Perhaps I will gain some courage and dig into the STM...

[baruch]

I don't think it's such a big issue to program the STM8 compared to an Arduino. The ideas are the same and are the harder part to grasp IMNSHO. The how is only slightly harder, instead of calling set_pin_output(1) you need to do PC_DDR |= (1<<3) but the idea is that you need to configure a pin to input/output and set some parameters for it (pull up/down and such). Try to review my C code to get an idea of it.

The STM8 has a 10bit ADC as well but the PWM is much better but even an 8bit PWM would be useful to get something working and I got a few contacts saying they wouldn't reflash the STM8 board of the original unit so an Arduino firmware may be a good thing for many people.

[baruch]

I started to implement calibration, so far I did it for Vin and Vout ADC. I have to say, the formulas for Vout were close enough that both the PWM control and the ADC require very little calibration, at least for my needs. I still don't get the 0.01V accuracy, even with my calibration but it's within the 0.1V level so for my personal needs it's fine.

I'm still lacking control of the buttons. Need to figure it out yet.