EEZ Bench Box 3 (BB3) and beyond...

[Kleinstein]

The common mode signal looks reasonable  30 mV_RMS at 1 k would be 30 µA. However there likely is also parallel capacitance to ground, that could absorb some of the current.  So the actual current would be somewhat higher. So the real test would be without the cap to ground.
I would still not call this really good - but maybe acceptable, but could still be an EMI problem.

The capacitance to ground may also be responsible for the different picture with the probe reversed, as than there would be additional injected signal from the other SMPS. The rest of the circuit produces more CM signal - it starts from a higher voltage and is higher power, so no real surprise.

Chances are the common mode choke would also have quite some voltage across and this way reduces the injected signal.
For less common mode signal both a lower cap transformer or a larger CM choke could help.

[prasimix]

As a first thing this morning I powered MCU with battery to remove the Mean well converters (two IRM-10 on AUX-PS module) from the equation:



I repeated the measurements only on the first two channels: AIN1 on which there is a discrete voltage divider and AIN2 with Caddock on input. First to show the measurement without divider, i.e. / 1 which is the same on both channels:



Measurement on AIN1 with /100:



Measurement on AIN2 with /100:



AIN2 consistently shows better results. The next thing I will try is to replace the voltage dividers at the inputs to see if the Caddock really makes a difference.

Measurement on 1K between MCU and MIO Gnd when probe Gnd is connected to MIO side now looks like this:

[prasimix]

Kleinstein, I can confirm your prediction that the type of voltage divider makes no difference. I swapped the discrete and Caddock divider and the AIN2 input still shows at least 10 dB better results. Maybe it’s a matter of PCB layout though since the signal path to these two inputs from end to end are not identical. Furthermore, AIN1 is closer to the upper edge of the PCB and could therefore be more exposed to external interference.

And now comes the interesting part. I tried to put the top cover that is wired to the PE, put back one DCP405 power module, and power everything from the AC input. This is what AIN1 with a short input now looks like:



50 Hz can now be found down at -97 dB. In the case of AIN2 inputs, it is not even distinguishable from other noise:

[DL8RI]

Hello everyone,

yesterday I finally also could start with my assembly.
As I was a bit "courageous" (a nicer term for "stupid"), I had the "bare board"-version ordered. I finished (except a few parts that are still to arrive) the DCM220.
Tomorrow I will do the MCU, that should be quicker, less parts... the DCM220 took me like 5-6 hours of work (but including digging through the huge TME/Mouser-Boxes for parts, now its a bit more organized).

I scrolled through the pages since Oct. Has nobody else got the barefoot-package? I was expecting a lot of problems/questions here regarding the assembly.

[prasimix]

Hi Martin, there is a separate thread about assembling EEZ BB3 Enclosure & Bare Boards kit version: https://www.eevblog.com/forum/projects/building-log-for-eez-bb3-enclosure-bare-boards/

[DL8RI]

Thanks Denis,

I did no see that thread. In case I encounter trouble, I will ask there...

[prasimix]

... also feel free to join Discord server, where you can ask about kit assembly on #kit-assembly channel.

[timbuktoo]

prasimix,

I've been using my BB3 to charge some 12V lead acid batteries using one of my DCP405 modules.  Lead acid batteries are typically charged with a constant current / constant voltage (CC-CV) charge profile.  In the past I've used a lab power supply with the output voltage set to the desired CV setting (13.8V in this case) and the current limit set to desired CC setting (C/3, 2A for this specific battery).  When I set the DCP405 to 13.8V/2A and begin charging a  battery, the supply output voltage is pulled down to the battery voltage (as expected), but the current reading on the meter jumps around tens of mA, and both the CV and CC LEDs are illuminated on the front panel. 

I haven't measured any signals inside the DCP405 to confirm this, but I believe what is happening (as predicted by Kleinstein in the quote at the bottom) is:

• DCP405 attempts to output 13.8V
• Battery draws CC limit of 2A, so `CC_ACTIVE` is asserted, turning Q27 on
• Q27 on changes voltage "setpoint" to ~90% of 13.8V, ~12.4V
• At 12.4V, the battery no longer pulls CC limit of 2A, so `CC_ACTIVE` is de-asserted, and the output returns to 13.8V
• repeat until the battery no longer pulls more than the CC limit

Another datapoint that makes me think Q27 voltage setpoint shift is causing this CC/CV crossover oscillation is I've noticed that if the battery is drawing CC limit, when I change the output voltage to be >~10% above the current battery voltage, the CC/CV oscillation stops. 

Have you noticed these oscillations before?  I'm also able to get them to happen using an electronic DC load, although the region where oscillation occur are much smaller than the CC region of a lead acid battery charge.

So it looks like the problem with CC to CV cross over at low currents is not so unique, just the current where it happens can be different.

In the circuit there is the part with Q27 that could be part of the problem. It seems to turn down the set voltage a little (some 10%) when in CC mode, with the idea to limit voltage overshoot when recovering. With a very low set current this could cause trouble: when no longer in CC mode Q27 turns off and raises the voltage. With a very low current setting, the voltage regulator part may call for more than the limiting current to charge the output capacitor. This would cause to get back into the CC mode. This could cause the slow oscillation / hart beat.

I see another problem with this circuit part: with a current limit just a little lower than needed to get the full voltage with a resistive load (e.g. 10.1 V and 10 mA setting with 1000 Ohms load resistance) the CC mode would engage and set the voltage limit down below the correct 10 V value.

For the low current range one could check the current readings. E.g. get some 10 mA and check with an external DMM - if the range switching is bad the current could be much lower (e.g. nA to  µA range) - though probably more current from leakage. So if the shunt switching does not work, it would probably be way off.

[prasimix]

Yes, I noticed that oscillation and Q27 is a nasty compromise between keeping fast rising time without overshoot, and without taking extra care about that in firmware. Perhaps we should remove Q27 and modify firmware to take care of that.

[exe]

Yes, I noticed that oscillation and Q27 is a nasty compromise between keeping fast rising time without overshoot, and without taking extra care about that in firmware. Perhaps we should remove Q27 and modify firmware to take care of that.

May be it's possible to tweak values of components around to make it more stable? Like tuning r118 and c42.

[prasimix]

Yes, that is one possibility but it probably just move "sweet spot" when CC/CV oscillation happens. I spent some time in the past trying that, it may be worth another attempt to at least obtain documented behavior.

[timbuktoo]

Yes, I noticed that oscillation and Q27 is a nasty compromise between keeping fast rising time without overshoot, and without taking extra care about that in firmware. Perhaps we should remove Q27 and modify firmware to take care of that.

Hmm.  I'm not crazy about this CC/CV oscillation.  I've used a reasonable variety of supplies from a number of the "big name" vendors (to charge batteries and "normal" use), and the exiting behavior caught me by surprise. 

Certainly there is a trade off between between rise time and overshoot.  What were/are your design goals for the rise time and overshoot, and how did the addition of Q27 improve/change things?

[prasimix]

Huh, that's a long story. The reference values ​​were those achieved in the H24005 project.
It all started with the fact that I dared to allow another person, who is in every way better at knowing power electronics, to suggest a different circuit from Leonid's used in the power module of the H24005 project. As can be seen Leonid used a MOSFET as a pass element. BJTs are now used, compensations are simplified, a different down-programmer is used, etc. At first glance, everything was very promising, but as I continued to test, certain problems began to appear. One of them was an overshoot that first went to deal with the RC elements on the DAC outputs, which solved the matter but the rise time thereby was significantly worse than in the previous design. Another option was to software-control the DAC settling time. I wanted to avoid this so that Martin has less work on the firmware side. So at one point the idea arose that during the rising edge when the CC mode is active, it is used to "shorten" by a certain percentage of U_SET value. The problem arises when the set I_SET is very close to I_MON and the CC_ACTIVE signal intervenes on the U_SET which also affects the I_MON, the CC mode is no longer active, which raises the U_SET again and the result is a small oscillation.

[Kleinstein]

The CC/CV cross over part can be tricky.  There are several strategies to reduce / aviod overshoot in the CC / CV cross over - most of them have some downsides.
A main problem is that the voltage regular would run into a from of regulator wind-up and thus reacts only with a delay.
A common method is using a rather large capacitor at the output so that the voltage would rise only slow - also not ideal.
A anti windup circuit is nonlinear and thus tricky to understand / calculate. One often has problems with the recision due the diode leakage and the like.

One could improve a bit with a few more tweaks in the compensation. However it takes more than just a littel different capacitor values.
One way to reduce the windup part is having some of the capacitance for the compensation from behind the diodes that combine the CC and CV regulation. This can reduce the wind-up part quite a bit, though a smaller rest remains. It is still not easy and needs new adjustment.
Changes at the compensation can be deep rabits hole - one can do a lot in simulation, but this is only as good as the modells are. So one still need real world test.

[timbuktoo]

I appreciate the additional background. 

I definitely recognize the benefit on reducing firmware complexity by keeping the core of this control loop in hardware.  Expanding a little on your suggestion to "Remove Q27 and modify firmware", one idea I've had is to remove Q27, then monitor when the DCP405 is in constant current mode in firmware.  If constant current is active and the measured voltage is more than a fixed voltage (1 or 2 volts?) below than the set voltage, reduce the set voltage to only be a fixed voltage above the actual voltage.  In this scheme, the worst case wind-up is limited, and overshoot when returning to CV mode should be limited as well. 

Other than complexity, another downside I see in pushing this part of the control in firmware could reduce the CC->CV recovery time, although I'm not sure that is necessarily bad, and I don't think CV->CC would be impacted.  I see there is a 'tickSpecific()' function in the DCP405 firmware https://github.com/eez-open/modular-psu-firmware/blob/c2db0051fa3d715b066e551637c37ebbed3dcee5/src/eez/modules/dib-dcp405/dib-dcp405.cpp#L273 where some other quasi-control actions happen.  How often does this tick get called?

I'd like to spice the control loop and play around with some control ideas, I'll report back if I have any more "good ideas".

Thanks for all the work to make the BB3 and taking the time to listen feedback from a total stranger.  I'm really impressed with my BB3 and how much capability is packed into a little box!

[prasimix]

I see there is a 'tickSpecific()' function in the DCP405 firmware https://github.com/eez-open/modular-psu-firmware/blob/c2db0051fa3d715b066e551637c37ebbed3dcee5/src/eez/modules/dib-dcp405/dib-dcp405.cpp#L273 where some other quasi-control actions happen.  How often does this tick get called?

It is called once every 1 ms (it's set "resolution" of FreeRTOS).

[timbuktoo]

I've looked more closely at the oscillation and I think its a bit larger than the "tens of mA" I initially described.  Below is a screen shot from an oscillation I datalogged and the magnitude of the oscillations are closer to 100 mA pk-pk.  I believe I had the current limit set to 150mA in this case.  Looking at these oscillations with my oscilloscope, I'm confident what I see in from the BB3 datalog is severely aliased (the oscillation are in the ~kHz range - it depends on a variety of factors battery SoC, current limit, etc), but the current magnitude I see with my scope across a shunt are in the same range (50 - 100 mA pk-pk) as this datalog plot.  All my batteries are fully charged right now, I'll discharge them and see what this oscillation current looks like at higher charge rates. 



In the course of charging my lead-acid batteries, I've been working on a micropython script implementing a CC-CV charge profile with preset suggestions for lead acid and li-ion batteries.  Its not quite ready for prime-time-sharing, and I'm undecided on whether I think this oscillation will have a negative impact on a battery but here are a few screen shots in case anyone is interested.

Main page:


Pressing the `calculator` button takes you here.  You can select li-ion, lead acid presets or custom cell voltage and C-rate values. 


While the charge is running, the elapsed time and Ahr delivered to the battery update along with the current battery voltage and current.  The datalog can also be checked while the charge is ongoing. 


And when the charge terminates you can see the charge stats.


The ability to run custom micropython scripts and interface with the native BB3 GUI is super cool!  I've never used a "big name" power supply that can do that    Between the documentation on your website, the existing scripts on GitHub, and the Discord community I was surprised how easy it was to get this running. 

[prasimix]

Thanks for great new MicroPython script. Looking forward to see it available to other users 

[poorchava]

Probably a bit late, but there is a really nice chip for +/-2.5V supply. LM27762. Can basically convert 3.3 or 5V into bipolar 2.5V at some 100mA or so. We used it with ADS131A02 in a 4.5dogot designs without any problem.

[prasimix]

Thanks for suggestion. It's price is very attractive and provides more then enough power on both rails. I’ll keep it in mind for one of the next revisions.

[wizard69]

I'm a bit late to this bus question but I have to point out that I'm not a big fan of IDC in this sort of application.   IDC ribbon cables are ideal for use them once and not touch them again applications but I find the reliability sucks if you need to change configurations often.

There likely isn't a perfect answer here but I'd rather see defined screw type terminal blocks.   More so if the goal is to support custom cards that might not allow for a nice cleanly located header.  Along the same lines it probably wouldn't hurt to have the ability to internal route trigger lines ideally with connectors that are not plug compatible with anything else in the interior.

IDC an ribbon cables would best be saved for internally mounted digital channels.   Even here though you would need a well defined bus.   I'm not even sure if such a bus even makes sense for the current goals of BB3.

I'm working of "finalization" of MIO168 module. As you probably know it should offer mixed I/O (hence MIO) where both digital and analog signals can be processed. The following idea came to my mind: as we already have a "power bus" on BP3C for different types of power output coupling, why not add an "analog bus" through which certain signals can be passed without the need for external cabling. A new bus would be placed on top of the module, with e.g. 2mm IDC connectors.

I wonder if someone may have already come across this way of connecting to refer me to a brand or model that has it, so I can see what they have to offer on such a bus.

[wizard69]

This sounds more like a dedicated interface than a bus or maybe I'm misunderstanding what people want for an analog bus.   

By the way your interface to the hypothetical DMM card and an associated scanner card would be a very nice set to have in the future for BB3.   However I'm not thinking bus here.

An analog bus to me anyways, is a set of signals that get transmitted from card to card.   These could be timing signals, trigger signals, well defined voltage signals or even a serial bus.   The only reason for them would be to supplement what is already in the BB3.    One set of signals that would be nice on an analog bus would be for E-Stop functionality to use if BB3 is in an automated test station. I'm not sure if the BB3 hardware supports such an ENABLE that can be used to put modules into a safe state. 

I don't follow this thread as much as I should so maybe I'm off base but a connection to a scanner card does not seem to fulfill the role of an analog bus.   It is something I'd like to see but I just don't see it as a bus.

I guess the ‘obvious’ application is to connect signal relay MUX cards to a hypothetical DMM card.

For that you actually wouldn’t need many wires (e.g. a ‘deluxe’ implementation of ground, guard+, force+, guard+, sense+, guard+, guard-, force-, guard-, ground) so 8-10 pins would probably work. Of course, if you might want to move some current around, you’d need paralleling.

I think Kleinsten’s right about using standard 2.54mm pitch and leaving room for different jumper options. If you go 15-way could you reuse parts from the main board to auxiliary board IDC?

On ribbon cable vs rigid PCB: cables have their issues but are tolerant of misalignment. A previous design I did had a PCB base board on the bottom and a PCB bridge board on the top and it got quite hard to get all of my cards lined up and plugged in without one leaving over.

Of course, it might be better to revisit the backplane for v2

[prasimix]

Thanks a lot for your inputs! You're right about naming: it's more like dedicated interface then a bus. Idea is remove a need to externally wire e.g. MIO168 with SMX46 or MUX14D. This tiny 2mm pitch IDC looks pretty good in reality, and cables once connected should not be moved often.

E-stop functionality can be provided via digital inputs (DIN1, DIN2) on the MCU module that are exposed on the front panel, and accept 3.3/5 V logic. If it is to be a switch then it can be connected between a digital output (DOUT1, DOUT2) and a digital input. Then the MCU can instantly interrupt/inhibit all installed modules.

[prasimix]

I'd like to open discussion here about @fietser28 proposal on Github #94 to upgrade existing remote voltage programming with current programming and to make control signal "floating" (#93). I'm planning to eventually add that change in next production batch of DCP405 module since it doesn't compromise obtained CE approval.





 

[Kleinstein]

The circuit makes some sense, but I think the LED function should be inverted, so that the LED would light if the external values is used. So far the LED would light up if an external set value is used and since one would usually only have 1 external set-point, the LED would be essentially always be on.

I would put the protection for the input behind the resistors - so with a moderately to high voltage nothing would blow and just the resistors get slightly warmer.

The TL072 OP may not be the best choice, as it would need a relatively large supply and is not rail to rail out. This way the voltage from the OP may exceed the supply of the CMOS switches.