EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: prasimix on June 21, 2018, 03:27:24 pm
-
EEZ BB3 crowdfunding campaign (https://www.crowdsupply.com/envox/eez-bb3) on Crowd Supply
Forum discussion about crowdfunding: https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/ (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/)
User manuals on English and German are available online: https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/1-introduction.html (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/1-introduction.html)
(https://i.imgur.com/tTIvhGh.png)
I'm opening this new thread since it does not strictly belongs to existing two threads: one about what is called EEZ H24005 programmable power supply (https://www.eevblog.com/forum/projects/diy-programmable-dual-channel-bench-psu-0-50v3a/) and another discussing DIB ("DIY instrumentation bus") (https://www.eevblog.com/forum/projects/diy-instrumentation-bus-(or-dib)/).
This one is about making EEZ H24005 a) even more modular and b) more “completed” design/project that does not include ready-made modules. That also does not imply that EEZ H24005 project is dead, and that people who built it or get it via crowdfunding campaign cannot count on further support.
Currently EEZ H24005 is modular in the sense that so-called Power modules (http://www.envox.hr/eez/bench-power-supply/power-board.html) are independent from digital control (Arduino Shield (http://www.envox.hr/eez/bench-power-supply/psu-digital-control.html)). Theoretically one can make another Power module with different capability and functionality as long as its dimension are within 165 x 74 mm and can use 26-pin connector for both power and control lines.
One possibility is to redesign that module in line with proposed DIB where PCB could be 145 mm tall and 170 mm wide (or even wider). That gives enough additional space to host a complete AC/DC power converter, what will be presented in future posts.
More “completed” design mean replacing of used ready-made modules with "home made" design. In case of the EEZ H24005 that means giving up from Arduino Due, AC/DC module (from Mean Well) used to deliver 48 V for Power Board and AC/DC module (from Vigortronix) for delivering 5/12 V for powering Arduino Shield and 12 V cooling fan.
Mentioned changes are not trivial at all (i.e. cannot be done in few days): replacing Arduino Due means migrating firmware to the new platform and replacing AC/DC parts include playing with mains voltage that require different discipline during development and testing to stay alive and also provide something that is robust enough to be safe and secure during operation under all (or at least imaginable but practically possible) conditions.
Just that two reasons are enough to keep topic separated from existing EEZ H24005 project since even if I succeed with it that don't necessarily means that many people will be interested to cope with different MCU and especially with circuit that works with mains voltage.
-
I was entertained with the idea to replace AC/DC power module or mains transformer with some “in-house” solution almost from the beginning of my programmable power supply adventure. But shortly after EEZ H24005 crowdfunding campaign fulfillment was completed I starts to think more seriously about it. The similar situation was with thinking about alternative for used Arduino Due. I'd like here first to address AC/DC power module since I spent much more time on it then to MCU alternative.
AC/DC power module that should replace existing Mean Well LRS-150-48 (48 V/155 W) is designed taking into account the following features:
- Wide input AC voltage (e.g. 85-265 Vac) without using a 115/230 Vac switch (also called universal AC input, full-range input, etc.)
- Widely adjustable output DC voltage 2-42 Vdc or more. Therefore it can replace not just Mean well's power AC/DC module but also pre-regulator stage of the Power board build around LTC3864.
- Over-current/short-circuit protection
- under-voltage and over-voltage protection
- Min. 200 W of continuous power
- Bias power supply with all needed fixed voltages for the existing Power board (replacing LTC3260 on the Power board for generating required negative voltages)
- Active/Synchronous rectification for better power efficiency (e.g. lower thermal losses)
- Compact design that both power and bias stage are within Mean Well’s module dimensions (i.e. 159 x 97 mm)
I've decided to give a try to the AC/DC converter topology that is possible unusual for such purposes but was recommended by the person who is a sort of “living legend” when comes to power analog electronics who is actively, massively and selflessly helping many DIYers (including me) on couple of regional (Serbian) forums. His name is Dragoljub Aleksijevic, known as Macola. Therefore presented AC/DC converter (that acts as power pre-regulator and bias power supply) is more or less my attempt to make alive what Macola in one moment suggested.
A couple of disclaimers/clarifications is needed here: first, he also suggested more advanced topologies that can serve as efficient power pre-regulator and has better EMI since there are not hard-switching, but since this was my first attempt to make power AC/DC converter I selected one that will be presented shortly. As you will see there include a lots of interesting details and challenges. Secondly, I was already spent many months on it and I'll try to squeeze a whole adventure in a few posts. Therefore it's quite possible that I'll forget to mention many important details so feel free to ask any kind of questions and I'll try to answer it by myself or by asking Macola for assistance.
The topology is called current-fed dual inductor converter (CF-DIC), that evolved from single inductor converter (or SIC) presented for the first time in the article Filho, Barbi (1996), A comparison between two current-fed push-pull DC-DC converters-analysis, design and experimentation (https://www.researchgate.net/publication/3673781_A_comparison_between_two_current-fed_push-pull_DC-DC_converters-analysis_design_and_experimentation).
The following picture shows basic components for converter's topologies presented in above mentioned article:
SIC:
(https://i.imgur.com/NV6KutS.png)
… and DIC:
(https://i.imgur.com/XTpsf04.png)
A list of DIC benefits over SIC topology is also presented and I'll mention it here for getting a better picture:
- Voltage across the switch is 50% lower, hence switching components stress is lower
- Transformer require only one primary coil and peak volt-ampere is 50% lower
- Input inductor current is 50% lower (a cheaper/smaller inductor can be used)
- Smaller current ripple and rms current in the output capacitor
- Slightly smaller switches rms current
- Inductor switching frequency is 50% lower (hence smaller losses)
What Macola proposed is a little bit different and with having in mind from the start what controller IC could be used to serve that purpose:
(https://i.imgur.com/sVGoxGu.png)
It has buck stage at the input that can be used to change duty cycle when PP (push-pull) stage is working with fixed duty cycle. In a way PP stage serve as a “DC transformer” (mind quotation marks here) that isolate primary from secondary side of high-voltage buck. Both buck (synchronous) and PP driver stages can be found in TI's LM5041B (http://www.ti.com/product/LM5041B) PWM cascaded controller. It include push-pull outputs that can be used to drive PP stage directly but with fixed duty cycle that is set to 50%. Depends of chosen topology, i.e. voltage-fed or current-fed PUSH and PULL outputs can be generated with programmed dead-time or overlap-time.
Driver signals overlapping is of paramount importance since neither of DIC inductors should be disconnected at anytime. That will induce a huge voltage that will shortly destroy one of the switching elements (MOSFETs in our case).
PP switching frequency is derived from buck stage frequency that is twice as much higher and set with external resistor.
How it works
Using Macola's words the following steps is an overview of important facts during operation:
1. Vin is switched on (first half cycle). HI-BUCK MOSFET and one of the PP MOSFETs (e.g. PUSH) are turned on. DIC1 inductor between them is connected to the full voltage (almost Vin) and current in it is rising following the dI = U / L * dt
2. When PWM time is expired, HI-BUCK is turned off and DIC1 inductor is trying to keep its current (Iend) to flow in the same direction. That current flow is preserved thanks to LO-BUCK MOSFET that is turned on (when expire dead-time after HI-BUCK is turned off). The PUSH MOSFET is still conducting. At the DIC1 inductor ends we have almost short-circuit condition (i.e. the major voltage drop is caused only by Rds, on of LO-BUCK and PUSH MOSFETs). Following the same law of dI = U / L * dt current change will be minor since voltage is small (about 1 V) hence we can consider that current is constant (e.g. Iend is still unchanged).
3. Just prior then PUSH MOSFET is switched off, PULL MOSFET is switched on (as defined with overlap time) and connect its end of primary coil to the ground. Otherwise when PUSH MOSFET is turned off both primary coil's ends will be left unconnected and the voltage on both drains will go into infinity (with disastrous outcome for one or more components). PULL MOSFET also connect its inductor (DIC2) to the ground and new Buck cycle is starting that is now charging DIC2 inductor.
4. Short overlap time is expired and PUSH MOSFET is turned off and voltage on its drain reach primary coil's Vclamp value (since its other end is grounded). Other end of the primary coil, that is connected to the switched off PUSH MOSFET is now behave as an accumulator that is charging and has Vclamp potential. Current thru DIC1 has Iend value and is now flowing thru the primary coil.
5. DIC1 inductor potential is now Vin – Vclamp, because Buck hi-side period is active. Since it was previously shorted and preserve Iend current, that current is now decrease slowly since a small voltage difference exists between its ends.
6. HI-BUCK is turned off again, and its voltage drops to LO-BUCK voltage drop (e.g. -Vd). DIC1 inductor has now Vclamp - (-Vd). The voltage difference is now much higher and current thru DIC1 inductor is falling much faster supplying the primary coil. DIC2 inductor has a constant current and its captured by short-circuit caused by PULL MOSFET conduction state and waiting that PULL MOSFET be turned off that it can start to flow into primary coil that will be reversely polarized in that moment.
7. Prior then PULL MOSFET is switched off (during the overlap period) now the PUSH MOSFET is turned on and “catch” its side of the primary coil, PULL MOSFET is turned off and current is continue to flow in other end of the primary coil that is reversely polarized.
… and the whole cycle is repeated over and again.
CF-DIC with short overlap time can be interpret as two boost converters that works in counter-phase with duty cycle a slightly over 50% and which load behind rectifiers is Vclamp. That means that the almost same rule is applicable for DIC inductor's calculation, where their supply is the buck stage, and average voltage of it pulses can be used as a DC source.
Output Vclamp on the Cout is reflected/mirrored on the primary coil proportionally to the transformer transfer ratio (Np/Ns). For example if Vclamp (i.e. converter's output voltage) is set to 10 V with transformer ratio N = 2 we'll have 20 V on the primary coil ends despite the fact that DC bus voltage is 325 Vdc (rectified 230 Vac).
Vclamp that is reflected/mirrored on the primary side can be seen as a voltage source with certain internal resistance. Therefore primary coil behaves as voltage source what is result of such heavy capacitance load. That load is necessary since it directly define its Vclamp. That is quite opposite from voltage-fed converters.
-
Now, I'll present what is assembled and tested so far, but first a short list of features:
- Wide AC input 85-265 Vac
- Wide DC output: 3-52 V controlled by tracker circuit
- Max. current 5 A continuously (i.e. max. power is 260 W)
- Synchronous rectifier
- Over-current protection (OCP) set to ~7.3 A
- Output over-voltage protection (OVP) set to ~54 V
- fsw, buck= ~68 kHz, fsw, pp= ~34 kHz
- QR flyback as bias power supply
A complete circuit (without QR flyback) can be split into two main section. Lets start with Buck/PP stage with DIC power inductors and transformer:
(https://i.imgur.com/WN88yqA.png)
As already stated LM5041B is used as main controller for this CF-DIC. It's PUSH-PULL outputs can deliver respectable 1.5 A peak and it's used to drive directly PP stage MOSFETs. Situation with buck portion is different. Its outputs HD, LD are TTL and require driver IC. Buck is working with high voltage (e.g. 325 Vdc) therefore a HV driver is also required. But, additionally to just HV driver, an isolated driver Si8233 (https://www.silabs.com/products/isolation/isolated-gate-drivers/si822x-3x-isolated-gate-drivers) from Silabs is used that improve separation of low-voltage/small signal and hi-voltage/high power grounds. As two power inductors Murata 60B684C (https://www.murata-ps.com/en/60b684c.html) are selected and finally one very interesting part (also suggested by Macola): a transformer that is winded using VAC core (T60006-L2025-W380 (https://www.vacuumschmelze.com/fileadmin/Medienbiliothek_2010/Produkte/Kerne_und_Bauelemente/Anwendungen/Kerne/Kerne_SKDs_Kunststoff/W380.pdf)) with Vitroperm 500 F core material. It allows us to work with lower switching frequency (~34 kHz) while flux density could go easily up to 0.5 T instead of 0.3 T suggested as upper max. (Bmax for most of the other core materials.
Thanks for it's high permeability give us primary coil with high inductance using fewer turns. Making such transformer wasn't a big deal. I made first one in less then a ten minutes in the following way: first I make a braid with multiple wires for primary coil and insert it into heat shrinking tube with very small diameter. That tube alone is certified for 600 V that in combination with existing wire insulation is more then enough in our case, since voltage on primary coils in worst case (the highest Vclamp of 52 V) shouldn't go over ~104 V. Such prepared primary "braid" is combined with braid for secondaries of the same length (that is valid for 2 : 1 : 1 ratio), secondaries braid is bend on half and I simply start with windings. The end result is looks like this:
(https://i.imgur.com/WpzCIki.jpg)
Doesn't look professional, but so far didn't make any trouble nor audible noise under any circumstances (if control loop compensation is properly set :)).
FB pin is grounded as usual in situation when secondary side is isolated and COMP pin is used instead for setting output voltage by changing duty cycle of HV buck stage.
LM5041B is powered from +12 V provided by QR flyback that will be presented later. But A-side of Si8233 needs +5 V and instead of providing additional bias voltage or stepped-down +12 V, a REF output from LM5041B is used for that purpose!
An diode clamping circuit is added in the PP stage to return back to the DCbus elcos (C34, C35) a part of reactive energy that exists due to L(sub)lk, pri(/sub) (primary coil leakage inductance) reducing the stress of the RC snubber over primary coil. Anyway, that energy cannot be transferred to the secondary side.
As one can see all MOSFETs are SiC (Silicon-Carbide) that is especially beneficial for HV buck side. Also diodes D13, D15, D18 and D19 are SiC, too. SiC diodes are suggested since they don't have undesirable recovery time nor recovery current. Therefore they put less stress on related circuits: D13 to AUX bias power supply, D18 and D19 to PUSH-PULL MOSFETs (Q5, Q6). D15 is added as a “support” for low-side buck MOSFET (Q3) or its body-diode. D16 which is ordinary Schottky is added for more balanced supply between hi-side and lo-side buck supply (VOA and VOB).
-
Hi Prasimix
I too have been wondering about a very similar topology (using a single buck inductor and H bridge for primary winding) for a similar application: wide range output.
There are three things I really like about this style: it only uses a single primary windin, is easy to protect against output short circuits, and should be able to provide a wide output voltage variation to efficiently supply the linear post regulator. There are a couple of things which make me nervous: where the CT goes, and the transformer isolation.
Maybe I'm just chicken, but I'm worried about people making their own transformers. This is because it's a safety part which has to stand off big surge and spike voltages of 2500 V or more. I'm concerned that someone might nick the insulating sleeve, or not allow enough creepage distance from the ends, or have some trapped metal particle that gradually rubs through, or... I suggest you plan to source a commercially built and Hi Pot tested transformer for this project. It will provide a margin of safety for the less experienced builders, and probably reduce the risk of you getting in legal trouble ("Your Honour, I made sure that the safety critical part was tested.") Also, the leakage inductance will be more consistent in a commercial product.
As it comes to the switching devices, I think your primary switches could be superjunction Si MOSFETs because they don't switch in pairs. Also, maybe the buck stage could use one Si MOSFET and an SiC freewheel diode (with a little efficiency loss...)
-
Hi Prasimix
I too have been wondering about a very similar topology (using a single buck inductor and H bridge for primary winding) for a similar application: wide range output.
There are three things I really like about this style: it only uses a single primary windin, is easy to protect against output short circuits, and should be able to provide a wide output voltage variation to efficiently supply the linear post regulator.
Yes, in fact this topology is inherently resilient against output short circuit.
There are a couple of things which make me nervous: where the CT goes,
That is not visible on the first sheet of schematics. I'll explain that in the next coming post.
... and the transformer isolation.
Maybe I'm just chicken, but I'm worried about people making their own transformers. This is because it's a safety part which has to stand off big surge and spike voltages of 2500 V or more. I'm concerned that someone might nick the insulating sleeve, or not allow enough creepage distance from the ends, or have some trapped metal particle that gradually rubs through, or... I suggest you plan to source a commercially built and Hi Pot tested transformer for this project. It will provide a margin of safety for the less experienced builders, and probably reduce the risk of you getting in legal trouble ("Your Honour, I made sure that the safety critical part was tested.") Also, the leakage inductance will be more consistent in a commercial product.
I was instructed when both primary and secondary wires are insulated with heat-shrink tube that gives margin of 3 kV, or 1.5 kV when only secondary wire is insulated. My hand-made transformer shown above has insulation of primary side only. I presumed that can provide an equal strength to the former example.
As already described we have here a much favorable situation then in case of e.g. flyback where on primary coil we have Vin, dc + Vclamp * N that could easily goes over 450 Vdc.
But, please note that if anything is happen with this project in the future I'm not going to wind dozens (or hundreds) of transformer by myself :). Therefore I already contracted Polish company Feryster (http://feryster.pl/) that send me yesterday picture of a prototype built in accordance with specification:
(https://i.imgur.com/waWwUBc.jpg)
As it comes to the switching devices, I think your primary switches could be superjunction Si MOSFETs because they don't switch in pairs. Also, maybe the buck stage could use one Si MOSFET and an SiC freewheel diode (with a little efficiency loss...)
I've used MOSFETs in my first prototype, IPA60R380P6XKSA1 for hi-side buck and push-pull MOSFETs and IPA60R120P7 for lo-side buck. Results was disappointing, but I suspect mainly due to badly routed PCB. That is one reason why isolated driver is used in current prototype. Maybe on the next PCB prototype I can try Si MOSFETs again but I think that one for hi-side buck should remain SiC. Lo-side could be removed and leave just SiC diode.
As you can already see I'm not so concern about BOM cost for this converter. I'm more interested to get robust and flexible design that can be easily scaled in the future if required. Selected topology promise easy upsize to couple of kW of output powers, but also a even wider output voltage. In that sense I'm particularly interested to build in the next step a converter which output voltage can go up to 400 Vdc and e.g. 500 W that can be used while building another SMPS :). Additionally (if that happen at all), with different transformer I believe that is possible to make a converter with output of few kV that can be used as source for some ESD testing and HV experimentation.
-
Regarding MOSFET selection I think that is worth mentioning how buck output looks when output voltage is approaching minimum value. For example, if set voltage is 4 V (current is above 1 A) it looks like this:
(https://i.imgur.com/Il4rhtM.png)
Pulse (inverted) is just 320 ns long and this is for 120 Vac (170 Vdc) and for 230 Vac it has to be even shorter! With SiC MOSFET is works like a charm.
-
The second sheet of the schematics include secondary side with current sense transformer, synchronous rectification, control loop and tracker circuit:
(https://i.imgur.com/k8uDPkN.png)
Current sense transformer is dual primaries Murata 54100C (https://www.murata-ps.com/en/54100c.html) (1:1:100 ratio) that is connected on the less noisy point on the secondary side. It's isolation strength is 1.2 kVrms. Current sensing transformer could be also deployed on the primary side, e.g. between PUSH-PULL MOSFETs drains but in that case we could experience higher drain's “capacitive noise” since they are not connected directly to the power GND. Another possibility is to put it before buck stage, when single transformer with single primary coil is sufficient. I didn't test that possibility.
With dual primaries and full rectification we can count with nice output that can be used for current limitation that is on LM5041B set to 500 mV. Value of termination resistor (RT) is set about 6.8 Ω (R52, R53 in parallel) that limit output current to about ~7.3 Apeak that give us enough margin for working max. of 5 A. R51, C55 makes RC low-pass filter on the CS input pin.
Synchronous rectification (SR) is accomplished with IR1168 (https://www.infineon.com/cms/en/product/power/ac-dc-power-conversion/ac-dc-pwm-pfc-controller/synchronous-rectification-ics/ir11688s/) and MOSFETs with very low Rds, on. Today there is a quite a lot MOSFETs that are advertised as suitable for SR. But in our case with such wide output voltage we have to take into account (and I forgot that a couple of times, with predictable results :() that its Vds, max has to be twice as high then output voltage (if transformer ratio N = 2). Such MOSFETs are still easier to find in TO-220 package then e.g. in DPAK. Also regardless of how small is Rds, on, for 5 A output you can still expect dissipation that goes over 1 W. That shouldn't be a problem since if enough free or forced air circulation can be insured. Usually SR MOSFETs has extended temperature range of 175 oC. Otherwise TO-220 could be more practical, but it has to be mounted with terminals as short as possible.
Above mentioned IPP147N12N3 (https://www.infineon.com/cms/en/product/power/mosfet/20v-300v-n-channel-power-mosfet/120v-300v-n-channel-power-mosfet/ipp147n12n3-g/) has Vds, max of 120 V and Rds, on of 14.7 mΩ. Another great candidate that is more expensive but still reasonably priced is IRFB4115PBF (https://www.infineon.com/cms/en/product/power/mosfet/20v-300v-n-channel-power-mosfet/120v-300v-n-channel-power-mosfet/irfb4115/) that goes up to 150 V with Rds, on of 9.3 mΩ.
You can find in attachment spreadsheet for calculating IR1168 working params that I made following its application note.
Of course, if dissipation and overall efficiency is not an issue SR can be replaced with suitable diodes (e.g. I've tested STTH802 for 200 V/8 A).
Finally, we have to close a loop to have regulated output voltage. Control loop resides on the secondary side and its output has to be isolated from COMP input pin of the LM5041B. Toshiba TLP291-GB.SE-T that is more compact then usually used optocouplers and also has swapped C and E output pins! First and obvious part for closing a loop is TL431 and it was used at the beginning and is enough if fixed output is needed (in that case neither separate aux power supply is needed, just additional secondary coil for AUX +12 V power). But, primary purpose of this CF-DIC is power pre-regulator that should provide variable output. That calls for tracking circuit that will monitor post-regulator Vout and modulate control voltage for the LM5041B. Usually, a PNP tracker is suggested (such solution is used between EEZ H24005 pre-regulator and post-regulator), but I found two disadvantages of TL431 + PNP tracker solution. First, it's more challenging to set loop compensation that works when post-regulator is in CV and especially CC mode. Another one that can be disastrous without adding additional protection (i.e. output OVP) is that any interruption/disconnection between tracker input and post-regulator output could easily increase CF-DIC output voltage to destroy secondary stage (what was happened to me twice when IR1168 and one or both SR MOSFETs were destroyed).
Therefore I was looking for other solution. First I came to pretty nice, and until recently a completely unknown for me TL103W (http://www.ti.com/product/TL103W) that is also used for control loops of SMPS, especially when constant current is needed (as in LED drivers). It is consists of two op-amps where first one has internal voltage reference of 2.5 V connected to non-inverted input. That first op-amp is replacing TL431 (that is not an ordinary op-amp) and output voltage applied to its inverting input via voltage divider (R63R69 + R73) set max. voltage on the CF-DIC output, and represent output OVP. The tracking functionality is accomplished by voltage divider's GND potential (i.e. lower end of R73). If R73 is connected to 0 V we'll have max. output voltage and it can be decreased by increasing R73 potential and for +2.5 V (that corresponds to voltage reference value), its output will fall to zero. Such tracking control I was found in an Electronic Design article (http://www.electronicdesign.com/boards/simple-switchers-make-simple-pre-regulators). Possible disadvantage of such tracker is that it require dual rail supply but that is not an issue in my case since bias power supply already offer +5/-5 V for powering post-regulator control circuits. The reference voltage has to be inverted (IC8A) and control voltage has to be within voltage reference range (0 – 2.5 V) and for that buffered signal (IC8B) from post-regulator CV control loop is used. IC8 is TL072 since it's already used on post-regulator side for lower BOM count.
This tracker works really nice and track CV to CC mode changes including short-circuit condition with voltage difference set to about 3 V. Currently it have only one obstacle: it cannot push output down to zero (it's about 0.11 V). Therefore when post-regulator output is approaching 50 V it cannot provide more then 1.5 V difference. Perhaps I failed to arrange TL103W and TL072 op-amps: if TL072 is used in place of second TL103W op-amp it could be possible to go down to zero since it is powered with dual rail. Here is what I have with current setup (I intentionally spread last few volts to highlight non-linearity caused by TL103W inability to pull output down to 0 V):
(https://i.imgur.com/YDdMIRm.png)
That is all for now about "theory" of CF-DIC. I'll start to publish some measurements before I continue with bias power supply that is also part of this design.
-
Current sense transformer is dual primaries Murata 54100C (https://www.murata-ps.com/en/54100c.html) (1:1:100 ratio) that is connected on the less noisy point on the secondary side. It's isolation strength is 1.2 kVrms.
Hmm. The isolation rating on that CT seems a bit low. I would happily put that somewhere int he primary side (e.g. in series with main MOSFET) but I suspect it only counts as functional isolation, and isn't sufficient for user safety. It's more work, but I do wonder
Regarding MOSFET selection ... Pulse (inverted) is just 320 ns long and this is for 120 Vac (170 Vdc) and for 230 Vac it has to be even shorter! With SiC MOSFET is works like a charm.
That is quite short. Maybe someone could look at a superjunction Si MOSFET as an optional cost-down.
I've used MOSFETs in my first prototype ... Results was disappointing, but I suspect mainly due to badly routed PCB. That is one reason why isolated driver is used in current prototype. Maybe on the next PCB prototype I can try Si MOSFETs again but I think that one for hi-side buck should remain SiC. Lo-side could be removed and leave just SiC diode.
I do like isolated drivers for that - even if you allegedly don't need isolation they can really simplify design by breaking ground loops.
-
Current sense transformer is dual primaries Murata 54100C (https://www.murata-ps.com/en/54100c.html) (1:1:100 ratio) that is connected on the less noisy point on the secondary side. It's isolation strength is 1.2 kVrms.
Hmm. The isolation rating on that CT seems a bit low. I would happily put that somewhere int he primary side (e.g. in series with main MOSFET) but I suspect it only counts as functional isolation, and isn't sufficient for user safety. It's more work, but I do wonder
Ok, the user's safety is of paramount importance that we can agree easily (hence your concern). Please let me know what is the worst case scenario here that CT could become dangerous? It's from one side connected to Out+, and on the other to the CS input of LM5041B that is isolated from HV buck using Si8233 and use AUX voltage from bias power supply (still not presented) that is isolated flyback. LM5041B is directly connected only to PUSH-PULL MOSFETs gates. Therefore we should have a multiple breakdown from buck isolator to LM5041B to CT or from AUX power to LM5041B to CT or from PUSH-PULL MOSFETs to LM5041B to CT.
If we want CT on the primary side, then I'd like to put it before buck stage rather then to PUSH-PULL drains to GND. In that case we don't need dual primary CT.
-
I did a quick search for superjunction MOSFETs and price comparison based on Mouser offerings. The currently used SiC is the cheapest one but it is still 2.85 EUR. But most of the superjunction's from e.g. Vishay offerings easily goes over 3 EUR and their performance is still inferior to SiC. Let me know if you eventually find something that is worth testing (still I can bet on inferior performance with wide output voltage). The real issue with selected SiC (and most of the others from the same family/manufacturer) is possible supply shortage. I can easily imagine a huge demand for such kind of device.
It's obvious that this project is not BOM optimized, but that is not my intention. I'm not here in competition with other (more BOM friendly) topologies that is in the first place mostly built for the fixed output voltage.
-
In this post I'd like to present some measurements that were performed on the primary side of the CF-DIC and could be of interest for further discussion and to potential builders.
Input voltage was 120 Vac (using isolation transformer), and CF-DIC output is set to 20 V by tracking post-regulator output of 17 V since as you can seen in the following picture on this (second) prototype PCB (“DIB format”) I put together complete CF-DIC, bias power supply and post-regulator that is copied from EEZ H24005 project. Additionally a provisional AC filtering is added and DIB interface section (that has to be tested).
(https://i.imgur.com/DDj9UKc.jpg)
In this revision TL431 with PNP tracker was used and QR flyback is based on controller that I'm going to change in final release (but more about that later). Also I still have to decide between two options: to leave together pre-regulator and post-regulator on the same PCB or to separate them on two PCBs: one with pre-regulator for 2 channels and another with post-regulators for 2 channels!
A few words about how I started to test a whole thing that is well known to experienced builders but could be helpful for beginners like me.
First, a different discipline is highly required from the start. That means that you cannot simply start to play with such type of circuits when you are tired, or your attention is shared between e.g. nowadays uninterrupted “noise” flow from from PC or "smartphone" screen or with someone that just came into the room and want to chat about weather, sport results, home affair, etc. Single mistake and ... puff, you can count on various damages that could cost at least you time and money with presumption that you was lucky and wasn't injured! Some people are using Plexiglas shield that are usually advertised for conducting chemical experiments (perhaps something like this (https://i.imgur.com/ryf9L7z.jpg)).
Secondly, I'd highly recommend that never, ever start with connecting the circuit to the mains voltage before you are completely sure that all parts works as predicted under load. I did it in few steps: at the beginning, with the first (non-SiC) prototype I was using EEZ H24005 set to its max. 80 V (that required to adjust ULVO voltage divider otherwise LM5041B will not start. You have to readjust it again when switch to the mains especially 230 Vac) and with foot pedal control for output control! Huh, that was a "life saver" few times :). Then I used next what I have on the bench as that is an old prototype of EEZ H24005 that goes a little bit higher up to 100 V. Of course in both cases a current limitation is used very conservatively/cautiously that resulted even in “soft-starting” of the HV bulk elco charging :). After that a 230/120Vac isolation transformer is used when working with 120 Vac is actually even more interesting since it put more stress on the input stage since required current is higher then with 230 Vac. Basically if everything seems to work fine with 80/100 Vdc power supply you can expect good results when connected to the AC input, first indirectly using isolation transformer and then directly.
Another important thing is scope, and I don't want to recommend such adventure without one. I'm using scope with ground connection isolated from the grid (since I don't have an differential probe). Don't ever try to think about using grounded one and touching anything on the primary side. Needless to say you cannot use same isolation transformer secondary to power both scope and CF-DIC. Use two separate transformers or one with dual and separated outputs.
Additional warning is needed for working with SiC MOSFETs: never, ever touch hi-side buck gate pin with your scope probe when circuit is powered on!
If you'd like to monitor signals on both primary and secondary side, take care about you GND connection. You'll broke in that manner ground separation (isolation) and when do that it's better to make it locally i.e. on the PCB then making a huge loop that goes over probe cable and ends up on the scope side.
On the picture below is shown how the latest working prototype PCB looks like from the bottom side. As one can expect there is a lots of modifications, one is already mentioned that is different control loop and tracker for what I made a small PCB instead of redoing a whole PCB once again. Instead of initially planned DPAK sync MOSFETs I'm using now more capable one (i.e. higher Vds, max) that are listed in schematics (IPP147N12N3GXKSA1). I've also added LC filter on the pre-regulator output and additional Cbulk (totaling 300 uF) for lower ripple when working with 120 Vac. 230 Vac works quite good with even single 150 uF, but in final version I'm going to use 2 x 120 uF.
(https://i.imgur.com/sMS4Ngx.jpg)
Let's start with measurements of all LM5041B control signals: HD, LD, PUSH and PULL.
Iout=1 A and due to single GND connected to one end of Cbulk that are fare away from LM5041B signals looks a little bit “messy” but in reality they are way better with proper probe grounding.
(https://i.imgur.com/wEhE6Ih.png)
With different timebase we can see e.g. that PUSH and PULL signals are overlapped.
(https://i.imgur.com/0x2hIUj.png)
Next measurement include buck output (DIC inductors input) and PP stage:
(https://i.imgur.com/sDYQHr8.png)
Without load primary coil ends (connected to PUSH and PULL MOSFETs) to ground:
(https://i.imgur.com/nSr3Gir.png)
… or better presentation when single probe is connected to the primary coil ends:
(https://i.imgur.com/xkUjDTi.png)
When Iout=1 A it looks like this (“top” voltage is 40 V for Vout=20 V):
(https://i.imgur.com/9VzD45a.png)
DCbus ripple for 3.5 A looks like this:
(https://i.imgur.com/iGCXsLc.png)
… and current transformer output on its termination resistor (non-filtered) for the 3.5 A (it's a little bit below half of scale since Imax is set to ~7.3 A):
(https://i.imgur.com/JAadG9S.png)
I don't have a current probe and cannot present any current measurement, neither thru DIC inductors, transformer or other parts of interest. Something that I'd like to have much more is thermal imaging. Phew, that could be something.
Please let me know if I forgot to mention some important measurement on the primary side, and I'll try to do it.
-
I suggest you check the voltages around the buck FET during the switching transition. You need to look out for big spikes or ringing.
The catch is that SiC devices are fast. As you said, the gates are very sensitive. Small stray capacitances and inductance can cause big problems. So crank up your scope to maximum bandwidth and see what you can see. Then work out whether the rise time in the screen is the rise time of the circuit or the rise time of your scope + probe. I have blown up circuits before because there was an short & nasty spike that I didn’t have the bandwidth to see.
While I do most of my power e work with the 20 MHz bandwidth limiter on, there are times when you need a 500 MHz scope to see the truth.
-
I suggest you check the voltages around the buck FET during the switching transition. You need to look out for big spikes or ringing.
I'm not sure how to achieve this, just to put probe tip in the near proximity of gate pin? I can for sure pick up some switching noise. Or a whole exercise is to see if some glitches exists and are interpolated to hi-side control signal?
-
A few screenshots of buck output, measured between hi-side MOSFET drain and source, with 70 MHz BW and 1K on probe tip. Vin=120 Vac, Vout=51 V, Iout=3 A:
(https://i.imgur.com/vzCiSqj.png)
... Rising edge:
(https://i.imgur.com/8okwIMc.png)
and falling edge:
(https://i.imgur.com/0HRFOyE.png)
EDIT: And same output without load:
(https://i.imgur.com/1SIHFjO.png)
-
Sorry, wrote some stuff just as you were posting. Will address at lunchtime (gotta run to work).
Ok, the user's safety is of paramount importance that we can agree easily (hence your concern). Please let me know what is the worst case scenario here that CT could become dangerous? It's from one side connected to Out+, and on the other to the CS input of LM5041B that is isolated from HV buck using Si8233 and use AUX voltage from bias power supply (still not presented) that is isolated flyback. LM5041B is directly connected only to PUSH-PULL MOSFETs gates. Therefore we should have a multiple breakdown from buck isolator to LM5041B to CT or from AUX power to LM5041B to CT or from PUSH-PULL MOSFETs to LM5041B to CT.
If we want CT on the primary side, then I'd like to put it before buck stage rather then to PUSH-PULL drains to GND. In that case we don't need dual primary CT.
OK, the CT secondary is connected to main DC bus 0V by the LM5041. This is connected to the incoming AC line via, I guess, a diode rectifier. From a safety perspective, that counts as connected. We therefore see that the weakest isolation between the DC output (which humans can touch) and the AC line is the CT. If the AC line is subject to a big spike (e.g. a circuit breaker opens / closes under heavy fault 'nearby' in the power system), large transients can be generated (>1kV). The CT probably isn't rated to reliably stop that, and if the insulation fails it will short mains potential into user-accessible terminals.
I see three approaches to resolving this:
- Place CT on primary side somewhere. This particular failure mode goes away.
- Use CT with 'reinforced' isolation
- Put LM5041 control chip on the isolated output side. This will involve some messing about (e.g. how to power it, adding isolated gate drive to primary MOSFETs). If you're using the DIB interface, there should be some DC power available to run the LM5041 for you, and maybe replace the QR flyback aux supply. (Note: buck converter chips are available to generate a little bit of non isolated 12V from 100 - 400V DC to drive primary MOSFETs.)
-
OK, morning tea time, so let’s have a look at those waveforms.
Straight away, they look suspiciously clean. Maybe your layout’s excellent, or maybe something is hiding.
Rise and fall times are approx 38 ns from ‘scope measurements. Given rule of thumb of BW (GHz) = 0.35 / tr (ns), get 0.35/38 = 0.0092 GHz BW, I.e. approx 10 MHz, which is within ‘scope capabilities. I suggest cranking the timebase up so we get more details on the transient. It should ideally take approx half the screen.
I’m a little concerned about the 1k series resistance. The Rigol 10x probe could have up to 15 pF capacitance, which gives a time constant of 10 - 15 ns. This is approx 10 - 16 MHz BW.
These bandwidths match up, so I suspect that what you’ve actually measured is the 1k resistor and ‘scope probe capacitance.
Also, were you using the probe clip and alligator clip ground? These aren’t good for higher frequencies.
Could you send a picture of your probe setup? We may be able to do much better.
-
Ha, ha, now that looks funny for me. Yes, it's almost suspiciously clean that one can think that source is something else or that pictures are doctored/Photoshoped :). But it wasn't so funny with my first prototype, quite contrary. I believe that current result is combination of multiple factors: GND isolations (thanks to Si8233), better PCB layout and use of SiC MOSFETs.
1K in combination with probe makes a RC filter. I've repeated measurements from the last post this time just with x10 probe applied between drain and source as shown on the next picture:
(https://i.imgur.com/t1fV3g0.jpg)
"Zoomed out" buck output, no suspicious glitches are visible:
(https://i.imgur.com/IFT7CMP.png)
... rising edge:
(https://i.imgur.com/dnwq28w.png)
... falling edge:
(https://i.imgur.com/HrObJHR.png)
... and without load:
(https://i.imgur.com/28I7f1C.png)
-
I see three approaches to resolving this:
- Place CT on primary side somewhere. This particular failure mode goes away.
- Use CT with 'reinforced' isolation
- Put LM5041 control chip on the isolated output side. This will involve some messing about (e.g. how to power it, adding isolated gate drive to primary MOSFETs). If you're using the DIB interface, there should be some DC power available to run the LM5041 for you, and maybe replace the QR flyback aux supply. (Note: buck converter chips are available to generate a little bit of non isolated 12V from 100 - 400V DC to drive primary MOSFETs.)
I think that first suggestion is the most practical one. I didn't find better CT so far with better margin or reinforced isolation. Most of them have just functional isolation of 500 Vrms for mounting on the primary side. Making a custom one just make things even more complicated.
Moving LM5041B on the secondary side asks for two additional gate isolation transformer for driving PP stage. Powering Si8233 is not a big issue since bias flyback AUX output can be step-down to required 5 V.
I'll try to incorporate Murata 53100C (https://www.murata-ps.com/en/53100c.html) on the existing PCB and see what will happen.
-
Ha, ha, now that looks funny for me. Yes, it's almost suspiciously clean that one can think that source is something else or that pictures are doctored/Photoshoped :). But it wasn't so funny with my first prototype, quite contrary. I believe that current result is combination of multiple factors: GND isolations (thanks to Si8233), better PCB layout and use of SiC MOSFETs.
1K in combination with probe makes a RC filter. I've repeated measurements from the last post this time just with x10 probe applied between drain and source as shown on the next picture:
That's more like it. A 10ns fall time is approx. 35 MHz BW (and I think you said you had a 70 MHz 'scope?) so you're probably good. We see a little bit of a spike, which is normal and expected. I suggest you also measure the drain-source voltage on the other MOSFETs, with the following questions in mind: is the signal I'm measuring within the bandwidth of my equipment and am I seeing nasty spikes / oscillation?
We'll have to think up a method for measuring current flow - perhaps you could cut a track and solder in a low value shunt between the synchronous rectifier FET and the 0V point (without messing up the gate drive loop!)?
With rise and fall times around 10ns, you could go down to 100ns minimum pulse width (maybe even 50%), which may allow you to increase the frequency and reduce the size of passives in the supply. Depends on switching losses.
(I once blew up a full set of 6 MOSFETs due to using a 50 MHz probe and not seeing a big 70 MHz oscillation. They went with a bang and sprayed some chunks of epoxy around the place.)
The new CT you're thinking of is rated to 500V, but that means tested at 500V RMS for 1 second. Insulation ages, so I would be a bit worried about that lasting for 10 - 20 years with 380V DC across the insulation. You need to look at not just isolation voltage, but also operating voltage.
-
I suggest you also measure the drain-source voltage on the other MOSFETs, with the following questions in mind: is the signal I'm measuring within the bandwidth of my equipment and am I seeing nasty spikes / oscillation?
The following screenshots were taken on lo-side MOSFET. Yes, I'm still on 70 MHz Rigol. I have an old analog 100 MHz Tek, but taking screenshots is not so simple (I need to call someone to take it while I'm probing signal on the PCB).
(https://i.imgur.com/mXoxNkL.png)
(https://i.imgur.com/1jlNDLm.png)
(https://i.imgur.com/PfKtIcx.png)
... and without load:
(https://i.imgur.com/AR7RTKn.png)
I didn't manage to destroy any MOSFET (that can be an explosive event) so far in normal operation. But I had two incident (in the same day thanks to lack of discipline mentioned in one of previous posts!) when I've touched, actually shorted two pins directly on the LM5041B instead of probing on neighborhood parts :phew:. End results was failure of multiple parts (LM5041B, Si8233, SiC MOSFETs), but fortunately without explosion.
-
Tried yesterday 1:100 Murata 53100C on buck input with unsatisfactory results as I expected (at least in comparison with current solution). Output waveform looks like this:
(https://i.imgur.com/uiUoRwV.png)
... or "zoomed out":
(https://i.imgur.com/xWQdaMf.png)
Even if that is acceptable, it is not attractive solution for wide input voltage range. If I found current limit for 230 Vac range it will be too small for 115 Vac and vice-versa, proper threshold for 115 Vac will be way too high for 230 Vac.
I found yesterday Pulse Electronics P0582NL (https://hr.mouser.com/ProductDetail/673-P0582NL) with 3 kVrms margin that is reportedly UL-C/UL recognized component, but it is too large for my current PCB. Therefore I have to rearrange/resize PCB layout. Other possibility is to reinforce current CT margin using opto-coupler circuit.
-
I'll try to do something with existing CT by enforcing its isolation by introducing an opto-coupler and TL431. That could be still cheaper and smaller solution and provide even higher margin than any off-the-shelf CT alone. This is a first simulation that can be used as starting point for real testing:
(https://i.imgur.com/pjF7ZFg.png)
-
That seems like a lot of bits, and I think it’s the wrong approach.
Firstly, the LM5041 is a peak current mode controller (with slope compensation) and needs a high speed analog current measurement to work properly. Your circuit doesn’t provide that.
Secondly, that’s a lot of extra components. If one of them fails you loose all current control and things get very risky.
Have you considered putting a CT in series with the transformer primary? It should be voltage clamped by the secondary output voltage.
Alternatively, you could place a 0.1R (approx) current sense resistor in series with the return current from the push-pull FET source pins. This effectively measures the total inductor current for you. Losses would be quite small.
Also, the C3M280090D is in a big TO247 package which is good for cooling and bad for parasitic inductance. If you look at the C3M280090J, it’s in an SMT package with less leakage inductance and a Kelvin Source pin for improved gate drive. The switching losses are halved for the SMT version.
-
That seems like a lot of bits, and I think it’s the wrong approach.
Firstly, the LM5041 is a peak current mode controller (with slope compensation) and needs a high speed analog current measurement to work properly. Your circuit doesn’t provide that.
Secondly, that’s a lot of extra components. If one of them fails you loose all current control and things get very risky.
It's wrong approach rightly in a order as you said: this circuit doesn't provide correct (pulsed) signal that can be used for slope compensation, and require much more components that is not so bad if its sum is cheaper then CT on secondary side with reinforced insulation.
Have you considered putting a CT in series with the transformer primary? It should be voltage clamped by the secondary output voltage.
Alternatively, you could place a 0.1R (approx) current sense resistor in series with the return current from the push-pull FET source pins. This effectively measures the total inductor current for you. Losses would be quite small.
Neither of that looks promising to me, especially adding anything in series with the source pins. Maybe with ordinary MOSFETs but not with SiC. Therefore I'll proceed with testing what is possible to do with adding CT at the buck input as started in post #20. I believe that better results can be achieved.
Also, the C3M280090D is in a big TO247 package which is good for cooling and bad for parasitic inductance. If you look at the C3M280090J, it’s in an SMT package with less leakage inductance and a Kelvin Source pin for improved gate drive. The switching losses are halved for the SMT version.
I'm aware of SMT package but also that it has much higher Rds, on (385 instead of 280 mOhms). If THT pins are inserted as much as possible (as I have now) I think that Llk is acceptable (anyway oscillograms looks fine). Also organizing cooling of THT is a way simpler then SMT. With min. heatsink it can provide half of output current without need to start fan. With bigger heatsink (e.g. if enclosed in chassis that is used for cooling) I belive that no fan will be required at all.
-
About CT insulation requirements: why don't you use a CT without a primary coil and use a suitably insulated wire (or wire + silicon sleeve) to reach the required insulation rating?
I know CT w/o primary are bigger, usually for larger currents etc... but you still can find something small enough I think.
As an alternative that I tried in the past, very good in terms of speed and accuracy, are open loop Hall effect sensors (LEM, Tamura...). They came also w/o primary and I managed to get my required 4kVdc insulation rating by using a wire + silicon sleeve.
-
About CT insulation requirements: why don't you use a CT without a primary coil and use a suitably insulated wire (or wire + silicon sleeve) to reach the required insulation rating?
I know CT w/o primary are bigger, usually for larger currents etc... but you still can find something small enough I think.
Yes, the main reason why I don't want to use such packaging is their dimensions. So far I didn't find anything that can fit within e.g. 10 x 10 mm. They can by default offer reinforced insulation that is important if CT is on the secondary side as @jbb warned me, but if I succeed to manage measurement on the primary side then functional insulation should be enough. Also I already find few single primary CT in small package the can withstand 1000 or 1500 Vrms, if Murata 53100C with its 500 Vrms is not suitable.
-
The problem with my first attempt to measure current on the primary side was that existing PCB wasn't designed to include CT and distance between Cbulk and hi-side MOSFET is very short. Without lots of thinking I was cut Vin trace before Cbulk instead of cutting that short trace between Cbulk and MOSFET! When I realized that I've managed in the second attempt to insert Murata 53100C (1:100) as shown below:
(https://i.imgur.com/U2gXVrT.jpg)
New schematic for current measurement is now looks like this:
(https://i.imgur.com/Cak94HB.png)
Output from CT is measured directly on the CS pin of LM5041B, PCB looks now even more messy but still everything works just fine :)
(https://i.imgur.com/6oELeSe.jpg)
Measurement for Vin=120 Vac (170 Vdc) and Iout=2,5 A:
(https://i.imgur.com/Yhqj4II.png)
... or Iout=5 A and compare it with previous measurement reported in #20 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg1635272/#msg1635272):
(https://i.imgur.com/I3DMLep.png)
-
Now with current measurement in place it's good to check how stressful is start-up. LM5041B as many other controllers has SS (soft-start) pin for limiting duty-cycle on power up. Soft-start sequence is also initiated every time when fault condition (e.g. Vcc under-voltage or Vin under-voltage) is no longer present. First I've tested it with SS capacitor with 10 nF that is apparently too low. Start-up current with 110 W load connected (Vout=44 V, Iout=2.5 A) looks like this:
(https://i.imgur.com/ubafUqD.png)
Much better result can be achieved with considerably higher value (e.g. 100 nF):
(https://i.imgur.com/0gyTcXA.png)
-
A clarification/correction is needed about SR controller that is presented in #6 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg1623355/#msg1623355). Infineon IR1168 (https://www.infineon.com/cms/en/product/power/ac-dc-power-conversion/ac-dc-pwm-pfc-controller/synchronous-rectification-ics/ir1168spbf/) min. operating voltage is set to 8.1 V (typ.) by ULVO protection therefore +7 V rail shown in that schematic does not work. Actually, if you try to power up the circuit, sync MOSFETs (Q6, Q7) will be disabled, but rectification will be in place using MOSFET's body diodes giving an impression that everything is working fine! But it is not a case and that can be easily proven by checking MOSFETs dissipation and of course gate drive signal that does not exist.
In my first prototype I had about +9 V for driving IR1168 but in latest prototype QR flyback offers just about +6.5 V (that is step-down with LDO to +5 V). Therefore in the final PCB I'll use IR11688 (https://www.infineon.com/cms/en/product/power/ac-dc-power-conversion/ac-dc-pwm-pfc-controller/synchronous-rectification-ics/ir11688s/), a similar model which working voltage goes down to 4.5 V.
Anyway, that IR1168/IR11688 is a great controller that withstand up to 200 V (Vds) without any extra circuits (like e.g. SRK2001). So far I didn't find anything even closer to it in the same price range. Also don't look for IR1163 as lower operating voltage IR1168 version announced (http://www.irf.com/product-info/fact_sheet/acdc-smartrectifier.pdf) for 2014. It seems that it is branded/labeled as mentioned IR11688.
-
Finally I'll present aux/bias power supply section that is required to power on primary side LM5041B (and indirectly Si8233 A-side through LM5041B) and on secondary side NFB control/tracker, Sync. rectification (SR) controller and provide all required voltages for connecting post-regulator similar to one used in EEZ H24005 Power board.
Coming to the final solution was an expectedly long journey caused with lots of presumptions and lack of experience. On the first CF-DIC PCB prototype I tried to use PI's TNY266GN flyback controller with few off-the-shelf transformers that has enough secondaries (four in total, or 3 + 1 AUX if you like). I was especially eager to see how Feryster's 2399 (http://dokumentacja.feryster.pl/rysuj.php?lang=pl&indeks=6205d38d6d1f18194e504d7689c3e94d) transformer will behave but end result was unacceptable, I suspect because of its primary inductance that is too low.
Mentioned controller is well packed and integrated (e.g. does need external switch and protection circuitry) with reasonable price.
In the meantime I found few interesting Quasi-resonant (QR) flyback controllers also well integrated and for even better price. I've decide to give a try to the latest (5th generation) ICE5QR4770A controller. Once again I found that mentioned Feryster is not a solution, and I tried another off-the-shelf transformer this time from WE (750811914 (https://katalog.we-online.de/en/ctm/MID-OLEFD/750811914?m=n&sp=https%3A%2F%2Fwww.we-online.com%2Fweb%2Fen%2Fwuerth_elektronik%2Fsearchpage.php%3Fsearch%3D750811914#vs_ct:2)). This time I found another issue, ICE5 for unknown reason cannot start with been "kicking off" by applying shortly required bias supply. I tried to solve that with assistance of Infineon support but for unknown reason it didn't want to start, possibly because some of its protection mechanism is triggered.
Finally I found ST's VIPer family of QR controllers and decide to use VIPer35 (https://www.st.com/en/power-management/viper35.html) in my latest prototype. In parallel I've arranged with people from Feryster to design a custom transformer (https://www.eevblog.com/forum/projects/assistance-for-finding-flyback-transformer-with-3-outputs-are-needed/msg1644737/#msg1644737) in accordance with my specification.
That was a wining combination: nice flyback with broad input voltage range that works in QR mode with all needed output voltages. The latest schematic for that part of the CF-DIC is shown below. AC input section will be shared with CF-DIC power section.
(https://i.imgur.com/PoW2JcC.png)
Measurement on VIPer35 Drain pin without load (Vin=230 Vac):
(https://i.imgur.com/W7fT7yx.png)
... or with moderate load applied:
(https://i.imgur.com/UGU3wOd.png)
It's clearly visible that VIPer35's internal MOSFET is switching on at the lowest point. That can be adjusted for the used transformer by changing the value of Rlim (R19).
Usual way of providing precise enough and cheap control loop with TL431/TL432 is not used since all critical outputs are additionally regulated by BJT or LDOs. Therefore just zener diode (ZD3) is used to set a main secondary output voltage.
Perhaps "double" rectification of AUX secondary shared between powering VIPer35 (D8, ZD2) and LM5041B (D1, Q1, ZD1) is not needed and can be reduced to single circuit. I have to test that further.
Your suggestions and comments are welcomed as usual.
-
I've decide to make CF-DIC as a separate/stand-alone module that is within size of Mean Well LRS-150-48 module previously used in EEZ H24005 project. All files are now available on the GitHub under CF-DIC (https://github.com/eez-open/CF-DIC) project. I'm going to order new PCB soon after some additional checking is performed since new layout is quite different from previous one but I believe that it should work nicely.
(https://i.imgur.com/7GvUdQ3.png)
(https://i.imgur.com/NtTl5FC.png)
-
Would you like some review help with it? I can see a couple of points that are quite close (and could still be fine, given the scale involved...)
-
Of course, just go ahead! I can provide separate images of only top and bottom layer traces for better visibility if you cannot open Eagle file.
-
In case that converter is housed in metal chassis I'd like to insert insulation sheet between bottom PCB layer components and metal plate.
I'd like to know what is a trade name for such insulation when ordering from suppliers. Here is how it looks like in Mean well module:
(https://i.imgur.com/gFQgyVa.jpg)
-
I've added in latest revision an optional temperature alarm based on simple LM211 (IC10) comparator and NTC (see Sheet 3of3 (https://raw.githubusercontent.com/eez-open/CF-DIC/master/EEZ%20CF-DIC%20r3B4%20Sheet3of3.png)). It is intended to pull-down PWRGOOD signal when temperature near one of sync mosfet become very high (currently set about 85 oC). NTC is SMT and it's located near Q8. Maybe that is not the best way how to accomplish temperature monitoring neither the best component: we can expect that some of SiC MOSFETs will be much hotter during the operation but my logic is that sync mosfet heating will increase proportionally.
Also instead of controlling PWRGOOD signal that require external agency for turn-off input voltage or remove connected load, another possibility is to block NFB optocoupler (OK2) or even LM5041B by inhibiting ULVO input while error state is reached. Former should be simpler while later asks for another optocoupler or moving a whole temperature monitoring circuit to primary side and power it from +12 V that is just fine for the LM211.
-
Thermal protection on the primary side of the converter could be something like this:
(https://i.imgur.com/142GrgL.png)
LM211 comparator is monitoring voltage on non-inverting input that comes from voltage divider with NTC (e.g. 10K/3570K). Reference voltage (that is stable enough) comes from LM5041B (REF pin) via R56/R59 divider. When temperature becomes critically high (and NTC value will decrease), LM211 will trigger Q5 that will pull to ground ULVO input until new power recycle. I've selected this method over comparator with hysteresis since it should be used only when something went terribly wrong.
-
Are you sure you can guarantee the minimum holding current of the SCR, with such high value resistors?
-
I've tested the circuit with a little bit larger SCR (MCR08) instead of specified "baby" NYC0102BLT1G (SOT-23 case), and triggering and holding is working fine repetitively.
-
What I see as a possible issue here is unwanted triggering due to some glitch in AC line that is picked-up by LM211. I've tested it on the breadboard and can simulate such situation with powering on ancient Weller soldering station that is on the same power line. I believe that situation when everything is on the PCB will be better, or suggested comparator/SCR circuit has to be improved?
-
Ok, it seems that quick remedy is to simply reverse a whole circuit and move up threshold level that will add extra immunity:
(https://i.imgur.com/dVZtPMY.png)
-
Just to be sure, I would place some capacitors to ground on both LM211 inputs, to aid immunity. You don't need us triggering speeds for temperature protection. And maybe a cap in parallel to ZD5?
I've tested the circuit with a little bit larger SCR (MCR08) instead of specified "baby" NYC0102BLT1G (SOT-23 case), and triggering and holding is working fine repetitively.
Hopefully you never come across a "right by the limit outlier" component ;D Usually for extremely low currents, an SCR made up of standard bipolar transistors works better, it has very low holding current.
-
And maybe a cap in parallel to ZD5?
Perhaps I can just move existing C42 to other side of R45, but I think that its current placement in combination with ZD5 that I must added to not exceed abs. max. ratings of ULVO (i.e. +7 V) for upper Vin give us a robust enough solution against glitches.
-
That's ok as well. It's just that I don't like fast switches discharging capacitors with no current limitation. That as well can cause glitches. Putting C42 directly on IC pin limits its discharge current.
That's really nitpicking on my side, of course :D
-
You mention on your website that the QR flyback is routed poorly, might I ask what parts in particular you feel need to be rerouted (its in the name :p), I figured out a nicer way of packing the LP2951, but I believe your referring to the viper35 side?
-
Have you considered putting a CT in series with the transformer primary? It should be voltage clamped by the secondary output voltage.
Alternatively, you could place a 0.1R (approx) current sense resistor in series with the return current from the push-pull FET source pins. This effectively measures the total inductor current for you. Losses would be quite small.
Neither of that looks promising to me, especially adding anything in series with the source pins. Maybe with ordinary MOSFETs but not with SiC. Therefore I'll proceed with testing what is possible to do with adding CT at the buck input as started in post #20. I believe that better results can be achieved.
Most likely I am out of my league here, but IMHO shunt and isolation amplifier, like Si8920 could be solution... perhaps. It's Up to 5000 Vrms for 1 minute after all. Just two cents obviously
-
You mention on your website that the QR flyback is routed poorly, might I ask what parts in particular you feel need to be rerouted (its in the name :p), I figured out a nicer way of packing the LP2951, but I believe your referring to the viper35 side?
You mean on the GitHub (https://github.com/eez-open/CF-DIC) not website? The latest PCB that was an attempt to clean up a jungle that grew up over the time (and shown on #10 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg1628840/#msg1628840) and #26 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg1652909/#msg1652909)) and to separate pre-regulation from post-regulation stage since that gives at the end much more flexibility.
CF-DIC (for pre-regulation) works on that PCB almost suspiciously good :-/O, but during the reorganization of the whole PCB layout I made a fatal mistake by putting LM5041B beneath power inductors :palm:. The result is a sort of "over-synchronization" when RT input pin (used also for ext. sync) obviously is picking up noise when load is connected (or a sort of positive feedback loop is created) and working frequency jump into the sky (more then 20x higher then set frequency defined with RT resistor!). That alone make a whole PCB completely unusable.
Another issue is connected with QR feedback that is not so problematic to rectify: I tried to supply both VIPer and LM5041B from the same rectified AUX voltage, but it seems that VIPer don't like that. Therefore two separate diode + cap is required. But, it's also possible that such weirdness is connected to the first issue and that LM5041B starts to sink too much power trying to drive MOSFETs (PP stage in the first place) with insane frequency. I'm working on new PCB, not r3B8 that is on the GitHub but currently r4B4 :).
-
Have you considered putting a CT in series with the transformer primary? It should be voltage clamped by the secondary output voltage.
Alternatively, you could place a 0.1R (approx) current sense resistor in series with the return current from the push-pull FET source pins. This effectively measures the total inductor current for you. Losses would be quite small.
Neither of that looks promising to me, especially adding anything in series with the source pins. Maybe with ordinary MOSFETs but not with SiC. Therefore I'll proceed with testing what is possible to do with adding CT at the buck input as started in post #20. I believe that better results can be achieved.
Most likely I am out of my league here, but IMHO shunt and isolation amplifier, like Si8920 could be solution... perhaps. It's Up to 5000 Vrms for 1 minute after all. Just two cents obviously
Thanks for that, but I don't like to put anything in series with source pins. Solution with CT properly connected in series on the input side looks good, and cheap transformers with functional isolation exists (i.e. 500 V), and for one who wants better isolation it's possible to use with the same footprint with Hi-pot of 1 kV (possibly even 2 kV).
-
... I figured out a nicer way of packing the LP2951
I forgot to mention that I'll probably move LDO's to the post-regulator board to have them closer to the load (i.e. control circuits).
-
shunt and isolation amplifier, like Si8920 could be solution
Thanks for that, but I don't like to put anything in series with source pins.
I said nothing about source pins, just mentioned shunt+Si8920. Put shunt where CT was originally planned, not on source pins :)
-
Sorry, didn't got it at first.
-
I just finished new PCB layout and commited it at the GitHub (https://github.com/eez-open/CF-DIC). I'd going to send it to ALLPCB for manufacturing in the course of next week. If someone possibly have any comment on it please let me know.
-
While waiting for new PCB for CF-DIC I've managed to assembly the first prototype for new MCU board based on STM32F769IGT6 in LQFP176 package. This board is intended to be mounted perpendicular to the chassis front panel with exposed sockets and connectors for Ethernet, I/O port, Micro SD card, USB, encoder and user switch (LCD TFT connector will be hidden behind front panel).
Project files are available in the new repository on GitHub (https://github.com/eez-open/modular-psu/tree/master/mcu). Currently MCU board take care about the following peripherals and functionality:
- Digital I/O: 2 x protected inputs, 2 x protected outputs
- Rotary encoder with switch
- 1 x user switch
- 3 x SPI channels (2 x Chip selects per channel)
- Battery backup (CR2032 button cell type)
- USB 2.0 OTG
- Micro SD card
- Ethernet PHY (10/100 Mbit/s)
- I2C EEPROM
- JTAG IDC 20-pin connector
- SDRAM (e.g. IS42S16400J)
- TFT LCD with 0.5 mm FFC 40-pin connector (e.g. RFE43BH-AIW-DNS or RFE430Y-AIW-DNS)
- TFT backlight brightness control
- Resistive touch controller
- Soft-start/stand-by AC power control
- Audio amplifier with small on-board speaker
Selected MCU is capable of driving directly TFT LCD with SDRAM used as frame buffer (one or more). I also include 100 Mbit Ethernet and still have enough pins for up to 3 SPI channels and various other I/O. PCB is 4-layer and despite that I didn't manage to provide optimal connectivity between MCU and SDRAM chip, but it seems that everything works as shown on picture that follows (Nucleo board on picture is used just as debugger with SWD interface). I have to leave it overnight and make additional memory tests to check if existing layout is usable or a new revision is required.
The MCU board has 40-pin connector on the right side where 3 SPI channels are available to communicate with up to 3 peripheral module using additional "backplane" PCB that will be introduced in coming weeks.
So far we tested TFT LCD, SDRAM and USB (we acquired USB VID:PID for free thanks to pid.codes (http://pid.codes/)).
We found one issue that is I'd like to believe due to our inexperience with STM32: we cannot generate 25 MHz clock from PLLI2SR that is exposed on MCO2 output that is reported here (https://www.eevblog.com/forum/microcontrollers/stm32f7-problem-with-mco2-output-derived-from-plli2sr/). Without that Ethernet cannot be tested. If we failed to run it with 10 MHz as master clock, it is still possible to change master clock (HSE) to something else and use that HSE as input for the MCO2 MUX to get required 25 MHz.
I'll continue to report about progress of running up this prototype PCB (r1B1) and about migration of EEZ H24005 firmware to STM32 platform. Your comments and suggestions are welcomed as usual.
(https://i.imgur.com/ulRTgmrl.jpg) (https://i.imgur.com/m6vqKuol.jpg)
-
I should point out your timing margins for your gerbers where on the edge of the margin, but still a smidge inside them when calculated from the setup and hold times, it only violates the manufacturers requested trace matching,
I suspect it would only really kill your memory access reliability in very humid air when the velocity of the signals reduce a little.
-
We continued to test MCU board and found few small issues on the PCB that is reported on the GitHub's issue tracker. Situation with using MCO2 output for generating 25 MHz clock from 10 MHz master clock input is still unclear, I didn't receive so far any answer is that possible or not. Therefore I've changed master clock xtal to 25 MHz and use HSE as input for MCO2 mux and Ethernet is now functional.
The new AUX PS board is also finished and ready for testing. It include soft-start/stand-by as previous version but for up to 3 power boards. NTC instead of power resistor is used for soft-start due to smaller profile (has to be below 30 mm vertically). I have to test if it can survive charging of up to 6 x 120 uF.
Instead of Vigortronix AC/DC dual output module (5/12W, max. 5W) a VIPer35 QR flyback is employed with off-the-shelf transformer (Feryster or WE). The PCB is intentionally much wider (210 mm) since it include power AC inlet and power switch to reduce required wiring even more. It also carry standby LED and PE 4 mm banana binding post (not mounted on the picture below) that will be exposed on the enclosure's front panel.
Finally, a dedicated fan controller IC with I2C bus is used to assist MCU with driving fan with PWM and measure fan speed and ambient temperature.
(https://i.imgur.com/g3aZZdE.jpg)
Its schematics looks like this (linked from GitHub (https://github.com/eez-open/modular-psu/tree/master/aux-ps) repository where BOM, Eagle and Gerbers files are also available):
(https://i.imgur.com/w6eIJoO.png)
(https://i.imgur.com/1wwi9XO.png)
-
Yesterday, I finalized PCB layout for the new Power module that is successor of the Power board (https://github.com/eez-open/psu-hw/tree/master/Power%20board) used in the EEZ H24005 power supply. The working name of this module is EEZ DIB DCP505 and its design files is now available on the GitHub (https://github.com/eez-open/modular-psu/tree/master/dcp505) (the BOM section is still missing). Its PCB form factor (160 x 95 mm) is modified in line with new EEZ DIB chassis that I'll announce soon, and comes with few new features. The major and most interesting new feature is 3-range current auto-ranging circuit. It is proposed by my friend Macola after I struggling for some time with another approach that require presettable up/down counter and require more digital I/O lines for both set and read selected range.
This one require a little bit more parts but from other side it offer simple and elegant way how to set max. output current (I_SET) and read actual current (I_MON) both with information about active range (CURR_50MA, CURR_500MA, CURR_5A outputs).
The auto-ranger is designed to cover current from 0 to 5 A with automatic switching between measurement current sense resistors to achieve max. reading resolution that will be in our case 15-bit for each range, that is theoretically 0.152 mA for 5A, 15.2 uA for 500 mA and 1.52 uA for 50 mA range. That give us enough room to provide resolution of 1 mA, 100 uA and 10 uA respectively.The simulation files are attached.
Setting output current is simple: on the I_SET input one has to apply control voltage from 0-2.5 V. The control voltage range is divided in three equal parts i.e. 0-0.833 V, 0.833-1.666 V and 1.666-2.5 V. In our case with 16-bit DAC that give us possibility to define max. current for the selected range in 21845 steps (2^16 / 3) that is approx. 0.228 mA for 5 A (5 / 2^15), 2.28 uA for 500 mA and 2.28 uA for 50 mA range.
The schematic and LTspice simulation is shown below. Simulation tested the circuit with output current (Iload) that rise over the whole range (0-5 A) and with output current set with 1.5 V that put it somewhere in the middle range (500 mA) that can be seen on the latest graph (Ictrl) when error amplifier change its output state. As output current rise range indication outputs state are sequentially changed from 50 mA over 500 mA to 5 A.
The interesting detail is using of the D1 Schottky diode that is connected in parallel with range switching MOSFETs (M1, M2, M3). Thanks to that diode we have more freedom to choose MOSFETs with extra low Rds,on (i.e. below 5 mOhm) that is much cheaper and comes in much smaller package for Vds,max that shouldn't be larger then 1 V :). A prerequirement that everything works fine is that voltage over D1 never exceed ~200 mV when it starts conducting and influence measurement. That shouldn't be a problem since selected current sense resistors value gives max. 50 mV of voltage drop for the full range (e.g. 5A * 0.01R = 50 mV).
The current measurement op-amp (for ADC) in this circuit is U5, that together with U6 inverter should be precise, low-offset and wired with precise resistor to achieve high precision. I'm going to use OPA4197 (http://www.ti.com/product/OPA4197) for testing. A small offset (above zero) is intentionally introduced to U5 scale using R47 for calibration purposes, i.e. that DAC don't need to deliver negative output for 0 A value. Also the selected gain of U5 give us full-range value below 2.5 V, again that is intentionally done for the calibration purposes that DAC don't need to deliver "overflow" value above 2.5 V for calibrated output.
Another important op-amp that should be precise is U3 that provide measure current value to U2 and U10 that are in charge to switch between ranges.
The simulation files are attached. Please note that parts used in the simulation differs to some degree with one that I'm going to use and test on the prototype PCB.
(https://i.imgur.com/B88DoWK.png)
(https://i.imgur.com/6xwfgGK.png)
-
Other new feature on the Power module is "heavy-duty" OVP with triac and two fuses that should offer over-voltage protection in both direction: for the power supply and connected load. Theoretically it should manage and survive few hundreds of Amps, e.g. when 10000 uF charged to 50 V is connected on the output and discharging. How nasty such load could be is presented in the following spice simulation (zip file attached down below):
(https://i.imgur.com/Rj57wzn.png)
The max. current peak (440 A !) and its shape is defined with R2 and L1 and their value should be selected in accordance with what chosen triac could survive. The on-board OVP circuit looks like this:
(https://i.imgur.com/rfHdTn3.png)
Note that L1 inductance from the simulation is implemented directly on the PCB as spiral trace (see PCB bottom layer below). Its designed in accordance with the following calculation for number of turns and trace width:
(https://i.imgur.com/Rvt6UMY.png)
(https://i.imgur.com/sUPFkEC.png)
The R2 from simulation that is R110 on the schematics is THT and could survive huge current peak (See AC01000001007JA100 (https://hr.mouser.com/ProductDetail/594-AC01W0R100J) datasheet).
OVP triggering threshold is set to 10% above programmed output voltage (U_SET). When triggered, triac will short power output lines and stay shorted until power is recycled or voltage above its A1/A2 pins drops down. If we presume that OVP is not triggered by Power module internal failure, we can reset it by simply set 0 V as new output voltage or by disabling OE (Output enable) circuit.
The new Power module also comes now with on-board SPI temperature sensor mounted beneath heatsink for main pass MOSFET and down-programmer MOSFET. It is thermally coupled with 5 mm thick thermal pad.
Module specific information such as calibration data or number of working hours, etc. can be now stored into on-board I2C EEPROM and makes them completely portable. Therefore, for example, it is not needed any more to recalibrate a module when it change its position inside the EEZ DIB chassis or when its moved into another chassis.
Finally this Power module is intended to be powered with CF-DIC power pre-regulator and bias power supply that is mentioned at the beginning of this thread and its recent progress is covered here (https://www.eevblog.com/forum/projects/wide-input-and-output-range-power-pre-regulator-(85265-vac-2-552-5vdc-5a)/msg2010842/#msg2010842).
A whole Power module is packaged on the PCB shown on the following two pictures (thanks to the OSHpark PCB preview feature):
(https://i.imgur.com/UKsziBO.png)
(https://i.imgur.com/ccuUoos.png)
-
This is reply to the question asked by one forum member which PM box is full, and I cannot reach him :)
The DCP505 is part of the new power supply that has to be completed in the coming months and I have to order first batch of board in coming days. It also require CF-DIC as pre-regulator and does not use Discovery but our new MCU board (STM32F7 based with larger 4.3 TFT) that is powered by new AUX PS board. The latest files can be found on the GitHub repository (https://github.com/eez-open/modular-psu) (currently backplane and new chassis design is missing). Feel free to subscribe on it to stay informed about progress. Please also note that when we finished with development and testing that is highly probable that a new group buy or crowdfunding will be organized.
EDIT: Nucleo board shown in post #51 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg1849265/#msg1849265) is used only as debugger/firmware downloader, our MCU board is beneath TFT display. USB and/or SD card firmware downloader will be used in the final release, instead.
-
A small update of what's going on here. The power module (DCP505) PCB has been arrived and I found instantly a stupid error on it: the power inputs on one of quad op-amp was swapped :(. Fortunately that wasn't a big deal to fix and I was focused on testing two new features: on-board OVP and three range current auto-ranging circuit.
The OVP behave more or less as expected, but main reason why I am going to replace it is lack of proper latching. When I've designing its PCB I still didn't know that Maxim has some interesting comparators equipped with latch functionality and which does not in the same time cost a fortune. Therefore I'd like to try their MAX9141 (https://www.maximintegrated.com/en/products/analog/amplifiers/MAX9141.html) in the next PCB revision.
The auto-ranging circuit is first tested in CV mode, and it works as expected. Possibly the switching between ranges could be further improved by decreasing Rgate value for switching MOSFETs.
Unfortunately it doesn't works correctly when change in current range is happen in CC mode when current value is somewhere in-between two ranges. It is especially obvious on lower two ranges (50 mA and 500 mA). The problem lies in part of the circuit that is in charge for setting control voltage range (U11, U12, U13, U7 in schematic posted in #54 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2079841/#msg2079841)) and which directly affect the CC control loop and switch back and forth I_SET value when output current is just in-between two ranges resulting in output current oscillations. That section was added to increase precision of I_SET (i.e. that output current can be set in 21845 steps for each range). Currently I don't have any idea how to make auto-ranging circuit stable in CC mode then to remove that section and use ~76.3 uA (5 / 2^16) as the smallest step in all ranges. That means that resolution of defining current in middle range (0-500 mA) will be 10 times worse, and 100 times worse in the low range (0-50 mA) then in high range (0-5 A). Perhaps that is still acceptable since auto-ranging circuit is primarily of interest to improve precision of measured current value.
The new auto-ranging circuit should now looks like this (available also in attachment):
(https://i.imgur.com/wws7dDX.png)
-
Since I have now all PCBs/modules defined for completing a new power supply, I can present a new chassis/enclosure that I'm discussing with enclosure manufacturer (again Varisom from Portugal) which can house up to three modules (i.e. channels). While designing it I was struggling with lots of dilemmas mainly generated by effort to make it as compact as possible that it doesn't occupy to much space it it is going to be placed on the benchtop. I spent some time trying to organize everything inside it that it can be placed in two ways: horizontally and vertically when all content on the TFT display have to be rotated for 90 (or 270) degrees. I gave up for the moment of that concept because it will require introducing of new (soft?) material for making “feet” all around, on all four sides not just one, and that will additionally prolonged firmware development.
The new enclosure should house the following items:
- MCU board
- AUX PS board (for powering MCU board, 12 V DC fans, and “non-isolated” devices on the peripheral modules that are DCP505 power module for now)
- DCP505 power module (up to three)
- BP3C backplane for connecting MCU board with peripheral modules
- Up to three power pre-regulators (presented here (https://www.eevblog.com/forum/projects/wide-input-and-output-range-power-pre-regulator-(85265-vac-2-552-5vdc-5a)/)) for powering DCP505
- 4.3 TFT touch-screen display and
- Two 12 V DC fans
To get an idea how parts mentioned above are related to each other, I'll post first pictures of the working prototype that is currently used for firmware development:
(https://i.imgur.com/JjouL9U.jpg)
(https://i.imgur.com/QouWEUr.jpg)
The MCU board is placed horizontally just as backplane connected using the 40-pin (2x20) 0.1” connector. Such separation lowering the cost of PCBs production since backplane can be now 2-layers, while 4-layers can be used for more demanding MCU board. I've gave up from idea that backplane has to be mounted on the enclosure's rear panel, and decide to mount it on the bottom plate where modules have to be inserted as in a same manner as in PC (i.e. that require that top/cover plate has to be removed before module is inserted/removed).
The backplane allows connection of control lines between MCU and peripheral module using the 26-pin (2x13) 0.1” connector (black receptacles visible on the rear part of the backplane). I have also decide to keep possibility for coupling power outputs in series or parallel for modules on first two slots. Hence 20-pin (2x10) 0.1” connectors and place for two power relays on the backplane (currently jumpers are used instead of them). That will allow MCU controlled coupling for up to 100 V (in series) or up to 10 A (in parallel) that will be available on the output terminals on the module inserted into first slot. OE (Output Enable) LED is now bi-color for indicating that output is active and not coupled (Green) or active and coupled (Red). That 20-pin connector on the third slot is “dummy” used just to short post-regulator power outputs with output terminals on the PCB front side (4 mm, 19.05 mm spaced red/black connectors).
The power module (DCP505) has exposed all LEDs and connectors on its PCB front edge where front panel metal plate will be mounted with two M3 bolts to the PCBs and another two to the enclosure front panel. The cooling of power (pass) MOSFET and down-programmer MOSFET is achieved with mounting heatsink directly on the PCB fixed with three M3 bolts. Heatsink on the picture is “off-the-shelf” SK 624 50 AL (https://www.tme.eu/en/details/sk624_50_al/radiators/fischer-elektronik/sk-624-50-al/). I expect that will be enough for up to 2 A of output current (~ 5W of dissipation) without need to turn on fans at all. An “issue” with this heatsink is that one has to make five M3 threaded holes that is more challenging than expected since fins are very dense (I was ruined one heatsink because drill tip broke while drilling and remain blocked in the hole). Therefore I have to check with Varisom if they can offer similar solution as one used for EEZ H24005 power modules).
The AUX PS module as shown on pictures are not on the right position. It will be mounted (vertically) on left from TFT display (and MCU board). Hence the 16-pin cable can be much shorter. Its PCB width is as wide as enclosure inside depth (230 mm) and that will reduce needed wiring since power (AC mains) switch, standby LED and PE 4 mm connector are exposed on the enclosure's front panel and IEC inlet (with two 20x5 fuses) on the rear panel.
Now we can see that the final width for three modules/channels enclosure is defined, starting from the left, with thickness of the AUX PS module, TFT display/MCU board width and 3 x 35 mm peripheral modules. That give us 290 mm in total. The height of the enclosure will be 119 mm (that is within 3U height). Enclosure can be carry around using 3248.1001 (https://www.tme.eu/en/details/mr-3248.1001/handles/mentor/32481001/) handle mounted on the top.
The first proposal for enclosure's front and rear panels looks like this:
(https://i.imgur.com/NoDBt45.png)
(https://i.imgur.com/MkRhk1c.png)
The following items mounted on the MCU board will be exposed on the enclosure's front panel (its working name is Bench Box 3):
- RJ-45 for 10/100 Ethernet (this is not optimal, a rear panel is perhaps better place for it but that would require additional wiring)
- 2x digital inputs i 2x outputs (protected) used for external triggering and syncing
- Micro SD card
- Mini USB OTG
- Encoder with Ø31x16mm knob (https://www.tme.eu/en/details/a3131068/shaft-potentiometers-knobs/okw/)
- User SW (programmable for various purposes)
I'll continue commiting changes about all parts of the project on GitHub repo here (https://github.com/eez-open/modular-psu) and your comments and ideas are welcomed as usual.
-
@prasimix Very nice layout! I like it.
What touch screen are you using please?
-
The idea is that various (any?) display with 40-pin 0.5mm connector (RGB interface, 12 o'clock viewing angle) can be used. Currently I've tested Raystar Optronic's RFE43BH-AIW-DNS (https://www.tme.eu/en/details/rfe43bh-aiw-dns/tft-displays/raystar-optronics/). Display on the picture is Riverdi's RVT4.3ATFWR00 (https://www.tme.eu/en/details/rvt4.3atfwr00/tft-displays/riverdi/rvt43a480272tfwr00/) but unfortunately that is a 6 o'clock viewing angle display and cannot be used in final product.
I got good recommendation for EastRising displays available on buydisplay.com and eBay. The price is fantastic, and sufficient reason to test some of them like ER-TFT043-8 (https://www.buydisplay.com/default/low-cost-4-3-inch-480x272-tft-lcd-display-w-optl-capacitive-touch-screen) or ER-TFT043-3 (https://www.buydisplay.com/default/tft-4-3-inch-lcd-module-touchscreen-display-for-mp4-gps-480x272).
It is important to mention that most manufacturers offers the same TFT displays with both resistive and capacitive touchscreen. Currently we are using resistive that is only supported by selected TSC2007 (https://www.ti.com/product/TSC2007) controller.
-
The idea is that various (any?) display with 40-pin 0.5mm connector (RGB interface, 12 o'clock viewing angle) can be used. Currently I've tested Raystar Optronic's RFE43BH-AIW-DNS (https://www.tme.eu/en/details/rfe43bh-aiw-dns/tft-displays/raystar-optronics/). Display on the picture is Riverdi's RVT4.3ATFWR00 (https://www.tme.eu/en/details/rvt4.3atfwr00/tft-displays/riverdi/rvt43a480272tfwr00/) but unfortunately that is a 6 o'clock viewing angle display and cannot be used in final product.
I got good recommendation for EastRising displays available on buydisplay.com and eBay. The price is fantastic, and sufficient reason to test some of them like ER-TFT043-8 (https://www.buydisplay.com/default/low-cost-4-3-inch-480x272-tft-lcd-display-w-optl-capacitive-touch-screen) or ER-TFT043-3 (https://www.buydisplay.com/default/tft-4-3-inch-lcd-module-touchscreen-display-for-mp4-gps-480x272).
It is important to mention that most manufacturers offers the same TFT displays with both resistive and capacitive touchscreen. Currently we are using resistive that is only supported by selected TSC2007 (https://www.ti.com/product/TSC2007) controller.
Raystar or Riverdi are not cheap. At this price level, Nextion (Serial interface) maybe a good alternative.
The other displays you mentioned (EastRising?) are really well priced. At < $10 for 4.3" display is no brainer.
-
At this price level, Nextion (Serial interface) maybe a good alternative.
Right, if its interface/controller works flawlessly, but still that approach make a whole thing less open source :).
-
Yes, Nextion does work flawlessly and extremely fast (has got its own processor)
-
That is very nice! Thanks for sharing!
Kind regards, Samuel Lourenço
-
The first proposal for enclosure's front and rear panels looks like this:
Neat. My initial response is "can you make it a touch shorter and do a full rack width case", but then I thought again. On my home bench at the moment is a gap where a HP E3631 used to be until it died. I actually have an Agilent N6705A sitting under the bunch to be a replacement, but haven't put it in place, in part because it's so big.
Looking forward to when I can put money down, your UI is better than the N6705A.
-
Thanks, I believe that with new MCU and bigger display we'll make UI even better. We also learn something about usability of the existing PSU (i.e. EEZ H24005) that can be further improved.
-
A long time ago a request for multiple fixed outputs for digital design (https://github.com/eez-open/psu-hw/issues/22) was posted on EEZ H24005 GitHub repo. I'm wondering how much outputs and what voltages/current such power supply module should provide? Does some of them should be variable to some extent? Does current auto-ranging for stand-by consumption measurement makes sense?
The newly proposed chassis could carry up to three modules. I believe that two fully featured (DCP505) modules is enough and that leave one place vacant for a multiple outputs module.
Thanks in advance for your valuable inputs.
-
The 3D model for new chassis is more or less finished and a couple of screenshots is shown below (top cover is set as transparent). A 3D PDF file can be found in attachment (Adobe reader, as far as I know is still the only one who can display 3D drawings):
(https://i.imgur.com/HTiOHYM.png)
(https://i.imgur.com/PGQ6pFG.png)
-
Cool! Fusion360?
-
No, SolidWorks made by great guy Mario from Varisom, Portugal (based on my basic DXF drawing (https://github.com/eez-open/modular-psu/tree/master/enclosure) made in Eagle). Hopefully they'll make it right in the first try, there is so many details that we tried to check via Skype :).
-
A long time ago a request for multiple fixed outputs for digital design (https://github.com/eez-open/psu-hw/issues/22) was posted on EEZ H24005 GitHub repo. I'm wondering how much outputs and what voltages/current such power supply module should provide? Does some of them should be variable to some extent? Does current auto-ranging for stand-by consumption measurement makes sense?
The newly proposed chassis could carry up to three modules. I believe that two fully featured (DCP505) modules is enough and that leave one place vacant for a multiple outputs module.
Thanks in advance for your valuable inputs.
Make it a usb 5v / 3.3v and or type c pd
Sent from my iPhone using Tapatalk
-
Thanks, I know nothing about USB type C, just information that it can be used also for "high power" supply, and have to investigate that further.
For 3.3/5 V outputs what current could be appropriate: up to 2-3 A?
-
Thanks, I know nothing about USB type C, just information that it can be used also for "high power" supply, and have to investigate that further.
For 3.3/5 V outputs what current could be appropriate: up to 2-3 A?
Whilst I would absolutely love a type-c USB-PD output, they might be a bit of a pain for an early module.
USB-PD rules say up to 3A at anywhere from 5-20v (with 5, 9, 15 & 20 being the standard voltages that should be supported), and 5A at 20v only if connected to a cable that declares itself safe for 5A.
-
I found that the USB 3 PD functionality can be provided using MCU from STM32F0 family for which ST offers USB-PD (https://www.st.com/en/embedded-software/x-cube-usb-pd.html?icmp=tt7079_gl_pron_apr2018) stack. I believe that could speed up a whole development of something that looks rather complex.
-
I found that the USB 3 PD functionality can be provided using MCU from STM32F0 family for which ST offers USB-PD (https://www.st.com/en/embedded-software/x-cube-usb-pd.html?icmp=tt7079_gl_pron_apr2018) stack. I believe that could speed up a whole development of something that looks rather complex.
You probably mean G0, as this are the CPUs that have CC pins.. however they don't provide protection on those pins.. so you have to somehow get the voltage which can go up to 25V down to safe levels e.g somewhere between 3.3 and 5V.
-
No, I did not. I'm referring on what ST specified. There is few possibilities with F0, but also more broader support for F0/F4 families. MCU is just a part of solution and seems that it replaces Type-Port Manager (TCPM) with hard-coded protocol. ST is mentioning that their solution is tested with ONsemi's FUSB307B Type-C Port Controller (TCPC). PD looks like a science for itself, but promise flexible bidirectional power distribution.
-
Ah ok. Well they also provide the PD libraries for G0 and L5, but G0 is way cheaper as it's m0+
-
Hi prasimix
I’m a bit behind on the thread and just caught up to the range switching CC issue. When I looked at the schematics with the three slope current setting I thought “that looks complicated, there might be ‘bumps’ moving between ranges for CC mode.” Then I saw your post where you discussed the issue.
I think the simplest solution is what you’ve done already: just have one CC range and call it a day.
But there may be a useful compromise between simplicity and performance. How does the following sound?
- CC split into 2 ranges (3 is too complicated)
- coarse range is 45mA - 5A
- fine range is 0 - 50mA
- the 45mA vs 50mA is for hysteresis and fewer surprises.
- when using fine range, just force the range switching circuit to 50mA range, because you already know what the current range should be.
- for improved accuracy, you could use the signal out of the switched current sense amplifier for feedback (but you may need different current control gains for stability)
-
Thanks for suggestion. Splitting CC in two ranges could include some guess work in operation, i.e. if load in sleep mode drawn few mA, and few hundreds of mA when wake up, then setting lower CC range will affect load operation. Anyway, I have to rethink auto-ranger design together with complete new proposed power module (DCP505).
-
It seems some other designs rely on overkill DACC resolution in combination with a log amplifier for the input current to make the current control work over the full range. I imagine mainly it would just make it harder to calibrate at the trade off only needing 1 range.
-
So I had a go at implementing a similar circuit in LTSpice. Hopefully some of the concepts will be helpful.
Basic concepts:
- Have a 5A shunt resistor always in circuit. As you pointed out a while ago, this makes it much easier to manage the range switching. It's also used for Constant Current (CC) control.
- Use a separate amplifier for 500mA and 50mA range. No need to measure the 5A range again. Also allows the use of a different gain which can improve Vos drift sensitivity.
- Use simplest comparator chain to select gain. Some hysteresis will be required, because switching the range FETs injects a bit of current into the system (due to gate charge).
- Separate CC ranges from ADC range. We don't want automatic switching of CC range, because switching glitches could disturb the main control loop and jam pulses into delicate loads. But we do want the current sensing to autorange.
- Provide 2 CC ranges with 'manual' switching. This will avoid automatic switching bouncing around, because the main control system controls the CC range override and the CC DAC.
Note: I'd expect to use a quad analog mux chip of some description.
In terms of devices with widely varying current limits, there are 3 approaches we could take:
- The user just selects the CC range before turning the supply on. If the 50mA CC range was selected, then the supply could only go to 50mA. If the 5A CC range was selected then current limit steps would be coarse. Note that current sense would still autorange.
- Basic CC range switching during operation. This would probably cause some kind of bump in CC mode because the CC DAC and the ForceLow signal might not be perfectly synchronised.
- Seamless CC range switching during operation. Add a second CC DAC&EA so that there is a 5A range CC DAC + EA and a low range CC DAC + EA. Preset the DAC (and allow it to settle) before flipping between ranges.
-
I just stumbled across this today. I like the wide input, wide output. I'm working on familiarizing myself with github and getting myself up to speed. I think you're really onto something great here.
-
I found that the USB 3 PD functionality can be provided using MCU from STM32F0 family for which ST offers USB-PD (https://www.st.com/en/embedded-software/x-cube-usb-pd.html?icmp=tt7079_gl_pron_apr2018) stack. I believe that could speed up a whole development of something that looks rather complex.
I have one of these PD Buddy boards with USB-C PD (5-20V 3A max).
I think it is based on STM chip. Please check it out:
https://www.tindie.com/products/clarahobbs/pd-buddy-sink/ (https://www.tindie.com/products/clarahobbs/pd-buddy-sink/)
-
@prasimix
Where are you going to print out your front panel please?
I did use Schaeffer AG in the past, but they are expensive.
Thanks
Alex
-
@prasimix
Where are you going to print out your front panel please?
I did use Schaeffer AG in the past, but they are expensive.
Thanks
Alex
Yes, Schaeffer is very nice but expensive, if I remember correctly only front panel would cost almost as twice as much as complete custom made enclosure (painted and with printed front and rear) for EEZ H24005 made by Varisom. I've ordered first prototypes from Varisom again (see #68 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2283135/#msg2283135)) that is going to paint and print out front and rear panels, too. I'll post some picture when it arrives.
-
I found that the USB 3 PD functionality can be provided using MCU from STM32F0 family for which ST offers USB-PD (https://www.st.com/en/embedded-software/x-cube-usb-pd.html?icmp=tt7079_gl_pron_apr2018) stack. I believe that could speed up a whole development of something that looks rather complex.
I have one of these PD Buddy boards with USB-C PD (5-20V 3A max).
I think it is based on STM chip. Please check it out:
https://www.tindie.com/products/clarahobbs/pd-buddy-sink/ (https://www.tindie.com/products/clarahobbs/pd-buddy-sink/)
I'll try to build a capable buck stage with CV and CC control, first. Next step could be addition of STM based PD control. The buck should accept 48 Vdc on input and I'm looking to give a try to LT3763 (https://www.analog.com/en/products/lt3763.html) controller. It seems that it has all what is needed even some extra stuff such as PWM dimming that could be useful for powering/testing power LEDs and laser diodes.
-
I came across this project while searching for open source Bench power-supply. I am interested in contributing to this work. I have background in FPGA/Digital HW and software design. Thanks! Lakshmi Aiyer
-
Many thanks Lakshmi for your interest. Yes, FPGA is something that is definitely coming into picture (after I failed to make something with XMOS xCORE ;)). Since development team of ULX3S (https://github.com/emard/ulx3s) project (based on Lattice ECP5) is in Zagreb, Croatia and I met them in person, we'd like to use it as a core for some new modules. Perhaps you should take a look on it, and we can continue discussion via PM, email or discord.
-
A small update regarding backplane. A new prototype now can host up to four power relays for combining output terminals on the first two slots (i.e. without external wiring) in the one of the following ways:
(http://i.imgur.com/a1gBRZ7.png) (https://imgur.com/a1gBRZ7)
Power relays are now controlled with 4-port I2C I/O expander. The populated PCB (except LEDs for indication which coupling is active) looks like this:
(http://i.imgur.com/anEyKf8.jpg) (https://imgur.com/anEyKf8)
Backplane pin mappings can be found in attached PDF.
-
You are really making it modular.
How many main modules do you intend having and do you foresee any add-on (optional) modules please?
-
The number of modules could be up to 7 with current addressing of the shared I2C (#0 is reserved for MCU board) that is intended to be used for module identification and module specific info (e.g. calibration params, working hours counters, etc.).
This backplane (BP3C) obliviously can carry up to three peripheral modules, and its dimensions are defined with Bench Box 3 enclosure presented in #68 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2283135/#msg2283135). For larger module counts you'll need a bigger enclosure, and on the backplane you have to decide which of SPI channels you'd like to share since currently each of three slot has dedicated SPI channel which is not really necessary at least when we talk about power board functionality.
So far, I've made two power modules: DCP505 (https://github.com/eez-open/modular-psu/tree/master/dcp505) (0-50V/0-5A max. 250 W) that works in combination with CF-DIC (https://github.com/eez-open/CF-DIC), and DCP405 (https://github.com/eez-open/modular-psu/tree/master/dcp405) (0-40V/0-5A max. 155 W limited by Mean Well AC/DC module). I'm now playing another module which should offer two simplified, more "crude" DC outputs i.e. without linear post-regulator stage based on LT3763 controller as announced recently.
-
Finally, after many months of waiting the first enclosure prototype arrived few days ago. Unfortunately with more issues that I expected, but all of them are really minor and related to the front panel. The biggest and obvious one is that hole for encoder's know is not positioned correctly :)
(https://i.imgur.com/y7q0Xyq.jpg)
(https://i.imgur.com/s94uZcB.jpg)
(https://i.imgur.com/rlZLYHg.jpg)
View inside the enclosure reveals that number of wires are minimum that will simplify assembly and servicing:
(https://i.imgur.com/5a5ix5U.jpg)
Area allocated to AC/DC modules are huge enough to host a toroidal transformer of respectable size:
(https://i.imgur.com/tNskick.jpg)
Feet that I found in Turkey (Altinkaya) looks pretty convenient and give us possibility to position the enclosure with an angle that will improve viewing angle on the TFT touchscreen display:
(https://i.imgur.com/6QUYChJ.jpg)
I'd like to hear your opinion about carrying handle mounted on the top cover. Some of my friends ridiculed it on the first sight as something extremely ugly. I was put it there to avoid increasing enclosure width and because with it one can conveniently and safely carry BB3 around using only one hand (another question is how often that could be a case).
Finally, here is a short overview of the first prototype:
https://www.youtube.com/watch?v=XSERym3_mug (https://www.youtube.com/watch?v=XSERym3_mug)
The project also got its web pages: https://www.envox.hr/eez/eez-bench-box-3/introduction.html (https://www.envox.hr/eez/eez-bench-box-3/introduction.html)
-
Your attention to detail is astounding as it is inspirational. Than you for your impeccably detailed posts, I've enjoyed reading the backlog over years across all your projects.
-
This looks very good and professional!
The handle - some people like it some people not. Personally I think it’s ok. Alternatively you can do a handle on the side, but this means the handle has to come off first before the cover????
-
It’s good to see this project coming along nicely! Things like enclosures always take a lot of work to get right.
I have some questions on the enclosure:
- what are the dimensions of the current prototype?
- which way does the air flow? Is the box normally at positive or negative pressure?
- with the carry handle in place, can you stack two units on top of each other?
-
Is this rack mountable?
Sent from my iPhone using Tapatalk
-
It’s good to see this project coming along nicely! Things like enclosures always take a lot of work to get right.
I have some questions on the enclosure:
- what are the dimensions of the current prototype?
290 (W) x 123 (H) x 240 (D) mm without feet mounted. Feet are 15 mm high.
Talking about width, that is more then a half of 19" rack. If we'd like to reach a full width, additional four modules could be added (seven in total).
- which way does the air flow? Is the box normally at positive or negative pressure?
That's the good question, the fan is currently mounted to provide positive pressure, but I presume it could be also negative. As far as I know each option has its pro's and con's. What would you like to suggest?
- with the carry handle in place, can you stack two units on top of each other?
Yes, stacking is possible:
(https://i.imgur.com/Qt94cHP.jpg)
-
Is this rack mountable?
It could be, but we should make some sort of mounting brackets (and few additional holes on the sides, too), and probably in that case feet have to be removed.
-
Hmm for a "pro" version something that could reuse a 4u server case and pcie style expansions to save costs would be cool...
Looks good for a compact half-width thing
Sent from my iPhone using Tapatalk
-
I've started to test a first prototype of "aux" power module based on LT3763 as announced in #86 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2381514/#msg2381514). I've managed to put two channels that could deliver 0-20 V up to 4 A each, and has output voltage and current control. It also comes with on-board MCU for few reasons:
- It will help us to define DIB protocol between master MCU and peripheral module with its own MCU
- The selected STM32F373 comes with multichannel 16-bit ADC for very attractive price that is below "standalone" 4-ch ADCs with the same resolution
- It should be cost attractive alternative to DCP405 module, when more power outputs are required on the bench: up to six channels with BB3 chassis.
The module name is DCM220, built on a 2-layer PCB. All selected components, as usual, are with exposed pins that I can solder it without need for stencil and reflow oven. OK, such requirement narrows the list of possible components, and perhaps more attractive controller then LT3763 exists on the market. Anyway, so far I'm satisfied with preliminary results made by testing only first channel. The first PCB prototype (r1B1) asked for some improvements, and it now doesn't look so nice (see below) but it will do the job.
(http://i.imgur.com/C04IN2o.jpg) (https://imgur.com/C04IN2o)
The schematics follows below and your comments are welcomed.
Bias power supply and DIB interface
(http://i.imgur.com/YkjezyM.png) (https://imgur.com/YkjezyM)
DC power input is +48 V that comes from Mean Well AC/DC module (max. 155 W), the same one used to powering the DCP405 module. TPS54060DGQ (IC2) is used as step-down converter which power inductor is replaced with coupled inductor that provide both positive and negative voltage. The negative one is used solely for diff. op-amp used for set output current. Since it cannot provide (RRO) rail-to-rail output, it is not possible to goes down to zero without slightly negative power rail. Firstly, I was thinking about deploying LM7705 but it's unnecessary expensive (with all that needed capacitors around it). Buck positive output is step-down once again with LDO (IC5) to provide +3.3 V for MCU, DAC and digital isolators.
Although power channels on this modules are not isolated (i.e. share the same Vout-), I've decide to isolate it from the MCU GND, to provide more flexibility to combine its outputs with other modules. Therefore DIB interface used for communication with the MCU board has to be isolated. A low speed variant (1 Mbit/s instead of 150Mbit/s) of IC1 and IC3 is selected that I believe will be sufficient for responsive communication. Module parameters are stored into I2C EEPROM (IC4).
DAC, temp. sensors and MCU
(http://i.imgur.com/iJK0yCS.png) (https://imgur.com/iJK0yCS)
I have (and still have) some doubts what is the most efficient way of controlling power buck controllers voltage and current: dedicated 4-ch DAC, MCU's built-in DAC and PWM output or combination of both (e.g. 2-ch external DAC, and 2-ch MCU DAC or PWM outputs). In the first prototype MAX5715 (https://www.maximintegrated.com/en/products/analog/data-converters/digital-to-analog-converters/MAX5715.html) is used, a 4-ch, 12-bit I2C DAC with pretty good price. The good thing about selected DAC is that 8- and 10-bit variants are also available that give us possibility to scale it down reducing the cost further.
It is already mention what was the idea behind selecting STM32F373 as on-board MCU: its 16-bit (SAR) ADCs. ADC inputs are used to monitor output voltage and current on both channel. To keep cost low, I've marked xtal as an option, since MCU could use internal resonator, which is not so accurate as external xtal but should do the job. We have to test that in practice. MCU flash programming is intended to be accomplish over JTAG/SWD connector, but afterward I decide to add possibility to use UART. That will require control of BOOT0 input and UART lines are also added into the latest revision of BP3C backplane (r3B1).
Power channel #1
(http://i.imgur.com/Zb0r2eI.png) (https://imgur.com/Zb0r2eI)
Design of the power channel is based on the typical application of the selected LT3763 which is high voltage sync buck controller that features current monitoring and control among many other things. It is powered from bias power supply to reduce its dissipation as in case that it is supplied directly from DC power input (+48 V). The +8 V that comes from bias supply is slightly above min. Vin that is +6 V. In fact, I didn't test that yet due to inconvenient tracing on the existing PCB but that is now included in the r1B2 revision.
As current control CTRL1 input is used that accept 0 to 1.5 V for current limit programming. Since DAC output goes up to 2.5 V its output is attenuated using the diff. op-amp IC9B that full DAC scale can be used. Max. output current is defined with Rsense (R27) that generate 50 mV drop for max. output current. With selected 12 mOhm that is about 4 A. Selected switching MOSFETs are IRFR7546TRPBF with low R(ds, on) and V(ds, max) of 60 V. The lo-side MOSFET could be assisted with diode (D4) that is marked as optional but I'm using SK55 on the prototype and have to test if it will stay or not. To further reduce output ripple and noise an additional LC filtering is added (L3, C52+C56) and I have to test how it affect transient response.
Voltage is programmed by bringing another DAC channel output to the FB voltage divider (R33, R39) via R41 that are calculated to give 0 to about 20 V on the output. Output voltage is monitored by bringing it to the MCU's ADC input using the separate voltage divider (R34, R40) that gives +2.5 V for max. output voltage.
The main obstacle with LT3763 is that no CC mode of operation indication is available. Therefore I tried to derived it from CV mode of operation when voltage on the FB input pin is constant and should be about 1.2 V. Op-amp IC11B works as comparator that compares ref. voltage that divider R43, R44 set to 1.119 V just a little bit bellow mentioned CV mode voltage. First I forgot to isolate FB from the op-amp but IC11C is added later that FB pin is not affected with connected comparator. No resistor is needed on the input of IC11C since selected MC33274ADR2G has not input diodes.
Comparator's output is used as CC indicator that goes to MCU and that can indirectly set on and off CC_LED. CV mode indication does not exist per se and OE (output enable) is used instead. To avoid simultaneous activation of CC and OE LEDs, Q4 disable OE_LED (green) when CC_LED is active. Ok, other possibility is to drive OE_LED as in case of CC_LED directly from MCU, a change that I'll probably add, since four pins remain unassigned on the MCU.
Finally, the power Vout- is exposed that can be coupled under firmware control with other module's grounds using only the half of DIB power sourcing connector (X4).
Power channel #2
(http://i.imgur.com/DgmJ8De.png) (https://imgur.com/DgmJ8De)
Nothing more can be said about second power channel that is identical to the first one.
Module's latest design files are now available on the GitHub (https://github.com/eez-open/modular-psu/tree/master/dcm220) as part of the BB3 project, and PDF schematic of the presented r1B2 is also attached here for the download.
-
Well the Crowd Supply news is out. I must say I'm looking forward to this as I did with the H24005.
I wonder what the priority of additional plug-in modules is? Higher voltages, Electronic Load.
Will there be a minimum configuration? Blanking panels?
Keep up the good work - and the outstanding documentation!
-
I'd like to supplement BB3 over the time in a way that it became a useful "benchtop station" for testing low power (up to 400-500 W) AC/DC and DC/DC converters. Therefore, a high voltage DC power source module with all protections is needed (For DC/DC converters, 40 V / 10 A or 80 V / 5 A should be sufficient for a time being).
Other one is power analyzer that could simultaneously measure DUT (i.e. DC/DC converter) input and output power and calculate all power related figures in real time. The electronic load looks like another important module for such purposes but, as time pass, I'm thinking more about 2-quadrant (bidirectional) power source that can return power back to AC mains. In that way "sinking" few hundreds of W shouldn't be an issue.
Another interesting function is a Bode plotter, entry level network analyzer, that should help to finding out in practice what is a stability of the DUT. That functionality perhaps could be included on the power analyzer module.
That type of applications probably will require introduction of FPGA, and I've started to follow ULX3S project, and hopefully with help of some other good-willing people we'll succeed.
Finally, we have to see what time will brings to us, and perhaps some other people will find this "form factor" and accompanied (I believe not non-sense) software/firmware suite attractive for their needs, that we can work together to brings new modules to general public.
-
Great job Prasimix. Ive been following along and not had much chance to comment but its really exciting to see the move from a single product to a modular platform :-)
-
Great to see you're gearing up for a release! I'm going to keep an eye out.
I have a question on the dual output module... just to clarify, will the two outputs share a common ground?
-
Great to see you're gearing up for a release! I'm going to keep an eye out.
I have a question on the dual output module... just to clarify, will the two outputs share a common ground?
That's right, since they also share the same power input (48 Vdc). For more details you can check the latest version of the DCM220 module on the GitHub here (https://github.com/eez-open/modular-psu/tree/master/dcm220) (where is also PDF (https://github.com/eez-open/modular-psu/blob/master/dcm220/EEZ%20DIB%20DCM220%20r1B2.pdf) version or in #100 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2510487/#msg2510487)). I believe that is not a great obstacle. And yes, it's floating in regards to other power modules, but if needed, its ground can be connected to other grounds under firmware control (e.g. that you don't have to do that with extra wires from the outside what I found myself to do so many times with H24005 :)).
-
I wonder if having a module to control an environmental factor (like temperature) would be attractive to others as well to as me? For example, one module could be measuring performance of a DUT, while another is ramping temperature up and down.
-
What kind of functionalities you have in mind? Perhaps we can combine more then one thing on the single module: e.g. if we are concern about temperature, we could have one or more temp sensor inputs with ADC, PID, also few digital inputs/outputs for triggering, control of heaters (AC or DC relays, triac/dimmer)?
-
What I had in mind was the ability to combine a series of environmental tests with a DUT's parametric tests.
Example:
Whilst stepping up and down supply voltage on a DUT, measure supply current for say x hours, or y cycles
Once x or y have completed, step say temperature over a range z
Complete all cycles until you get back to the original values for x,y,z and see if the DUT performs the same
Another example could be monitoring the same data as above - but the environmental changes are the frequency and magnitude of physical vibration. The issue is one of tying the DUT's performance to the environmental condition and having a common timestamp supplied by your CPU and fed to the memory card.
I suppose it's a crude data acquisition system - but the basics will all be there. A common time stamp for stored data, parametric measurement and environmental control in cycles. It reduces the effort made for field testing of devices likely to be subjected to harsh environments.
I'm keen on your Bode plotter too.
-
Good, described "testing automation" is already in place to the great extent if we are talking strictly about DC power source (PSU) functionality: we can continuously measuring all output params (voltage, current and power, energy counter will be also added), and have a great flexibility to program (change) output parameters via SCPI commands (e.g. you can also execute LIST of parameters, initiate data logging into internal SDcard and conveniently transfer it to the PC thanks to EEZ Studio). Currently, output params changes could be synchronized with external processes via two buffered digital inputs and two outputs.
But, we have all freedom to build a new module where we can "integrate" some of external devices functionalities (to clean up benchtop a little bit :)). Especially because we can include its management to the existing "SCPI engine" on the BB3 chasis side, that could simplify user interactions locally (via TFT touchscreen+encoder) or remotely (via PC).
I presume that making an general purpose multi-channel data acquisition module should make sense. Perhaps with few outputs (for signaling, but also for power control). The module front panel is big enough that reasonable number of I/O terminals can be exposed on it.
-
I can see your creative juices flowing. Thank you for enabling the input.
-
Yes, and I do believe that existing H24005 and especially new BB3 project has a real potential to be used in testing automation processes saving time and money at least for various entry level tasks. Thanks for initiate such discussion and looking forward also for more inputs from you and other forum members.
-
Looking forward to this.
-
Yes, and first thing first. I have to make BB3 happen (initiated with crowdfunding): to organize everything that its production can started and can be delivered smoothly that more people could get it for development and evaluation purposes, too (apart from use its existing modules for daily power delivering requirements on our benchtops ;) ).
-
I'm definatly on the hope for an SMU type plugin, And I'm trying to consolidate how it could could be approached, even If it ended up being a 3rd slot module of my own design (As long as the price is not too insane, I should be a first hand backer this time around)
-
(As long as the price is not too insane, I should be a first hand backer this time around)
A good thing this time is that, thanks to real modular approach (something that also existed in H24005 project but not executed properly), the "entry-level" solution starts to makes sense, too. It will include BB3 chassis, AUX-PS (+5 V, 10 or 20 W, and +12 V/10W, softstart, fan speed control), MCU board (STM32F7, 4.3" TFT touchscreen, encoder, Ethernet, USB, etc.) and three slot backplane (with power coupling). Any you can start adding new modules, that are not necessarily just single quadrant DC sources.
But, the two-channel kit, comparable with H24005, should be in the same price range with H24005. I'm working on that, and hopefully that will become reality (even that BB3 is more capable).
-
I wonder if having a module to control an environmental factor (like temperature) would be attractive to others as well to as me?
I'm definatly on the hope for an SMU type plugin...
I think there are a lot of opportunities for modules - that was Prasimixes whole concept :).
For example, I have been doing some battery evaluation stuff at work, and there is a massive gap in the market between the <$500 hobby battery charger (they're quite good but not precision) and the >$10,000 professional battery analysers. Maybe a BB3 with an SMU card, a Peltier control card, and an external thermal chamber (which could be bolted to the side of the BB3 to make a 19" rack payload) would do the trick?
Possibilities (and idea source):
- Precision power meters (Prasimix)
- Temperature controller (AlanS). A cut-down version could also function as precision RTD thermometer or strain gauge receiver
- SMU (Rerouter)
- Multi-channel data acquisition card (HP, Keithley et al)
- Precision battery cycler (me)
- Bidirectional DC supplies (me) for loop-back power testing
- Tiny thermal chamber inside a card (me) for component and small battery characterisation
- Battery backup module (behind LCD) for reliability or in-field usage (me). This would make power supplies and shipping very complicated.
There are heaps of things people could build...
-
It is important to mention that most manufacturers offers the same TFT displays with both resistive and capacitive touchscreen. Currently we are using resistive that is only supported by selected TSC2007 (https://www.ti.com/product/TSC2007) controller.
Capacitive would be nice I would guess, resistive touch seems to stop working/malfunctioning after some time.
-
I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.
Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices. It would be handy to be able to measure/control the PSE end.
-
Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices. It would be handy to be able to measure/control the PSE end.
Oh that's a cute idea, I love that. Ability to source 30-55v (to simulate cable drops), reporting of what class the device asks for.
-
For example, I have been doing some battery evaluation stuff at work, and there is a massive gap in the market between the <$500 hobby battery charger (they're quite good but not precision) and the >$10,000 professional battery analysers. Maybe a BB3 with an SMU card, a Peltier control card, and an external thermal chamber (which could be bolted to the side of the BB3 to make a 19" rack payload) would do the trick?
Could you please elaborate this a little bit more. What thermal chamber and Peltier elements are used for? To test battery behavior under different temperature? I presume then that Peltier control card should include multiple thermocouple sensor inputs that will be used to set output for powering Peltiers?
Possibilities (and idea source):
- Precision power meters (Prasimix)
- Temperature controller (AlanS). A cut-down version could also function as precision RTD thermometer or strain gauge receiver
- SMU (Rerouter)
- Multi-channel data acquisition card (HP, Keithley et al)
- Precision battery cycler (me)
- Bidirectional DC supplies (me) for loop-back power testing
- Tiny thermal chamber inside a card (me) for component and small battery characterisation
- Battery backup module (behind LCD) for reliability or in-field usage (me). This would make power supplies and shipping very complicated.
There are heaps of things people could build...
Yes, and all that is mentioned could be integrated and benefit from the "software suite" that is already in place: to manage modules locally (TFT touchscreen + encoder) or remotely (via SCPI commands to EEZ Studio or similar application).
-
I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.
Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices. It would be handy to be able to measure/control the PSE end.
Ok, but I don't known anything about PSE port. Do you have any useful links to some intro/beginners content?
-
I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.
Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices. It would be handy to be able to measure/control the PSE end.
Ok, but I don't known anything about PSE port. Do you have any useful links to some intro/beginners content?
I am not sure why PoE needs to be integrated into power supply because there are different kinds of power PoE sourcing (standards) and to cover them all, provide all features needed for testing of PoE devices, module needs to be quite complex thus expensive. Those who are ready pay significant money most likely will buy something from SiFos (http://sifos.com/Products/PSA-3000-PowerSync-Analyzers-PoE-PSE-Test) (or similar) anyway.
If you are going to implement PoE module, more or less it shall contain main components of this board:
http://www.ti.com/tool/tps2372-4evm-006 (http://www.ti.com/tool/tps2372-4evm-006)
[edit] If it is about popular < 30W Type2 PoE, then this much simpler board a module: http://www.ti.com/tool/tida-00465 (http://www.ti.com/tool/tida-00465)
-
Could you please elaborate this a little bit more. What thermal chamber and Peltier elements are used for? To test battery behavior under different temperature? I presume then that Peltier control card should include multiple thermocouple sensor inputs that will be used to set output for powering Peltiers?
Yes, for precision work it’s common for people to test at different temperatures, eg 0C, 20C and 40C. This is because cell Open Circuit Voltage is a bit temperature sensitive and cell resistance is very sensitive to temperature and state of charge.
(I’ve also found that stable control of the cell voltage and current is important. A bit of voltage ripple can make quite a big difference to when exactly the cell is “fully charged,” which leads to a random spread of capacity measurements. To get around that you then need to average more test cycles and everything takes longer...)
For a small cell, a small thermal chamber could probably be done with Peltier elements. Both heating and cooling modes would be required, which suits a Peltier well. I guess that a ‘proper’ setup would have 2 basic sensors on the Peltier elements for protection and coarse control, and at least one more precise (eg RTD) sensor for the chamber temperature. Ideally I would tape 1 more sensor to the cell itself for a grand total of 4. (But what if I want to test several cells at a time :D?)
My idea of a tiny thermal chamber which bolts on the side of a BB3 is cute but probably impractical.
-
I like this idea (jbb) of being able to control a peltier based chamber from within the BB3.
When not being used for important stuff we could use it to keep our wine in good condition (I'm joking). :-DD
-
Wine bottles are quite long... maybe a can of beer ;)?
-
I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.
Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices. It would be handy to be able to measure/control the PSE end.
Ok, but I don't known anything about PSE port. Do you have any useful links to some intro/beginners content?
I am not sure why PoE needs to be integrated into power supply because there are different kinds of power PoE sourcing (standards) and to cover them all, provide all features needed for testing of PoE devices, module needs to be quite complex thus expensive. Those who are ready pay significant money most likely will buy something from SiFos (http://sifos.com/Products/PSA-3000-PowerSync-Analyzers-PoE-PSE-Test) (or similar) anyway.
If you are going to implement PoE module, more or less it shall contain main components of this board:
http://www.ti.com/tool/tps2372-4evm-006 (http://www.ti.com/tool/tps2372-4evm-006)
[edit] If it is about popular < 30W Type2 PoE, then this much simpler board a module: http://www.ti.com/tool/tida-00465 (http://www.ti.com/tool/tida-00465)
you may not see the need for it, and i may not see the need for other types of modules to do various differnet jobs. Thats not really the point. The point is that if the interface to be able to plug your module into is stadnard, and its easy enough to add code to it, then it makes it increadibly flexible for people to create things to their own needs. of course there will be things that will be common for a lot of people, but tehre will be lots of odd ball things that people would make for themself.
-
Also there is a lot in 1 given power supply module that can be mostly reused for other purposes. Even for my SMU thoughts, most of it will be just giving it a bidirectional output stage and current shunt. apart from the level of ideal output stability its just set current with voltage compliance limit or set voltage with current source limit. the smarts come from how you use that, the feedback chain is still analog, the sampling is technically independent,
As such I'm beginning by trying to make a more flexible ADC, then once that is covered, figure out how the output stage could get away with the current tracking approach to keep the output stage regulating with very low dissipation.
The keysight level SMU's seem to have a step response bandwidth close to 50KHz, so nothing too extreme,
Technically with a multi-slope ADC like I'm trying to help work out, you could have as many analog inputs as you can mux in, so having say 6 external ADC inputs would not be expensive to add to things, just slow down how many data points you can pull off a second for a given resolution.
-
Thats not really the point.
That was exactly my point - that this particular function (especially 1-channel), can live it's own life w/o being irreversibly married with power supply.
The point is that if the interface to be able to plug your module into is stadnard, and its easy enough to add code to it
Yes, good point. Nobody can forbid you to make module *you* want to make and use. Perhaps I missed something - are there any obstacles that are not allowing you to make PoE module or what?
-
That was exactly my point - that this particular function (especially 1-channel), can live it's own life w/o being irreversibly married with power supply.
90% of what you need to provide the functionality of a PSE, ( that has all the measurement / control that you want ) is already there. 'Marrying' it with the unit on your desk, is not a problem at all.
The point is that if the interface to be able to plug your module into is stadnard, and its easy enough to add code to it
Yes, good point. Nobody can forbid you to make module *you* want to make and use. Perhaps I missed something - are there any obstacles that are not allowing you to make PoE module or what?
I was'nt asking any one to make it for me. It was an example. I was enquiring as the open-ness of the interface that it will connect to.
There will be no end of special use-cases that people want to build for themselves.
-
90% of what you need to provide the functionality of a PSE, ( that has all the measurement / control that you want ) is already there. 'Marrying' it with the unit on your desk, is not a problem at all.
If all what's needed is functionality of PSE, then yes I agree. On the other hand many tests are better done using standalone adapter. Such as lightning surge immunity (if apply), Ethernet signal integrity, looking for transformer core saturation current - all will benefit from standalone PSE board/adapter. If adapter for testing is needed anyway, for me there is no point to have PoE-enabled supply. Disclaimer: I do not require for everybody to agree my point of view obviously [lol].
-
I've just finished the latest DCM220 dual power module. A brief info for newcomers: it is built around LT3763 sync buck that offers current programming and monitoring. Unfortunately it does not provide CC mode of operation indication. Therefore I derived it from FB signal. A 4-channel 12-bit DAC (MAX5715) is used for set output voltage and current (times two for two channels). Instead of using dedicated ADC for measuring output voltage and current a STM32F373 MCU is used which comes with attractive multichannel 16-bit ADC! Output terminals are for 4 mm banana plugs and bi-color LED indicator is used to indicate OE (Output Enable) and CC mode of operation. Output voltage is limited to 20 V (but can be much more since Vin is 48 Vdc) and output current to approx. 4 A. Power outputs are "floated" in regard to other module's GND, but two channels share the same GND on board.
(http://i.imgur.com/9FDRKWC.jpg) (https://imgur.com/9FDRKWC)
Output ripple is pretty good, if we take into account that is SMPS, and e.g. for Iout = 2 A it's below 5 mVpp or 1 mVrms (measured on the output capacitor):
(http://i.imgur.com/W6n01GX.png) (https://imgur.com/W6n01GX)
So, with three DCM220 one could count on up to 6 programmable power sources packed into EEZ BB3.
Two yellow wires are correction after so far unsuccessful attempt to use on-board bias supply (+7.5 V) to power LT3763 instead of full +48 Vdc used for powering this module. Idea was to reduce dissipation of its internal regulator, but it seems that in that case output voltage cannot goes beyond voltage that is applied on its Vin (i.e. 7.5 V), at least not without damage (I've lost two of them together with few MOSFETs).
-
Very nice looking module. Congrats! You did not populate RC snubbers (R31+C52, R54+C75). Why? Do you have switching waveform with/without showing difference or lack of it?
-
Actually didn't finished all testing. There is also place for diode in parallel for lo-side MOSFET assistance. I was pretty satisfied with existing results, and something that really bother me is that inability to power the LT3763 with lower voltage (e.g. something that I find possible on many TI/LM controllers).
-
Maybe a zener down from your 7.5V rail to the auxiliary Vin pin? (I think those are often around 5V for LT chips.)
-
Actually didn't finished all testing.
Sure. Testing alone can take lot of effort and time. BTW would be nice to see load regulation step response, like 0.1A -> 2A -> 0.1A
There is also place for diode in parallel for lo-side MOSFET assistance. I was pretty satisfied with existing results
Hard to see at this time/div, but it seems that there is some ringing. If you have time and option to test with/without snubber - why not.
something that really bother me is that inability to power the LT3763 with lower voltage (e.g. something that I find possible on many TI/LM controllers).
LT3763 is LED driver controller - it may have limitations & design compromises compared to "proper" power supply IC's. I am afraid that block diagram is not telling whole picture and you can't do anything about this "problem".
-
Here is transient response with compensation as it is (check schematics (https://github.com/eez-open/modular-psu/blob/master/dcm220/EEZ%20DIB%20DCM220%20r1B2.pdf) on GitHub, Pg. 3).
A Jim William AN104 transient load tester (https://github.com/eez-open/ltc-an104-transient-tester) is used, and step response is 1 A.
(http://i.imgur.com/lWU4TXY.png) (https://imgur.com/lWU4TXY)
-
Maybe a zener down from your 7.5V rail to the auxiliary Vin pin? (I think those are often around 5V for LT chips.)
Thanks, but I'm not really sure what you mean, and don't know if Vin is "auxiliary" to LT3763 or not. Please find below correction that I had to made that LT3763 behave properly again:
(http://i.imgur.com/gX7GOpc.png) (https://imgur.com/gX7GOpc)
-
I see that you tied IVINP and IVINN (inputs of amplifier) directly to power rail. Could be reason why you lost IC while you powered it with low voltage, thus creating big difference between IVINP/N inputs and VIN. I know this is speculation - because block diagram does not show how particular amplifier is powered, nor say - it is "over the top input" type or not. [edit] Better idea would be to tie them to VIN pin, through resistor like 1K or so. [edit1] There could be similar problem with output current sense amplifier as well.
-
Hm, that's a good point! Perhaps they should be also tied now to bias power just as Vin. I have to order a few more LT3763 for further testing.
-
For testing purposes I would replace output current sense series R51 & R52 with bigger resistors, like mentioned 1k. It may cause sense error, but could protect amplifier and let you do some testing and tinkering.
-
I'll definitely spend some time to explore this possibility. It would be a shame not to use lower Vin, if possible, when we have on disposal that +7.5 V.
-
Hm, I don't know why I didn't try it before, but here it is. The LTspice model (in attachment) is clearly shows what I've found in practice (with great difference that nothing is damaged). The voltage applied on the Vin pin is set to 8 and 48 V, and with former output voltage cannot reach set value:
(http://i.imgur.com/gZIt9dd.png) (https://imgur.com/gZIt9dd)
-
I'll try the different approach here and that is Vout "tracking". LT3763 Vin,min is 6 V therefore we need offset of at least 6 V, i.e. for Vout, Vin has to be 6 V or higher. With tracking a considerable part of total dissipation is moved to external BJT that can be easier to cool. Number of extra parts are minimal and simulation results are promising. Now I have to check that in practice.
(http://i.imgur.com/ILIAeNT.png) (https://imgur.com/ILIAeNT)
Simulation above give us around 250 mW of dissipation for Vout of 5.5 V. That is almost 4 times lower then in case that +48 V is applied to Vin pin.
-
I've tested previously mentioned proposal to decrease Vin voltage (and consequently LT3763 power dissipation) and it looks promising. If +48 Vdc is applied to Vin input with Vout=10.5 V and Iout=1.2 A the LT3763 easily goes over 100 oC in a matter of minute (I didn't try to push it to the thermal shutdown):
(http://i.imgur.com/aExGb2S.png) (https://imgur.com/aExGb2S)
After that I've added simple regulator as in picture below:
(http://i.imgur.com/bV99ol9.jpg) (https://imgur.com/bV99ol9)
The LT3763's power dissipation drops significantly measured over many minutes (and without forced cooling) and even with higher output current (2 A). On the picture is also visible that temperature of the MOSFET is higher, but in SOT-223 it will be much easier to cool it then LT3763.
In summary, I think that simple hack is a more cheaper then switching from 2- to 4-layer PCB to eventually provide better cooling of LT3763.
(http://i.imgur.com/st8nNmF.png) (https://imgur.com/st8nNmF)
EDIT: check important notice in #152 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2672265/#msg2672265)
-
I'm following along here, and I thoroughly recommend getting some of that linear dissipation out of the driver chip. But I have a couple of questions:
- Is having IVINP and ININN greater than VIN OK?
- What happens when the output voltage is at a maximum? It looks like you'll still have considerable dissipation across the internal regulator.
It's a shame that you can't feed 5V straight into INTVCC, but the data sheet says "Do not force any voltage on this pin."
If the situation is bad with high output voltage, can you measure the DC supply current into Vin? I wonder how much of it is gate drive current, which you might be able to get around using an external gate drive supply and BJT buffer pairs to isolate the gate drive power from the on-chip regulator. Or just use MOSFETs with smaller Qg...
-
Is having IVINP and ININN greater than VIN OK?
Yes, that question still remains, it seems that leaving them tied to +48 Vdc does affect regular operations, but there is still two more options: to connect them together with Vin pin or to leave them connected together but floating. I've asked that question on Analog forum and maybe someone reply.
What happens when the output voltage is at a maximum? It looks like you'll still have considerable dissipation across the internal regulator.
Obviously that produce max. dissipation, but I'll test that and see if it is still acceptable or not (testing mentioned above was for the middle of the range).
If the situation is bad with high output voltage, can you measure the DC supply current into Vin? I wonder how much of it is gate drive current, which you might be able to get around using an external gate drive supply and BJT buffer pairs to isolate the gate drive power from the on-chip regulator.
I believe I could and that will be something in line with simulation (i.e. about 20 mA).
Or just use MOSFETs with smaller Qg...
Yup, it still better to move dissipation to MOSFETs (with smaller Qg and consequently higher Rds,on) then to have it on the controller. I'll check what I have on the stock, or I can order something new. If you have any good candidate to suggest that is in DPAK package, let me know.
-
Hm, IRFR7546 really doesn't seems light with its 58 nC (typ) of total gate charge. I'm definitely give chance to some others like NTD5867NLT4G, IPD400N06NG or FDD5612.
I've tried with max. Vout (i.e. 20 V) and for Iout of 2 A and little assistance of cooling fan (which is a part of the deal, together with onboard NTC for measuring temperature) the LT3763 temperature is around 60 oC, that is not bad at all:
(http://i.imgur.com/cK2fyGm.png) (https://imgur.com/cK2fyGm)
-
This starts to looks better and better. I got today NTD5867NLT4G and replace initially selected IRFR7546TRPBF MOSFETs. Former is twice as much cheaper has Total Qg of only 15 nC (typ.), but also very low QRR (Reverse Recovery charge) of only 12 nC. The results is obvious, now without fan assistance, for Vout=20 V, and Iout=2 A I have the same results as previous with fan cooling:
(http://i.imgur.com/cj5VBe2.png) (https://imgur.com/cj5VBe2)
... with fan cooling its go below 50 oC. Oh, and currently the ambient temperature is 30 oC!
(http://i.imgur.com/YaTePWy.png) (https://imgur.com/YaTePWy)
-
Now we’re cooking! (Or, rather, not cooking.) Looks like you got a temperature rise of of 32 K down to 18K, which is a big improvement.
Perhaps a quick test at minimum output voltage would be in order to check the temperature rise of your linear dropper MOSFET?
It looks like the MOSFETs run cooler too. It’s easy to get caught up in the on resistance / conduction losses and lose sight of the switching losses.
I would like to clarify one thing: given a maximum output of 20V (which will be totally fine for many applications), why are you using a 48V input rail? Is it for common parts? With a 24V input I think you can get lower Qg MOSFETs again and drive the control chip directly from 24V.
-
48V is because the same slot has to support the higher voltage single channel modules.
-
48V is because the same slot has to support the higher voltage single channel modules.
Exactly, that will run cost down, and with unified DCbus, we can in the next step starts to think about AC/DC converter with multiple isolated outputs, and after that about bidirectional one when 2Q and 4Q power modules come into picture!
-
A small update regarding the DCM220 Vin hack (see #144 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2639193/#msg2639193)): I found that when LT3763 is disabled full DCbus voltage appears on that pin (that should be input)! Therefore the voltage difference between added regulator MOSFET source and gate is 36 V, that is not good. To fix that issue a diode in series with MOSFET source to LT3763's Vin is added.
-
The latest version of DCP405, a single output power module, is more or less finished and ready for planned forthcoming crowdfunding. It includes a few modifications (thanks to my friend Macola) from the previous revisions that were used the same design as the power module from the EEZ H24005 project. First, how it looks like:
(http://i.imgur.com/EEj4QpF.jpg) (https://imgur.com/EEj4QpF)
Here is the list of changes:
- The main change is that N-channel MOSFET as pass element in the post-regulator section is replaced with 2 x PNP BJTs (D45H11).
- Changing of pass element driver section also asked for different type of down-programming. Therefore that circuit is completely redesigned.
- The CV/CC mode of operation detection is now much simpler.
- The bias power supply that was use not so efficient combination of linear step-down regulator (TL783) and LTC3260 capacitive switcher is replaced with low power buck (TPS54060) that is using coupled inductor to generate positive and negative voltage.
- The good thing about replacing MOSFET (that is in TO247 package) and TL783 is that now I can use "off-the-shelf" L-profile heatsink, that will greatly simplify assembling, and no custom heatsink is needed anymore.
- More precise (and still very cost attractive!) MC33272ADR2G op-amps are used instead of TL072. The CV loop compensation network is also cleaned up and adjusted to work properly with new op-amps.
Schematics of the post-regulator is shown below (mentioned new bias supply and CV/CC detection is not shown), and complete design is available on the GitHub (https://github.com/eez-open/modular-psu/tree/master/dcp405) as usual.
(http://i.imgur.com/dZuTVL7.png) (https://imgur.com/dZuTVL7)
LTspice simulation of the new post-regulator is also available on the GitHub, but it is also attached to this post. Please note that it assume that input voltage is fixed, not regulated by pre-regulator circuit.
-
Oh yes, I forgot to mention that I've made some measurements for the DCP405 module that can be found on: https://www.envox.hr/eez/eez-bench-box-3/eez-bb3-measurements/dcp405-power-module.html (https://www.envox.hr/eez/eez-bench-box-3/eez-bb3-measurements/dcp405-power-module.html)
-
The firmware is now pretty completed regarding the new GUI, and it can be test even without having physical device thanks to the Web simulator (https://www.envox.hr/eez-modular-firmware-simulator/). It includes almost all functionality of the real device and gives even possibility to attach load, and mouse wheel can be used to simulate incremental encoder. I'm attaching a few pages below and your feedback about look and feel, usability, etc. is highly appreciated.
(https://i.imgur.com/4TiWrrz.png)
(https://i.imgur.com/zOCbByO.png)
(https://i.imgur.com/ik7NLq1.png)
-
Wow, this is great! I used it a little bit, the confusing part that by default max current was set to zero. So, it was in CC mode, but voltage and current were 0. Sort of what it should, but in real world zero is not exactly zero, so there are some numbers jumping around.
I quickly used it, was a bit difficuilt in the beginning. There are many options. I'd prefer some dedicated knobs, but this design with several modules just doesn't support it. Nonetheless, I hope it would be possible to bind the rotary knob to quickly change voltage. Motivation: sometimes I characterize elements like diodes by slowly manually changing current/voltage and observe how it reacts. Sort of poor man's SMU. I understand that it supports programming, but I found a dedicated controls to be useful.
Anyway, great job!
-
Yes, it's possible to "dedicate" encoder knob to any of output values (U, I or P). On the simulator you just need to position mouse on it, click, and use mouse middle wheel to increase/decrease current value. On the real device you just need to select output value with your finger thanks to touchscreen and engage knob. If you click "user sw" you can change knob step value (e.g. auto, 500 mV, 1 V, 2 V or 5 V when voltage is changing).
-
cant' wait to buy one!
-
Don't know if you possibly have the previous H24005 unit, but if you have one I can say that BB3's bigger display, better rendering (fonts are now antialiased) and responsiveness makes a huge difference, probably similar to one experienced between H24005 and regular PSU with LED/LCD displays, keypad/knobs. You cannot feel that on the simulator.
-
Yep. I thought the previous simulator was great and then realised that using the real thing would mean I was better using a rubber topped pencil than my stubby fingers. STILL it was better then my other supplies.
-
For those who are not aware that there is a topic for the upcoming crowdfunding campaign, here is the link:
https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2786804/#msg2786804 (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2786804/#msg2786804)
The campaign should start this week and I want to thank you in advance for your support and I believe BB3 will live up to your expectations.
-
The campaign is now up.
I hope that I’ll be able to work with the DIB spec to produce custom modules, and I am looking forward to (hypothetical) extra modules for things like 2Q supplies and precision power meters.
I have a couple of technical questions:
- How are you doing on testing and assembly? I’ve found with my products that there can be quite a lot of design for testing work...
Eg, the connectors that were fine for dev work may wear out surprisingly fast when you’re testing a production batch and cause intermittent test failures :-(
[li]If you get a good number of orders and the cost per unit comes down a bit, would you consider doing an IEC 60950 (or similar) safety evaluation in a test lab?[/li][/list]
-
I hope that I’ll be able to work with the DIB spec to produce custom modules, and I am looking forward to (hypothetical) extra modules for things like 2Q supplies and precision power meters.
Many people are asking for 2Q module, and I wonder what is the best way to gather information on what people need and create an initial specification that should be used as a design guide. Perhaps we could start a discussion here and then create a new public repo on GitHub and transfer useful information there to make it accessible in a more structured way.
I have a couple of technical questions:
- How are you doing on testing and assembly? I’ve found with my products that there can be quite a lot of design for testing work... Eg, the connectors that were fine for dev work may wear out surprisingly fast when you’re testing a production batch and cause intermittent test failures :-(
- If you get a good number of orders and the cost per unit comes down a bit, would you consider doing an IEC 60950 (or similar) safety evaluation in a test lab?
Basic PCB testing and module assembly will be done by a PCBA contractor, functional testing will be done on my side when firmware will be downloaded and the functionality of the entire system will be tested. The self-test itself gives a good picture of what's is good or wrong, this was the case with the H24005 testing so I'll do the same for BB3.
I'm not in a position to invest in any testing automation yet, but I believe this will change if the number of units increases over time.
Having in-house safety (and EMC) evaluation could be a great plus, but it's also out of my current budget. So far, I've secured funding for entering EU-accredited lab for EMC and safety CE compliance certification for the current BB3 configuration. I'll see when testing starts if I can arrange with them some pre-compliance testing for future modules/configurations with some discounts.
-
for the 2Q, If I recall correctly it kind of needed your fancier mains supply, as you where planning on dumping the excess power back to mains, I suppose it would not be hard to take the current thermal power budget to know how much you could dissipate using the existing modules.
-
...
Many people are asking for 2Q module, and I wonder what is the best way to gather information on what people need and create an initial specification that should be used as a design guide.
...
I'll bet a quality 2Q module turns out to be quite complicated... for example, working out the voltage and current loop priorities in a sensible fashion.
...
Having in-house safety (and EMC) evaluation could be a great plus, but it's also out of my current budget. So far, I've secured funding for entering EU-accredited lab for EMC and safety CE compliance certification for the current BB3 configuration. I'll see when testing starts if I can arrange with them some pre-compliance testing for future modules/configurations with some discounts.
Yeah, gear gets expensive real fast. And EMC testing sometimes requires large and specific setups (Faraday cage room, anyone?). You probably know this already, but it's good to get in for compliance testing quite early - issues get more expensive to fix as you get further through the design process. This might apply double for safety testing...
for the 2Q, If I recall correctly it kind of needed your fancier mains supply, as you where planning on dumping the excess power back to mains, I suppose it would not be hard to take the current thermal power budget to know how much you could dissipate using the existing modules.
While it might seem attractive to dump power to the mains side, you could get an islanding (https://en.wikipedia.org/wiki/Islanding) problem, and may require quite elaborate anti-islanding systems. I think you're right that a good start would be to rate the unit to suit available power dissipation.
I guess you could have an external power resistor which plugs in for expanded range. Getting a bit complicated at that point...
-
It really depends. Lets start with presumption that 2Q should substitute electronic load. Electronic loads comes in all shapes and sizes depending of the use case. My idea is to start with "dissipative" 2Q module. If we want to dissipate e.g. 100 W or even more its obvious that such dissipation will be an overkill if everything has to be done inside BB3 chassis. If the main scenario is to test another power supply, DC-DC module or huge battery discharge then we cannot do that in that way.
But, if we'd like for start to address people how is willing to test their battery operated or low power devices (e.g. various IoT gadgets) that is operated with small battery and low voltage then it seems that 2Q with e.g. 20-25 W of sinking power could be more then enough, or not?
In the next step for bigger power e.g. up to 200 W we could provide connection for external power resistor, that has to be safely caged against the accidental touch, and dissipate excess power outside BB3 chassis. Not so elegant but could be cost effective.
After this stage all others should include bidirectional AC/DC power stage.
-
Hi jbb, it seems that we're replying in the same time. I'm agree, making a quality (and reliable) 2Q could be quite complicated. Another mission impossible for me, but with assistance from here and there I'm now quite confident that it is doable.
-
Why not make the power supply battery powered and use the big battery to absorb the power instead of dissipating it. Or use super capacitors to store the power. If you keep an almost empty battery in the supply under normal conditions and only charge it that way and if it is charged beyond a certain point power other channels with the stored energy. Then instead of dissipating the power you store it.
-
Why not make the power supply battery powered and use the big battery to absorb the power instead of dissipating it. Or use super capacitors to store the power. If you keep an almost empty battery in the supply under normal conditions and only charge it that way and if it is charged beyond a certain point power other channels with the stored energy. Then instead of dissipating the power you store it.
Hm, sounds interesting, perhaps supercap could be more suitable for such job since it should offer more freedom for charging i.e. when sinking is active. In that case a possible option could be a connector for connecting external battery/supercap?
-
Why not make the power supply battery powered and use the big battery to absorb the power instead of dissipating it. Or use super capacitors to store the power. ...
The downside of a battery or capacitor bank is that it has finite energy capacity. It could be very annoying to have the load stop working in the middle of a test because the battery is full...
One thing to look out for: it can get really hard to ship lithium batteries (whether non rechargeable coin cells, LiIon, LiPo, LiFePO4...)
-
I've backed your CrowdSupply thing. I can't wait, as this supply looks excellent - your attention to details is highly commendable.
However: It's currently 62% funded.
Am I right in assuming if it doesn't hit 100% funding, no one gets their PSU kits?
I really hope this isn't the case.
Is there a plan B if it fails to get there?
All the best,
Dan
-
Yes, if it doesn't hit 100% no one gets BB3. The plan is to finally try to find a way to launch a campaign at leading crowdfunding sites such as Kickstarter and Indiegogo. It will take extra time to do this. In the case of Kickstarter, I also need an intermediary agency, since it is still not possible to start a campaign directly from Croatia.
-
I do not have that much personal experience with crowdfunders, but I made some observations.
I also was put off by the sharp drop of progress, but since then it grew steadily, if slowly. The initial surge were the early birds, which must have gone fast. Surprising, seeing that the discount wasn't *that* high.
Generally most campaigns see a surge near the end as well, at least if the situation is not hopeless.
Maybe we can get Dave to cover the BB3 in a Video? Does he have a H24005?
-
I do not have that much personal experience with crowdfunders, but I made some observations.
I also was put off by the sharp drop of progress, but since then it grew steadily, if slowly. The initial surge were the early birds, which must have gone fast. Surprising, seeing that the discount wasn't *that* high.
Generally most campaigns see a surge near the end as well, at least if the situation is not hopeless.
Yes, nothing is finished yet. We've entered the most challenging phase now to make it visible to "outsiders" and I don't have a marketing team nor agency specialized in crowdfunding campaign promotions :). I also didn't check how visible was Crowd Supply site two years ago (in time of H24005 funding) but I can imagine that its visibility is deteriorating (I was recently warned about that from owner of other campaign who has some "metrics" available).
Maybe we can get Dave to cover the BB3 in a Video? Does he have a H24005?
As far as I know, he doesn't. I failed to send him H24005 and that was happened again with BB3. This time I didn't manage to ensure funds for test run of modules that I can complete a few units and send them around. There was a promise from a guy who visited me this summer from Middle East willing to invest in EEZ project and get 10 units for university on which he is supposedly works but he simply disappeared, and I've lost time waiting for nothing.
-
Don't stress about the guy going missing. There are mongrels everywhere - I hope he got nothing from you. :box:
I'd suggest that you keep the updates happening (on the Crowd Funding page). Some of the stuff you have been talking about with jbb may be a good starting point - he drinks, so he can't be all bad. The updates will show that this is a product for the future and not a dead end.
What other modules are you looking at - other than power supplies? A self contained generator/meter for complete frequency responses - or other module combinations for designer/maker small production runs would keep interest going.
And then there are your early birds. It appears that as most of your clients want "one with the lot" and are prepared to pay for it. You have 80-odd potential product ambassadors who should promote the unit in order to ensure that they get theirs. Best of luck.
-
One more thought. How about a demo of a computer controlled test scenario/s where information is fed back to the operator for decision making?
I used a H24005 to test some Chinese vibration motors to destruction before I committed to buy more. I'm not aware of any other power supply family that can do the work of the products in the Envox family AT THEIR PRICE POINT.
-
Don't stress about the guy going missing. There are mongrels everywhere - I hope he got nothing from you. :box:
I'd suggest that you keep the updates happening (on the Crowd Funding page). Some of the stuff you have been talking about with jbb may be a good starting point - he drinks, so he can't be all bad. The updates will show that this is a product for the future and not a dead end.
Project/product is all but dead! The first update should be ready in 2-3 days and it covers in more details data logging that can be start with one (two :)) clicks. Logged data can be displayed immediately during a logging and when logging is finished. It is also possible to transfer logged data now to PC with one click action! Taking screenshots, and SD card file manager will be also presented in the first update.
We're also preparing presentation of MicroPython scripting, which is, I believe, another unique feature of the device in its price category (if anyone at all has the ability to run Python scripts directly on the device, not its PC control application). As first scripts example I'd like to make a diode tester and simple transistor curve tracer. Therefore your suggestions about curve tracer "feature set" is welcome. I have a basic understanding what is needed to draw U-I plot, but still if someone knows where to find a sort of flow diagram that would be nice.
What other modules are you looking at - other than power supplies? A self contained generator/meter for complete frequency responses - or other module combinations for designer/maker small production runs would keep interest going.
If we put aside 2Q and 4Q power modules, then DC power analyzer is high on the priority list (mentioned also here (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2795014/#msg2795014)). Simple multi-line/channel digital and analog I/O board could be added rather quickly as a good showcase for potential builders of the other modules. I'm also interesting in building a simple Bode plotter that will require signal generator and decent A/D stage.
And then there are your early birds. It appears that as most of your clients want "one with the lot" and are prepared to pay for it. You have 80-odd potential product ambassadors who should promote the unit in order to ensure that they get theirs. Best of luck.
That's right and I want to thank you for your support. I do believe that other backers also will find a time to spread a word about BB3.
-
One more thought. How about a demo of a computer controlled test scenario/s where information is fed back to the operator for decision making?
I used a H24005 to test some Chinese vibration motors to destruction before I committed to buy more. I'm not aware of any other power supply family that can do the work of the products in the Envox family AT THEIR PRICE POINT.
Huh, that is something that I need badly: a "use case" how EEZ PSU helps one in everyday work and what is not easily achievable with basic PSU. May I contact you via PM for more details? That could be a great story for the next newsletter!
-
Of course!
-
I have had quite some time now to think around your project. I was not sure where to post this, but I think it fits a bit better here than in the announcement post.
The points I am going to outline all are related to the mechanical design. I am also aware that, for the running campaign, not much (if anything) can be changed. Also, I am referencing the open box picture on Crowdsupply.
- 1. The wiring harness.
Is the harness routed as it is in the picture, or is that pic more of a showcase of the harness? I would be afraid if the harness could be pinched between the divider and the lid when something heavy is placed on top of the BB3. I would prefer the harness to be routed through the divider. Also, a minor point, looking at the lowest module, it seems that the harness is a tad too short, flexing the board. - 2. The Aux Power Board.
Actually my biggest critique of the design. By the looks of it, I would have to open the BB3 to unplug it. Would it not make much more sense to have a power jack on the back panel and run wires to the AUX board, instead of having that deeply recessed power jack? In the process I would also make the fuse accessible without opening the box - 3. The Ethernet port.
I have read you explaining somewhere here that the ethernet port is where it is, mainly for routing issues. I get that, looking at the gerbers, moving the port to the other side may be a major issue. One suggestion that should be possible without major changes: Use a "top loading" RJ45 jack. Maybe even keep the LED indicators on the front panel. Then use a small patch cord with a clip-in coupling to route the network to the back of the unit. - 4. The backplane.
Last point, and the biggest. I'm sure you have explained it somewhere: Why not an actual, well, backplane?
That would of course be a major change. Something that would require a re-spin of almost everything. But the ability of changing modules without opening the box would be a major benefit in my opinion, especially once more modules become available. And I'm sure a backplane could be designed to allow enough airflow.
But of course proper backplane connectors are expensive, and additional mechanical features like guide rails and stable mounting of the backplane would also increase cost.
Nothing of this will be stopping my pledge (which I may still upgrade). Some of these (the harness, Aux board and maybe the network) will be things that I will try to implement with the kit.
I just wanted to present my ideas. I'm sure you had good reasons to design the BB3 as you did.
Maybe some of that can be used for an eventual BB4 ;)
-
Thanks for your feedback and support!
I have had quite some time now to think around your project. I was not sure where to post this, but I think it fits a bit better here than in the announcement post.
The points I am going to outline all are related to the mechanical design. I am also aware that, for the running campaign, not much (if anything) can be changed. Also, I am referencing the open box picture on Crowdsupply.
1. The wiring harness.
Is the harness routed as it is in the picture, or is that pic more of a showcase of the harness? I would be afraid if the harness could be pinched between the divider and the lid when something heavy is placed on top of the BB3. I would prefer the harness to be routed through the divider. Also, a minor point, looking at the lowest module, it seems that the harness is a tad too short, flexing the board.
Wiring to the modules are little too short, final version will be longer. I probably didn't fully understand this, but I see no way that the cables inside could be compromised by placing anything on top of BB3. Mean Well modules are mounted on the top cover (from "below"), and cables according to the modules stand between Mean Well modules and the back panel. Care should be taken to ensure that the cables are inserted under the fan.
2. The Aux Power Board.
Actually my biggest critique of the design. By the looks of it, I would have to open the BB3 to unplug it. Would it not make much more sense to have a power jack on the back panel and run wires to the AUX board, instead of having that deeply recessed power jack? In the process I would also make the fuse accessible without opening the box
If your major concern is fuse replacement, then here we go:
(http://i.imgur.com/zdVtUjI.jpg) (https://imgur.com/zdVtUjI)
3. The Ethernet port.
I have read you explaining somewhere here that the ethernet port is where it is, mainly for routing issues. I get that, looking at the gerbers, moving the port to the other side may be a major issue. One suggestion that should be possible without major changes: Use a "top loading" RJ45 jack. Maybe even keep the LED indicators on the front panel. Then use a small patch cord with a clip-in coupling to route the network to the back of the unit.
Okay, it looks like some people really have a problem with this heretical approach and some don't :)
It looks like this to me, and so far I have had no problem working with it:
(http://i.imgur.com/NEVJx1T.jpg) (https://imgur.com/NEVJx1T)
Yes, one option would be to place the RJ-45 on the opposite side of the PCB (where the LDO is now), add an extra patch cable and open a hole in the back panel.
4. The backplane.
Last point, and the biggest. I'm sure you have explained it somewhere: Why not an actual, well, backplane?
That would of course be a major change. Something that would require a re-spin of almost everything. But the ability of changing modules without opening the box would be a major benefit in my opinion, especially once more modules become available. And I'm sure a backplane could be designed to allow enough airflow.
But of course proper backplane connectors are expensive, and additional mechanical features like guide rails and stable mounting of the backplane would also increase cost.
Nothing of this will be stopping my pledge (which I may still upgrade). Some of these (the harness, Aux board and maybe the network) will be things that I will try to implement with the kit.
I just wanted to present my ideas. I'm sure you had good reasons to design the BB3 as you did.
Maybe some of that can be used for an eventual BB4 ;)
Yes, this could be done in another way, i.e. how classic multi module enclosure where each module must be the same size. This has the advantage you already mentioned: if someone has more than three modules and wants to exchange them, they will need to remove 4 more screws. The current principle is just like with a PC, but everything happens on the front and not the back side and the modules can be of different sizes.
-
Thanks for the reply :)
I have only looked at the pictures on the crowdsupply page.
1. It was not visible on the top-down open box shot that the Meanwell units are higher than the divider, and if I have understood you correctly, are somewhat used as structural element. That of course eliminates possible pinching. Also I would never have thought that the modules are mounted on the top cover. Interesting concept.
2. Similar here. The picture of the populated AUX-PS board shows the soldered power connector, looking as if the power cable would have to be routed to the inside. It seems you are already doing something similar to what I described :-+
3. That looks workable. I was not aware that the feet create a gap that large.
4. I was not aware that you could swap modules while only having access to the front. :-+ See point 1 why I though that this was not possible ;). I can see the flexibility advantage of having less limitations for the board size.
-
4. I was not aware that you could swap modules while only having access to the front. :-+ See point 1 why I though that this was not possible ;). I can see the flexibility advantage of having less limitations for the board size.
I think I need to clarify this: "everything is happening on the front and not the back side": this does not mean that the modules can be pulled out in the front, but that the PC concept is inverted: just as with a PC the cover should be removed for accessing PC cards (that are on the back side), is the same with BB3 to access modules (that are on the front side). Sorry for confusion.
-
When I first saw the BB3, I assumed that the backplane was in back and the modules could be pulled out and swapped without taking the case apart. It seemed like a reasonable assumption for modular lab equipment. Can you highlight reasons you chose to put the backplane on the bottom instead of against the back? Easier airflow for cooling?
-
Yes, easier airflow for cooling is one of the reason. With backplane on the rear you have to put cooling fan on top or below modules. That adds at least 2 extra centimeters in height.
There are two other reasons: the ability to insert modules of different lengths and the ability to extend the backplane with new connectors (for additional functions and higher speeds) while maintaining backward compatibility.
-
Also, if a card can be pulled out the front then people want hot (power-on) swapping, which can open several cans of worms.
The space for custom extra backplane is nice, too.
-
The MicroPython (https://micropython.org/) is coming on BB3, here is few screenshots, and more stuff is coming soon :)
(http://i.imgur.com/2CT2qeh.png) (https://imgur.com/2CT2qeh)
Scripts folder:
(http://i.imgur.com/swbpJqS.jpg) (https://imgur.com/swbpJqS)
Debug console (output):
(http://i.imgur.com/8fVGsMH.jpg) (https://imgur.com/8fVGsMH)
-
Does this mean that a "Test Automation" script, written on the computer, can be sent to the BB3 where the direction/options for the test itself can be controlled by an operator from the front panel of the BB3? Can the results be sent back auto-magically to the computer (Test Manager)?
For example:
A battery charging test script:
* The script is started
* The script asks the operator for battery type
* The script sets up the BB3 with appropriate limits and safeguards
* The script asks for the time length of test or test start/stop times (or other condition)
* The script draws data from the BB3 for analysis
* The script allows the operator to terminate the test from the front panel
-
Yes, that is one of the possible scenario. Currently auto-magical transfer of data has to be initiated by selecting the data file and click upload, but we'll add more magic to skip that step :-/O
-
Is the DCP405 safe to use for battery charging (specifically, if the mains fails)?
-
Thanks for asking that, I'll include that in one of the next video where various protections will be presented. Battery can remain connected regardless of blackouts and no extra diode connected in series is required as in case of many other PSU.
-
I'd like to present you a screenshot of first MQTT implementation on the BB3. It shows monitoring of output voltage and current on first two channels.
The MQTT connectivity makes BB3 an IoT client that can coexists with "fellow" IoT devices that it could power.
This first example is accomplished by setting MQTT broker on CloudMQTT (https://www.cloudmqtt.com/) and MQTT Explorer (http://mqtt-explorer.com/) is used to make connection.
(http://i.imgur.com/LjLiRyU.png) (https://imgur.com/LjLiRyU)
Now, we have to add possibility to receive all messages that appears in event log (e.g. protections tripped, channel fault, fan fault, etc.). I believe that could be a great feature for new modules that comes like multi channel data logging and I/O. Your inputs, ideas, comments are welcome as usual!
-
Hi Denis,
I enjoyed seeing the update you posted to the CrowdSupply page today explaining the power output coupling / tracking; something you mentioned in the original listing and one of the main reasons I joined in, but nice to see the detailed video explanation :-+
My questions:
1. I've backed the Early Bird 2x Channel + extra DCM220 module for 4x channels... however say I wanted more channels, maybe the same again:
What options, if any, are there for tracking between multiple units? I obviously don't want to combine voltages/currents in any combination between 2x BB3's, but is it possible to turn all outputs on and off of both BB3's from one unit? Can I safely combine multiple BB3's to have one single common GND? [Say set each unit to common GND mode, and link both units with a lead?]
Many of my projects have many voltage rails, so looking for a good solution. [e.g. typically use simultaneously up to: -24V, +24V, +3.3V, +5V, +2.5V, +6.0V, +7.5V +12V], often less.
Are there any other clever features that you can think of having multiple BB3's "talk" to each other, to provide a nice scaleable solution?
2. Could a BB3 be configured with 3x DCP405 (Full) or is it limited to 2x - any other caveats running 3x DCP405 modules?
3. How future proof is the BB3 chassis? I see you made the H24005, which I'm unfamiliar with, but how long is the BB3 likely to stick around, or will there likely be a new chassis in a year or two?
4. Do you have a timeline on any new modules // roadmap?
Keep up the excellent work! I really hope you make the 100% target; the level of detail you've put in to this is really excellent.
All the best,
Dan
-
1. I've backed the Early Bird 2x Channel + extra DCM220 module for 4x channels... however say I wanted more channels, maybe the same again:
What options, if any, are there for tracking between multiple units? I obviously don't want to combine voltages/currents in any combination between 2x BB3's, but is it possible to turn all outputs on and off of both BB3's from one unit? Can I safely combine multiple BB3's to have one single common GND? [Say set each unit to common GND mode, and link both units with a lead?]
Many of my projects have many voltage rails, so looking for a good solution. [e.g. typically use simultaneously up to: -24V, +24V, +3.3V, +5V, +2.5V, +6.0V, +7.5V +12V], often less.
Are there any other clever features that you can think of having multiple BB3's "talk" to each other, to provide a nice scaleable solution?
Tracking between multiple units could be accomplished from "outside" i.e. using EEZ Studio with little help of JS or by using MQTT client (we are finishing MQTT support). Anyway, we'll be more then happy to assist anyone who come with such request, that means who bought more then one BB3 unit :)
Idea is also to add into future chassis without TFT console that could house e.g. 6-7 units that do not require AC/DC converters (i.e. data loggers, I/O, switch matrix, signal generator, etc.). In that case we have to think about some "inter-chassis" communication.
2. Could a BB3 be configured with 3x DCP405 (Full) or is it limited to 2x - any other caveats running 3x DCP405 modules?
Yes, the third module could be also DCP405. Only limitation is couplings. It cannot be combined in series, parallel or as "split rails".
3. How future proof is the BB3 chassis? I see you made the H24005, which I'm unfamiliar with, but how long is the BB3 likely to stick around, or will there likely be a new chassis in a year or two?
There is two major reason why I've decided to move from H24005 to BB3: 1) limited modularity and 2) we've reached Arduino Due limits. It's conceived to last for a while and can be upgraded with new functionality. Currently, I can only think of new chassis as one mentioned above ("expansion unit"). That possibly will introduce changes on rear panel, but "real panel upgrade" could be a part of the deal in that case. Idea is to try to establish production after crowdfunding campaign.
4. Do you have a timeline on any new modules // roadmap?
There is not strict timeline but I'd do my best to complete at least two new modules in 2020: 1) 2Q DC power module with two current ranges suitable for powering and monitoring consumption of battery powered devices, and 2) simple data-logger (that "simple" is not necessary too simple :).
Please note that we are nothing even closer to smallest T&M corporation you ever heard of, and everything lasts much more time. During 2020 I'll probably need to spend more time on promotion and marketing that could seriously affect speed of development. Things is currently as it is, I don't like to inflate an illusion about something that we are not or make empty promises, but try to deliver as much as possible, aware of our limitations (our means Martin's and mine).
Keep up the excellent work! I really hope you make the 100% target; the level of detail you've put in to this is really excellent.
All the best,
Dan
Thanks Dan for your support, maybe we can make it happen.
-
Thanks Denis for the detailed reply; all sounds really promising.
What does the digital I/O on the front panel currently do?
Would it be easy enough to allow the units to trigger each others "outputs enable / disable" from the state of the digital IO?
If this is, then I'd almost certainly be up to backing a 2nd unit. [Not pressuring you, just would be personally useful to me if I can turn on 6-8 outputs at once].
All the best,
Dan
-
Thanks for mentioning I/O ports on the front panel. There is a serial port exposed, and you can use it as trigger in/trigger out: in essence everything is already there for simple multi-chassis communication!
-
Excellent! Is any of this triggering currently implemented in the firmware?
If not, is there any chance it will be when the units are shipping?
-
Yes, triggering is already supported, if we need more "magic" we'll add it :-/O
-
Yes, triggering is already supported, if we need more "magic" we'll add it :-/O
Perfect - just backed a 2nd unit :-DMM
-
I love the new MicroPython update you posted @ CrowdSupply.
The diode test example got me thinking: I test a lot of laser diodes in my line of work, and characterising their PI curve is often useful. However to measure laser power I have a specialised power meter [either thermopile or calibrated photodiode depending on type of laser under test].
These meters generally output 0-2V full scale.
Using your BB3 setup like this would be tremendously helpful... to accurately meter: voltage, current and optical power (via scaled analog input voltage from power meter). And get the script to only test to certain current limits or optical power limits etc.
Question: could your system be extended to easily incorporate an analog input? (Or does it already?)
This would open up many many useful doors :)
-
I love the new MicroPython update you posted @ CrowdSupply.
The diode test example got me thinking: I test a lot of laser diodes in my line of work, and characterising their PI curve is often useful. However to measure laser power I have a specialised power meter [either thermopile or calibrated photodiode depending on type of laser under test].
These meters generally output 0-2V full scale.
Using your BB3 setup like this would be tremendously helpful... to accurately meter: voltage, current and optical power (via scaled analog input voltage from power meter). And get the script to only test to certain current limits or optical power limits etc.
Question: could your system be extended to easily incorporate an analog input? (Or does it already?)
This would open up many many useful doors :)
There are also the doors that it will open with additional modules. It seems that a mooted multiple channel data-logger may be just what you need. The whole ecosystem that Envox is building will help a lot of us get our products to production.
-
There are also the doors that it will open with additional modules. It seems that a mooted multiple channel data-logger may be just what you need. The whole ecosystem that Envox is building will help a lot of us get our products to production.
That's the main reason I got involved :-+
-
Hi all,
Did I read somewhere that 3rd parties will be able to design, build and sell modules. If so, will there be a schematic/layout template be available at some point.
Ian.
-
Hi Ian, that is correct. Everything is provided as open source, open hardware. Therefore everyone is invited not just to make new modules but to clone and sell everything what is done so far. New module has to follow DIB v1.0 specification (https://www.envox.hr/eez/eez-dib/dib-v1-0-specification.html), and if DIB v2.0 is ever happen it will be backward compatible with v1.0.
First step toward module "template" can be found here: https://github.com/eez-open/modular-psu/tree/master/DIB%20v1.0 (https://github.com/eez-open/modular-psu/tree/master/DIB%20v1.0)
We'll do our best to assist one in integration with firmware (https://github.com/eez-open/modular-psu-firmware) and the rest of the system.
-
Question: could your system be extended to easily incorporate an analog input? (Or does it already?)
This would open up many many useful doors :)
Actually one analog input already exists but is not wisely deployed: it can be used only to control output voltage (i.e. remote programming). I've selected 4-ch ADC at the very beginning and didn't know in that time where to use all inputs. Usage of two is obvious: monitoring output voltage and current (U_MON and I_MON), but remaining two are used for monitoring DAC outputs (U_SET and I_SET).
Even with current configuration by adding another 1-to-2 mux (like SN74LVC1G3157) it could be possible to use existing Rprog input not only for controlling output voltage but as general purpose analog input. In that case U_SET or I_SET monitoring has to be disabled.
-
Actually one analog input already exists but is not wisely deployed: it can be used only to control output voltage (i.e. remote programming). I've selected 4-ch ADC at the very beginning and didn't know in that time where to use all inputs. Usage of two is obvious: monitoring output voltage and current (U_MON and I_MON), but remaining two are used for monitoring DAC outputs (U_SET and I_SET).
Even with current configuration by adding another 1-to-2 mux (like SN74LVC1G3157) it could be possible to use existing Rprog input not only for controlling output voltage but as general purpose analog input. In that case U_SET or I_SET monitoring has to be disabled.
Ah nice!
Maybe I'll wait for a "ADC / AIO module" once the 2x units arrive to extend idea this further.
Good to know it's on the road map though + keep up the good work.
I really hope you reach the funding target; I'll be most disappointed for everyone involved if not.
-
Test scripts on board does look like a win, and Python is quite easy to understand and edit. No messing about trying to compile the whole thing from C source code.
This begs the question; could we write device drivers for the modules in Python? (They would be a little slower, but that would be OK for many things.) And store the device driver code inside the module I2C EEPROM?
————
Some security thoughts for nerds:
- STM32F7 doesn’t have a Memory Management Unit (MMU) (may have a Memory Protection Unit(MPU) which isn’t as good) so a Python virtual machine is a great way of separating applications
- it’s highly likely that there will be ways for malicious code to break out of the expected behaviour of the Python sandbox
- storing code on a device that you buy off the internet isn’t great
- the Python code on the modules could be signed using asymmetric cryptography (eg ECDSA) so that the code can be verified before execution
- EEZ could hold a master private key, and issue certificates to developers that let developers sign their own code
- maybe unsigned code could run if the user clicks an “OK, run it this time” button or configures their unit into some ‘developer’ mode
-
This begs the question; could we write device drivers for the modules in Python? (They would be a little slower, but that would be OK for many things.) And store the device driver code inside the module I2C EEPROM?
This is an interesting question or proposal. Simplicity of Python is great feature, but overall performance is questionable. It could be fine for module that does not need a fast communication with the master MCU module (that is in charge of driving TFT touchscreen display). Peripheral module in that case needs on-board MCU by default, what is also not a big deal, but we have to add support for inter-module communication that is based on Python (what is not currently the case). Anyway, this is an idea worth of considering.
Some security thoughts for nerds:
- STM32F7 doesn’t have a Memory Management Unit (MMU) (may have a Memory Protection Unit(MPU) which isn’t as good) so a Python virtual machine is a great way of separating applications
- it’s highly likely that there will be ways for malicious code to break out of the expected behaviour of the Python sandbox
- storing code on a device that you buy off the internet isn’t great
- the Python code on the modules could be signed using asymmetric cryptography (eg ECDSA) so that the code can be verified before execution
- EEZ could hold a master private key, and issue certificates to developers that let developers sign their own code
- maybe unsigned code could run if the user clicks an “OK, run it this time” button or configures their unit into some ‘developer’ mode
Ok, "nerds" are welcomed with their comments here, and I have to discuss this with Martin, too.
-
Some security thoughts for nerds:
- STM32F7 doesn’t have a Memory Management Unit (MMU) (may have a Memory Protection Unit(MPU) which isn’t as good) so a Python virtual machine is a great way of separating applications
- it’s highly likely that there will be ways for malicious code to break out of the expected behaviour of the Python sandbox
- storing code on a device that you buy off the internet isn’t great
- the Python code on the modules could be signed using asymmetric cryptography (eg ECDSA) so that the code can be verified before execution
- EEZ could hold a master private key, and issue certificates to developers that let developers sign their own code
- maybe unsigned code could run if the user clicks an “OK, run it this time” button or configures their unit into some ‘developer’ mode
Ok, "nerds" are welcomed with their comments here, and I have to discuss this with Martin, too.
Nerd here. Opinionated nerd with software security experience, including design and implementation of software provisioning secured by public key encryption.
I would really rather not have to jump through hoops to run my own code on my own BB3. The target user isn't naïve.
I'd like to point out that there are currently 129 backers, with less than two weeks remaining on the campaign. This does not make the BB3 a substantial attack target. There's a joke: When you are in a group being chased by a bear, you don't have to run faster than the bear, you just have to run faster than the slowest person in the group. Are people going to spend time attacking the BB3 when they could be trying to take over npm or pypi packages with tens or hundreds of millions or more of potential targets?
If you start signing other people's code, you are asserting something about it. Let's pretend you set this up and start signing code. What precisely does that signature represent? Does it mean you have audited the code for safety, and are confident that it won't break something? If someone is writing malicious code, are you more likely to catch it than someone with expertise in the domain in which the code applies? If you sign malicious code because you missed the malicious nature, and it causes harm, have you incurred liability by explicitly signing the malicious code?
Encryption is not magic pixie dust that makes code secure.
You have to start with what the actual threat is, and then design a system to protect against that threat. I don't see a threat that this proposal actually protects against. I understand the theoretical danger of running "untrusted code" on a power supply, but sprinkling encryption over that code is not an effective protection mechanism.
I did warn that I'm an opinionated nerd here. ☺
-
Hello Everyone,
I want to share with you my progress with BB3 project (see photos below)
I've been very keen to do this project from the start and I've been waiting for it to be finished impatiently.
So far I have built 3 modules (MCU, AUX-PS & BP3C )
The next step is to build the DCP405 module, and I am waiting for the DCM220 to be finished.
“Prasimix” has done a great job with this project and has been very helpful, keep it up!
Robert
[(http://i.imgur.com/xMBlWLQ.jpg) (https://imgur.com/xMBlWLQ)][/(http://i.imgur.com/imrlDE5.jpg) (https://imgur.com/imrlDE5)]
-
Great job! :-+
-
EEZ BB3 is now OSHWA-certified as open hardware. Its UID is HR000002 (https://certification.oshwa.org/hr000002.html).
(http://i.imgur.com/FI0KkIj.png) (https://imgur.com/FI0KkIj)
-
Hi all,
Just backed this and really hoping it goes ahead.
I am interested in building/selling a module which replicates one of my PDVS2 products, I.e. 0-10vdc, 10uV step change, 20bit DAC, LM399AH ref. Etc.
I think it would be fun albeit loaded with challenges.
Ian.
-
Hi Ian, that sounds fantastic! :-+
You can count on all our support of adding new module (e.g. firmware wise, etc.). Just for the record: it does not need to be open source as rest of the BB3.
-
Nerd here. Opinionated nerd with software security experience...
I'd like to point out that there are currently 129 backers, with less than two weeks remaining on the campaign. This does not make the BB3 a substantial attack target...
That's a very relevant point, thank you. "Threat modelling says don't bother, the crackers will come for your neighbour's IOT stuff first."
-
100% Funded. We're on!
-
Congratulations prasimix!
-
Yes! It’s happening! :-DMM
Great start to 2020
All the best for the rest of the journey to get them ready and shipped out.
-
Oh, so looking forward to this.......
-
Congratulations prasimix! The funding pace seems to have picked up a bit towards the end, so maybe there's a chance of hitting the $100k stretch goal. :)
-
Congratulations prasimix! The funding pace seems to have picked up a bit towards the end, so maybe there's a chance of hitting the $100k stretch goal. :)
I guess it changes mindset post 100% from "do I want to maybe back this?" (possible 60-70% stall) vs. "I want to order this with a slightly shipping delay" :)
I really hope this sticks around for many years and continues to evolve at close to it's current pace w.r.t. talk of extra modules / 8x way chassis? etc.
-
The first video of BB3 as an automated NPN curve tracer:
https://twitter.com/envox/status/1212716344724066305
-
Would it be possible to run a similar demo in the 50mA range for the results, would then really show off its resolution,
-
... BB3 as an automated NPN curve tracer ...
Nice! Should be applicable to other devices too (MOSFETs etc.). Seeing a video demo also shows the value of the nice big touch screen :).
At risk of being a little picky - I know you’re busy! - it would be really cool if the last couple of seconds of the video were a screen grab (or close up photo of whatever) of the curves to show what you got.
And now on another subject; it looks like you might make your stretch goal. If you do move the Ethernet and USB ports, would that free up a little room on the front of the master control board? If so, I think moving the boot mode switch from the aux power board to the master control board would be nice; those traces went quite close to the main power switch and were making me nervous.
-
The curve tracer software is wonderful! Updating the display on the fly - even better!
-
Nice! Should be applicable to other devices too (MOSFETs etc.). Seeing a video demo also shows the value of the nice big touch screen :).
At risk of being a little picky - I know you’re busy! - it would be really cool if the last couple of seconds of the video were a screen grab (or close up photo of whatever) of the curves to show what you got.
Yes, it is applicable, check new video: https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2856622/#msg2856622 (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2856622/#msg2856622)
And now on another subject; it looks like you might make your stretch goal. If you do move the Ethernet and USB ports, would that free up a little room on the front of the master control board? If so, I think moving the boot mode switch from the aux power board to the master control board would be nice; those traces went quite close to the main power switch and were making me nervous.
Thanks for suggestion, I'll definitely take that into account (added in GitHub as #62 (https://github.com/eez-open/modular-psu/issues/62)) if we're going to implement changes on front panel as required for stretch goal.
-
The curve tracer functionality looks awesome and could potentially replace the PC connected unit I currently have. Is there any reason why the BB3 couldn't support P-channel transistor tracing in the future, or negative voltages (even if you just swap the polarity manually on the breadboard)?
-
No, there is no reason. For N-ch/NPN we are using "common ground" coupling. For P-ch/PNP you cannot use it, but Ch1 and Ch2 Vout+ has to be connected with external wire. We'll include P-ch/PNP version soon.
-
No, there is no reason. For N-ch/NPN we are using "common ground" coupling. For P-ch/PNP you cannot use it, but Ch1 and Ch2 Vout+ has to be connected with external wire. We'll include P-ch/PNP version soon.
Hmmm. I wonder how easy it is to display a connection diagram on screen as you set up the connections for the DUT. This may be useful as we head to new modules - especially if they interact with each other.
-
That's a valid idea. Displaying a picture with wiring details is not a problem at all. I'll add that to Martin's todo list :-/O
-
Wohoo! $100k! Congratulations.
So where does this leave the USB / Ethernet? :-/O
USB: Front + Rear?
Ethernet: Rear only?
-
Follow this link please: https://twitter.com/envox/status/1214314436359532544 ;)
-
Follow this link please: https://twitter.com/envox/status/1214314436359532544 ;)
I don't have Twitter so can't vote.
My vote is:
If it's USB Host / mass storage [USB on front, Ethernet on rear]
If it's USB Device to plug into a PC [Both USB and Ethernet on rear]
-
...no Twittering here either. I second Daniel's vote:
If USB Host / mass storage -> USB on front, Ethernet on rear
If USB Device to plug into a PC -> Both USB and Ethernet on rear
Congratulations, Denis & Martin!
-
Ditto for me
(Note: just moving one port will reduce design risk, and I suggest that be the Ethernet port.)
-
Ditto for me.
-
No, there is no reason. For N-ch/NPN we are using "common ground" coupling. For P-ch/PNP you cannot use it, but Ch1 and Ch2 Vout+ has to be connected with external wire. We'll include P-ch/PNP version soon.
This is excellent, thanks prasimix. I've been using my curve tracer to match transistors for Vgs and transconductance, so the transfer curve script is very interesting to me. In my ideal world you'd be able to set the constant Vds and sweep range for Vgs either positive or negative, to allow for testing depletion-mode devices. Excited to see how the script capabilities continue to develop. There's lots of interesting matching automation that could be done with Python!
I was also curious to get your opinion on whether those of us who ordered the two channel 'full' kit should consider adding a DCM220 before the campaign ends tomorrow. Will this module continue to be available afterwards? I don't have a specific use in mind for it currently, but am trying to decide whether to get one now if it won't be available, or save the space for future modules.
Thanks again for all the time and effort you've put into the design and campaign!
-
I was also curious to get your opinion on whether those of us who ordered the two channel 'full' kit should consider adding a DCM220 before the campaign ends tomorrow. Will this module continue to be available afterwards?
Yes, it will be available afterwards.
-
My vote is:
If it's USB Host / mass storage [USB on front, Ethernet on rear]
If it's USB Device to plug into a PC [Both USB and Ethernet on rear]
I did vote on twitter for USB on front, Ethernet on rear, but this from @danielbriggs makes even more sense. I was assuming USB mass storage was a supported mode when I voted for front/back instead of back/back.
-
Who told you that host/device mode is not supported? Actually, we still need to do some job for host mode that will allows us to communicate with e.g. keyboard, keypad or USB foot pedal. The same is valid for mass storage. I'm not sure about possible performance of mass storage and is it possible to have acceptable performance without jeopardizing the rest of the system. Therefore if mass storage is the only reason why USB should be on the front panel, then I'd prefer to move USB to the rear, too.
-
Thanks Denis for the detailed reply; all sounds really promising.
What does the digital I/O on the front panel currently do?
Would it be easy enough to allow the units to trigger each others "outputs enable / disable" from the state of the digital IO?
If this is, then I'd almost certainly be up to backing a 2nd unit. [Not pressuring you, just would be personally useful to me if I can turn on 6-8 outputs at once].
All the best,
Dan
Hi Dan, just to let you know that I find some time today to test this. Wiring is quite simple:
(http://i.imgur.com/NQW41bb.jpg) (https://imgur.com/NQW41bb)
On "master" chassis (upper one) Dout2 has to be defined like this:
(http://i.imgur.com/KQMO1DK.jpg) (https://imgur.com/KQMO1DK)
... and on "slave" chassis Din1 is defined like this:
(http://i.imgur.com/XchnTJs.jpg) (https://imgur.com/XchnTJs)
I also defined on "master" User SW as Inhibit that gives me control of all power outputs at both chassis:
(http://i.imgur.com/F44ONoU.jpg) (https://imgur.com/F44ONoU)
-
This is excellent! Many thanks for taking the time to demonstrate that small (but important to me) feature.
Roll on March (or whenever they ship) :-DMM
-
I've found time to design two new peripheral modules so far. They are very simple: one features 6 power relays (name: PREL6) and another 4 x 6 switch matrix made with signal relays (name: SMX46). Both modules have two thing in common: connector on their front panel (see below) and entry-level on-board MCU.
(http://i.imgur.com/k4aGpA4.jpg) (https://imgur.com/k4aGpA4)
The connector is 16-pin dual row 3.81 mm and two of them is possible to mount on the module's front panel. Sockets with various number of pins (8-pin push-in type is shown on the picture) can be used and they could be of push-in type, with screws, etc. Few manufactures has it in offering like WE and Weidmueller and cheaper versions are available on Alibaba, etc.
Functionality of both modules are trivial and control could be easily accomplished with I/O expander parts such as MCP23S08 or MCP23S17. But I found that entry-level STM32F030 MCU is in the same price range and offers more freedom in programming and has extra features (e.g. PWM generation). Since on-board firmware downloading procedure completely automated on the BB3 (i.e. few clicks and master MCU will do it for you) there is no reason what not use MCU instead of I/O expander.
PREL6
Quick facts
- 4 x SPDT relays, max. 8 A / 230 Vac
- 2 x SPST relays, max. 8 A / 230 Vac
- On-board +3.3 V LDO
- STM32F030 MCU
- Firmware download via UART
- Optional SWD for debugging
- I2C EEPROM for storing board specific parameters
- Dimensions: 146 x 95 mm, 2-layer PCB
(http://i.imgur.com/Uso3nQD.png) (https://imgur.com/Uso3nQD)
Source files on the github: https://github.com/eez-open/dib-prel6 (https://github.com/eez-open/dib-prel6)
Schematics are in the attachment.
SMX46
Quick facts
- 24 x SPDT relays, max. 2 A
- 1 x power relay, max. 8 A / 230 Vac
- 2 x DAC output 0 - 10 V
- On-board +3.3 V LDO
- STM32F030 MCU
- Firmware download via UART
- Optional SWD for debugging
- I2C EEPROM for storing board specific parameters
- Dimensions: 146 x 95 mm, 2-layer PCB
(http://i.imgur.com/VKKxS7F.png) (https://imgur.com/VKKxS7F)
Source files on the github: https://github.com/eez-open/dib-smx46 (https://github.com/eez-open/dib-smx46)
Schematics are in the attachment.
The SMX46 module also includes one power relay and two analog outputs derived from PWM generated by the on-board MCU.
Both modules will be programmed from local TFT touchscreen display or remotely with new set of SCPI commands that we have to add. They will be also accessible via MQTT.
Your comments are welcome as usual.
-
Relays for everyone! :)
A relay mux is a classic part, so I’m sure some people will want one.
- great to see its differential
- maybe there should be provision for marshalling rails inside the BB3 case?
On the power relays:
- good to see MOVs
- remember to note that DC switching ratings are much lower than AC
- I expect someone will try to switch mains with it, so you’ll need all the clearance you can get between the power and relay drive lines. (I think IEC 60950 likes 3.5mm creepage, but I’m not sure)
- to make some room in the congested zone, maybe you could move the drive transistors and catch diodes away from the relays?
On relay cards in general:
- it would be nice if the microcontroller kept a cycle count for each relay
- you can never cover all use cases, so having an easy open-source design template could be very useful for someone who needs to roll their own custom card
-
Many thanks for suggestions. Catch diodes are already away 4.5 mm from the relay power inputs, and I moved Q4 and Q5 away to increase clearance over 3.5 mm. New revision is committed on the GitHub.
Cycle count for each relay will be stored on the EEPROM locally together with total and last working hours.
-
The next module that I'd like to make is mixed I/O. Selected front panel connectors (2 x 16 pins) allow e.g. 8 digital inputs and outputs, and 4 analog inputs and 2 or 4 outputs. Question is what voltage (and current?) levels to offer? So far I've found that other manufactures usually offer industrial/PLC levels:
- Digital inputs: Voltage: +24 V for hi level (usually with wide margin and hysteresis), Current: 0-20 or 4-20 mA
- Digital outputs: 500 mA output hi-side or low-side with various protections, usually resistant to over +40 V
- Analog inputs: 0-10 or +/-10 V, 0-20 or 4-20 mA
- Analog outputs: same as above.
I/Os should be isolated from MCU. I found that e.g. Silabs Si838x (https://www.silabs.com/isolation/industrial-io/si838x-digital-isolators) could be a good candidate for 8 isolated digital inputs. For isolated digital outputs I'd like to use ST ISO8200B (https://www.st.com/content/st_com/en/products/power-management/intelligent-power-switches/high-side-switches/iso8200b.html) or Infineon ISO1H811G (https://www.infineon.com/cms/en/product/power/isolated-industrial-interface/iso1h811g/).
I'm still searching for suitable analog I/O solution and currently looking for DAC. I believe that, for the start, 12-bit will be enough (I'd like to deploy multichannel 16/24-bit on the other module, simultaneous sampling, etc. but that is another story). The question is what to do with analog outputs, especially if we want to support all the levels mentioned above. I've found one possibly interesting solution from Maxim, MAX155000 (https://www.maximintegrated.com/en/products/interface/current-loop-products-4-20ma/MAX15500.html) that is advertised as "output conditioner" and provides a programmable current up to ±24mA, or a voltage up to ±12V proportional to a control voltage signal. The control voltage is supplied by an external DAC (2.5 or 4.096 V FS). The MAX155000 solution cannot be cheap because of its price and that it requires DAC (and Vref). Perhaps more flexible solution and little bit cheaper could be using four of single channel DAC7760 (https://www.ti.com/product/DAC7760) or one quad channel DAC7716 (https://www.ti.com/product/DAC7716) with some extra circuits.
Your input is welcome.
-
Denis,
Just thinking ahead: how is the BB3 suited to quickly reconfiguring modules?
i.e. obviously not hot-swap, but made me think with all new module designs on the horizon, if I have a full chassis, say I need to pull out the dual output module and pop in a DIO card for a project for a day or two... it's not a big job to reconfigure / hassle to swap a module software-wise?
Thanks,
Dan
-
Firmware already automatically recognize all supported modules in any combination and locations. For example you can swap DCP405 and DCM220 between slot #2 and #3 and that change will be reflected on the display and firmware will even try to match modules params saved in user profile despite the fact that channel type are changed. Additionally all module specific params such as activity counters and calibration cannot be compromised with such change since that params are stored on their on-board EEPROMs.
The arrival of new modules raises the question of BB3 capacity. I've already mentioned that one of possibility is to make an chassis with same footprint (to be "stackable") as BB3 but without display. Such chassis should host up to 7 modules that don't require AC/DC converter as power modules. Inter-chassis communication for start could be over Ethernet where BB3 (with display) can detect other chassis and become their master. Such chassis will be accessible remotely over Ethernet (SCPI/Telnet and MQTT).
-
Thanks Denis,
That's really promising, and long term would love to extend my involvement within this ecosystem, by buying new modules to suit projects to hand + hopefully developing my own modules for specific tasks if time allows.
I think for the next few months though, using the 2x I've bought as fully loaded PSU's would be tremendous. But good to know the roadmap of the system as it develops + looks like it's got a great future with enough support behind it.
All the best,
Dan
-
This is looking great; if it was good enough for HP to have stackable cases for the HP3497/98; it's good enough for me. Imagine - setting up a test condition, powering it up, characterising the results, recording and displaying them all from the one(2) box. Fantastic.
Looking forward to the simultaneous 16/24 bit sampling unit too. We may need the capability to go >48V? Is that where the electric car market is going?
-
The question is what to do with analog outputs, especially if we want to support all the levels mentioned above. I've found one possibly interesting solution from Maxim, MAX155000 (https://www.maximintegrated.com/en/products/interface/current-loop-products-4-20ma/MAX15500.html) that is advertised as "output conditioner" and provides a programmable current up to ±24mA, or a voltage up to ±12V proportional to a control voltage signal. The control voltage is supplied by an external DAC (2.5 or 4.096 V FS). The MAX155000 solution cannot be cheap because of its price and that it requires DAC (and Vref). Perhaps more flexible solution and little bit cheaper could be using four of single channel DAC7760 (https://www.ti.com/product/DAC7760) or one quad channel DAC7716 (https://www.ti.com/product/DAC7716) with some extra circuits.
Your input is welcome.
I really like using AD5752R (https://www.analog.com/en/products/ad5752r.html) (16-bit software programmable bi-polar with integrated reference) with success on some projects.
Also pin compatible with the 14+12-bit versions AD5732R / AD5722R if you need to save a little £ and don't need all the bits.
Also available without the built in reference, but the AD5752R is perfect for my uses + worth the extra cost.
-
Thanks for suggestion. The AD5722R looks nice except it's not cheap. I'll try in the first run to use DAC7563 (http://www.ti.com/product/DAC7563) instead for the first two analog outputs. It also has internal reference, but lacks bipolar output. That can be resolved with additional op-amp on the output. For another two analog outputs I'll use DAC7760 (http://www.ti.com/product/DAC7760). It offers both current and voltage outputs. The good thing about both devices is that they have a 16-bit counterparts if someone need higher resolution.
-
Looking forward to the simultaneous 16/24 bit sampling unit too. We may need the capability to go >48V? Is that where the electric car market is going?
Yes, I was thinking about up to 100 V on the input. Talking about electric cars, it seems that powertrain battery could go up to 800 V :-//
-
Yeah, electric vehicles are going up. I think a many run at 400V (ish), with higher voltages like 800v for higher performance.
I wouldn’t be surprised to see 1300V or even +-750V come in for heavier vehicles.
I would be nervous about making test gear for EV applications as these systems could have very high energy faults (remember DC arcs are hard to extinguish).
-
If EVs don't use higher voltages, the current gets insane. The Chevy Bolt has a 149 kW motor. I don't know the voltage but I suspect it is on the order of 400 volts so the current will be on the order of 370 Amps. That's a lot of current! They certainly wouldn't want to use something like 100V and 1500 Amps.
https://en.wikipedia.org/wiki/Chevrolet_Bolt
I have had mine for 3 years and I like it a lot.
-
It seems that every time I have to work on auto-electrics, the laws of physics get broken - because half the readings don't seem to make sense. :-DD
Re the upper limit, maybe another of your famous (and worthwhile polls). 48V would do me (which probably means 60).
-
If EVs don't use higher voltages, the current gets insane. The Chevy Bolt has a 149 kW motor. I don't know the voltage but I suspect it is on the order of 400 volts so the current will be on the order of 370 Amps. That's a lot of current! They certainly wouldn't want to use something like 100V and 1500 Amps.
[...]
I have had mine for 3 years and I like it a lot.
You might like this dissection of a Bolt battery pack by Weber State University's John D. Kelly:
https://www.youtube.com/watch?v=ssU2mjiNi_Q (https://www.youtube.com/watch?v=ssU2mjiNi_Q)
-
We made some real progress regarding fusion of BB3 and ULX3S. Goran from radiona.org (http://radiona.org/ulx3s/) (from ULX3S team) made a PCB (available on the GitHub (https://github.com/goran-mahovlic/LVDS_RGB_experimental)) where RGB output from BB3's STM32F7 MCU is serialized into LVDS from one side, and FPGA video output (LVDS) is deserialized into RGB output to drive directly TFT display. Therefore we can swap between "slow" content (GUI/HMI) and fast content that can be generated directly from FPGA (e.g. data logging, scope, etc.).
In this way we don't need to get rid from "legacy" code written for STM32 and have fast processing on board (Lattice ECP5 (https://www.latticesemi.com/Products/FPGAandCPLD/ECP5)).
Next step is to try to synchronize video outputs from STM32 with ECP5 that we can combine "slow" and "fast" (e.g. ScopeIO (https://github.com/hdl4fpga/hdl4fpga)) content on the same screen!
(http://i.imgur.com/V069otD.png) (https://imgur.com/V069otD)
(http://i.imgur.com/wZjqOtX.jpg) (https://imgur.com/wZjqOtX)
-
if the BB3 gets any smarter I'll have to move it to the server room. :clap:
-
I've finished another module for BB3 this time for mixed I/Os (MIO168). I'd like to thanks once again to @jbb for assistance and few great suggestions. My idea was to have module that could accept low-voltage (3.3/5 V) and industrial voltages/levels. Therefore digital inputs should withstand at least 24 V. Digital outputs are low-side and could drive load connected to up to 60 V. Analog inputs are bipolar and could be voltage (up to +/-10 V) or current (0-24 mA). Analog outputs are also bipolar (+/-10 V) and two channels supports both voltage and current outputs.
Instead of isolating inputs and outputs, a whole module is "floating" and power rails are isolated using 2 W off-the-shelf DC-DC converter. I'll test two different model from TRACO and Mean Well, both with and without LDOs for +/-12 V rails (+5 V and 3.3 V LDOs are mandatory).
Analog input in current mode is accomplished by applying burden resistor that comes with current limiter. Input mode is selected with analog switches DG468 (https://www.vishay.com/product?docid=74413) that can withstand over +/-12 V when powered with +/-15 V.
Selected MCU is probably overkill, maybe not, but can drive SDRAM if necessary, and I've already added place for optional micro SD Card just for testing (BB3 MCU module has micro SD Card).
Quick facts
- 2 x 16-pin dual row 3.81 mm I/O connectors
- 8 x protected digital inputs (3.3/5/24 V), 2 x fast/slow, 6 x slow
- 8 x digital outputs (4 x low-side, dual channel smart switch BTS3408G (https://www.infineon.com/cms/en/product/power/smart-low-side-high-side-switches/low-side-switches/hitfet-automotive-smart-low-side-switch/bts3408g/)) with multiple protections and FAULT detection, 550 mA per channel (current limit 1 A)
- 2 x PWM outputs, protected
- 4 x analog bipolar inputs with protection. Voltage or current selection per channel. 14-bit ADC, max. 500 KSPS (ADS8674 (http://www.ti.com/product/ADS8674)), replaceable with pin compatible 12- or 16-bit version. Switchable bias for NTC sensors on first two channels
- 2 x analog bipolar outputs (+/-5 V, +/-10 V, 0-5 V, 0-10 V). Voltage or current output with protection. 12-bit DAC (DAC7760 (http://www.ti.com/product/DAC7760)), replaceable with pin compatible 14- or 16-bit version
- 2 x analog bipolar outputs +/-10 V (DAC7563 (http://www.ti.com/product/DAC7563))
- On-board isolated +/-15 V (2W) power supply with +/-12 V, +5 V and +3.3 V LDOs
- STM32F446 MCU
- Firmware download via SPI
- Optional SWD for debugging
- Optional Micro SD card
- I2C EEPROM for storing board specific parameters
- Dimensions: 146 x 95 mm, 2-layer PCB
Source files on the github: https://github.com/eez-open/dib-mio168 (https://github.com/eez-open/dib-mio168)
Schematics are in the attachment.
I've used 4-layer PCB this time. Your comments and suggestions are welcome.
(http://i.imgur.com/HuL3hzB.png) (https://imgur.com/HuL3hzB)
-
Brilliant work.
One very minor point:
Is there a reason for having 2x different types of analog out functionality?
It would be (albeit slightly selfish for what I want to do) great if all analog outputs could be of the first type (DAC7760) to give a total of 4x 0-5V analog outs. Or is there good reasoning to have 2x of each type?
Keep up the good work.
Dan
-
I see pads are not just plain areas of copper, they look to be segmented. What advantage does this give and how is this done? With solder mask?
-
Is there a reason for having 2x different types of analog out functionality?
It would be (albeit slightly selfish for what I want to do) great if all analog outputs could be of the first type (DAC7760) to give a total of 4x 0-5V analog outs. Or is there good reasoning to have 2x of each type?
I've put two types for testing purposes, and DAC7563 is selected because of its price. Originally comes with unipolar voltage output it is still cheaper with added extra op-amps for Vref/2 and bipolar output. It shouldn't be a problem to put four DAC7760 (or even its 16-bit counterpart) if someone find a good "use case".
-
I see pads are not just plain areas of copper, they look to be segmented. What advantage does this give and how is this done? With solder mask?
I believe that started to happen to OSHpark previews when I made changes in corner "roundness" in Eagle (or something similar, I cannot remember), if you're talking about "artifacts" shown below, but that is not visible on the manufactured PCB.
(http://i.imgur.com/0EfYpNg.png) (https://imgur.com/0EfYpNg)
-
Thanks
Let’s hope people like it.
I’ve been wanting to have a play with Peltier coolers, and the combo of some analog IO with a programmable DC supply is very promising. Just the sort of thing that modular test gear should be good for.
I don’t have time to do a big review, but noticed a couple of things:
- there should probably be a high value high voltage resistor across the GND to PE capacitor (eg 1 Meg 1kV or similar series string). This is to discharge accumulated potential (eg from ESD strikes)
- the input protection components should be placed as close to the connectors as reasonably possible (it looks like there will be competition between the various pins
- some components are really close to the main connector and could be hard to repair
- the ground traces on input protection should be nice and wide to conduct high frequency ESD energy (or use ground plane)
- the protective earth connection seems to be a long way from the plugs. Is this for cable routing reasons?
- you’ve got the option for common mode chokes on the isolated +-15V supply. I don’t think using two common mode chokes like that will be very effective. A three-winding choke is probably better. Or place it on the power input side where there are only 2 lines.
- LDOs May get hot. You could consider a buck converter for the 3.3V if the STM22 draws lots of current
- you might want a little series resistance on the PWM outputs in case of short circuits
-
I don’t have time to do a big review, but noticed a couple of things:
- there should probably be a high value high voltage resistor across the GND to PE capacitor (eg 1 Meg 1kV or similar series string). This is to discharge accumulated potential (eg from ESD strikes)
Good point, I'll add 2 x 470K 1206 in parallel with C97 (4n7 1812).
- the input protection components should be placed as close to the connectors as reasonably possible (it looks like there will be competition between the various pins
- some components are really close to the main connector and could be hard to repair
Yes, I tried to place protection component close to the connectors, and without using both sides of the PCB. Therefore some compromise was needed, and I decided to place digital inputs after analog inputs and use bottom layer for traces to that section.
Protection components for remaining sections are close to the connectors and could be problematic to service them with hot air, but shouldn't be an issue in two soldering irons are used :).
- the ground traces on input protection should be nice and wide to conduct high frequency ESD energy (or use ground plane)
PCB is 4-layer and second layer is dedicated ground plane. Do you suggest additional ground plane on other layer?
- the protective earth connection seems to be a long way from the plugs. Is this for cable routing reasons?
Yes, all cables are cut to size with presumption that input connectors are on the far right side of the PCB.
- you’ve got the option for common mode chokes on the isolated +-15V supply. I don’t think using two common mode chokes like that will be very effective. A three-winding choke is probably better. Or place it on the power input side where there are only 2 lines.
I have used "off-the-shelf" tiny (0805) CM chokes, that was the easiest way but probably not so effective. I have to find out if small 3-winding choke exists.
- LDOs May get hot. You could consider a buck converter for the 3.3V if the STM22 draws lots of current
3.3V LDO shouldn't be a problem, ST power calculator estimates no more then 55 mA in worst case scenario. The 5V LDO is under more stress stepping down from 12 V, but still, that shouldn't be a problem even for SOT23-5 package (perhaps I should put more pads on its GND pin?).
- you might want a little series resistance on the PWM outputs in case of short circuits
Ok, how about 47R, or that is too little?
-
Sorry for delay; it's been a busy few days.
PCB is 4-layer and second layer is dedicated ground plane. Do you suggest additional ground plane on other layer?
Ah, the joys of 4 layer boards. A good ground plane should do a lot for you.
Suggest you try to get roughly equal areas of copper on each side of the PCB (i.e. top vs bottom, mid1 vs mid2) to reduce the risk of warping.
- you might want a little series resistance on the PWM outputs in case of short circuits
Ok, how about 47R, or that is too little?
Seems like a good first try. May need to test it a little with sample loads (e.g. 70 cm of coax or twisted pair). Given you're paralleling output buffers, maybe put 100R on each buffer output? This will also prevent large current flows if buffer delays don't match exactly.
-
I've wanted for a long time to have electrical/electronics calculators next to me on the benchtop when I'm working with electronics. For the same reason why I don't like USB (i.e. PC based) instruments like scope, logic analyzers, etc. I don't like online calculators to find out quickly right resistors value for certain opamp gain, output from voltage divider because I have to move back and forth from one table to another. Other possibility will be to place PC next to my D.U.T. but I don't want that only keyboard occupy a substantial area of already crowded benchtop. MicroPython (MP) scripting starts to changed that and first results are already here. Currently I don't have a time to shot a video about that but few screenshots could help you to get an idea.
First, the BB3 SD card file manager are changed to present files with thumbnails, then when you enter Scripts subfolder, first comment from .py file could be displayed as description, and finally we made a first step toward integration of MP scripting and GUI editing in EEZ Studio. The underlying mechanism is SCPI, and new set of commands was added that MP could interact with custom made pages (created in EEZ Studio).
So far, we have the following calculators available:
- Op-amp (non-inv, inv, differential and diff. simplified)
- Voltage divider
- R/L in parallel and C in series
You can be sure that we will not stop there and that the number of scripts will increase over time :)
(http://i.imgur.com/EAg5Ioz.png) (https://imgur.com/EAg5Ioz)
(http://i.imgur.com/0vrJHWB.png) (https://imgur.com/0vrJHWB)
-
... and yes, your suggestions are highly welcomed. Just to let you know what is already in the queue:
- RC snubber calculator (based on this (https://e2e.ti.com/blogs_/b/powerhouse/archive/2016/05/05/calculate-an-r-c-snubber-in-seven-steps) method)
- PWM/Square wave generator (within limits of Dout pins on the front panel)
- Ohm law calculator
-
This is an incredibly good idea, and another reason why I’m so glad I got onboard with this platform. :-+
-
With all the downtime of late I just read through this thread and have to say i'm very impressed. This is a very useful product that could find use on an advanced hobbyist desk to an Engineers test stand.
One thing I noticed is for people calling for modules a little outside of what one might find suitable for a power supply. I suspect what many want is a modernized approach to instruments like was seen in the Tektronix TM500/5000 series. In a way that is what I would like to see come to market. However a power supply with the capability of delivering this power level would never fit into such a platform. So I rather like the platform as is and especially like the use of MicroPython. Even better is that the right type of expansion boards are on the way!
Since everybody envisions a version #2 of a successful product here are some ideas that might be wroth considering for the mainframe:
- Consider a USB-PD port on the mainframe. You could instrument it or not, my primary interest is in all the devices that need power from these ports. However I can see how product designers could use an USB-PD port with full reporting of voltage and current usage.
- It would also be nice to have a 5VDC port on the main panel, banana plugs of course. Nothing fancy here at all, 1-2 amps with no adjust ability.
- Yes it is extra work but the Ethernet port needs to be on the back side of the box
- This one I'm not sure about as it is user interface related but you might consider integrating the user switch into the rotary knob.
- Directly related to the above You might want an M12 receptacle wired in parallel with the user push button. The would allow for remote pushbutton cords that you can easily buy for pushbutton operation. A switch like these: http://www.switchcraft.com/productsummary.aspx?Parent=1162, (http://www.switchcraft.com/productsummary.aspx?Parent=1162,) with an M12 connector on the other side. M12 connectors are heavily used in automation and industry and have the right qualities for something that gets puled on. Of course cheaper solutions can be used but probably not as convenient or widely used.
- Always make sure there is room for that second fan. Not ever installation will be on an air conditioned desktop.
That is about the only real suggestions I can offer up for a version 2 maintframe. IF there are ergonomic issues they will show up in time.
As for your I/O cards, looking at all the comments in one read tonight I think what you might need is a MicroPython based intelligent card. Possibly a card that sits on top of one of these new relay cards. The reason I say that is because some of the requests involve I/O and processing that probably wasn't thought about when the project started. That could be handled by a card with processing capability and some good ole RS232 comms. Yes RS232 is old but it is still widely used on process controller and the like. If you can imagine the card would buffer or process data in the middle so to speak. Say read data from an environmental chamber, process and format for the mainframes controller. Maybe make control decision on its own. In an ideal world the mainframe controller would do that itself but apparently you don't have the I/O or didn't expose it.
This has become long winded but it took a good portion of the night to read this thread anyways.
-
:clap:
I love it. Now if we can only have the ability for component substitution and test under programme control.
-
Thanks for your feedback, more comments below ...
Since everybody envisions a version #2 of a successful product here are some ideas that might be wroth considering for the mainframe:
Consider a USB-PD port on the mainframe. You could instrument it or not, my primary interest is in all the devices that need power from these ports. However I can see how product designers could use an USB-PD port with full reporting of voltage and current usage.
Ok, that sounds like a valid idea, its connector could take the place on the front panel where the Ethernet jack was previously (see below). Quite another thing is how to accomplish "power source/drain" section and where to place it.
It would also be nice to have a 5VDC port on the main panel, banana plugs of course. Nothing fancy here at all, 1-2 amps with no adjust ability.
Hm, that is not so simple, especially if you'd like a properly spaced banana plugs that take a lot of space. Other possible issue for some people could be isolated/floated output that offers currently available power modules (DCP405 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-dcp405-power-module.html) and DCM220 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-dcm220-dual-power-module.html)). A whole idea about DCM220 module is to provide two AUX outputs. Perhaps a too expensive approach :).
Yes it is extra work but the Ethernet port needs to be on the back side of the box
That is already done as part of crowdfunding campaign stretch goal (https://www.crowdsupply.com/envox/eez-bb3/updates/power-output-coupling-and-tracking-and-the-announcement-of-our-first-stretch-goal). New front and rear panel can be seen in the picture here (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg2968372/#msg2968372).
This one I'm not sure about as it is user interface related but you might consider integrating the user switch into the rotary knob.
Rotary knob/encoder already comes with switch that is used for "confirmation" mode. User switch provides quick access to few extra functions.
Directly related to the above You might want an M12 receptacle wired in parallel with the user push button. The would allow for remote pushbutton cords that you can easily buy for pushbutton operation. A switch like these: http://www.switchcraft.com/productsummary.aspx?Parent=1162, (http://www.switchcraft.com/productsummary.aspx?Parent=1162,) with an M12 connector on the other side. M12 connectors are heavily used in automation and industry and have the right qualities for something that gets puled on. Of course cheaper solutions can be used but probably not as convenient or widely used.
For remote control you have SCPI commands that can be send via USB or Ethernet. I'm fan of foot pedal because it leaves both hands free, but yes, why not also use mentioned push button cord. You can wire it to one of digital inputs on the front panel right now.
Always make sure there is room for that second fan. Not ever installation will be on an air conditioned desktop.
There is a room for second fan. The first prototype of rear panel had a second hole, but I gave up because only one was enough.
That is about the only real suggestions I can offer up for a version 2 maintframe. IF there are ergonomic issues they will show up in time.
As for your I/O cards, looking at all the comments in one read tonight I think what you might need is a MicroPython based intelligent card. Possibly a card that sits on top of one of these new relay cards. The reason I say that is because some of the requests involve I/O and processing that probably wasn't thought about when the project started. That could be handled by a card with processing capability and some good ole RS232 comms. Yes RS232 is old but it is still widely used on process controller and the like. If you can imagine the card would buffer or process data in the middle so to speak. Say read data from an environmental chamber, process and format for the mainframes controller. Maybe make control decision on its own. In an ideal world the mainframe controller would do that itself but apparently you don't have the I/O or didn't expose it.
This has become long winded but it took a good portion of the night to read this thread anyways.
Since MicroPython is already "on board" everything inserted into the "mainframe" will be MicroPython enabled. Announced MIO168 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2955988/#msg2955988) module is no exception. The same goes for the remote control of its resources using SCPI and MQTT.
Regarding "mainframe version 2": what will happen in the future will be directly connected and affected with destiny of "version 1" that I have first to deliver to crowdfunding campaign backers and try to establish sales channels that could generate enough revenue to keep us alive. Looks like this year will be decisive for us and many others.
-
:clap:
I love it. Now if we can only have the ability for component substitution and test under programme control.
Thanks Alan, could you be more specific about component substitution?
-
Sorry Denis I was being a smart arse. The BB3 is getting close to doing all of our jobs for us. :palm:
-
With respect to MircoPython is there a physical RS232 port available? I didn't notice if one existed and if MicroPython even supports such for the controller board. The idea of course is to be able to hook up to the most basic of process controller, most of which seem to do RS232 comms.
-
There is not RS232 port per se. But UART (TTL) port is exposed on the front panel (Din1 and Dout2 pins) and Virtual COM via USB is supported. It is important to understand that MicroPython is not implemented here as "core engine" but it's just one of the process under control of FreeRTOS. Therefore you are not able to access directly with MP any hardware resource, and cannot, let's say, compromise core processes. MP has on its disposal "high-level" functions that are accessible with SCPI commands. For example, you cannot go with MP to DAC on the Ch1 power module and set its value to 1.25 V to have 20 V on the power output, but you can use scpi("VOLT 20") to do the job. So, the MP is added as a scripting tool in the first place, that one can easily automate various tasks. Those who are interested can find existing examples on the following link: https://github.com/eez-open/modular-psu-firmware/tree/master/scripts
-
A short introduction to newly added power output ramp and delay feature.
https://www.youtube.com/watch?v=-PTuCwCbV40 (https://www.youtube.com/watch?v=-PTuCwCbV40)
-
The prototypes of the three new modules (PREL6 (https://github.com/eez-open/dib-prel6), SMX46 (https://github.com/eez-open/dib-smx46) and MIO168 (https://github.com/eez-open/dib-mio168)) have been assembled and ready for integration into BB3.
All modules will be presented and accessible via a local touchscreen and supported through SCPI and MQTT and managed using MicroPython scripts. The first practical scenario for their use will be to automate testing of assembled BB3 units once we have passed the required certification tests.
(http://i.imgur.com/UDEK6Vp.jpg) (https://imgur.com/UDEK6Vp)
(http://i.imgur.com/HmTI35V.jpg) (https://imgur.com/HmTI35V)
(http://i.imgur.com/F0idqLP.jpg) (https://imgur.com/F0idqLP)
-
Front panel view with new module:
(http://i.imgur.com/D5akIxH.jpg) (https://imgur.com/D5akIxH)
-
It’s so great to see these modules coming out. And using these parts to test your own products is really showing some confidence... and should find all kinds of little bugs.
I know what they’re all for, but that seems like a lot of analog switch ICs :-). I’m sure people will find the V / I / NTC input ranges helpful.
-
A short introduction to newly added power output ramp and delay feature.
https://www.youtube.com/watch?v=-PTuCwCbV40 (https://www.youtube.com/watch?v=-PTuCwCbV40)
First of all: Nice feature.
I played around with the trigger, list and ramp features in the simulator and am wondering: Why is ramp a separate function instead of a property of the list implementation?
I will try to explain using SCPI commands. If there would be an command like:
[SOURce[<n>]]:LIST:TYPE {ramptype}[, ...] where ramptype = 0 mean step, 1 = linear ramp, 2 = exponential ramp, ... = use imagination...
This would make:
-[SOURce[<n>]]:CURRent:MODE STEP, CURRent:TRIGgered and CURRent:RAMP:DURation {<duration>} (and voltage equivalents) obsolete
- programmability more flexible because a list can generate ramps arbitrary up/down steps, etc.
- UI could stil have a menu to program a STEP in a simple way: This would just create a LIST with the right properties. The user can even edit the list afterwards to add steps (in that case going back to STEP menu would clear the list after a warning/conformation)
- The list edit menu would also need a type selection (icon?) for voltage and current. I think this would fit.
Makes any sense?
-
Yes, it makes sense what you said. What we have now may have happened to others as things gradually added. I tried to add a similar set of commands that can be found with e.g. Keysight or R&S. What is count on the first place is user experience, and that is of course a question of taste, habit and experience. For advanced user it will be more interesting to have everything on single place as you suggested. For beginners, setting up just a turn-on ramp&delay might be sufficient.
What we are missing is more flexible way for adding ramps (triangle) in program list, the same stands for e.g. sine wave generation. For that I'd like to add [SOURce[<n>]]:ARB subsystem, again to be more "compatible" with big guys. Perhaps [SOURce[<n>]]:LIST:TYPE is also implemented by others, if you have any reference please let me know.
-
I didn't look to the big guys, just made it up. ;D
I did some digging in manuals: Keysight doesn't have a property like this in there list function in the models I looked up. The R&S NGP800 has an 'interpolate' option in there implementation of a list which they call ARB. It's not exactly defined what interpolation it does, but looks like lineair interpolation, which I called lineair ramp before. On there product page they have a screenshot of it (under Arbitrary Function): https://www.rohde-schwarz.com/nl/product/ngp800-productstartpage_63493-670592.html (https://www.rohde-schwarz.com/nl/product/ngp800-productstartpage_63493-670592.html)
The word Interpolate/Interpolation is a much more specific description of the functionality compared to the TYPE I made up.
The R&S SCPI implementation is not so nice (to my taste), because you quickly get into some kind of comma-counting-hell >:D and it doesn't allow for adding options/features later on in a backwards compatible way:
ARB:BLOC:DATA 1,1,1,1,0,2,2,2,1,1,3,3,1,0 (its a repeat of volt, current,time,interpolate)
BB3 equivalent:
LIST:VOLT 1,2,3
LIST:CUR 1,2,3
LIST:DWEL 1,1,1
LIST:INTerpolate 0,1,0 (new, instead of TYPE, 0= step, 1= interpolate)
Both sets of commands do the same:
- 1V,1A for 1 sec as a step
- rising from 1V,1A to 2V,2A in 1 sec (this is the function we're talking about)
- 3V,3A for 1 sec as a step
I agree that more complex ways of interpolation (e.g. exponential) might be better handled with the ARB subsystem. Just adding the interpolation makes the list function very powerful (in my opinion).
-
That method while possibly needing a little polish would leave room for odd ramps, e.g. a sine wave could be done by adding type classes for the 3 sine segments, step gets you square like waves, interpolate gets you ramps, and other modes gets you sine and other,
Sine I see as being 3 main options, either crest / peak with the slow start and then fast change,
fast change to slow crest / peak
or from crest to peak or vice versa as a half sine wave.
If you wanted to you might then later make use of that chunk of code to generate some of the simple shapes via UI.
This way a sine wave would just be an arb table of the min / max voltage and the smooth type with the frequency being the inverse of the interpolation time.
Edit: and things like simulating a rectifier output would just be a fast start segment + a ramp down in a cycle.
Edit2: while probably not the easiest thing, allowing things like % as an input for the values would make things a bit more powerful, so e.g. adjusting the maximum amplitude, the min being set at 60% then tracks along at 60% of that start value, or vice versa if the end was a % and the start a fixed value. this would be more for UI than SCPI, but I'm dreaming.
Edit3: or relative values, e.g. *-2V for 2V less than the start value, probably again for UI.
-
@Jan28, @Rerouter thanks for additional comments and suggestions. I have opened a new ticket (#22 (https://github.com/eez-open/modular-psu-firmware/issues/22)) in which I have added your suggestions that can be taken into account in the new firmware revision. I'll keep you posted on the progress.
-
EEZ BB3 User manual on English and German is now available online: https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/1-introduction.html (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/1-introduction.html)
-
Looks nice and clear. Can't wait to actually assemble mine.
After Figure 26 (insert SD card) you might want to add an instruction to turn the device off and remove the power cord before continuing with the power modules. Just to be sure.
-
Good point! I'll add that.
-
Hi,
I love the concepts of your open source power supply! Since my lab supply blew up today and I need one I am curious if you have any idea how big the backlog is. Or in other words: when would I get one if I order now ;D
Second question: I'm working with royer oscillators and other inverter topologies. My last supply didn't like that very much (not a high end one, but still) and I've heard this could cause problems with other, better supplies. Do you know if your supply is robust enough? Can it handle spikes of HF ripple on the output?
Thank you (for all of your work and for reading my questions ;) )
Max
-
Hi,
I love the concepts of your open source power supply! Since my lab supply blew up today and I need one I am curious if you have any idea how big the backlog is. Or in other words: when would I get one if I order now ;D
Second question: I'm working with royer oscillators and other inverter topologies. My last supply didn't like that very much (not a high end one, but still) and I've heard this could cause problems with other, better supplies. Do you know if your supply is robust enough? Can it handle spikes of HF ripple on the output?
Thank you (for all of your work and for reading my questions ;) )
Max
Hi Max, we're going to ship 50+ more units to CS/Mouser together with campaign fulfillment. Therefore if you order it now, I don't see a reason not to receive it in the same time as campaign backers.
Powering mentioned kind of devices could be a problem and is not easy to cover different scenarios when connected load/device works under different input voltage, switching frequency, has connected different load to its output, etc. I have an oscillator that is used to generate 10 kV+ and producing plasma beam/arc. It is so nasty that once it was almost completely destroyed my previous mobile phone that was more then a meter away. When powered from H24005 from my previous project it has a power to wipe off all content on the TFT display and occasionally even reset a whole unit. I tried the same scenario many months with BB3 and didn't seen similar effect (ok, the TFT display and MCU is different). I can try it once again, but that is no warranty that your or similar device do not generate problem to BB3.
-
I saw this from Kerry Wong:
http://www.kerrywong.com/2020/04/12/non-destructive-testing-of-fuses/ (http://www.kerrywong.com/2020/04/12/non-destructive-testing-of-fuses/)
Seemed like the kind of thing that the python scripts would be useful for. ☺
-
Does the DCM220 allow for using shrouded 4mm banana plugs?
-
...I'm working with royer oscillators and other inverter topologies. My last supply didn't like that very much ... Do you know if your supply is robust enough?
I guess this depends on whether it's RF content (MHz+) getting in and messing things up or big swings in power flow due to converter ripple (kHz - MHz) messing up the regulation.
If it's the former, you could try clip on ferrite EMI filters.
If it's the latter, I've achieved some good results in the past with a crude method:
- Use internal voltage sense, not 4 wire external sense
- Put a shunt resistor directly across the bench supply output, drawing 1% to 5% of power supply current rating. This will get the output stage, drivers etc. conducting. Unfortunately power supply current reading will now have an offset. (If you let the resistor warm up to constant temperature the offset should be pretty stable, at least.)
- Put a series resistor between the bench supply and load. I've used enough in the past to drop 1% to 5% of the supply voltage under expected load. Unfortunately power supply voltage reading will now be wrong, and the offset will depend on load current.
-
Does the DCM220 allow for using shrouded 4mm banana plugs?
No, it does not.
-
Someone (Cal Tech?) makes some converters which have a shrouded banana jack on one end and a standard banana plug on the other. There’s a little grub screw inside so that you can lock the banana plug into place.
Ooh, not what you’re looking for but Pomona 2894 (banana plug to binding post) could be handy.
-
I'm thinking about https://spot.staubli.com/fileadmin/spot/24.0163_en.pdf (https://spot.staubli.com/fileadmin/spot/24.0163_en.pdf) for the DCM220. They're not very expensive about 2 euro's a piece.
-
I'm thinking about https://spot.staubli.com/fileadmin/spot/24.0163_en.pdf (https://spot.staubli.com/fileadmin/spot/24.0163_en.pdf) for the DCM220. They're not very expensive about 2 euro's a piece.
That's an interesting solution (also good for other instruments I have here).
@Denis, is there any scope for the DCM220 to accept the same terminals as on the other modules that accept shrouded 4mm's? (Even if I drill out the panel slightly)
Have you got the part numbers for both connectors on either module to hand?
-
Hm, I didn't pay too much attention to the DCM220 because I saw it as an auxiliary power source from the beginning. To reduce costs, I also chose cheaper terminals. That turns out to not be the wisest decision :)
At the moment, I can only promise that in the next version, the DCM module will get the same terminals as the DCP module.
Part numbers can be found in BOMs: here (https://github.com/eez-open/modular-psu/tree/master/dcm220/BOM) and here (https://github.com/eez-open/modular-psu/tree/master/dcp405/BOM).
-
Ohhhhhh, so looking forward to getting my BB3.......I've even started clearing an area on the workbench for it's permanent stay........not to mention developing my own modules for it.
Roll on delivery day.
Ian.
-
Hello prasimix,
I'm CrowdSupply backer of EEZ-BB3 and it seems there is no any news since about 1 month, I hope all is fine on your side.
Do you have some update about the "EEZ Bench Box 3" ?
Best Regards,
Benjamin
-
Hi Benjamin,
The updates are over on this thread: https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg3063776/#msg3063776 (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg3063776/#msg3063776)
-
Sorry hydrabus, time simply passes and the things promised to me do not happen. In short, I have everything except the DCP405 module for which I don't know what the status is (not to go into details now). I believe this will be known through the next week.
-
Another achievement on BB3 + ULX3S integration track (previously mentioned in post #259 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg2945124/#msg2945124)): images from two sources can be combined with overlaying and displays on the same touchscreen. On one side we have content generated from STM32 running BB3 firmware, and from other side is ScopeIO on ECP5 FPGA:
(http://i.imgur.com/jGigfg2.jpg) (https://imgur.com/jGigfg2)
(http://i.imgur.com/WW7E3bD.jpg) (https://imgur.com/WW7E3bD)
(http://i.imgur.com/1rnhn48.jpg) (https://imgur.com/1rnhn48)
In the next step, we will try to synchronize a higher resolution source (800x480 or 1024x600) and provide the combined image on the HDMI output (for presentation on an external monitor or projector).
-
... and BB3 screen content on HDMI monitor! Now you can imagine to have e.g. control menus on the small touchscreen and live data (e.g. data logger, etc.) on the big screen: monitor or projector for presentation or for classroom work, etc.
(http://i.imgur.com/piCoGJ0.jpg) (https://imgur.com/piCoGJ0)
-
Wow! :-+ :-DMM
This project just keeps on developing!
-
... and BB3 screen content on HDMI monitor! Now you can imagine to have e.g. control menus on the small touchscreen and live data (e.g. data logger, etc.) on the big screen: monitor or projector for presentation or for classroom work, etc.
(http://i.imgur.com/piCoGJ0.jpg) (https://imgur.com/piCoGJ0)
Or for someone whose eyes are not so good! :phew:
-
Or if you like higher resolution (1024x576x60) with fixed frame buffer
(https://i.imgur.com/1ogm2ov.png)
-
I spent some time to check what is available in STM32H7 family which offers both single and dual core MCUs. It seems that migration to it sounds like no brainier since it gives more speed for less money. For example, STM32F769IIT6 costs € 11.08 on Mouser (qty. of 100), while STM32H743IIT6 costs € 9.58 and offers 480 MHz for system clock, and 1 MB of RAM (while F7 offers 216 MHz and 512 KB).
However, the question remains, can one easily switch from F7 to H7, i.e. are they pin compatible when selecting package with the same pin count that is LQFP-176 in our case. Migration is unfortunately not straightforward, but it is not impossible either. I was able to put all the necessary functionality on the H7 device, I even managed to improve the following things:
- SDRAM address bus is increased to 13-bit, that allows us to connect up to 32 MB
- SD card bus is expanded from 1-bit to 4-bit (I wonder how much this could speed up access to the SD card!)
- Touchscreen controller got a dedicated I2C bus
Something that may be missing is USB 2.0 which unfortunately cannot be realized without external PHY.
Of course it all fits together on a PCB of identical dimensions as the existing F7 MCU module. The only new thing I had to add was a 25 MHz external oscillator (XO1) and a 1:2 clock driver (IC5) because there were no free pins on the MCU to define the clock output for Ethernet PHY.
(http://i.imgur.com/QtKtwxe.png) (https://imgur.com/QtKtwxe)
(http://i.imgur.com/8rnH10E.png) (https://imgur.com/8rnH10E)
-
Don't shoot the messenger but. Why don't you upgrade to LQFP 208... This would probably mean that you can do USB 2.0. and also add QSPI flash if there will be need to have memory mapped resources (fonts, images, etc.)
The CubeMX should do that upgrade pretty seamlessly.
Also there is(was) a mess with H series. Some registers were remapped and some frequency changes and no part number change was made |O so you need to be careful.
-
Yes, I believe that migration to LQFP-208 is also possible, and could be more challenging if we want to preserve same PCB dimensions, but even that is not so critical since there is a plenty of room to grow inside enclosure. Only width has to be preserved that we don't need to change front panel holes.
Thanks for warning regarding H7 mess. If you have more detail or link to discussion about it let us know, particularly if proposed STM32H743IIT6 is mentioned.
-
A simple example of how to use Node-RED to communicate with BB3:
https://www.youtube.com/watch?v=0xQ6Xuq53fA (https://www.youtube.com/watch?v=0xQ6Xuq53fA)
-
I have been following this project, and I am also preparing to DIY an EEZ BB3. I am in China and I can’t see the pictures and videos when browsing the posts on the EEV BLOG website, which makes me very frustrated. In addition, my English is not good, so I can only read the posts through machine translation, and many of the content is not very understanding.
The work I have done recently is to analyze the schematic diagrams of each module, organize the BOM, and replace the components that are not easy to buy in China or the more expensive components with those that are relatively easy to buy and cheaper.(I also want to buy a kit directly to support this project, but the exchange rate of USD to RMB is too high, which is a big expense for me. So, I decided to DIY an EEZ BB3 by myself, but it did not help this project. I am very sorry.) The EEZ BB3 package is designed very well! I am slowly studying its essence. After finishing the BOM, I will conduct trial production of the first machine. Recently, I have seen the appearance of DCM224 module, and I am looking forward to its hardware system release.
On the https://www.envox.hr/eez/eez-bench-box-3/introduction.html (https://www.envox.hr/eez/eez-bench-box-3/introduction.html) website I saw a detailed explanation of the schematic diagrams of each module of EEZ BB3. This part is great! It is very worthy of my study, but it seems that the schematic diagram explained is an old version, which is different from the latest version of the hardware, which is a pity. I don’t know if there is the latest version of the document explaining the hardware principle? In this way, it is much easier to understand the design principle corresponding to the latest version of the schematic diagram and this document (I have poor analog circuit knowledge :palm:).
In the choice of MCU, I think it is indeed inferior to using STM32H743IIT6. Now this chip has a low price and strong performance. The price of this chip used in our recent project is much cheaper than STM32F769IIT6, and it is better to buy. The version of the chip we use is older, the main frequency can run up to 400MHz, the new version of the chip can run up to 480MHz.
-
Thanks for your inputs...
Recently, I have seen the appearance of DCM224 module, and I am looking forward to its hardware system release.
That's right, the DCM224 is a variant of DCM220 derived from modifications made to make it easier to pass EMI testing for CE. The main difference is the transition from a 2-layer to a 4-layer PCB and the reorganization of the power loop. It was also added that the MCU controls the switching frequency of two LT3763 controllers with counterphase signals. The option of frequency dithering has also been added, which can further enhance the EMI image.
For easier differentiation, I changed the output voltages and currents so that it goes up to 24 V and about 5 A (not calibrated), so the new name: DCM224. Finally, the option of PWM dimming power output has been added.
On the https://www.envox.hr/eez/eez-bench-box-3/introduction.html (https://www.envox.hr/eez/eez-bench-box-3/introduction.html) website I saw a detailed explanation of the schematic diagrams of each module of EEZ BB3. This part is great! It is very worthy of my study, but it seems that the schematic diagram explained is an old version, which is different from the latest version of the hardware, which is a pity. I don’t know if there is the latest version of the document explaining the hardware principle? In this way, it is much easier to understand the design principle corresponding to the latest version of the schematic diagram and this document (I have a poor analog circuit level :palm:).
Yes, and I have no excuses for that. I have set relatively high standards and now I need to maintain them. I need to update the project pages as soon as possible as it will help other people who backed the "EEC BB3 Enclosure & Bare Boards" kit to more easily follow the design (they are welcome here and in the newly opened topic (https://www.eevblog.com/forum/projects/building-log-for-eez-bb3-enclosure-bare-boards/)). I am currently finishing updating the user manuals (English and German) and I believe that I will soon be able to update the project pages as well.
In the choice of MCU, I think it is indeed inferior to using STM32H743IIT6. Now this chip has a low price and strong performance. The price of this chip used in our recent project is much cheaper than STM32F769IIT6, and it is better to buy. The version of the chip we use is older, the main frequency can run up to 400MHz, the new version of the chip can run up to 480MHz.
I'm aware of that, that's why I made the new MCU module version (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg3117674/#msg3117674) with H743, but the layout of the new PCB is just the beginning: we need to assemble the module and then the most important thing follows: adapt the firmware to work with two cores and work reliably. I think the new module will have to wait since the F769 does its job very well, albeit for a slightly higher price.
Priority will be given to new peripheral modules: we need to finish the three we started (MIO168, SMX46, PREL6), but also start working on some new ones. I am thinking primarily of the 2Q/4Q power module and I would love to see progress on high precision DMM, something based on a @Kleinstein design (https://www.eevblog.com/forum/metrology/diy-high-resolution-multi-slope-converter/) or @jaromir design (https://www.eevblog.com/forum/metrology/diy-6-digit-handheld-volohmmeter/).
-
Thank you for replying to me so early! Thank you very much for answering all my questions! It is the high standards of your project that attracted me, and your spirit of dedicated research is very worthy of our study! Many R&D engineers around me are too impetuous, and they are not careful in researching technology. This disappoints me very much, and I really want to change this situation. We have also established an interest group to study and study the EEZ BB3 project, hoping to learn more knowledge from it and develop good research and development habits. We will continue to pay attention to the EEZ BB3 project, and once again thank the EEZ BB3 team for their efforts!
-
That's right, the DCM224 is a variant of DCM220 derived from modifications made to make it easier to pass EMI testing for CE. The main difference is the transition from a 2-layer to a 4-layer PCB and the reorganization of the power loop. It was also added that the MCU controls the switching frequency of two LT3763 controllers with counterphase signals. The option of frequency dithering has also been added, which can further enhance the EMI image.
For easier differentiation, I changed the output voltages and currents so that it goes up to 24 V and about 5 A (not calibrated), so the new name: DCM224. Finally, the option of PWM dimming power output has been added.
For a more complex power system and EMI testing is required, it is difficult to design a two-layer board, the ground plane is not continuous, the ground impedance is large, and the wiring is more difficult. Four-layer board is indeed a better choice, and the cost will not increase too much.
The 2Q/4Q power module is absolutely awesome! Looking forward to it!
-
Question: can dcp405 generate waveforms? If so, what's the maximum frequency? I need a 100Hz signal (either sine or triangle). Of course it will be uni-polar, but that can be fixed with a DC-blocking capacitor.
-
The easiest way to perform that is to apply external signal generator on Rprog inputs on the front panel and activate Rprog option (see Section 11.5.3 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/11-special-channel-functions.html#bb3_man_ch_advanced_options)). Here is an example of 200 Hz sinawave 2Vpp that should generate about 32 V on the DCP405 output (attached load is 4R7 + 4R7):
(https://i.imgur.com/JsSNiSm.png)
Another example is 120 Hz triangle (50% ramp):
(https://i.imgur.com/GMHGvpS.png)
... and 120 Hz square wave:
(https://i.imgur.com/QMKlJ4L.png)
-
Thank you very much, this is more than I hoped.
-
Today we finalized support for SMX46 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-smx46-switch-matrix-module.html). This is the first step in the direction of transforming the BB3 from a programmable power supply into a T&M chassis, which was the initial idea after the closure of the H24005 project. It is supported now in master firmware v1.3 (https://github.com/eez-open/modular-psu-firmware/releases/tag/1.3) and got its own (https://github.com/eez-open/dib-smx46-fw/releases/tag/0.8) firmware that can be easily downloaded without an additional debugger/programmer as is the case with the DCM module. The first use case for this module is to enable automation of module production testing, and we will start with the DCP405.
SMX46 got all the necessary SCPI support (which included adding a new ROUTe (https://www.envox.hr/eez/eez-bench-box-3/bb3-scpi-reference-manual/5-subsystem-command-reference/bb3-scpi-route.html) subsystem), and here are a few screenshots of what it looks like on the BB3 display:
3 module view (second slot):
(https://i.imgur.com/ELukfIM.jpg)
Maximized view:
(https://i.imgur.com/6XqvEo0.jpg)
Settings page:
(https://i.imgur.com/U9tV7w8.jpg)
Analog output calibration:
(https://i.imgur.com/VJ6x5mT.jpg)
Relays cycle counters:
(https://i.imgur.com/8Nj3FuI.jpg)
Switch matrix routing and label settings:
(https://i.imgur.com/5CfsNtW.jpg)
-
Hello,
I'm new to this thread and I'm really impressed with the capabilities of the firmware of Bench Box 3 tool.
A few years ago I've started a similar hobbyist project called Labtool, supporting the usage of the various measurement modules. My device consists of the backplane with slots for up to 10 add-on modules, housed by a laser-cut metal housing.
The main capabilities of a backplane are:
- 7 inch LCD, 800x480 (or 6.5'' 400x240 with touch capability)
- MCU STM32F429 2MB Flash with external 32MB SDRAM, 64MB SPI Flash and battery backup RTC
- bunch of embedded interfaces like ethernet, 2xUSB, RS232, RS485, LIN, 2xCAN, I2C, SPI, UART, PWM, DIO, AIO
The purpose to design this tool was the need to have a freely programmable test & measurement device, capable to run even complicated test sequences thanks to PLC-like firmware. The idea reflects the capability to use each of the existing I/O and it's set of capabilities (like the current, voltage, baud rate, duty cycle, frequency, phase, etc.) as a parameter or result storage of any logic or arithmetic sub-block.
Each I/O card, sized 60x122mm, communicates with a backplane through 32-pin connector, providing +5/+12 supply, 16MHz system clock, SPI, I2C, and a few dedicated bi-directional lines. On every card exists small I2C configuration memory, which provides card information (like name, type, calibration data, etc.) during the initialization phase or after hot-swap.
Up to now I've designed and tested six different modules: 6-channel relay board, 8-channel high side driver module, 2 and 4 channels DDS signal generator, spectrum analyzer DC-50MHz, dual programmable resistor decade, and a 4-quadrant power supply +-20V/+-2A :). And of course, the port extension for debugging ::). Some photos are attached herein.
Unfortunately, this project consumed me a lot of time and due to other professional activities was not yet fully finalized, mostly its software part. So this is why I'm impressed with the complete functionality of your design.
In a case someone will find this design useful, I can share schematics and some build guidance.
-
[...]
Up to now I've designed and tested six different modules: 6-channel relay board, 8-channel high side driver module, 2 and 4 channels DDS signal generator, spectrum analyzer DC-50MHz, dual programmable resistor decade, and a 4-quadrant power supply +-20V/+-2A :). And of course, the port extension for debugging ::). Some photos are attached herein.
Nice work! Surprising how much like the BB3 it is, too - clearly there's a need for an open platform like this.
-
Great work @goleszek! The project seems to include a lot of ideas that have been implemented or are planned for BB3. Some of your modules could be a great addition to the BB3, some like the 4-quadrant PSU have been under consideration for a long time.
If there is a good will to share the details, I suggest you open a GitHub account and put there everything you want to share and specify license. Of course there is no reason not to do that here on the forum, in this thread or a new one.
In theory, someone might be able to try and adapt the BB3 firmware part to your chassis when you get a richer GUI and solid SCPI support.
By the way, I'm also interested in more details about your PLC-like firmware i.e. PLC functionality/programing principle, how far you've come and if you have any plans about it.
-
Hi @prasimix,
Yes, I thought about putting everything "as is" to Github, but probably as a next step this will need my prompt support on that (which, unfortunately :(, I can't provide due to lack of time).
Anyhow, I will prepare some details regarding 4-quadrant PSU and PLC-firmware basis, which I will post here soon - maybe someone will find it useful.
For now, I've added herein some pictures, which didn't fit in my previous post (sorry for low quality of some of them).
-
Promissed summary of my implementation of the the 4-quadrant supply:
It can provide current +/-2A and voltage +/-20V to the load connected between J5 and J6. The regulation topology operates around GND, so only +/5V supply is required.
Ports meaning from the schematic:
SDAC - analog input for V or I control, +/-2V range
GENOUT - analog input from a signal generator, +/-10V range
SSOURCE - digital input for source selection ("1" - from SDAC, "0" - from GENOUT)
IVSENSE - analog output, proportional to load current or voltage, +/-2V range
IVREAD - digital input for readout selection ("1" - current read, "0" - voltage read)
IVMODE - digital input for mode selection ("1" - current mode, "0" - voltage mode)
ILIM- - analog input setting sink current, 0..+2V (reflects 0 to -2A limit)
ILIM+ - analog input setting source current, 0..+2V (reflects 0 to 2A limit)
Circuit behavior:
U27 acts as an operating mode selector
U24A buffers signal from the load for further processing by ADC/MCU
U23A and U23B act as comparators, supporting independent sink/source current limits, regardless of actual mode (voltage or current). U26B inverts control signal ILIM+.
U25B acts in a current control loop, inverting signal proportional to current, taken from R189, R185
U25A acts as an error amplifier
U26A provides a control signal, preselected by U27 mux
Q3 and Q4, with shunt resistors, act as fast comparators, limiting load current to kindly +/2A during fast switching (like driving capacitive load by a square wave). Under such a condition control loop with opamps can't compensate correctly, so some protection mechanism is needed.
U28 and U29 provide control currents - they can be realized by simple LMxx source or even resistors.
Darlington pair Q5/Q6 provides load current, being controlled by mA sources.
This supply requires floating pre-regulators or fixed voltage (if thermal budget allows it), connected to OUTPUT, VPOS and VNEG pins.
The power (PGND) and logic/control (GND) grounds are shorted by R190, however effectively conducting no current. This short is for a reference only.
-
Hi again, and sorry for late response I was occupied with other issue (https://www.eevblog.com/forum/projects/emi-issue-with-bad-power-plane-and-sdram/msg3258962/#msg3258962). 4Q PSU module seems very simple, but if it has proven to be stable and can handle properly changes in operating mode (i.e. with min overshooting) and going through zero, it makes sense to try to adapt it for BB3. For starters, I might do an LTspice simulation that can help with further development and modifications as well.
I also see the next candidate for BB3 that I was already thinking of adding for testing automation purposes and that is the resistor decade module. Congratulations on how you packed the relays! I guess they can't be hand soldered so densely placed and that an reflow oven is needed.
Can you publish the schematic, I wonder what ratios of resistors you used and what ranges with which steps are possible.
Thanks again for sharing this with us.
-
One thing that is difficult to distinguish from the pictures, and what interests me is what the master MCU (STM32F4) directly controls. He seems to be responsible for a lot of things, so I wonder what the overall performance is. Unless in case when one of the demanding modules is active the others go to sleep or get a very low priority.
-
I don't think the modules would need a lot of active attention from the mast µC. The DDS chips and supply would essentially run on there own, one programmed. It would be mainly the ADC read back from the supplies.
With DDS the µC could however add extra functions like modulation, and this would need quite some time / attention.
How to split the control jobs between the master and and cards is a good question though.
By nature the 4 quadrant supply would have to cope with high power loss, when in the sink quadrants. So I wonder if it is worth doing full pre-regulation. One might limit it to just plain linear, possibly with 2 steps so that the sink mode would not add much extra power from the supply.
-
Yah, the sink quadrants are a bit vicious...
Assuming +20V on terminals, sinking 2A load. That would appear to be 40W... except that the pass transistor is sinking to, say, -25V. So it’s actually 90W or so. Yikes!
Some kind of multi-range switch - and a large heatsink - definitely required. I seem to recall that Liv (?) posted a DC power supply design here a few years ago with a Class G output stage which effectively does automatic range switching.
-
There was a lab supply project with a class G output stage from Liv. It could be extended to 4 quadrants. With 4 quadrants just using 2 steps, one from some 20-25 V and one from zero could be enough. So the maximum voltage drop converted to heat would be some 25 V. Starting from zero could start if the external supply is higher than some 2 V. More steps would not improve the worst case power loss very much.
For not so high currents there is an odd variant, using an emitter-follower with a limited collector voltage. With higher voltage the current would be just from the base current. So the transistor changes from current amplifier to diode function. Chances are this type could be build relatively simple. It just needs a relatively robust BJT that can withstand 2-3 A of base current (e.g. something like TIP3055). For something like +-20V 2A this configurations looks reasonable. The the more classical form with 2 BJTs (or BJT + MOSFET) in series would also work with not too much extra effort.
Part of this may be hidden in the "pre-regulator" part.
-
The resistance module used for Labtool project reflects 1-2-3-4 sequences for value setting. However, it is not limited only to such steps. My initial assumption was to combine typical range from 10ohm to 10Mohm (1st decade on the board) and 0.1ohm to 20ohm (2nd decade, used as a power load), as indicated on the schematic. Additionally, to minimize resistance offset introduced by relay switches I added a bypass, which effectively reduces an overall error.
Finally, I hand soldered :( two identical decades with a higher range. If you plan to build your own, I strongly suggest using TH instead SMT relays - the assembly process will be much easier, as pointed by @prasimix.
For high-density packing and expected accuracy one should consider self-heating of relay coils - with 50 relays onboard and full activation it is more than 5..7W. During a long time operation, the resistance drift is kindly measurable.
The design uses TLE75008 relay drivers, although these ones can be replaced with 12-channels NCV7751, simplifying overall design, with higher availability.
The polymer fuses R38 and R130 can be replaced by shorts or typical (wire) fuse, which may reduce additional error due to temperature.
-
@prasimix
-> One thing that is difficult to distinguish from the pictures, and what interests me is what the master MCU (STM32F4) directly controls.
Well, I used 10ms grid to communicate with each of the modules, independently of its number. If there was some action to be taken (like new data to be set, status check, readout, etc.), the F4 MCU was able to do it easily. In parallel, it supports LCD and onboard interfaces - with dedicated FIFOs and dual/triple video buffering, there was no lag observed.
The firmware runs on the FreeRTOS, with 1ms systick.
-
Hi Prasimix,
Is BB3 still on course for Oct. 6th shipping (Mouser).
Thanks,
Ian.
-
For high-density packing and expected accuracy one should consider self-heating of relay coils - with 50 relays onboard and full activation it is more than 5..7W. During a long time operation, the resistance drift is kindly measurable.
Yes, relays heating is another thing I wanted to point out. Therefore, using a latching relay would make sense. Unfortunately their driving requires a lot more components, and it would be good if there was some integrated multi-channel driver, just as is the case with non-latching relays.
-
Hi Prasimix,
Is BB3 still on course for Oct. 6th shipping (Mouser).
Thanks,
Ian.
Hi Ian, I really don’t know what to say. Looking at some other campaigns I see that everything needs to show up at the Mouser stock first to move on. This happened last week, for all items except individual DCP and DCM modules (don't know why since I sent them all together). I don’t know how synchronized CS and Mouser are when it comes to setting dates, but it would be high time it finally moved towards backers. Maybe it really happens tomorrow, which will be seen when the stock changes.
-
One can use similar drivers for dual coil latching relays as for simple relays, it just needs twice as many. There are several types of power shift registers like tpic6C595 for 8 and also 16 outputs. With latching ones heating at the driver is usually not a problem.
-
The efficient and cost effective solution can be usage of typical non-latching relays, but driven from 2-step voltage regulator. During relay activation, the supply may go to nominal level (like 10V) and then be reduced to kindly 5V (or even lower, depending of release voltage). The overall power dissipation can easily be reduced in half and in a relay's coil by 75%...
-
Resistor bypassed with a capacitor will be basically the same :). http://think.gusius.com/contactor-coil-power-saver/ (http://think.gusius.com/contactor-coil-power-saver/)
The reason I didn't use it in one of my designs is that the capacitor needs to be reliable. If it dries out, the relay may stop activating.
-
@exe
Yet for driving many relays (like a decade module) probably you need to replicate your circuit, which is not needed for previous one (i.e. when relays are activated from a GND side and sharing common supply)...
-
Hi Prasimix,
Is BB3 still on course for Oct. 6th shipping (Mouser).
Thanks,
Ian.
Hi Ian, I really don’t know what to say. Looking at some other campaigns I see that everything needs to show up at the Mouser stock first to move on. This happened last week, for all items except individual DCP and DCM modules (don't know why since I sent them all together). I don’t know how synchronized CS and Mouser are when it comes to setting dates, but it would be high time it finally moved towards backers. Maybe it really happens tomorrow, which will be seen when the stock changes.
Good news! got an email today.....it's being despatched.
Ian.
-
First power photo below.
My initial interest is to use the BB3 help automate the testing of some of the products I make.....firstly where I set a power supply powering my products to various voltages and measure test points as I go along, and up the output voltage & CC setting as I go.
So, I got SCPI up & running on the BB3, got Keysight IO configured with the BB3 and my own GPIB app now talking to the BB3. So far so good!.....working out the box.
The very basics so far........
OUTP OFF, CH1
VOLT 15
CURR 0.5
OUTP ON, CH1
Ian.
(https://www.ianjohnston.com/images/stories/IanJ/eevblog/BB3.jpg)
-
Hi Ian, I'm so glad to see that your BB3 is working properly. Feel free to upgrade to the latest firmware v1.3.2 (https://github.com/eez-open/modular-psu-firmware/releases/tag/1.3.2) (instructions are available in Chapter 13 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/13-firmware-upgrade.html)) that the two modules use the entire screen. Also feeling free to try EEZ Studio (https://github.com/eez-open/studio/releases/tag/0.9.7), it's free. I'm also trying to finish a chapter on Node-RED integration that might be interesting to you.
-
I forgot to mention that MicroPython could be used for test automation, too. You can download few examples (not really about test automation :)) from here (https://www.envox.hr/eez/eez-bench-box-3/firmware.html) (or automate their download using EEZ Studio) and Chapter 16 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/16-scripting-with-micropython.html) covers "hello world" example where you can find how to make custom pages for interaction via its touchscreen.
-
prasimix,
With Keysight IO libraries I can query/response the BB3.....but from my own VB app I can make a valid connection but can't query the BB3 at all. I get an error responce.
I have written my own VB app but it uses an extensive GPIB library from PavelW. The IO library returns "MAV bit not set" when I try to query the BB3.
The developer of that library I remember he came across somebody else with the same issue try to connect to a DMM and offered the following repsonce at the time.
If the message is "MAV bit not set" then it is clear: your meter is not quite compliant with the 488.2 specification on the meaning of status byte bits. I explain. Polling the status byte is used here to check if the device is ready to send response, according to 488.2 this information is coded in the "Message Available" bit of the status byte, the bit 5 (so the default mask used is 16).
Keysight interactive IO works because it does not use any information from the status byte: when you hit "read" it calls the raw low-level read function which waits until it gets response. But then once a "read" is issued the whole gpib bus will remain blocked until your meter is done with the measurement - very annoying if you have more than one devices connected, especially with high NPLC where it can take seconds to respond. This software uses periodic polls to check if the data is available, before calling "read", in this way the bus remains available and the program is able to query two (or more) devices simultaneously. This is the default configuration but it can be easily disabled on per-device basis (you may do it yourself or ask Ian to add checkboxes controlling the "enablepoll" flag for each device). For a more elaborate version, the MAV masks can also be set individually for each device.
The above just my quick initial ideas as to the problem.........
I can work around it per what Pavel suggests and implement a checkbox in my app to enablepoll.........but just wondered initially your thoughts.
Ian.
-
Hi,
I have a question regarding the usage of the BB3 (I am using Firmware V1.0 as shipped).
How do I change the default power up voltage/current (DCP405)...........seems to be 20Vdc/2.5A at the moment.
Also, and perhaps a future firmware tweak......I'd like to specify the minimum step change of the rotary encoder (say 0.1V, 0.01V etc), making it quicker to achieve the exact setting rerquired.
Ian.
-
A BB3 arrived here in Sweden today. Dropped off at my door just after lunch today having left Texas on the 14th.
Assembly now started ;)
Oops, failed on step 2. Missing one J, have 5 or so extra L ...
-
Hi,
I have a question regarding the usage of the BB3 (I am using Firmware V1.0 as shipped).
How do I change the default power up voltage/current (DCP405)...........seems to be 20Vdc/2.5A at the moment.
Also, and perhaps a future firmware tweak......I'd like to specify the minimum step change of the rotary encoder (say 0.1V, 0.01V etc), making it quicker to achieve the exact setting rerquired.
Ian.
+1 to both of these
-
Hi everyone,
@cadwal, @Kean: Kind of a solution for the power on settings: In the User Profiles Menu you have the option "Autorecall on power-on" (shown and described in the manual on page 51) which means it powers up with the settings you had the last time. Maybe another option that fits to your question: Settings->System protection settings->Force disabling of all outputs on power up.
Assembled my BB3 today. First impressions are pretty good so far. Here's what I noticed (positive first):
+ This thing is FAST. Boot time, UI response time and especially control and read out of the outputs. I've been sitting here for a minute turning the thing on-off-on-off just because it can do it so fast. The fast readout is impressive, too.
+ Manual looks well made. A lot of pictures of the UI with markings where to click what. Haven't used it a lot because IMO you shouldn't need a manual to get to know the basics about your device/tool/whatever. Manual is for the advanced and complicated stuff; the daily stuff should be self-explainig.
+ Many parts of the UI are well designed. Not only with regards to the previous point, but also with an eye on productivity. This was a big fear of mine; having a lot of features and a touch display is nice, but if it's slower to use than the good old 4 knob analog supply, it's annoying. Very happy to see that this fear did not become true for most parts.
+ Assembly was pretty straightforward. Big thumbs up for requiring only two types of screwdrivers, two types of screws (technically three if you count the two longer ones) and nothing else. No washers or clips or dunno what.
+ Packaging was pretty efficient. Everything protected and pretty much as compact as possible. This is the kind of details that give me the feeling that someone put effort and thoughts into it.
+ Putting those power supply modules into the bottom PCB was veery satisfying ;D
+ Look and feel during the construction was very good. There're only very few minor things that could be improved in my opinion. Like it!
+ Thaaank you for the option to turn off the beep sounds. Otherwise I'd have desoldered the thing sooner or later.
+ Not directly related to BB3 itself, but I can't emphasize enough how much I respect the effort prasimix put in the fulfillment of the crowd supply campaign. I really hope that in the end you didn't loose money on this; that's really the last thing you deserve.
Now on the other side I also noticed things that could be improved in my opinion, and how I think it could be done. This time I try to put it in a meaningful order. While I'm typing this I realise it's getting muuuuch longer than I thought. Sorry for that. I really want to give some constructive feedback with this and hope that it is indeed useful (and not a much too long waste of time..).
At the very end I describe a more serious issue with my DCP405 modules. So in case you want to read this review another day (which I fully understand), I'd appreciate if you could take a look at the very last point (made it bold).
My Setup:
BB3 with 2x DCP405 and 1x DCM220. I'm still on v1.0 (reasons below). I guess some of the issues have been fixed in the meantime.
Getting started:
- So you get this note with half a dozen links. They are short but still, you have to type them by hand. I think you could include a QR code. There're too many links to include a direct QR code for every link, so I'd suggest to include one single QR code. It'll link to this document online. Then you can copy&paste (or even better: click) all the links you need or want to have a look at. Of course, not everyone wants to do this on his phone, nor can everyone do this. But those people can still type the links by hand. There's no disadvantage for them.
Access to information:
- Index in the PDF manual does not link to the pages. That's usually one checkbox at the PDF export and very useful. Another thing that's a bit confusing/annoying: Since the index does not link to the pages I enter the page number in my PDF viewer, f.ex. page 23. But this actually brings me to page 25. There's a mismatch; the x-th page of the document is not page with number x.
- I understand that this device is quite complex and powerful. However I had to click quite some time around before I found the assembly instructions. I'd have to take a more serious look at this and especially think about how one could make this easier before I can come up with concrete ideas.
- At one point I wanted to download the manual, because I had no idea where I'd find this information on the website. I found a "User Manual" entry in the index table at the top (reminder: I'm on my smartphone). Two download buttons are presented to me, for english and german. Okay so I click on the download button for the german one. But instead of getting the PDF I get to a new page whose purpse is apparently to give me "Download Details". And another download button. So I click on that and what do I get? well, still no download. Another page, this time providing me the very useful "Download summary". Which is basically the same thing as the two pages before but at least a different layout. Oh, and there's another one of those wannabe download buttons. You'll never guess what it does. It actually started a download - finally!
Seriously, I doubt its necessary or a good idea to let anyone go through that many useless (IMO) pages to open a manual...
- Another thing I particularly noticed on the page about how to do a firmware update. There's a short intro and then a looooong Linux secion with loots of code. Might be nothing complicated and really well described - that's not the point. I am not a Linux user (I guess like most people) and this was all I saw, even when scrolling down a bit. It's only after quite some more scolling that the Windows tutorial appeared. What if I have a Mac? do I scroll even more? The point I want to make is: obviously this page contains a couple very long sections. they have to be that long and that's fine. But it does not make the page more readable. If I have to scroll through an entire webpage that is multiple screen heights long, to find out if it even contains the information I'm looking for ("Firmware update with Windows"), I think the design is not the most user friendly.
Here's what I'd suggest for the mobile webpage. The page filling "global index" at the top can be hidden in a side menu. You know, the thing you acces with the button in the top left corner, that has thee horizontal lines as icon. This is important because the first thing I will see when opening the page can now be actual content and not a menu have to scroll through every time I click on a link. For the page itself I think a wikipedia-like design would help a lot. What I mean is that every section is at first collapsed and only its title visible. This is IMO a very clever way to allow quick navigation through a page with long sections - like wikipedia articles or firmware update guides. I'd immediately see 13.1 Linux, 13.2 Windows - perfect, tip to show that section and done.
- Speaking of firmware updates (does not quite match this section but fits perfectly after the previous point). You need different tools to upgrade different parts of the BB3? That's a bit disappointing... I hope you manage to get this all under one hood. Another issue IMO: you need to get this wired up to a PC...? Not sure if everyone has a lab PC - I for sure didn't have one for a loong time. What I'd love to do is this: Download the latest firmwares, drag them onto the microSD card, and the BB3 will update everything it finds a firmware for. No need to have a PC next to your lab supply, no need to download and configure any drivers or software according to multiple (!) tutorials. Just drag&drop, plug&play, done. (An even more fancy idea: since the thing has networking... You could let BB3 download new firmwares from the github release page ;D )
- The complicated looking update procedure is the main reason why I'm still on v1.0. Download, drag&drop would've been a no-brainer but this is something I have to read through on another day. And while I absolutely appreciate that the firmware can be updated (meaning the device gets better and better over time), this makes me think that not as many people will update their BB3 and they won't do it as frequently as they would otherwise. HOWEVER, as I said, I haven't gone through the procedure, maybe it's already very quick 'n easy and half of my critic here is not right. Would be great! Still want that SD update :P
Case/Mechanical/Assembly:
- I did not count the screws at the beginning but I know I missed one black screw when I was done. For some reason I have 6 of the silver screws left. Haven't found a hole where they'd be missing... That aside, I do think there should be 1 spare screw of both types, possibly even a third of the longer black ones. Since there're only 2 (3) different screw types, this shouldn't add too much cost and would help in case you loose one. Especially since quite a few BB3 users will open their case again to upgrade/change the modules - another chance to loose a screw. I thought about this when I realized there were no extra screws. And I really wished it when I realized I missed one. Don't want to blame anyone but I assembled it on a clean table with a clean, white floor underneath and I can not find it. So yeah, I'm probably blind. :palm:
- The screws that hold the display are rusted...? Is that normal?
- About half of the threads in the case had paint in them which made it pretty hard to force the screw in. At least they won't get lose! Don't know if this can be avoided or not; just wanted to note it.
- The top case is slightly bended (higher in the middle); it can be pushed down about 2mm. Additionally, because it's screwed down on only two axes (left and right on the same place), the top part can be slightly pushed forwards/backwards and doesn't line up with the bottom part. Both things are purely cosmetic and no real issues but IMO this does not match the quality and feeling of the other parts. Take the bottom half; that one feels rock solid. Second reason for brining it up: both things could be fixed with one minor change I think: add 1 screw between front panel and top case, and 1 between back panel and top case. This should not only prevent the forward/backward fexibility but also hold the top piece down properly for an overall even more rigid feeling.
- The cable for the fan is about 3cm too short? I can't put it the way as shown in the assembly manual. If I put it from the connector down between the DC/DC converters and the heatsink, there's not enough length to put it against the backplate; it goes straight to the fan. (think of a triangle. hypotenuse is shorter than the other two sides together). Is this meant to be like this? Again, doesn't cause any issues I think but didn't seem right to me...
- A true detail: Every word on the front panel and on the module front panels has the first letter in upper case - as I'd expect it. Except of two things: SD card, which is fine IMO, and "Open hardware / open source". The second open in lower case does not look right to me; doesn't match the first one. You dont write "Dual sync buck" instead of "Dual Sync Buck" either. Not 100% sure if the "hardware" and "source" should be upper case, too, but at least the two "open" must be equal IMO. As I said, a detail, but one I'll see every single time I use the BB3 - which will hopefully be very often ;)
The Rotay Encoder
Now this one deserves its own section in my post because it was honestly the biggest disappointment. From your videos I can see that you don't use the encoder that much and prefer the keypad. I tried both and the encoder is really the thing that suits me the best. I'm sure this is very individual and every one will come up with a different habit that seems perfect to him/her. The most natural feeling way for me is touch the value, turn the knob. I don't use the keypad, I don't use the knob's push button to cycle through the values. What made it even more disappointing is that I absolutely believe that it could be possible to set values very fast. Like "I don't miss the 4 potentiometers from my analog supply at all" kind of fast. So here we go with my issues...
- For some reason the encoder does not sit straight. This means that the knob is too close to the front panel in one point and depending on how I turn it, scratches over the front panel. This feels really really cheap. I might even open it again and try to resolder the encoder to fix this.
- The knob sits rather loose on the encoder shaft. Being a big know makes it look even worse. Again, very cheap feeling to me.
- The encoder itself has no decent ticks but feels rather soft and spongy - again, a big knob doesn't help. Big knob = large radius = large lever arm => soft spongy ticks feel even more soft.
- The velocity control does not work at all for me. So I did play quite a bit with it and here's the issue (I think): the velocity increases only after about half a turn. If you turn the knob a quarter turn you won't get very far no matter how fast you do it. However, if I turn the knob with two finger, half a turn is the most I can turn it; usually more like 1/3 of a turn. If the knob was smaller, it would be more; maybe someone with bigger hands can turn this big knob a full turn but I cant. Same thing if you turn it with one finger by putting it on the side; you get about 1/3 of a turn.
So for my usual way(s) of using a knob velocity control is de facto inactive, making the knob de facto useless.
The only way to really get velocity control is to put one finger on the front of the knob and turn around (which includes slipping off). Then you can turn it a full revolution (before slipping of) and velocity control becomes veeery visible. But as described above; for the way I use a knob this is much too late.
Bottom line: please adjust the velocity control such that you can easily get across the range with 1/3 turns. I know it's possible. And I'm pretty sure some knobs I've used recognize when you to multiple quick movements (like you usually do with two fingers), and don't restart for every 1/3 turn at "zero velocity". One might say they have a bit more inertia.
- Even worse: If I have the velocity settings not at maximum (gets worse the lower you go), I can turn the knob and individual steps don't do anything anymore. I can turn the knob a whole revolution without changing the value. I think 1 tick should always do something.
Using BB3 and its UI (reminder: v1.0!)
- While I said above that I do think it's well made in most parts, it does make a ... convoluted? impression. Even though I know what is what, the overview with the 4 channels (I have 2x DCP405 + 1x DCM220) does somehow not look "clear", "stuctured". I honestly can't tell you why.
- When I tested it for the first time I turned on Channel 1 (first DCP405); fine. Tipped on channel 2 (second DCP405) - and I get a warning that its not calibrated. Okay, no worries, let's do it - but nooo I can't. This thing comes out of the box with a cal password. Okay, it's nice to have that option, but the few people who need this, will find the option because button for changing the cal password sits right next to the button for the main password - no chance to miss it. But everyone else (and seriously, how many people really want this?) has additional work with this. And especially during the very first "hands on", I shouldn't have to search through the manual for some default password... Even worse - I can't remove the thing? I can't leave the password blank when changing it? Might someone explain, why I, as a private user, would need to be forced to password protect the calibration routine?
- This point I'll bet that it's been fixed by now: There's the Settings point "Encoder & User sw" but I don't see any settings for the user sw? Maybe I'd have to read through the manual in detail but so far I haven't found any option or setting for that switch.
- I kinda mentionned it in the positive points but that beep thingy sounds "not good"; rather cheapish-annoying. Might be highly subjective; maybe other users like it.
- Now this is serious IMO. Using the DCP405 modules (happens with both of them). When I have the current limit at 8mA or lower and I short the output, it does not recover correctly after removing the short. Voltage was around 10V, but doesn't seem to matter. What happens is that the voltage stays slightly below the set value (f.ex. 11.5V instead of 12V) and the CC LED remains on. Current stays at the limit until I increase it to about 10mA or higher. Only then the current will drop back to 0 and I can decrease the limit again. MAYBE this a soldering fault on both of my modules...? One of them hat 2 capacitors that fell of the board, and a third one with a bad solder joint. Additionally I just noticed that that module must have at least one more bad solder joint, because the CC LED started flickering, and reacts if I knock on the case. Any ideas? That aside, the issue that it does not recover after entering current limiting mode is equally present on the other DCP405 module. I couldn't find any bad solder joints on that one but maybe I missed something?
Okay, finally, I'm done (or forgot the remaining points). If you read through all of this, I do hope it's useful. Thank you for all of your work, and in case all of this sounds too negative, you should know that I don't regret to have opted for the BB3 and would do it again. :)
Max
-
Hi prasimix,
Trying to update firmware, not going so well.
I followed the Windows install for the DfuSE_Demo. Got it installed.
Powered up the BB3 in DFU mode (confirmed with blank LCD).
Usb cable connected Windows acknowledges a Usb connection (sounds).......but in Device Manager I have no "STM Device in DFU mode" listed.
Your guide tells me to install driver manually, but link is to the 32-bit Win7 version and as such won't install telling me to install 64-bit version......I couldn't find it. I have Win10.
So, I tried running ZADIG (I'm sure you will be aware of this app) and can confirm with the BB3 in DFU mode I see "STM32 BOOTLOADER" listed.......so I tried each of the 4 available drivers listed, but none of them give me "STM Device in DFU mode" in Device Manager.
So, at the moment I cannot upgrade the firmware.....very frustrating.
Btw, on normal boot of the BB3 I get "MASTER STM32 R2B4 - FAILED"...........is that normal?
Other than that, I do have an ST-LINK V2 and a V3.....can I use that direct on the MCU board via ST-LINK Utility, I notice there is an unpopulated header, SWD I presume....?
Ian.
UPDATE:
Got DFU mode in Device Manager now.....had to right click on STM32 BOOTLOADER in Device Manager and manually update drver from list of available. DFU mode driver was listed.
Firmware of my BB3 now updated.
Ian.
-
Good to see that you succeed. Do you know what the problem was, to possibly add it to the User manual, to avoid future frustrations of other users?
Do you still have a problem with Master: Failed at startup? The reason for this may be the wrong set date/time, the problem with the SD card or with the backplane. Additional info can be found in the event log (see Section 9.1 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/9-system-functions.html#bb3_man_event_viewer)).
-
Hi,
I have a question regarding the usage of the BB3 (I am using Firmware V1.0 as shipped).
How do I change the default power up voltage/current (DCP405)...........seems to be 20Vdc/2.5A at the moment.
Please consult Chapter 7 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/7-basic-operations.html).
Also, and perhaps a future firmware tweak......I'd like to specify the minimum step change of the rotary encoder (say 0.1V, 0.01V etc), making it quicker to achieve the exact setting rerquired.
Already implemented :). You can do that with User Sw set to "Encoder step" (see Section 9.8 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/9-system-functions.html#bb3_man_user_sw).)
-
Hi all,
Based on the latest firmware (MCU) here are my initial thoughts of the BB3 GUI.
1. The encoder acceleration takes a bit of gettiong used to. Set it quite low and not much happens. Set it high and as you rotate the encoder with one quick action you might go up or down say 0.3V......but the acceleration only seems to come into play when you rotate the encoder again....i.e. it's that gap between rotating once and rotating it again that governs when the display should jump in much bigger steps. I am thinking there must be a better way for this.....it is really frustrating to use.
2. The encoder know is too big and too close to the User SW. I have lost count the number of times I have rotate the knob but accidentally hit the button whist doing so. I fitted my own, small diameter knob.
3. When using the encoder it's quite hard on the eyes to see the setpoint (Vdc) display change, i.e.:
25V
25.005
25.01
25.015
25.02
The readout jumps from side to side as it centre justifies all the time. It would be better to have the XX.XXX at all times. No digit blanking, and perhaps left justify maybe.
Personally, I would like to be able to only allow 0.1Vdc steps when using the encoder, but make this selectable in config for those that want max resolution.
4. Similarly, for the Vdc feedback, you can get the following on the display
8.1
8.015
8.005
8.00
or, indeed:
37.01
37.005
37
So, there's inconsistency here.......
5. The touchscreen buttons are probably a little on the small side, not much can be done about that I guess......but maybe a larger LCD next time.
6. Entering Voltages using the keypad, 40.1Vdc of course is not accepted, neither is 40.000002.......but 40.000001 is accepted?
So far though I am really liking the BB3.......hopefully it will become my primary PSU.
UPDATE: Just saw your post about USER SW.......fixes the XX.XXX issue for the most part, but would still like to see XX.X on the voltage setting for instance. at the moment it goes 14.8, 14.9 then 15. I think should be 15.0.
Ian.
-
Good to see that you succeed. Do you know what the problem was, to possibly add it to the User manual, to avoid future frustrations of other users?
Do you still have a problem with Master: Failed at startup? The reason for this may be the wrong set date/time, the problem with the SD card or with the backplane. Additional info can be found in the event log (see Section 9.1 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/9-system-functions.html#bb3_man_event_viewer)).
I had to right click on STM32 BOOTLOADER in Device Manager and manually update the driver from list of available that popped up. DFU mode driver (various versions) was listed so I chose the newest.
It's possible because I already had an STM32 dev system loaded that it didn't install correctly.
Ian.
-
prasimix,
With Keysight IO libraries I can query/response the BB3.....but from my own VB app I can make a valid connection but can't query the BB3 at all. I get an error responce.
I have written my own VB app but it uses an extensive GPIB library from PavelW. The IO library returns "MAV bit not set" when I try to query the BB3.
The developer of that library I remember he came across somebody else with the same issue try to connect to a DMM and offered the following repsonce at the time.
If the message is "MAV bit not set" then it is clear: your meter is not quite compliant with the 488.2 specification on the meaning of status byte bits. I explain. Polling the status byte is used here to check if the device is ready to send response, according to 488.2 this information is coded in the "Message Available" bit of the status byte, the bit 5 (so the default mask used is 16).
Keysight interactive IO works because it does not use any information from the status byte: when you hit "read" it calls the raw low-level read function which waits until it gets response. But then once a "read" is issued the whole gpib bus will remain blocked until your meter is done with the measurement - very annoying if you have more than one devices connected, especially with high NPLC where it can take seconds to respond. This software uses periodic polls to check if the data is available, before calling "read", in this way the bus remains available and the program is able to query two (or more) devices simultaneously. This is the default configuration but it can be easily disabled on per-device basis (you may do it yourself or ask Ian to add checkboxes controlling the "enablepoll" flag for each device). For a more elaborate version, the MAV masks can also be set individually for each device.
The above just my quick initial ideas as to the problem.........
I can work around it per what Pavel suggests and implement a checkbox in my app to enablepoll.........but just wondered initially your thoughts.
Ian.
Thanks for this. Martin will investigate and we'll let you know what he found. If you have a chance to get some VB sample, it could speed things up for me.
-
prasimix,
With Keysight IO libraries I can query/response the BB3.....but from my own VB app I can make a valid connection but can't query the BB3 at all. I get an error responce.
I have written my own VB app but it uses an extensive GPIB library from PavelW. The IO library returns "MAV bit not set" when I try to query the BB3.
The developer of that library I remember he came across somebody else with the same issue try to connect to a DMM and offered the following repsonce at the time.
If the message is "MAV bit not set" then it is clear: your meter is not quite compliant with the 488.2 specification on the meaning of status byte bits. I explain. Polling the status byte is used here to check if the device is ready to send response, according to 488.2 this information is coded in the "Message Available" bit of the status byte, the bit 5 (so the default mask used is 16).
Keysight interactive IO works because it does not use any information from the status byte: when you hit "read" it calls the raw low-level read function which waits until it gets response. But then once a "read" is issued the whole gpib bus will remain blocked until your meter is done with the measurement - very annoying if you have more than one devices connected, especially with high NPLC where it can take seconds to respond. This software uses periodic polls to check if the data is available, before calling "read", in this way the bus remains available and the program is able to query two (or more) devices simultaneously. This is the default configuration but it can be easily disabled on per-device basis (you may do it yourself or ask Ian to add checkboxes controlling the "enablepoll" flag for each device). For a more elaborate version, the MAV masks can also be set individually for each device.
The above just my quick initial ideas as to the problem.........
I can work around it per what Pavel suggests and implement a checkbox in my app to enablepoll.........but just wondered initially your thoughts.
Ian.
Thanks for this. Martin will investigate and we'll let you know what he found. If you have a chance to get some VB sample, it could speed things up for me.
My code is based on Pawel's original here:-
https://www.codeproject.com/Articles/1166996/Multithreaded-communication-for-GPIB-Visa-Serial-i (https://www.codeproject.com/Articles/1166996/Multithreaded-communication-for-GPIB-Visa-Serial-i)
I will be playing around with it this weekend to see if it is something else causing the problem as Pawel gave me that workaround which I haven't tried yet properly.
Ian.
-
Good to see that you succeed. Do you know what the problem was, to possibly add it to the User manual, to avoid future frustrations of other users?
Do you still have a problem with Master: Failed at startup? The reason for this may be the wrong set date/time, the problem with the SD card or with the backplane. Additional info can be found in the event log (see Section 9.1 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/9-system-functions.html#bb3_man_event_viewer)).
Fixed......I didn't realize the SD card needed to be fitted.
Ian.
-
Hi everyone,
@cadwal, @Kean: Kind of a solution for the power on settings: In the User Profiles Menu you have the option "Autorecall on power-on" (shown and described in the manual on page 51) which means it powers up with the settings you had the last time. Maybe another option that fits to your question: Settings->System protection settings->Force disabling of all outputs on power up.
Assembled my BB3 today. First impressions are pretty good so far. Here's what I noticed (positive first):
+ This thing is FAST. Boot time, UI response time and especially control and read out of the outputs. I've been sitting here for a minute turning the thing on-off-on-off just because it can do it so fast. The fast readout is impressive, too.
+ Manual looks well made. A lot of pictures of the UI with markings where to click what. Haven't used it a lot because IMO you shouldn't need a manual to get to know the basics about your device/tool/whatever. Manual is for the advanced and complicated stuff; the daily stuff should be self-explainig.
+ Many parts of the UI are well designed. Not only with regards to the previous point, but also with an eye on productivity. This was a big fear of mine; having a lot of features and a touch display is nice, but if it's slower to use than the good old 4 knob analog supply, it's annoying. Very happy to see that this fear did not become true for most parts.
+ Assembly was pretty straightforward. Big thumbs up for requiring only two types of screwdrivers, two types of screws (technically three if you count the two longer ones) and nothing else. No washers or clips or dunno what.
+ Packaging was pretty efficient. Everything protected and pretty much as compact as possible. This is the kind of details that give me the feeling that someone put effort and thoughts into it.
+ Putting those power supply modules into the bottom PCB was veery satisfying ;D
+ Look and feel during the construction was very good. There're only very few minor things that could be improved in my opinion. Like it!
+ Thaaank you for the option to turn off the beep sounds. Otherwise I'd have desoldered the thing sooner or later.
+ Not directly related to BB3 itself, but I can't emphasize enough how much I respect the effort prasimix put in the fulfillment of the crowd supply campaign. I really hope that in the end you didn't loose money on this; that's really the last thing you deserve.
Now on the other side I also noticed things that could be improved in my opinion, and how I think it could be done. This time I try to put it in a meaningful order. While I'm typing this I realise it's getting muuuuch longer than I thought. Sorry for that. I really want to give some constructive feedback with this and hope that it is indeed useful (and not a much too long waste of time..).
At the very end I describe a more serious issue with my DCP405 modules. So in case you want to read this review another day (which I fully understand), I'd appreciate if you could take a look at the very last point (made it bold).
My Setup:
BB3 with 2x DCP405 and 1x DCM220. I'm still on v1.0 (reasons below). I guess some of the issues have been fixed in the meantime.
Getting started:
- So you get this note with half a dozen links. They are short but still, you have to type them by hand. I think you could include a QR code. There're too many links to include a direct QR code for every link, so I'd suggest to include one single QR code. It'll link to this document online. Then you can copy&paste (or even better: click) all the links you need or want to have a look at. Of course, not everyone wants to do this on his phone, nor can everyone do this. But those people can still type the links by hand. There's no disadvantage for them.
Access to information:
- Index in the PDF manual does not link to the pages. That's usually one checkbox at the PDF export and very useful. Another thing that's a bit confusing/annoying: Since the index does not link to the pages I enter the page number in my PDF viewer, f.ex. page 23. But this actually brings me to page 25. There's a mismatch; the x-th page of the document is not page with number x.
- I understand that this device is quite complex and powerful. However I had to click quite some time around before I found the assembly instructions. I'd have to take a more serious look at this and especially think about how one could make this easier before I can come up with concrete ideas.
- At one point I wanted to download the manual, because I had no idea where I'd find this information on the website. I found a "User Manual" entry in the index table at the top (reminder: I'm on my smartphone). Two download buttons are presented to me, for english and german. Okay so I click on the download button for the german one. But instead of getting the PDF I get to a new page whose purpse is apparently to give me "Download Details". And another download button. So I click on that and what do I get? well, still no download. Another page, this time providing me the very useful "Download summary". Which is basically the same thing as the two pages before but at least a different layout. Oh, and there's another one of those wannabe download buttons. You'll never guess what it does. It actually started a download - finally!
Seriously, I doubt its necessary or a good idea to let anyone go through that many useless (IMO) pages to open a manual...
- Another thing I particularly noticed on the page about how to do a firmware update. There's a short intro and then a looooong Linux secion with loots of code. Might be nothing complicated and really well described - that's not the point. I am not a Linux user (I guess like most people) and this was all I saw, even when scrolling down a bit. It's only after quite some more scolling that the Windows tutorial appeared. What if I have a Mac? do I scroll even more? The point I want to make is: obviously this page contains a couple very long sections. they have to be that long and that's fine. But it does not make the page more readable. If I have to scroll through an entire webpage that is multiple screen heights long, to find out if it even contains the information I'm looking for ("Firmware update with Windows"), I think the design is not the most user friendly.
Here's what I'd suggest for the mobile webpage. The page filling "global index" at the top can be hidden in a side menu. You know, the thing you acces with the button in the top left corner, that has thee horizontal lines as icon. This is important because the first thing I will see when opening the page can now be actual content and not a menu have to scroll through every time I click on a link. For the page itself I think a wikipedia-like design would help a lot. What I mean is that every section is at first collapsed and only its title visible. This is IMO a very clever way to allow quick navigation through a page with long sections - like wikipedia articles or firmware update guides. I'd immediately see 13.1 Linux, 13.2 Windows - perfect, tip to show that section and done.
- Speaking of firmware updates (does not quite match this section but fits perfectly after the previous point). You need different tools to upgrade different parts of the BB3? That's a bit disappointing... I hope you manage to get this all under one hood. Another issue IMO: you need to get this wired up to a PC...? Not sure if everyone has a lab PC - I for sure didn't have one for a loong time. What I'd love to do is this: Download the latest firmwares, drag them onto the microSD card, and the BB3 will update everything it finds a firmware for. No need to have a PC next to your lab supply, no need to download and configure any drivers or software according to multiple (!) tutorials. Just drag&drop, plug&play, done. (An even more fancy idea: since the thing has networking... You could let BB3 download new firmwares from the github release page ;D )
- The complicated looking update procedure is the main reason why I'm still on v1.0. Download, drag&drop would've been a no-brainer but this is something I have to read through on another day. And while I absolutely appreciate that the firmware can be updated (meaning the device gets better and better over time), this makes me think that not as many people will update their BB3 and they won't do it as frequently as they would otherwise. HOWEVER, as I said, I haven't gone through the procedure, maybe it's already very quick 'n easy and half of my critic here is not right. Would be great! Still want that SD update :P
Case/Mechanical/Assembly:
- I did not count the screws at the beginning but I know I missed one black screw when I was done. For some reason I have 6 of the silver screws left. Haven't found a hole where they'd be missing... That aside, I do think there should be 1 spare screw of both types, possibly even a third of the longer black ones. Since there're only 2 (3) different screw types, this shouldn't add too much cost and would help in case you loose one. Especially since quite a few BB3 users will open their case again to upgrade/change the modules - another chance to loose a screw. I thought about this when I realized there were no extra screws. And I really wished it when I realized I missed one. Don't want to blame anyone but I assembled it on a clean table with a clean, white floor underneath and I can not find it. So yeah, I'm probably blind. :palm:
- The screws that hold the display are rusted...? Is that normal?
- About half of the threads in the case had paint in them which made it pretty hard to force the screw in. At least they won't get lose! Don't know if this can be avoided or not; just wanted to note it.
- The top case is slightly bended (higher in the middle); it can be pushed down about 2mm. Additionally, because it's screwed down on only two axes (left and right on the same place), the top part can be slightly pushed forwards/backwards and doesn't line up with the bottom part. Both things are purely cosmetic and no real issues but IMO this does not match the quality and feeling of the other parts. Take the bottom half; that one feels rock solid. Second reason for brining it up: both things could be fixed with one minor change I think: add 1 screw between front panel and top case, and 1 between back panel and top case. This should not only prevent the forward/backward fexibility but also hold the top piece down properly for an overall even more rigid feeling.
- The cable for the fan is about 3cm too short? I can't put it the way as shown in the assembly manual. If I put it from the connector down between the DC/DC converters and the heatsink, there's not enough length to put it against the backplate; it goes straight to the fan. (think of a triangle. hypotenuse is shorter than the other two sides together). Is this meant to be like this? Again, doesn't cause any issues I think but didn't seem right to me...
- A true detail: Every word on the front panel and on the module front panels has the first letter in upper case - as I'd expect it. Except of two things: SD card, which is fine IMO, and "Open hardware / open source". The second open in lower case does not look right to me; doesn't match the first one. You dont write "Dual sync buck" instead of "Dual Sync Buck" either. Not 100% sure if the "hardware" and "source" should be upper case, too, but at least the two "open" must be equal IMO. As I said, a detail, but one I'll see every single time I use the BB3 - which will hopefully be very often ;)
The Rotay Encoder
Now this one deserves its own section in my post because it was honestly the biggest disappointment. From your videos I can see that you don't use the encoder that much and prefer the keypad. I tried both and the encoder is really the thing that suits me the best. I'm sure this is very individual and every one will come up with a different habit that seems perfect to him/her. The most natural feeling way for me is touch the value, turn the knob. I don't use the keypad, I don't use the knob's push button to cycle through the values. What made it even more disappointing is that I absolutely believe that it could be possible to set values very fast. Like "I don't miss the 4 potentiometers from my analog supply at all" kind of fast. So here we go with my issues...
- For some reason the encoder does not sit straight. This means that the knob is too close to the front panel in one point and depending on how I turn it, scratches over the front panel. This feels really really cheap. I might even open it again and try to resolder the encoder to fix this.
- The knob sits rather loose on the encoder shaft. Being a big know makes it look even worse. Again, very cheap feeling to me.
- The encoder itself has no decent ticks but feels rather soft and spongy - again, a big knob doesn't help. Big knob = large radius = large lever arm => soft spongy ticks feel even more soft.
- The velocity control does not work at all for me. So I did play quite a bit with it and here's the issue (I think): the velocity increases only after about half a turn. If you turn the knob a quarter turn you won't get very far no matter how fast you do it. However, if I turn the knob with two finger, half a turn is the most I can turn it; usually more like 1/3 of a turn. If the knob was smaller, it would be more; maybe someone with bigger hands can turn this big knob a full turn but I cant. Same thing if you turn it with one finger by putting it on the side; you get about 1/3 of a turn.
So for my usual way(s) of using a knob velocity control is de facto inactive, making the knob de facto useless.
The only way to really get velocity control is to put one finger on the front of the knob and turn around (which includes slipping off). Then you can turn it a full revolution (before slipping of) and velocity control becomes veeery visible. But as described above; for the way I use a knob this is much too late.
Bottom line: please adjust the velocity control such that you can easily get across the range with 1/3 turns. I know it's possible. And I'm pretty sure some knobs I've used recognize when you to multiple quick movements (like you usually do with two fingers), and don't restart for every 1/3 turn at "zero velocity". One might say they have a bit more inertia.
- Even worse: If I have the velocity settings not at maximum (gets worse the lower you go), I can turn the knob and individual steps don't do anything anymore. I can turn the knob a whole revolution without changing the value. I think 1 tick should always do something.
Using BB3 and its UI (reminder: v1.0!)
- While I said above that I do think it's well made in most parts, it does make a ... convoluted? impression. Even though I know what is what, the overview with the 4 channels (I have 2x DCP405 + 1x DCM220) does somehow not look "clear", "stuctured". I honestly can't tell you why.
- When I tested it for the first time I turned on Channel 1 (first DCP405); fine. Tipped on channel 2 (second DCP405) - and I get a warning that its not calibrated. Okay, no worries, let's do it - but nooo I can't. This thing comes out of the box with a cal password. Okay, it's nice to have that option, but the few people who need this, will find the option because button for changing the cal password sits right next to the button for the main password - no chance to miss it. But everyone else (and seriously, how many people really want this?) has additional work with this. And especially during the very first "hands on", I shouldn't have to search through the manual for some default password... Even worse - I can't remove the thing? I can't leave the password blank when changing it? Might someone explain, why I, as a private user, would need to be forced to password protect the calibration routine?
- This point I'll bet that it's been fixed by now: There's the Settings point "Encoder & User sw" but I don't see any settings for the user sw? Maybe I'd have to read through the manual in detail but so far I haven't found any option or setting for that switch.
- I kinda mentionned it in the positive points but that beep thingy sounds "not good"; rather cheapish-annoying. Might be highly subjective; maybe other users like it.
- Now this is serious IMO. Using the DCP405 modules (happens with both of them). When I have the current limit at 8mA or lower and I short the output, it does not recover correctly after removing the short. Voltage was around 10V, but doesn't seem to matter. What happens is that the voltage stays slightly below the set value (f.ex. 11.5V instead of 12V) and the CC LED remains on. Current stays at the limit until I increase it to about 10mA or higher. Only then the current will drop back to 0 and I can decrease the limit again. MAYBE this a soldering fault on both of my modules...? One of them hat 2 capacitors that fell of the board, and a third one with a bad solder joint. Additionally I just noticed that that module must have at least one more bad solder joint, because the CC LED started flickering, and reacts if I knock on the case. Any ideas? That aside, the issue that it does not recover after entering current limiting mode is equally present on the other DCP405 module. I couldn't find any bad solder joints on that one but maybe I missed something?
Okay, finally, I'm done (or forgot the remaining points). If you read through all of this, I do hope it's useful. Thank you for all of your work, and in case all of this sounds too negative, you should know that I don't regret to have opted for the BB3 and would do it again. :)
Max
Massive thanks Max, for massive feedback. That is what we need. Seems to me that you are a perfect beta tester! I would love to get a similar review in a timely manner in the future.
I don’t know if it makes sense to answer every point so I would make some summary.
The complete enclosure design is a big disappointment considering that the same manufacturer made the enclosure for the previous project (H24005) and this was supposed to be a simple upgrade. Unfortunately that did not happen. I don’t know if it makes sense to say how much time and money was spent and prototypes made to end up getting something so mediocre.
You yourself have already noticed some things, such as rusty studs for the display frame because an aggressive cleaner was used in preparation for painting. I’m sorry I didn’t have the opportunity to deliver something better.
Your comments about the website are accurate. I can't say anything other than that the website requires a complete redesign that will, among other things, take better care of mobile browsers. This includes the download procedure, for which we use the Joomla extension in which everything is so complicated.
We will probably have to hire an external company for that, because we cannot do it alone at the moment.
The things we will pay attention to is definitely the encoder whose support is weak and not in line with everything else that has been done so far. The second thing we will work on is definitely further simplification of the system (master) firmware download procedure.
I have already answered the User Sw menu question, but I repeat here: to enter, press and hold User sw until the menu appears (see Section 9.8 (https://www.envox.hr/eez/eez-bench-box-3/bb3-user-manual/9-system-functions.html#bb3_man_user_sw)).
In the end, I can say that I cannot repeat the behavior of DCP405 that you mention. To reproduce the problem I will need more details about the procedure, maybe some short video if it is not a problem?
-
Hi all,
Based on the latest firmware (MCU) here are my initial thoughts of the BB3 GUI.
1. The encoder acceleration takes a bit of gettiong used to. Set it quite low and not much happens. Set it high and as you rotate the encoder with one quick action you might go up or down say 0.3V......but the acceleration only seems to come into play when you rotate the encoder again....i.e. it's that gap between rotating once and rotating it again that governs when the display should jump in much bigger steps. I am thinking there must be a better way for this.....it is really frustrating to use.
2. The encoder know is too big and too close to the User SW. I have lost count the number of times I have rotate the knob but accidentally hit the button whist doing so. I fitted my own, small diameter knob.
3. When using the encoder it's quite hard on the eyes to see the setpoint (Vdc) display change, i.e.:
25V
25.005
25.01
25.015
25.02
The readout jumps from side to side as it centre justifies all the time. It would be better to have the XX.XXX at all times. No digit blanking, and perhaps left justify maybe.
Personally, I would like to be able to only allow 0.1Vdc steps when using the encoder, but make this selectable in config for those that want max resolution.
4. Similarly, for the Vdc feedback, you can get the following on the display
8.1
8.015
8.005
8.00
or, indeed:
37.01
37.005
37
So, there's inconsistency here.......
5. The touchscreen buttons are probably a little on the small side, not much can be done about that I guess......but maybe nding problem, obviously something is not done well because there is no reason to accept 40.000001 and not accept 40.000002. It must reject both. Reported as issue [ua larger LCD next time.
6. Entering Voltages using the keypad, 40.1Vdc of course is not accepted, neither is 40.000002.......but 40.000001 is accepted?
So far though I am really liking the BB3.......hopefully it will become my primary PSU.
UPDATE: Just saw your post about USER SW.......fixes the XX.XXX issue for the most part, but would still like to see XX.X on the voltage setting for instance. at the moment it goes 14.8, 14.9 then 15. I think should be 15.0.
Ian.
As I already answered @MaxZ encoder functionality needs to be improved. Not much has been done on it because I don’t use it much, but that’s by no means an excuse. I opened a new issue for further discussion and tracking (#72 (https://github.com/eez-open/modular-psu-firmware/issues/72)).
Thanks for issue #6! I like such details. Although this is a rounding problem, obviously something is not done well because there is no reason to accept 40.000001 and not accept 40.000002. It must reject both. Reported as issue #73 (https://github.com/eez-open/modular-psu-firmware/issues/73).
-
- The cable for the fan is about 3cm too short? I can't put it the way as shown in the assembly manual. If I put it from the connector down between the DC/DC converters and the heatsink, there's not enough length to put it against the backplate; it goes straight to the fan. (think of a triangle. hypotenuse is shorter than the other two sides together). Is this meant to be like this? Again, doesn't cause any issues I think but didn't seem right to me...
I forgot to comment on this. My fan cable looks like this:
(https://i.imgur.com/WyRZTWB.jpg)
We just added a Molex connector to the original cable. Do you think it should be even longer? Extending the cable would be too complicated.
-
Hi prasimix,
Thanks for the response to my feedback! If it helps I‘m more than willing to test new features if I find the time to do so.
I guess in that case you‘d prefer another way of communication than this forum thread...? Especially since there‘re now 200 people with issues that may post here.
Kinda good to hear that you could not reproduce the issue with the DCP405; this probably means it‘s not a general design flaw and rather an issue with my specific modules.
here‘s the video of the DCP405 modules which don‘t recover. It unvoluntarily features the knob again... you‘ll see what I mean. Btw I could not reproduce the flickering CC LED that seemed to be caused by a bad solder joint.
https://youtu.be/QlECKDh7nF0
Since I was already recording I thought I‘d record my issues with the rotary knob, too.
https://youtu.be/oOLDDVv1HUU
Considering the fan cable: I attached pictures of my cable when trying to put it down as seen in the instructions. It‘s just long enough to get down to the bottom. If it was possible I‘d lile to see a little more length there because I feel like the other cables (whose leghts are good btw!) could possibly push against this one, putting it under stress. But seriously, it may be just fine. Since an extension of the cable is indeed a lot of work, it might be possible to „mirror“ the PCB, putting the connectors at the bottom instead of the top? That would give the few centimeters I‘m looking for. This however comes at the expense of worse accessibility of the connectors... It‘s something I‘d have to spend a bit more time on, maybe try it out. Hard to judge without opening it again.
Edit: Sorry for them being upside down... hate jpeg auto/not-auto rotate issues.
Kind regards,
Max
-
Hi prasimix,
Thanks for the response to my feedback! If it helps I‘m more than willing to test new features if I find the time to do so.
I guess in that case you‘d prefer another way of communication than this forum thread...? Especially since there‘re now 200 people with issues that may post here.
Right, it should be a different arrangement and you should have on disposal new things that need to be examined.
Kinda good to hear that you could not reproduce the issue with the DCP405; this probably means it‘s not a general design flaw and rather an issue with my specific modules.
here‘s the video of the DCP405 modules which don‘t recover. It unvoluntarily features the knob again... you‘ll see what I mean. Btw I could not reproduce the flickering CC LED that seemed to be caused by a bad solder joint.
https://youtu.be/QlECKDh7nF0
This is definitely not a normal behavior. Even with down-programmer disabled it should go down to zero fast. Ok, I'm testing with the latest firmware but that should not make a difference. That issue requires more examination.
Since I was already recording I thought I‘d record my issues with the rotary knob, too.
https://youtu.be/oOLDDVv1HUU
I'm sharing your frustration about encoder (Bourns) + knob, and I’ve been living with it for a few years now! The fact is that I did not find a satisfactory combination of knob and encoder. Tolerance is unacceptable, almost 1 mm. I remembered my Denon receiver that I paid a small fortune few years ago. I can tell you the tolerance of his knob is no better, but that doesn’t comfort me. If you or someone else knows about quality encoders and knobs, I would love to try a new combination.
Since an extension of the cable is indeed a lot of work, it might be possible to „mirror“ the PCB, putting the connectors at the bottom instead of the top? That would give the few centimeters I‘m looking for.
It's not that simple because on the AUX PS we have mains voltage and traces towards the power switch go along the bottom edge. I can't put a fan connector down there.
-
As I already answered @MaxZ encoder functionality needs to be improved. Not much has been done on it because I don’t use it much, but that’s by no means an excuse. I opened a new issue for further discussion and tracking (#72 (https://github.com/eez-open/modular-psu-firmware/issues/72)).
Thanks for issue #6! I like such details. Although this is a rounding problem, obviously something is not done well because there is no reason to accept 40.000001 and not accept 40.000002. It must reject both. Reported as issue #73 (https://github.com/eez-open/modular-psu-firmware/issues/73).
Just to add for completeness on the encoder issues:-
1. There seems to be a change of direction issue with the encoder....i.e. if turning up the way and you decide to turn it down it takes an extra couple clicks on the encoder to reach the same value.
2. I have set the encoder steps to 100mV and so would expect to have one click per 100mV.....but some clicks don't change anything.
Other than that, could you add 0.5V for a valid step change. I for one would find that useful as 100mV maybe too small, 1V too big.
Ian.
-
Thanks, I updated #72 with your latest comments, and yes, we can add 0.5 V step. You can expect some progress about encoder issues very soon!
-
I'm sharing your frustration about encoder (Bourns) + knob, and I’ve been living with it for a few years now! The fact is that I did not find a satisfactory combination of knob and encoder. Tolerance is unacceptable, almost 1 mm. I remembered my Denon receiver that I paid a small fortune few years ago. I can tell you the tolerance of his knob is no better, but that doesn’t comfort me. If you or someone else knows about quality encoders and knobs, I would love to try a new combination.
I designed a product a couple of years ago which used a bourns 24PPR encoder......and had exact same frustrating 'slap' issue.
Bourns PEC12R-4222F-S0024
Bourns PEC11R-4015F-S0024
Some of them have plastic shafts, others have metal ones.......if I remember correctly the metal shafted ones had a little less slap and were a drop in replacement. Might be worth looking at.
Ian.
-
Hello again,
Kinda good to hear that you could not reproduce the issue with the DCP405; this probably means it‘s not a general design flaw and rather an issue with my specific modules.
here‘s the video of the DCP405 modules which don‘t recover. It unvoluntarily features the knob again... you‘ll see what I mean. Btw I could not reproduce the flickering CC LED that seemed to be caused by a bad solder joint.
https://youtu.be/QlECKDh7nF0
Sorry, I forgot to mention that today I updated* to v1.3.2. So the video was made with v1.3.2 and the issue is still there, exactly the way it was with v1.0.
Updating was thankfully easier than I feared. Since I don't want to put another tldr post here, I'll save that (and other) feedback for another day and place ;)
Since an extension of the cable is indeed a lot of work, it might be possible to „mirror“ the PCB, putting the connectors at the bottom instead of the top? That would give the few centimeters I‘m looking for.
It's not that simple because on the AUX PS we have mains voltage and traces towards the power switch go along the bottom edge. I can't put a fan connector down there.
I am aware of this (or misunderstand the issue you describe). Hence I suggested to mirror the whole PCB instead of just moving the fan connector. So not only would the fan connector go to the bottom, but the mains voltage traces would at the same time go to the top. I know that this might not be possible because components can't be mirrored and not every component is symmetrical like a resistor. It was an idea, no more. And as I said, I'd need to have a look at more details of the layout of the PCB and the case to judge whether it is feasible or not. But honestly, I didn't want to dig that deep into it for now. Especially since I'm not even sure the cable is truly too short, which is the very first thing I'd check before thinking about any kind of redesign. The next time I open it up (which will probably be soon because of the DCP405 issues), I'll have another detailed look at it and give more precise feedback.
Kind regards,
Max
-
I'm sharing your frustration about encoder (Bourns) + knob, and I’ve been living with it for a few years now! The fact is that I did not find a satisfactory combination of knob and encoder. Tolerance is unacceptable, almost 1 mm. I remembered my Denon receiver that I paid a small fortune few years ago. I can tell you the tolerance of his knob is no better, but that doesn’t comfort me. If you or someone else knows about quality encoders and knobs, I would love to try a new combination.
I designed a product a couple of years ago which used a bourns 24PPR encoder......and had exact same frustrating 'slap' issue.
Bourns PEC12R-4222F-S0024
Bourns PEC11R-4015F-S0024
Some of them have plastic shafts, others have metal ones.......if I remember correctly the metal shafted ones had a little less slap and were a drop in replacement. Might be worth looking at.
Ian.
The choice of encoder is further narrowed because an angled version is required. What you sent are "straight" versions.
-
I am aware of this (or misunderstand the issue you describe). Hence I suggested to mirror the whole PCB instead of just moving the fan connector. So not only would the fan connector go to the bottom, but the mains voltage traces would at the same time go to the top. I know that this might not be possible because components can't be mirrored and not every component is symmetrical like a resistor.
A complete mirror would also require moving down the IDC 16-pin connector which would complicate the connection to the MCU module.
-
Opened it up again, the fan cable is fine as long as you do not put it inbetween the heatsink and the DC/DC module as shown in the assembly instructions. If you do that, it'll not quite reach to the case, meaning it will stay under stress.
Thinking about the DCP405 issue... Since both modules show the exact same issue, is it possible that the actual problem is on another board, affecting both modules at the same time? Thought this would be more likely than having two modules fail in the exact same way...
EDIT: in a couple days I should have access to my IR camera again so maybe I‘ll find out where the power is dissipated.
Kind regards,
Max
-
A BB3 arrived here in Sweden today. Dropped off at my door just after lunch today having left Texas on the 14th.
Assembly now started ;)
Oops, failed on step 2. Missing one J, have 5 or so extra L ...
So I left out the middle stud on the AUX-PS board as that seemed to be the one least necessary and easiest to add later.
But this time I failed on step 9. Nothing happens at all when I turn on the (nice) switch. Nothing on the screen at all and complete silence.
The fuses in the IEC connector are ok, cable F has the correct orientation and the flat flex cable also is as deep in as it can go.
-
A BB3 arrived here in Sweden today. Dropped off at my door just after lunch today having left Texas on the 14th.
Assembly now started ;)
Oops, failed on step 2. Missing one J, have 5 or so extra L ...
So I left out the middle stud on the AUX-PS board as that seemed to be the one least necessary and easiest to add later.
But this time I failed on step 9. Nothing happens at all when I turn on the (nice) switch. Nothing on the screen at all and complete silence.
The fuses in the IEC connector are ok, cable F has the correct orientation and the flat flex cable also is as deep in as it can go.
Remove 16-pin IDC cable and check if standby LED is active when turn power on. Few other backers reports that cable failure. Also you should hear fan is spinning for a few seconds after the power is turned on.
-
Opened it up again, the fan cable is fine as long as you do not put it inbetween the heatsink and the DC/DC module as shown in the assembly instructions. If you do that, it'll not quite reach to the case, meaning it will stay under stress.
Thinking about the DCP405 issue... Since both modules show the exact same issue, is it possible that the actual problem is on another board, affecting both modules at the same time? Thought this would be more likely than having two modules fail in the exact same way...
EDIT: in a couple days I should have access to my IR camera again so maybe I‘ll find out where the power is dissipated.
Kind regards,
Max
I would rather suspect the DCP405 modules themselves. Can you check if the same problem exists when the current range is set to High (see Section 11.5.1 (https://envox.hr/eez/eez-bench-box-3/bb3-user-manual/11-special-channel-functions.html#bb3_man_ch_advanced_options))?
-
I would rather suspect the DCP405 modules themselves. Can you check if the same problem exists when the current range is set to High (see Section 11.5.1 (https://envox.hr/eez/eez-bench-box-3/bb3-user-manual/11-special-channel-functions.html#bb3_man_ch_advanced_options))?
No, can't get the issue when setting it to high range. Going down in the 10s of uA range makes the CC LED pulse slowly. If it wasn't a fault it would actually be a nice "heartbeat effect": https://www.youtube.com/watch?v=qouWOPiXFGA (https://www.youtube.com/watch?v=qouWOPiXFGA)
The limit values were only reduced to get a better visibility on the graph. They don't seem to affect the behavior.
Maybe this slowed down version helps diagnosing the behavior. If I can provide any other information, please tell me!
Kind regards,
Max
-
<snip>
So I left out the middle stud on the AUX-PS board as that seemed to be the one least necessary and easiest to add later.
But this time I failed on step 9. Nothing happens at all when I turn on the (nice) switch. Nothing on the screen at all and complete silence.
The fuses in the IEC connector are ok, cable F has the correct orientation and the flat flex cable also is as deep in as it can go.
Remove 16-pin IDC cable and check if standby LED is active when turn power on. Few other backers reports that cable failure. Also you should hear fan is spinning for a few seconds after the power is turned on.
Ah, yes, that gives fanspin and a green standby LED. Thanks!
I had removed the AUX-PS board and was checking it out and I could not find anything that was wrong (without connecting AC power that is), even the power button checked out ok.
I will bring out suitable probes and check that cable in detail...
-
<snip>
<snip>
Remove 16-pin IDC cable and check if standby LED is active when turn power on. Few other backers reports that cable failure. Also you should hear fan is spinning for a few seconds after the power is turned on.
Ah, yes, that gives fanspin and a green standby LED. Thanks!
I had removed the AUX-PS board and was checking it out and I could not find anything that was wrong (without connecting AC power that is), even the power button checked out ok.
I will bring out suitable probes and check that cable in detail...
Ah yes, all pins are connected to all other pins, probably not what was intended :-DD
The attached image is a bit fuzzy, but it can be seen that the cables are not in their "grove" but rather right in between so the "knifes" or whatever one wants to call them cuts through the cables on either side of it so everything gets connected together. Quite an achievement that...
If this was a TME part it probably is not the best place to get a replacement?
-
<snip>
<snip>
Remove 16-pin IDC cable and check if standby LED is active when turn power on. Few other backers reports that cable failure. Also you should hear fan is spinning for a few seconds after the power is turned on.
Ah, yes, that gives fanspin and a green standby LED. Thanks!
I had removed the AUX-PS board and was checking it out and I could not find anything that was wrong (without connecting AC power that is), even the power button checked out ok.
I will bring out suitable probes and check that cable in detail...
Ah yes, all pins are connected to all other pins, probably not what was intended :-DD
The attached image is a bit fuzzy, but it can be seen that the cables are not in their "grove" but rather right in between so the "knifes" or whatever one wants to call them cuts through the cables on either side of it so everything gets connected together. Quite an achievement that...
If this was a TME part it probably is not the best place to get a replacement?
Send me your address, and I'll send you a new cable. TME has one but it is a little bit longer 15 cm: https://www.tme.eu/hr/en/details/fc16150-s/ribbon-cables-with-idc-connectors/amphenol/ (https://www.tme.eu/hr/en/details/fc16150-s/ribbon-cables-with-idc-connectors/amphenol/)
-
I would rather suspect the DCP405 modules themselves. Can you check if the same problem exists when the current range is set to High (see Section 11.5.1 (https://envox.hr/eez/eez-bench-box-3/bb3-user-manual/11-special-channel-functions.html#bb3_man_ch_advanced_options))?
No, can't get the issue when setting it to high range. Going down in the 10s of uA range makes the CC LED pulse slowly. If it wasn't a fault it would actually be a nice "heartbeat effect": https://www.youtube.com/watch?v=qouWOPiXFGA (https://www.youtube.com/watch?v=qouWOPiXFGA)
The limit values were only reduced to get a better visibility on the graph. They don't seem to affect the behavior.
Maybe this slowed down version helps diagnosing the behavior. If I can provide any other information, please tell me!
Kind regards,
Max
Ok, so there is a good chance that something is not soldered properly (or something dropped off) in current control loop section. Perhaps R62, IC21, etc. Please let me know if you can spot anything suspicious, otherwise we could organize repair. Sorry for that.
-
Mh haven‘t spotted any issues so far... I did gently push a few suspicious components with a screwdriver but nothing moved.
I took pictures of the area; I dont have a microscope for this so my phone had to do the job. Far from perfect but maybe not completely useless. This is btw. the left/first module (the one I already had to solder on).
Thumbs up for the shematic as PDF which I could search through for the component. Would be great to have a PDF of the PCB as well - or did I simply not see it?
Edit: Those faston connectors of the ground wires are probably the tightest ones I‘ve ever had. I can‘t unplug the one of the second DCP405 module with my fingers. I don‘t have slippery fingers at all; if I pull harder I‘ll just hurt myself. So yeah; will have to use pliers... Just to get this right, I totally agree that they should by no means sit or become loose. However I don‘t think this is a connector thats made to be used with pliers and I also worry about putting that much mechanical stress on its solder joints...
Kind regards,
Max
-
Thumbs up for the shematic as PDF which I could search through for the component. Would be great to have a PDF of the PCB as well - or did I simply not see it?
PCB top and bottom side generated by OSHPark can be found in Images (https://github.com/eez-open/modular-psu/tree/master/dcp405/Images) folder.
Thanks for pictures, that section look good, question is does IC21 is working properly. Another section of interest is around IC10. It is possible that some of the components do not have a good value. That “heartbeat” looks like some oscillation when it’s in the low range and it’s possible that something is wrong with the compensation on those modules.
-
For the voltage not reaching the set value in the low current ranges, it could be some kind of oscillation. With some 5 mA this could be faster, so it would not be visible as a heart beat, but still cause the on average lower voltage.
It may be worth checking the current reading in the low range - it could be a problem with the shunt switching so that the low shunt has not connection.
The down-programmer could be an error source that could be turned off for a test.
With 2 such broken boards the test procedure should ideally include a test that could detect such a failure. With better solder quality such errors are less likely, but one never knows.
-
Good point @Kleinstein, one of the possibility is that driving of Q10 is faulty, and when in low range mode current flows via D14 on which voltage drop is higher then on Q10 and CC compensation is not effective.
-
With 2 such broken boards the test procedure should ideally include a test that could detect such a failure. With better solder quality such errors are less likely, but one never knows.
We'll definitely need to include more testing for low range mode.
-
Thumbs up for the shematic as PDF which I could search through for the component. Would be great to have a PDF of the PCB as well - or did I simply not see it?
Hi Max you can try this gerber view
https://tracespace.io/view/?boardUrl=https://kitspace.org/boards/github.com/eez-open/modular-psu/dcp405/dcp405-f688500-gerbers.zip (https://tracespace.io/view/?boardUrl=https://kitspace.org/boards/github.com/eez-open/modular-psu/dcp405/dcp405-f688500-gerbers.zip)
This is also amazing software, but someone would need to add boards and calibrate them...
https://www.inspectar.com/ (https://www.inspectar.com/)
-
Hi,
I got intrigued by the bad heartbeat issue and powered up my BB3 to have a test, and made a short video of my experience.
https://youtu.be/649JsJ7pv3g
Ian.
-
Thanks for the inputs!
Unfortunately the pictures and the gerber viewer don't serve the purpose I had originally in mind. This being a completely unknown PCB to me, I wanted to search for the component name to find it quickly. Not very important though.
Looking at IanJs video I note a few things:
* he has a similar issue, although at lower currents.
* Recovery goes very fast until it almost reaches the set voltage, then it takes considerably more time. Is that normal...? At least that's something I can't see on mine. But I can't go that low in current without hitting the heartbeat issue either...Edit: Sure, same behavior on mine, too. Still: is that normal?
* We're now at at least 3 DCP405 with pretty much the same issue ??? @IanJ: how about your other DCP405?
Progress on my side!
As far as I can see I have no missing component on the entire board when comparing it to the PCB images on GitHub. For quickly checking component orientations it would be nice to have a high resolution picture without heatsink.
Disabling the down-programmer "solves" the issue! I attached two screenshots that show the output voltage after enabling the output, one with down-programmer enabled, one with it disabled.
Kleinstein suggested to change the current reading to the lower range, too. I don't know how to do that? I have set the DCP405 explicitly to the 50mA current range but I'm still getting only 0.5mA resolution on the read out value - even if my set value is 10uA.
Kind regards,
Max
-
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.
-
Update: Disabling the down programmer removed the oscillation but unfortunately did not completely solve the issue... Enabling the output with 10V/20uA makes the output rise linearly (CC LED only) up to 9.76V, where it'll stop with both CC and CV LEDs on. Not sure but this seems to match Kleinsteins explanation(?)
Kind regards
Max
-
@Kleinstein diagnosis is accurate, the issue is related to Q27 which was subsequently added (hence the high designation number) to prevent overshoot while still maintaining a high rising time when the voltage increases. This in combination with the down-programmer generates a problem at low set currents. We can solve this part in software by turning off the down-programmer at very low currents (where it doesn't make much sense).
EDIT: question is what current level to set as a threshold for deactivating down-programmer.
EDIT2: This issue exist only in low current range.
-
As I said just before: this would remove the oscillation, but does not solve the issue with the output voltage not recovering completely...
Update: Disabling the down programmer removed the oscillation but unfortunately did not completely solve the issue... Enabling the output with 10V/20uA makes the output rise linearly (CC LED only) up to 9.76V, where it'll stop with both CC and CV LEDs on. Not sure but this seems to match Kleinsteins explanation(?)
Kind regards
Max
-
How does the voltage output look with a scope - chances are in the non working CC/CV cross over case there would be some kind of oscillation, that may be a little to fast to be seen with the integrated voltage and current readings.
For a test if Q27 is part of the problem one could remove R118 or solder a bridge over Q27 (would make the voltage setting some 10% lower). As a side effect there may be more voltage overshoot - so it is not a final solution, just for testing. It would than need a different solution (e.g. larger value for C47, maybe C44+R51 instead of C46 or some limit to the output of IC9A) to limit voltage overshoot.
Because of the other expected issue (problem if the current limit needs the voltage to drop just a little), we may need an alternative to Q27 anyway.
-
Well after reading this i had to check mine and i can confirm that it acting the same on both modules. It doesnt recover if current is set below 7mA. I tried with the 100ohm resistor on output and it is the same. Disabling the down programmer eliminates this.
What i dont understand is, what hapened to my DMM. It was connected in series and i it blew the fuse!! When this happened, the voltage was set to 24V and current to 5,5mA, with down programmer disabled.
It is a Fluke 179 with the 440mA fuse (genuine one, as the meter was never opened before - i am the only one who uses it)...
-
@Kleinstein: No oscillations as far as I can tell. However, [edit]during ramp up and[/edit] when it is stuck in this CC/CV crossover, I do pick up more 50Hz noise (20mVpp, while open circuit [positive cable disconnected from BB3] noise is 40mVpp). Once it‘s in CV mode the noise is gone. A little bit strange but nothing I worry about; its not the job of the power supply to get rid of noise from unshielded lab cables.
@elekorsi: since it‘s not an assembly fault probably all DC405 modules are to some extend affected by this issue.
Kind regards,
Max
-
Well after reading this i had to check mine and i can confirm that it acting the same on both modules. It doesnt recover if current is set below 7mA. I tried with the 100ohm resistor on output and it is the same. Disabling the down programmer eliminates this.
What i dont understand is, what hapened to my DMM. It was connected in series and i it blew the fuse!! When this happened, the voltage was set to 24V and current to 5,5mA, with down programmer disabled.
It is a Fluke 179 with the 440mA fuse (genuine one, as the meter was never opened before - i am the only one who uses it)...
So far I managed to blow 440 mA fuse only during the calibration when forgot to switch DMM input terminal when switch from low to high current range when second point is about 4.5 A :(
-
So far I managed to blow 440 mA fuse only during the calibration when forgot to switch DMM input terminal when switch from low to high current range when second point is about 4.5 A :(
Jep... I know what you mean... It might be a good idea to show a warning, or even simpler and inherently safe: swap the order; starting with 4.5A first, and then going down to 45mA (can't remember the exact value). It is a tiny bit counter intuitive since we want to start at the left and go up step by step but if this comes at the expense of half of the user blowing their multimeter fuses...
Kind regards,
Max
-
I understand this, but to me it happened when the current was set to 5,5mA, not during calibration or any other misstake with the high current setting.
-
I understand this, but to me it happened when the current was set to 5,5mA, not during calibration or any other misstake with the high current setting.
That could happen only if DCP405 has serious fault in CC control loop. If that is a case you can check that with same setup and DMM set to 10 A. It should notice 400+ mA current.
-
I understand this, but to me it happened when the current was set to 5,5mA, not during calibration or any other misstake with the high current setting.
That could happen only if DCP405 has serious fault in CC control loop. If that is a case you can check that with same setup and DMM set to 10 A. It should notice 400+ mA current.
For info,
With a couple of small test cables and a 500mA fuse, and setting the BB3 to 40V/50mA I can blow the fuse if I touch the cable off and on a few times.
With a 1A fuse I can see the fuse wire within the glass move and return to centre when I attach the leads.
Touch the leads togeher without a fuse and you'll get lots of sparks.
CC mode reaction time, cable inductance, back EMF......not entirely sure but all my bench PSU's do this. There is a lot of energy to dissipate.
(https://www.ianjohnston.com/images/stories/IanJ/eevblog/fuse.jpg)
Ian.
-
Hi everyone,
...
- The cable for the fan is about 3cm too short? I can't put it the way as shown in the assembly manual. If I put it from the connector down between the DC/DC converters and the heatsink, there's not enough length to put it against the backplate; it goes straight to the fan. (think of a triangle. hypotenuse is shorter than the other two sides together). Is this meant to be like this? Again, doesn't cause any issues I think but didn't seem right to me...
...
Max
Figures 1 and 32 (https://envox.hr/eez/eez-bench-box-3/eez-bb3-building-instructions/bb3-kit-assembly-instructions.html) show the fan rotated 90 degrees clockwise.
The fan leads are on the left side, not the bottom side.
-
CC mode reaction time, cable inductance, back EMF......not entirely sure but all my bench PSU's do this. There is a lot of energy to dissipate.
Not really understand this: you mean DCP405 behave differently or similar to your other PSUs?
We have a 33 uF elco on output that needs to be discharged and it is generally better to use OE ON/OFF control than direct load connection.
-
CC mode reaction time, cable inductance, back EMF......not entirely sure but all my bench PSU's do this. There is a lot of energy to dissipate.
Not really understand this: you mean DCP405 behave differently or similar to your other PSUs?
We have a 33 uF elco on output that needs to be discharged and it is generally better to use OE ON/OFF control than direct load connection.
Yes, the DCP405 is the same as my other bench PSU's........so I don't really see a problem and it's probably why fuses such as the 440mA DMM fuse mentioned earlier can get blown despite setting CC to well below the fuse rating.
In my post/photo I just tried to demonstrate that.
33uF I guess would do it for sure....
Ian.
-
For the reaction of the constant current limiting there are 2 components: one is the output capacitor. 33 µF are more on the low side for a lab supply if charged to some 30 V and with low ESR it may be enough to stress a fuse. There is not very much one can do about this - the regulator needs some capacitance and the lower the capacitance the higher the chance to get overshoot in the CV to CC transition. The only thing that may get a slight improvement is from some series resistance to the large part of the capacitance - so not a low ESR cap, but more like a higher ESR one. The parallel ceramic cap is good for the highest frequencies and provides the low ESR there.
The other contribution to the current surge is from the time it takes for the regulator to react. Here it could be a slight problem that the CV loop looks quite fast compared to the CC loop. So the CV part may increase the current too much before the CC part starts reacting. Initially the OP (IC10A) from the CC loop is near positive saturation and it takes some time to discharge C55. A possible known counter measure would be to have the left side of C55 connected to the other side of the diode D13. This way the capacitor would not start from so high and the CC mode can react faster (possibly unpleasantly fast for some uses).
I don't know the size of the 2 nd contribution - it could be comparable to the output cap.
-
33uF I guess would do it for sure....
Yes, it is out of CC control loop control.
-
A possible known counter measure would be to have the left side of C55 connected to the other side of the diode D13. This way the capacitor would not start from so high and the CC mode can react faster
Hm, this is an interesting detail. I will try to test it (first to come up with some satisfactory solution on the other front (https://www.eevblog.com/forum/projects/allowed-leakage-current-and-current-harmonics/msg3282412/#msg3282412) :)).
-
I decided to check the response for CC and here are the results. First screenshot is with 100ohm resistor across the output, the second one is with 1ohm and the third one is a 1us detail of current on 1ohm. Yellow is voltage, purple is current.
When i checked the datasheet of the fuse it is clear that the fuse did exactly as expected... ;D
-
You are using OE ON/OFF control or just touch wire as @IanJ explained?
-
That was a wire touch, as i wanted to see why my fuse had blown 8)
ON/OFF method is on the bellow picture, 20mA set, 1ohm resistor across the output
-
OK, so everything is under control when it is under control :-+
-
For repetitive stress testing one can use list programming. For example, I made this simple step from 0 to 50 mA, with voltage set to max, and repeat that test 1000 times with 200 mA fuse directly connected to the power output:
(https://i.imgur.com/o2iXKln.jpg)
... and you can observe that in YT view (refresh rate is set to 5 ms, upper current limit is set to 60 mA for better current view):
(https://i.imgur.com/UusLXn2.jpg)
-
Heads up on a case grounding issue I found on my BB3. Seems the nice paint does too good of a job being an insulator! (details, details).
I posted a blog:https://gojimmypi.blogspot.com/2020/10/envox-eez-bench-box-3-ground.html (https://gojimmypi.blogspot.com/2020/10/envox-eez-bench-box-3-ground.html) on how I scraped a bit of the paint off of the case at the standoffs and added a wired connection to improve ground safety.
-
Hi all,
Possible small issue on Current reading on display (actual Current).
When a load is disconnected, sometimes the Current display will drop down to 0A, sometimes 0mA.
You can see it jump between 0 Amps and 0 mA and seems a little random on where it actually lands.
It looks like it may be down to a calibration artefact, i.e if when the load is disconnected and the zero Current to be displayed is a little off, say -0.5mA then it will display mA.......and maybe if it is NOT off then it can land on 0A and stay there. Albeit not 100% sure about this though because I have seen 0mA exactly being displayed (but could be rounded).
Confused?.....I can easily create a video to demonstrate if req'd.
Ian.
-
Thanks Ian, message taken :). I'll add that in existing #73 (https://github.com/eez-open/modular-psu-firmware/issues/73).
-
Hi all,
Really enjoying my BB3, in the coming weeks it's going to be used extensively whilst I test a whole production run of boards.............Anyways, just another minor level issue:-
I have confirmation turned ON and use DARK mode.
After V or I entry is made and with the default "10" for Lightness the flashing yellow/white is ok, but not great. Turn the Lightness up any further and it's barely seeable. Turn it down to say "5" and it's better.
I think maybe the colours could be tweaked to make the flashing-await-confirmation much more obvious.
Also, yellow is really assigned to #1, whilst green is for #2, so wonder if yellow flashing for all confirmations on all channels is the best (just being picky here!).
PS. I have kinda settled on Brightness = 20, Lightness = 5.
Also, could you have Encoder Step (via User SW) setting retained on power up.
Ian.
-
Hi all,
Really enjoying my BB3, in the coming weeks it's going to be used extensively whilst I test a whole production run of boards.............Anyways, just another minor level issue:-
I have confirmation turned ON and use DARK mode.
After V or I entry is made and with the default "10" for Lightness the flashing yellow/white is ok, but not great. Turn the Lightness up any further and it's barely seeable. Turn it down to say "5" and it's better.
I think maybe the colours could be tweaked to make the flashing-await-confirmation much more obvious.
Also, yellow is really assigned to #1, whilst green is for #2, so wonder if yellow flashing for all confirmations on all channels is the best (just being picky here!).
PS. I have kinda settled on Brightness = 20, Lightness = 5.
Ian.
Thanks, reported as #76 (https://github.com/eez-open/modular-psu-firmware/issues/76).
-
Also, could you have Encoder Step (via User SW) setting retained on power up.
Reported as #77 (https://github.com/eez-open/modular-psu-firmware/issues/77).
-
prasimix,
With Keysight IO libraries I can query/response the BB3.....but from my own VB app I can make a valid connection but can't query the BB3 at all. I get an error responce.
I have written my own VB app but it uses an extensive GPIB library from PavelW. The IO library returns "MAV bit not set" when I try to query the BB3.
The developer of that library I remember he came across somebody else with the same issue try to connect to a DMM and offered the following repsonce at the time.
If the message is "MAV bit not set" then it is clear: your meter is not quite compliant with the 488.2 specification on the meaning of status byte bits. I explain. Polling the status byte is used here to check if the device is ready to send response, according to 488.2 this information is coded in the "Message Available" bit of the status byte, the bit 5 (so the default mask used is 16).
Keysight interactive IO works because it does not use any information from the status byte: when you hit "read" it calls the raw low-level read function which waits until it gets response. But then once a "read" is issued the whole gpib bus will remain blocked until your meter is done with the measurement - very annoying if you have more than one devices connected, especially with high NPLC where it can take seconds to respond. This software uses periodic polls to check if the data is available, before calling "read", in this way the bus remains available and the program is able to query two (or more) devices simultaneously. This is the default configuration but it can be easily disabled on per-device basis (you may do it yourself or ask Ian to add checkboxes controlling the "enablepoll" flag for each device). For a more elaborate version, the MAV masks can also be set individually for each device.
The above just my quick initial ideas as to the problem.........
I can work around it per what Pavel suggests and implement a checkbox in my app to enablepoll.........but just wondered initially your thoughts.
Ian.
Thanks for this. Martin will investigate and we'll let you know what he found. If you have a chance to get some VB sample, it could speed things up for me.
UPDATE:
I have spoken to the GPIB library developer and it turns out it appears that the BB3 implementation is raw socket connection only.
The GPIB library compatibility I have is with the more usual Visa "INSTR" devices using the standard VXI11 or HiSlip protocol.
Actually, the full list of options:
- Visa
- GPIB: ADLink
- GPIB488.dll
- Com Port
So, at the moment I am not able to control the BB3 from my own GPIB app.......unless I can look into modding the library code myself to add VB.NET TCP/IP (getting towards my limits on this and might push my knowledge of VB & GPIB!).
Ian.
-
I understand, but what's about "Com Port" that is also mentioned? Does it means USBTMC or virtual com?
Adding VXI-11, HiSlip (or LXI) we'll be considerable effort for us in this moment, maybe not if some nice open source lib are available. Perhaps we could work with GPIB library developer that you mentioned and see what he is using and what is a possiblity to work with "raw" (telnet) connection.
-
I understand, but what's about "Com Port" that is also mentioned? Does it means USBTMC or virtual com?
Adding VXI-11, HiSlip (or LXI) we'll be considerable effort for us in this moment, maybe not if some nice open source lib are available. Perhaps we could work with GPIB library developer that you mentioned and see what he is using and what is a possiblity to work with "raw" (telnet) connection.
For my purposes and having GPIB working on teh BB3 with my App it's a "nice to have"......so wouldn't want you to go out your way to spend a lot of time to implement INSTR etc.
The GPIB library developer has already told me he's got no time to implement TCP/IP socket at the moment, although you could always contact him and ask questions.....he's a GREAT guy.
https://www.codeproject.com/Articles/1166996/Multithreaded-communication-for-GPIB-Visa-Serial-i (https://www.codeproject.com/Articles/1166996/Multithreaded-communication-for-GPIB-Visa-Serial-i)
Com port = Although Visa can be used to access serial ports it was simple to write an implementation using the standard SerialPort class provided in .NET.....thus does not require any Visa resources.
"COM1:9600,N,8,1,CRLF"
I have never used the library inthis way so don't know much more than this.
Ian.
-
Hi,
When logging the brown background behing the Current display isn't full width.......or is this a dynamic display? (haven't fully tested the functionality yet).
Ian.
(https://www.ianjohnston.com/images/stories/IanJ/eevblog/logging_1.jpg)
-
Thanks Ian, it a bug. Reported as #80 (https://github.com/eez-open/modular-psu-firmware/issues/80).
-
Thanks Ian, it a bug. Reported as #80 (https://github.com/eez-open/modular-psu-firmware/issues/80).
Also, I think the brown background behind the voltage display is 1 pixel to the right.
Ian.
-
Hello,
If the user switch is set to change the encoder step this works in most places where the encoder works but not in the 'edit list' screen (running firmware v1.3.2). In this menu the encoder and pressing the encoder switch behave consistent with other screens.
[attach=1]
Jan
-
Just for info, we have a very thorough beta tester on the case. If there is a bug in the UI, he will find it, believe me :-DD
-
For Australians:
All shipping documents said that the unit would arrive tonight; I picked it up 2 days ago. Amazingly it got to Melbourne in about 3 days and then sat in limbo for a few more. Fairly typical I suppose.
Unit arrived with packaging in good condition and as expected exhibits Envox's high standards. I'm looking forward to the additional modules and perhaps an extra frame.
A word of warning though. My CPU board had its USB connector floating around inside the bag. It later jammed itself under IC4. So please, don't just blindly plug the boards in and power up - check for any manufacturing issues. Denis and Martin don't need any more heartaches due to their previous dodgy supplier.
Alan
-
A word of warning though. My CPU board had its USB connector floating around inside the bag. It later jammed itself under IC4. So please, don't just blindly plug the boards in and power up - check for any manufacturing issues. Denis and Martin don't need any more heartaches due to their previous dodgy supplier.
I had the same problem - USB connector and "boot0" button floating around where they should not be. Parts and PCB were undamaged. Solder looks granular, making me think they did not receive enough heat during reflow. Everything else was perfect, though, and it went together smoothly.
-
Well I finally got around to building my BB3. What a lovely piece of gear and the basis for a data acquisition unit I need for module testing. Denis, I need the second frame.
I'm full of admiration for Andrew McNamara. He evidently had few issues retrofitting the USB connector. With my old eyes it was no fun at all. The language was colourful and would have been educational for grandkids were they allowed to visit in Danistan - read Victoria, Australia.
I now have one DCP405 module (A) working as expected - the other (B) not so much. Switching AC-DC pre-power supplies and positions in the backplane produces the same results. That is A works and B is different.
B has a maximum output voltage of about 200mV and goes out of CV mode at about this point. Hmmm. Time to look for the circus diagrams. :scared:
-
Well I had another look. :scared:
Module B has a fixed output voltage of about 190mV. When loaded by anything the output voltage drops to zero. When the output voltage setting is increased to 190mV the module goes out of CV mode laving the output voltage at 190mV.
NOW I'll look at the circuits. :box:
-
Well I finally got around to building my BB3. What a lovely piece of gear and the basis for a data acquisition unit I need for module testing. Denis, I need the second frame.
I'm full of admiration for Andrew McNamara. He evidently had few issues retrofitting the USB connector. With my old eyes it was no fun at all. The language was colourful and would have been educational for grandkids were they allowed to visit in Danistan - read Victoria, Australia.
I now have one DCP405 module (A) working as expected - the other (B) not so much. Switching AC-DC pre-power supplies and positions in the backplane produces the same results. That is A works and B is different.
B has a maximum output voltage of about 200mV and goes out of CV mode at about this point. Hmmm. Time to look for the circus diagrams. :scared:
I'm so sorry to hear that. A couple of suggestions on where to start unless you want to arrange a replacement:
1. see if the PCB needs to be further cleaned of solder balls (some of them was so dirty!)
2. when OE is on, check directly on the gate of Q9 if you have +5 V
I presume that output current is not set to zero when you get about 200 mV.
-
I'm full of admiration for Andrew McNamara. He evidently had few issues retrofitting the USB connector.
It hasn't been refitted yet, unfortunately. I'm waiting on a friend with reflow gear and skills to have time to take a look.
-
Module B has a fixed output voltage of about 190mV. When loaded by anything the output voltage drops to zero. When the output voltage setting is increased to 190mV the module goes out of CV mode laving the output voltage at 190mV.
Hmmm... that sounds very similar to what I see with my 3 "junkyard" DC405 modules, although I expect there will be several causes for these symptoms. I haven't dug in too far yet, but two of mine show significant solder balls around the middle of the PCB. The third looks quite clean with just a few solder balls sitting in tented vias, but that could indicate some problems lurking below... :scared:
It hasn't been refitted yet, unfortunately. I'm waiting on a friend with reflow gear and skills to have time to take a look.
Andrew, I'd be happy to take a look for you - just not this weekend.
Kean
-
I know my "junkyard" DCP405 boards are not expected to work, so this is just a quick data point during some initial troubleshooting.
All three exhibit a similar problem with only 200mV max output (set for 5V 100mA), but only on one does the CV light stay on, and no CC on the one where CV goes off.
Anyway, all three show a low output voltage from the pre-regulator of about 4.7V instead of roughly double that on a good DCP405. Not sure if that is a pre-reg problem though.
Gate of Q9 is near 5V when output enabled, and 0V when disabled on all three. +/-9V and +/-5V rails are all OK as well, although the 9V rails are a bit low at around 8.6V.
Oh, and apparently the one where the CV light stays on apparently doesn't even manage to output 200mV.
I need to study the schematics more and get my head around the design... which was a large reason behind getting these. Thankfully someone published excellent documentation & design notes! :-+
-
Anyway, all three show a low output voltage from the pre-regulator of about 4.7V instead of roughly double that on a good DCP405. Not sure if that is a pre-reg problem though.
That doesn't necessary means that pre-regulator has a problem because its tracker (Q2) just follows what is on the output. Right way to check pre-regulator is to disconnect R10 from POST_OUT+ and connect it to external control voltage to see if it can output voltage that is few volts above control voltage. It also has to be enabled. If you want to do that externally, remove D1 and apply +5 V on pin 8 (RUN input).
-
That doesn't necessary means that pre-regulator has a problem because its tracker (Q2) just follows what is on the output.
Yes, I was just coming to that conclusion as I was writing the above. Getting late here though, and I have to work this weekend... but I'll try get back to it soon. Thanks!
-
OK, I fixed one. Yay! :box:
The pre-reg was fine, confirmed per instructions from prasimix although I cheated a bit just injecting 5V (from channel 1 with common ground) via 10k into base of Q2. So I became suspicious of the circuit around Q8/Q9.
Tracing the schematic while checking various things and I discovered R49 was completely missing (15R 0.75W 2010). It is part of OE circuit alongside Q9. I only had a 15R 1210 part (0.33W), but installing it gave me an output.
I tested at 50mA load from 2V to 15V and it was OK but uncalibrated. I need to reinstall the heatsink before I calibrate and run some more tests, but I think it will be good once I also replace that resistor with higher rating.
I don't think the other two will be so easy... but that is OK as I am actually looking forward to studying the control loops further.
-
It can be declared functional when you can output all 5 A (for that of course you need to put heatsink back) and DP is functional.
-
R15 should see a maximum of some 100-200 mA (mainly the base current for the output stage) and thus up to some 150-600 mW. So the smaller resistor may work, if the power transistors are relatively high in amplification. The power at the resistor goes up with the square of the output current, so some 2 A should still be on the safe side with the lower power one.
The control loop may want some more tweak. This is about the cross over between CC and CV mode. There was trouble at low currents, that could be reduced by turning of the down programmer, but it does not solve all the trouble here.
Missing parts (possibly lost on transport), bad joints and solder balls are likely the prime candidates to look for at the bad boards.
-
It can be declared functional when you can output all 5 A (for that of course you need to put heatsink back) and DP is functional.
Was trying to go home... but challenge accepted! :-DD
-
And success! :-+
Voltage calibration was really easy. It seems to now be reading within 1mV of set value from 1 to 40V (no load).
Current calibration went ok-ish, but it will need to be redone because some idiot just blew the 10A fuse in their 34465A. Doh! :palm:
I wasn't sure of the best way to test the down programmer... and it is late so I wasn't going to RTFM LOL.
So I set channel 1 to 5V 20mA and connected it in parallel with channel2 set for 4V 1A, and it was happily outputting 4V and sinking 20mA.
-
I wasn't sure of the best way to test the down programmer...
The easiest way is to set the trigger mode to list and create a simple list:
(https://i.imgur.com/jSNUDmK.jpg)
Decrease "YT view sampling rate" to 10 (or 5 ms):
(https://i.imgur.com/XqcJZkf.jpg)
Output without load connected and DP enabled:
(https://i.imgur.com/DpJURxX.jpg)
With DP disabled:
(https://i.imgur.com/dTEhUyQ.jpg)
-
A brief update on the problem I encountered with the MIO168 (https://github.com/eez-open/dib-mio168) module: the ADC ADS8674 (https://www.ti.com/product/ADS8674) used with floated inputs (when nothing is connected to them) will output an internal biasing voltage that depends on the selected range. Let’s say for ± 2.5 × VREF range (i.e. ± 10.24 V) it will be around 2.2 V probably because the leakage current for that range is 2.25 uA and the input impedance is 1 Meg.
It looks ugly and confusing and I don’t know how to solve it without adding an op-amp to the input which I have already discussed with @Kean on Discord.
In Section 8.3.1. that is confirmed, and sounds to me as "It's Not a Bug, It's a Feature":
If the analog input pins (AIN_nP) to the devices are left floating, the output of the ADC corresponds to an internal biasing voltage. The output from the ADC must be considered as invalid if the devices are operated with floating input pins. This condition does not cause any damage to the devices, which are fully functional when a valid input voltage is applied to the pins.
The nice thing about the currently used ADC is that it's multi-range, has a bipolar input and accepts high voltage (± 10.24 V is high from the ADC standpoint) so the AFE is minimal. However, if I have to add op-amps to the input, then I can try my luck with some other ADC and arrange the bipolar input and range as desired. Does anyone have a suggestion for good alternatives?
-
It looks ugly and confusing and I don’t know how to solve it without adding an op-amp to the input which I have already discussed with @Kean on Discord.
So I had one (ugly) suggestion for this which was to add a 1M load resistor at the ADC inputs which is switchable under software control.
Then if the firmware detects an input voltage in a certain range as typically caused by the ADC PGA bias voltage leakage, the firmware can enable the 1M input impedance and then monitor the ADC reading. If it drops by approx half, then the input can be considered floating.
This could of course be disabled via a setting if the user wants to avoid that behaviour, or the process could also be reversed with the 1M input impedance normally enabled.
Yeah I know it is an ugly hack. :popcorn:
-
Normally it is the responsibility of the user to apply the right signal - to the card does not really have to detect of the input is open. Don't expect a correct measurement if nothing is connected. Adding an external amplifier would not avoid the problem. There is not real advantage in reading close to zero from an open input.
I think the idea of switching the input to see if the input is not connected is a good idea. However the inputs are differential, so there is more than just the option of open or connected. It can be open at both sides and there may be a relatively high impedance source. To some extend already switching the gain may be enough to detect an open input (so without extra HW).
When used as a true differential input with an isolated voltage source, I see not problem and there should be no offset / extra bias current. The biasing is nice to keep things in the center where the amplifier can work.
The main trouble comes when the ADC is use as single sided - than the 1 M input impedance is not relative to ground, but a fraction of the internal biasing voltage. So one would see some input bias current (0.1-2 µA) and this current in combination with a non zero source impedance can be a problem. It adds some offset and not just the normally expected gain error.
For the price the performance of the ADS8674 still looks good.
With the internal AA filter the 500 kSPS are a bit misleading, as there is a 15 kHz BW limit. At least this is also there when sampling all inputs in a fast sequence.
With external amplifiers/input stages I would consider a different ADC, like ADS131A04 or similar. The sampling rate is lower, but more BW and as a SD ADC not much AA filter is needed.
-
When used as a true differential input with an isolated voltage source, I see not problem and there should be no offset / extra bias current. The biasing is nice to keep things in the center where the amplifier can work.
Except it can't be used as a true differential input, only single ended.
Per the datasheet:
The devices allow a ±0.1-V range on the AIN_nGND pin for all analog input channels.
-
When used as a true differential input with an isolated voltage source, I see not problem and there should be no offset / extra bias current. The biasing is nice to keep things in the center where the amplifier can work.
Except it can't be used as a true differential input, only single ended.
Per the datasheet:
The devices allow a ±0.1-V range on the AIN_nGND pin for all analog input channels.
This is indeed a problem. So there should be a way to tie the negative side input with a relatively low impedance to ground. I would suggest more like 1 K, so that even with 10 V applied to the 1 M input impedance on the high side by an external source would not drive the return side to more than 100 mV. It is still nice to have some kind of low side sensing for the resistors used for current inputs.
-
It hasn't been refitted yet, unfortunately. I'm waiting on a friend with reflow gear and skills to have time to take a look.
Andrew, I'd be happy to take a look for you - just not this weekend.
Thank you for the offer Kean, but my friend was able to successfully reattach the USB connector tonight and I've since updated to v1.4 (very nice!)
-
I'm working of "finalization" of MIO168 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-mio168-mixed-i-o-module.html) 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 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-bp3c-backplane.html) 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.
(https://i.imgur.com/wj4fGwP.jpg)
(https://i.imgur.com/Af6wGUk.jpg)
-
I'm sorry, not suggestions / info on the bus examples for other T&M, but for the physical implementation: what about PCB edge connector + something like a Nvidia SLI bridge?
They do 2x and 3x way ones, and the module spacing looks similar:
(https://m.media-amazon.com/images/I/61f-e-wQdLL._AC_SS350_.jpg)
(https://i.ebayimg.com/images/g/E5UAAOSwElhbzOnE/s-l400.jpg)
-
Looks expensive :)
-
Some analog interconnection can make sense, e.g. from an analog input or output to a relay card. It may include also some digital (e.g. sync signals).
It could still be tricky to find a good layout / choice of pins to make it work for more than a few cases that are know up front.
Additional switching may be needed on the cards, if one wants to keep the flexibility without changing the interconnects.
The IDC connectors look OK. I would probably go with the more standard 2.54 mm pin spacing and this 1.27 mm spacing of the normal flat cables. I would prefer more like a low pin count (e.g. 10 or 6 pins) and if really needed to use 2 cables. This may give more flexibility, to choose only the wanted connections.
-
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
-
Thanks @Kleinstein, @jbb. I like idea to split analog bus connector in two, but don't like idea to use 0.1" pitch since my current experience with low pin count cables is that have a weak connection, i.e. they easily lose contact and for that reason I would go for a smaller pitch.
-
For the standard pitch, there are very cheap cables with low quality. So one may have to be a little more careful in the choice. However I so no reason why a smaller (less common) pitch would make things much better. The soldered connections may be more reliable then IDC.
There seem to be some unreliable IDC cables, but I am afraid this is no limited to the standard pitch.
With a low pin count one may use classical crimped cables. Usually there is enough space between the boards, to no need to use the angled connectors. For an analog signal it may be just 2 or 4 lines that are needed.
-
An apology for what was said in the previous post: it's not that the cable has a bad connection, but the connection between the plug and the socket is problematic because the number of pins is too small. This is especially pronounced for the 6-, 8-pin 0.1" version. The 10-pin is slightly better but still questionable.
-
Follow up on post #438 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg3304520/#msg3304520) where I expressed dissatisfaction with the bias voltage display when the input is floating which is why I would try to use another ADC. @Kleinstein in #440 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg3304648/#msg3304648) suggested using ADS131xxx which is a very interesting series and offer 24-bit (in theory) and simultaneous sampling for affordable price. However, I now have a problem with the bipolar signal. They like most others do not have bipolar input. I have two options: to add an op-amp (per channel) for level shifting or to look for another candidate.
-
The ADS131A04 actually has the option to run with a +-2.5 V or similar analog supply and this way operate also with negative voltages at the input. There even is a charge pump integrated to create the negative supply. In this respect it is one of the few SD ADC chips that can work bipolar even with a single ended signal.
The ADS131E... also can use a negative supply and have buffers included.
The description is a bit confusing however.
Some difficulty comes from the limited (e.g. +-2.5 V) range, so a 10 V voltage would need an extra divider at the input. On the upside the noise is relatively good, so that one could directly connect something like a thermocouple.
-
New MCU module prototype powered by ULX3S displays the image concurrently on two screens: a TFT touchscreen and an external monitor. This could find its purpose in presentations and in classrooms.
(https://i.imgur.com/SQbRIjW.jpg)
(https://i.imgur.com/6w99sQU.jpg)
-
Thanks to @Kleinstein assistance I'm progressing well with MIO168 AFE modifications. New ADC will be definitely ADS131E04IPAGR (https://www.ti.com/product/ADS131E04) that is pin compatible with 6- and 8-ch variant.
Existing Traco DC-DC converter will be also replaced with new one build around SN6505B (https://www.ti.com/product/SN6505B), that looks like more flexible solution that could be also more silent. Since mentioned ADC is 24-bit, I believe that is at least 19-bit resolution achievable and in that case it will be good enough for simple automated voltage and current calibration, before a fully featured DMM module become available.
The question remains which voltage reference to use? ADC comes with 2.4 V internal reference with ±0.2% accuracy and 20 ppm/°C temp. drift. I can always set this as the default, but I would like to provide a place on the PCB for external reference.
It is not entirely clear what reference voltage I can use as I will use ±2.5 V for powering the analog part (to accept the bipolar input signal). In DS there are recommendations for AVdd of 3 and 5 V. If ±2.5 V can be interpreted as 5 V then 4 V is specified as the nominal reference voltage. Your thoughts are welcome.
-
With an analog supply of +-2.5 V and having the negative input more or less tied to ground, it does not make much sense to have a reference voltage of more than 2.5 V. The typical value is also 2.5 V - so this would be obvious choice. If there is a true differential drive, one could consider a higher reference voltage, like 4 V.
The ADC itself is specified with 3 ppm/K max., so the reference does not have to be a much better than the ADC. However the ADCs upper limit may be conservative to allow for easy testing.
An external reference would only make sense if considerably better than the internal one.
I would consider the max6225 or ADR441. Not sure if an extra reference driver is needed.
-
Great suggestions, many thanks. MAX6225 looks somewhat better, and price is accordingly higher. The good thing is they comes with standard pinout so one can experiment (REF50xx has that pinout, too). However, I believe that buffering is needed, or at least the Fig. 29 is described as "typical external reference drive circuit". This isn’t the first time TI has pushed a buffer for its ADCs that is typically built around the OPA350.
-
... and we have the first MicroPython application created by a community member thanks to @Jan28 (on Discord (https://discord.com/invite/dhYMnCB)): Reforming electrolytic capacitor ...
(https://i.imgur.com/CEo4s72.jpg)
The process is logged and can be viewed locally or on a PC thanks to EEZ Studio:
(https://i.imgur.com/8cqDhsi.jpg)
(https://i.imgur.com/A1qQsaa.png)
-
Hi prasimix,
I have just finished assembling my BB3 kit. When assembling, I had the following issues:
- The hole in the front panel for the 5-pin push-in connector is slightly offset to the right, so it is quite difficult to push the connector in (it rubs on the left side of the connector). It would probably be a good idea to add some more tolerance to this. All of the other connectors are accessible (incl SD card).
- I am missing two of the black countersunk screws
- One of the meanwell power supplies (the one that came with the DCM220) had missing screws in the screw terminal blocks. Upon closer inspection, the screws were actually lodged inside the power supply chassis itself (inside the "honeycomb" case)! It's possible that if I didn't look for this, plugging in the power supply could have ended very badly... This was probably my biggest issue with the assembly.
- The MCU board was shipped with the nut and washer from the encoder loose inside the sealed antistatic bag; they were just sitting on top of the PCB. This is a problem because there is a battery inserted in the board, so it could have shorted something on the PCB. Also, in general having metal fragments from the washer on the PCB is a bit of a concern if the shipping was rough.
- It was quite difficult to insert module #1 in the backplane, as the upper tab on the front panel sheet metal interfered with the front panel of the DCP405. It would be helpful if you could add some more clearance here. Modules 2 and 3 were fine.
Overall, I think the assembly went well and the instructions were easy to follow. I look forward to tinkering with this device more.
Thanks!
-
Thanks for reporting this so far unique collection of issues. :)
I wonder what that offset hole for a 5-pin push-in connector looks like. I would expect the holes on all the front panels to be the same, but they don’t seem to be.
The problem with mounting the module in the first slot I believe was caused by a improperly mounted display frame. You should probably move it a little to the left so as not to disturb the front panel of the module.
The issue with Mean Well seems to me the most serious. Since Mean Wells came in the factory packaging it is easily possible that their quality control did not notice that the screws had fallen inside (I was not in a position to open all the packages).
Anyway, I'm glad to hear that you managed to fix everything.
-
I think that I have now all in place for redesigned AFE for MIO168 module that is based on 4-ch simultaneous sampling 24-bit ADS131E04. First I have to thank @Kleinstein once again for his selfless assistance and patience as we went through a dozen iterations. The ADS131E04 is a pin compatible with the 6- and 8-channel versions which can be handy for future upgrades.
The ADC is powered with +/-2.5 V to be able to accept a bipolar signal. A place for buffered external reference in SOIC8 packaging is also allocated. The picture also shows the driver for the latching relays shown below. In the bottom right corner are analog bus extenders that I called ADIB: these will be two 10-pin connectors on which two analog inputs with sense and guard and Gnd are exposed. On the MIO168 they will be connected to the inputs of the ADC which have active clamps on them (IC28).
(https://i.imgur.com/lVdZ4U0.png)
I called the next AFE "Hi-voltage" because it can measure up to ±150 or ±240 V, depending on the divider used (Caddlock or discrete). For better accuracy, the voltage can be measured in three ranges. This AFE also has the option to measure current in case a 4-24 mA sensor is connected to the input. The current shunt has a limiter in front made of a combination of two depletion FETs, a resistor and a PTC, and at the AFE output there is an active clamp that cuts everything over ±2.42 V.
(https://i.imgur.com/ciR8kvF.png)
The next AFE I called “Hi-current” because it allows measuring of current up to 10 A in three ranges. It can also be used in voltage mode when it is possible to measure voltages up to ±15 V in two ranges.
The selection of the operating mode (voltage/current) is selected with a signal relay (ISEL_1), and hi current mode with a power relay (ISEL10A). Since the entire MIO168 is floated and uses a small DC-DC converter for isolation, it is important to take care of consumption. For this reason latching relays were used instead of regular ones. Relays with two coils are used, and the MCU will take care of set and reset actions. Relays with two coils are used, and the MCU will take care of set and reset actions.
(https://i.imgur.com/dJ3wjks.png)
To summarize, we'll have two pairs of AFEs that can measure voltage and current simultaneously. This means we can also measure power. In combination it can be used to measure the efficiency of, e.g. a DC-DC converter (input and output are monitored simultaneously). We basically have a rudimentary DC power analyzer as well as a entry-level DMM (the real one should follow, if we can reuse a 6.5-digit DMM module that @Kleinstein is working on). I will be more then happy if I manage to get 18-bit precision.
-
Thanks for reporting this so far unique collection of issues. :)
It sounds to me like the package experienced a lot of vibration during transit.
-
Yesterday I sent JLCPCB to make a new set of PCBs for MIO168 and AFE. Eventually I also moved the newly selected ADC to AFE piggyback and added two “ID” lines so that the MCU could recognize the different AFEs we might have in the future.
(https://i.imgur.com/kWEKc5X.png)
One detail remained open: I did not yet find a satisfactory board-to-board pair of connectors that would allow a distance of 22.5 mm between the AFE and MIO boards. Currently the closest I have found is a combination that gives about 18.8 mm (see picture) i.e. it is shorter by about 3.7 mm (approx. 150 mils). Since the receptacle is more or less the same height, it remains for me to find a larger pin header. The required number of pins is 36 (2 x 18). Any suggestions are welcome.
(https://i.imgur.com/jw3Dgou.jpg)
-
Any suggestions are welcome.
Does it need to be exactly 22.5? If not, stacking of multiple headers could work :). In the worst case, a short ribbon cable. Or pogo-pins or other spring-loaded contacts
-
22.5 mm would be optimal, in that case 8-pin 3.81 mm connector on AFE piggyback (X1) will be in line with neighbor 16-pin two rows 3.81 connector (X3) that is 22.5 mm high. The AFE connector will hanging over same type of 8-pin connector on the MIO base board (X4). I already have enough distance between AFE and MIO but the front panel would probably look nicer if we could achieve those 22.5 mm.
-
Got a recommendation from Samtec support to try the following combination: SSW-114-01-L-D (https://www.samtec.com/products/ssw-114-01-l-d) + DW-14-10-L-D-550 (https://www.samtec.com/products/dw-14-10-l-d-550)
-
Since MIO now has a separate AFE I think we could have more different types in the future. The first one I presented earlier has the ability to measure high voltage and current. Here's what else comes to mind:
1. "Entry level" (i.e. cheap version) - similar to the initial version where we had voltage measurements up to +/- 10 V and current (4-24 mA).
2. "Isolated" - a Hi-voltage/Hi-current version that has two inputs isolated. In this way, the voltage and current on the primary and secondary sides could be monitored simultaneously. Isolated modulators such as AMC3306M25 (https://www.ti.com/product/AMC3306M25) could be used here
3. "Autoranging" - A version that would have fast current autoranging (two ranges would be enough to start) for accurate monitoring of IoT and similar devices where there are large and fast changes in power consumption.
I am especially interested in the third version, since we will have an ADC with simultaneous sampling, both current ranges can be monitored simultaneously, however the question of very fast (preferably of the order of a few microseconds) switching from low to high current shunt remains. I still have no real idea how to do it. Maybe a power MOSFET with a powerful gate driver could help here.
-
MUX14D is a new multiplexer module that could be combined with MIO168 and SMX46. It has two banks of 7:1 multiplexers with dual lines and it can be combined in single 14:1 multiplexer. Multiplexer outputs are exposed on front panel connectors and ADIB connectors for internal wiring with other modules.
Module details are available on GitHub (https://github.com/eez-open/dib-mux14d).
(https://raw.githubusercontent.com/eez-open/dib-mux14d/master/Images/EEZ_DIB_MUX14D_PCB_top.png)
-
Next level of modularity, MIO168 module with AFE4 piggyback are ready to be tested and support in firmware. Front panel is used from previous MIO168 prototype, next one will come without hole between two upper 8-pin terminal connectors:
(https://i.imgur.com/GWfT713.jpg)
(https://i.imgur.com/ZAa21e6.jpg)
(https://i.imgur.com/xImgcia.jpg)
(https://i.imgur.com/g3BkTbS.jpg)
-
I'd like to share with you first results that I got with MIO+AFE presented in previous posts. It seems when the voltage divider is used (e.g. /100) that significantly degrade the measurement, or perhaps better to say it significantly amplifies the common mode noise and 50 Hz (mains frequency here) stands out so much. For example, then 2 V is measured with /1 range (+/-2.4 V) FFT looks like this:
(https://i.imgur.com/KD8Q8eP.png)
On the same input (AIN1) with /100 range (+/-240 V) FFT for the same signal looks like this:
(https://i.imgur.com/bw9nK1W.png)
It's massive 40 dB difference! Connecting PE on AIN1- makes situation ever worse, adding additional 5 dB:
(https://i.imgur.com/ZbtWAYa.png)
I put a Caddock voltage divider (1776-C68 (https://hr.mouser.com/ProductDetail/caddock/1776-c68/?qs=2QmwSASSNhaGcnZtYodE5g%3D%3D&countrycode=DE¤cycode=EUR)) on the AIN2 input, and the situation looks a bit better. For /1 range it looks like this:
(https://i.imgur.com/Y8WfbCo.png)
... and with /100 range is about 10 dB better then with voltage divider made of discrete 1206 Susumu resistors (RG3216P serie) in AIN1 input:
(https://i.imgur.com/TNR2QYg.png)
The pleasure is that the complete process is made within the EEZ environment: the signal is sampled with 500 SPS for 15 seconds, with one click it is transferred from Data Logger to the EEZ Studio where with a few more clicks I have FFT.
The question is what can be done here. Should I deal further with the PCB layout, should I put an additional filter on the ADC input?
-
Getting 40 dB higher 50 Hz hum with the divider active means the same voltage level is present at the ADC. This points to something like inductive coupling. Capacitive to the ADC input would be even weaker with the x1 range as the input is lower impedance.
Seeing mainly 50 Hz and not much 100 Hz suggest that it does not come from the supply voltage. At least the 50 Hz don't seem to come from the 2 V source.
It could still be coupling to the reference side - one would see the difference, when looking at the signal with a shorted input. This case would not reactor to the reference side.
With no extra shield the level of hum does not look so bad. The -100 dB without the divider actually looks quite good.
AFAIK the ground of the CPU board is not directly connected to PE and the case. So there may be some residual AC, e.g from Y caps at the supplies or similar. The level of hum may vary with other modules and possibly how the PC is connected.
One could try with an extra probe with an AC signal to see which area of the board is sensitive and may want extra shielding.
It is a little odd that the different dividers make so much different - I would normally not expect that much difference. The expected downside from the SMD resistor version would be more higher relative TC and maybe more effect of self heating - though usually not so bad at only 240 V max. The frequency response may also be different between the dividers - though usually not a big deal at 50 Hz.
-
Thanks Kleinstein for your input and good idea tom perform measurement with input shorted. I got the following results:
1. AIN1 shorted /1 range (discrete divider):
(https://i.imgur.com/Dgncsmj.png)
2. AIN1 shorted /100 range:
(https://i.imgur.com/IgZt0dw.png)
3. AIN2 shorted /1 range (Caddock divider):
(https://i.imgur.com/ANoZD4f.png)
4. AIN2 shorted /100 range:
(https://i.imgur.com/Au7CJzM.png)
MIO+AFE was installed in Slot #3 (far right) when DCP405 power module was in Slot #1. Removing DCP405 does not improve results.
You're right about MCU module (CPU board): it is not connected directly to PE. MIO from other side is completely "floating" but its Gnd is connected to PE with 4n7/2kV. Removing PE wire on MIO does not make any difference.
-
The hum does not look like it is coming from the reference.
I don't think the difference between the channels is from divider itself, more like the 2 inputs having different coupling to the outside and maybe to the unused channels 3 and 4. One could check the channel separation to get an idea the coupling: so apply some AC signal to channel 3 or 4 and check the response on 1 and 2. Even if not the source of the hum the channel separation should be checked anyway.
To measure even weak coupling, one can compute the correlation, like in a lock-in amplifier. So use 1 channel as reference and than look in the other channel for the same frequency. Ideally this could be done real time one board - though it is quite some effort, and the board still misses a low noise amplifier input to make it a lock-in amplifier.
The x1 range has a relatively large resistor at the input for protection - so it may still be capacitive coupling. 100 K for protection is about the same as the /100 divider. So coupling to behind the protection and to behind the divider would look similar.
One could try a makeshift shield (connected to the MIO ground), and for a test connecting the MIO ground to the case.
There is not much filtering that could be applied to suppress the hum - at least not analog. For slow measurements one can have digital filtering by averaging over multiples of 20 ms.
As a final solution one may need an extra shield. A revised layout (e.g. additional ground areas, maybe some thinner lines) may also help, though not sure how-much it would help.
I do not consider the hum so much to warrant a new PCB revision - just keep in mind if a revision is needed anyway.
As the measurements work, I assume the DCDC converter is also working OK. Is the injected common mode signal reasonably low (measured voltage over some 1 K from the isolated ground to the ground of the CPU board)?
-
ADC channels 3 and 4 are not unused: they also have input stage, and for testing they are set in current mode, i.e. shunt is active over their inputs. Test with 1K connection between MIO and MCU GND is performed with x10 probe, and long Gnd clip.
If probe Gnd is connected to MCU side it looks like this (100 mV/div):
(https://i.imgur.com/xcSSrQD.png)
... and when probe tip and ground are swapped, i.e. Gnd is connected to MIO side it looks like this (500 mV/div):
(https://i.imgur.com/JT6uwCh.png)
-
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.
-
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:
(https://i.imgur.com/KICA4dZ.jpg)
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:
(https://i.imgur.com/ek97YoS.png)
Measurement on AIN1 with /100:
(https://i.imgur.com/kZIdWzi.png)
Measurement on AIN2 with /100:
(https://i.imgur.com/RV1Fagh.png)
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:
(https://i.imgur.com/FWTCNOJ.png)
-
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:
(https://i.imgur.com/x82WZ7C.png)
50 Hz can now be found down at -97 dB. In the case of AIN2 inputs, it is not even distinguishable from other noise:
(https://i.imgur.com/vTmDsVK.png)
-
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.
-
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/ (https://www.eevblog.com/forum/projects/building-log-for-eez-bb3-enclosure-bare-boards/)
-
Thanks Denis,
I did no see that thread. In case I encounter trouble, I will ask there...
-
... also feel free to join Discord (https://discord.com/invite/dhYMnCB) server, where you can ask about kit assembly on #kit-assembly channel.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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 (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!
-
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 (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).
-
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.
(https://i.imgur.com/25HQFx7.jpeg)
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:
(https://i.imgur.com/6142Lff.jpg)
Pressing the `calculator` button takes you here. You can select li-ion, lead acid presets or custom cell voltage and C-rate values.
(https://i.imgur.com/ZUdaBlh.jpg)
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.
(https://i.imgur.com/ft83hui.jpg)
And when the charge terminates you can see the charge stats.
(https://i.imgur.com/9Uy48yq.jpg)
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. :clap:
-
Thanks for great new MicroPython script. Looking forward to see it available to other users :-+
-
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.
-
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.
-
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 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-mio168-mixed-i-o-module.html) 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 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-bp3c-backplane.html) 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.
(https://i.imgur.com/wj4fGwP.jpg)
(https://i.imgur.com/Af6wGUk.jpg)
-
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
-
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 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-mio168-mixed-i-o-module.html) with SMX46 (https://www.envox.hr/eez/eez-bench-box-3/eez-dib-smx46-switch-matrix-module.html) or MUX14D (https://www.envox.hr/eez/eez-bench-box-3/dib-mux14d-multiplexer-module.html). 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.
-
I'd like to open discussion here about @fietser28 (https://github.com/fietser28) proposal on Github #94 (https://github.com/eez-open/modular-psu/issues/94) to upgrade existing remote voltage programming with current programming and to make control signal "floating" (#93 (https://github.com/eez-open/modular-psu/issues/93)). I'm planning to eventually add that change in next production batch of DCP405 module since it doesn't compromise obtained CE approval.
(https://user-images.githubusercontent.com/8796121/105979736-4ab90d80-6094-11eb-9e75-50017451b38c.png)
-
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.
-
I setup up the LED steering this way because I couldn't find a pin on the I/O expander to drive it from software.
It should be off if there is no remote programming and on if there is either remote voltage or current steering taking place. This is not wired correctly in the diagram: The 2n7002 gates should be connected to the aux_uset and aux_iset signals, not the output of the AND gates.
I choose the TL072 because it is already widely used in the DCP405, keeping the BOM simple and power rails are available.
You're right protection is not present yet, but should be added in final design. The current rprog on the DCP405 has protection.
The comparator and and gates are there to enable a setting a limit on output when remote programming is enabled.
Two questions I have, while we are discussing this:
- The steering range is from 53mV - 2.5V, not from 0V-2.5V is this a problem, should we add something to compensate for this?
- Instead of limiting the output (in this design), is scaling a better option (more complex to realise). With scaling I mean that if we set a max of 10V on the BB3, 2.5V remote programming voltage gives a 10V output?
-
- Instead of limiting the output (in this design), is scaling a better option (more complex to realise). With scaling I mean that if we set a max of 10V on the BB3, 2.5V remote programming voltage gives a 10V output?
Yeah, scaling (by input attenuation) that 10 V gives max voltage makes sense. Many control signals are in 0-10 V range.
-
Scaling in such a way that 10 V at the input would give the set value may be better, but also much more difficult to implement, as it requires a kind of multiplication.
So I think the way it is drawn is OK: have the external value and the set value as an upper limit.
Instead of the comparator and switching part, one could also use precision clamps, though this would need a negative supply. The switching solution as should be OK, maybe with a small extra filter cap so that the external signal is not too fast.
For the OP I would suggest something like MCP6001, so with a rail to rail output and singel supply (or RR) input.
For the logic polarity one could use NAND gates and swap the signal inputs at the switches. Alternatively one could use 2 diodes as a wired OR instead of the 2N7000 and drive the LED from the AND gates.
-
OK, take into account that we have on disposal -5 V and about -8 V if negative supply is needed.
-
Hi everyone,
I have noticed that when I hook up my multimeter directly to the output of the DCM220, it reads ~1.3V when the outputs are off or inhibited. This is not the case for the DCP405 modules; they read as basically zero.
Is this behaviour expected? I realise that the load of the multimeter is very small, but I just wanted to check if anyone else sees this. I had assumed that OFF = 0V.
Thanks,
Jeremy
-
Yes, that is expected it hasn't down programmer as DCP module, and it cannot go below 1 V even with load connected. Please note that DCM is "auxiliary" DC source and cannot be compared to the capabilities of the DCP module. What you're measuring is remaining voltage on output capacitor and if you try to measure current it will be close to zero.
-
Thanks for the clarification, and yes, I am aware it is more for powering less sensitive/auxiliary systems. Are there current limits applied when the module is in the off state? If I was to short the + and - while the supply is off, would that damage the unit?
-
No, current limit (that is very coarse in comparison with DCP module) is not active when LT3763 is off, but only remaining current from output capacitor will flow and that shouldn't have any effect on module itself.
-
This is a new proposal for Remote programming presented in #498 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg3530232/#msg3530232).
Input op amp is changed to MCP6001 powered from single rail. LED driver is also changed, and 2G08 instead of 2 x 1G08 is used. I also added 10K on all comparator inputs.
(https://i.imgur.com/Tj7COkQ.png)
-
I forgot to mention that LM293 is now also powered from single rail that output stays within 0 to V+ range.
-
I don't think the 10 K resistors at the comparator are needed. The signals are well limited in range.
For some filtering it may help to have capacitors in parallel to R11 and R4.
I don't think one would need Q1. Just the LED towards ground should be OK.
-
Thanks @Kleinstein, corrections below:
(https://i.imgur.com/ZpcWpgr.png)
-
I think @kleinstein mentioned it before, in this design the LED is ON only if vrprog or iprog is on AND the input signal is below the limit. This means that if you turn on rprog and you input voltage is below the limit, the Led will turn on (just as it works inter current dcp405). If you increase your rprog input voltage above the limit, the led will turn off although rprog is still set.
If the anodes of D1 and D2 are connected to aux_uset_sw and aux_iset_sw then the behaviour of the leds changes: they are always on if prog is on, even if the output is limited by the set limit.
In my opinion both are valid, just different:
- With the current firmware there also is an indication rprog is on in the display in the set values. You will also be able to see on the main screen if it is voltage or current programming. The led has some redundancy to this.
- It can be a nice indication you’re rprog input is getting limited because there is no other way to know if limit is enforced or not. It might confuse users because the behaviour requires reading the manual....
A third (fancy, feature creep) option: make the led dual color. One color (yellow?) for rprog active and another colour (red?) if rprog is active AND the limit is enforced.
More feature creep (or an enabler for later software features): feed the led status as it is now (or the OR of the two comparators) back to the MCU. This allows for measuring if limit was hit and maybe optionally enable a protection on it in software (e.g. turn output off if limit is hit) in the future.
One question I still have: Is the limit circuit (comparator, logic and relais) in combination with C21 dampening and the limited bandwidth of the output (500Hz ~= -3db) fast enough to not overshoot beyond the limit of you step up rprog above the limit? This circuit will probably pass a (small enough?) pulse above the set limit into into the next stages of the dcp405, these stages have a limited bandwidth that probably smooths the step enough to not have any overshoot, but it should be verified. If I have time I will try to measure the max pulse width not causing overshoot on he current rprog interface (voltage only...) that will give an estimate of the budget for the delay of the comparator, and gate and relais combination.
-
I see the main purpose of the LED to show if the voltage or current is actually set by the external value. So the LED turning off indicates that the setting is by the internal setting - either because of hitting a limit or because programmed to do so, which is the normal case.
The speed of the external signal causing overshoot is a valid point. The idea of the C21, C6 is to slow down the external signal enough so that the comparator / switch is fast enough to avoid much overshoot. It won't be a 100% protection as there is no good control how hard the input is driven extenally. The comparator is quite fast giving a dealy of maybe a 2 µs or so (depends on how much the limit is exceesed) the logic CMOS swtiches are very fast (e.g. < 100 ns). The trasition from the external to internal setting is the faster one - depending on the values of R2,R3 the transition back can be a bis slower, which may be good. So I would consider somewhat larger values for R2 and R3.
I just realized that the clamping diode for the input should be more like 1 pair of back to back diodes instead of a zener / transsorb. The voltage accross the inputs should normally be small anyway, and there are diodes to the supply inside the OP anyway.
-
I did some tests to simulate the possible overshoot using a DCP405 and driving the prog of it with a signal generator and an on-amp configuration like the design.
The AWG starts at 0V then generating a short pulse at 2.5V (full scale of rprog, rise time = 9ns) and after that it goes down to a lower value simulating the situation where the rprog is driven at a step of 2.5V and there is a limit set.
I varied the voltage levels, the length of the pulse and the load of the DCP405:
- The load doen't change things as long as the current limit is high enough.
- The worst case seems to be a low limit value and a full scale (2.5V) step. Seems logical..
- Worst case meaning the settings where the shortest pulse width created overshoot.
First I played around with limit around 1.25V (20V output). A pulse < 100us didn't give overshoot.
Playing with low limit values (around 1V) make things a lot worse:
[attachimg=1]
This is with a pulse of 20us at 2.5V and a limit voltage of 100mV (output = 0,7V)
Decreasing the pulse with to 10us gives:
[attachimg=2]
Going even lower (limit = 70mV / output = 0,2V) also gives overshoot at 10us, reducing the pulse with 8us eliminates this also.
This is a pretty extreme edge case: You set the output limit to 0,2V and drive the rprog interface to deliver 40V...
The most extreme overhoot (relative) is to step 8mV into rprog with an offset of 57mV (= 0V output in my setup), still feeding a 2us 2.5 pulse, then 8mV causes a output of overshoot of 100mV at 120mV. It is a very extreme case: who will set the limit to 0.1 V?
Given the specs from the datasheets of the comparator and logic this should not be a problem. The comparator is max 2us and the logic is an order of magnitude below that.
I think the limit circuit is fast enough for the voltage control.
-
@Jan28, what current range settings you're using? If you are in "Best" mode then you can expect huge overshoot since firmware based current range switching is too slow.
-
I think @kleinstein mentioned it before, in this design the LED is ON only if vrprog or iprog is on AND the input signal is below the limit. This means that if you turn on rprog and you input voltage is below the limit, the Led will turn on (just as it works inter current dcp405). If you increase your rprog input voltage above the limit, the led will turn off although rprog is still set.
If the anodes of D1 and D2 are connected to aux_uset_sw and aux_iset_sw then the behaviour of the leds changes: they are always on if prog is on, even if the output is limited by the set limit.
Yes, I understand that and as @kleinstein explained I don't see any issue with it at all.
In my opinion both are valid, just different:
- With the current firmware there also is an indication rprog is on in the display in the set values. You will also be able to see on the main screen if it is voltage or current programming. The led has some redundancy to this.
- It can be a nice indication you’re rprog input is getting limited because there is no other way to know if limit is enforced or not. It might confuse users because the behaviour requires reading the manual....
On the firmware side, we have enough freedom to present this special situation in the most convenient way and that we do not need to consult the manual for that :).
A third (fancy, feature creep) option: make the led dual color. One color (yellow?) for rprog active and another colour (red?) if rprog is active AND the limit is enforced.
More feature creep (or an enabler for later software features): feed the led status as it is now (or the OR of the two comparators) back to the MCU. This allows for measuring if limit was hit and maybe optionally enable a protection on it in software (e.g. turn output off if limit is hit) in the future.
Um, you need to consider that this is already a dual LED THT and I don't know if there is a version where one of them is also bicolor.
-
The speed of the external signal causing overshoot is a valid point. The idea of the C21, C6 is to slow down the external signal enough so that the comparator / switch is fast enough to avoid much overshoot. It won't be a 100% protection as there is no good control how hard the input is driven extenally. The comparator is quite fast giving a dealy of maybe a 2 µs or so (depends on how much the limit is exceesed) the logic CMOS swtiches are very fast (e.g. < 100 ns). The trasition from the external to internal setting is the faster one - depending on the values of R2,R3 the transition back can be a bis slower, which may be good. So I would consider somewhat larger values for R2 and R3.
10K instead of 4K7 for R2, R3 or even higher?
I just realized that the clamping diode for the input should be more like 1 pair of back to back diodes instead of a zener / transsorb. The voltage accross the inputs should normally be small anyway, and there are diodes to the supply inside the OP anyway.
I don't understand this, the input voltage can be 0 to 2.5 V, and there was talk of a 0 to 10 V range. How to protect it only with a pair of back to back diodes?
-
@Jan28, what current range settings you're using? If you are in "Best" mode then you can expect huge overshoot since firmware based current range switching is too slow.
It was in "best mode" with the limit set to 5A. So I think there was no software switching?
Most of the measurement I did with 10ohm resistor.
-
Just to be sure, check how it looks like with current range set to 5 A.
-
Checked with 5A setting: No difference, looks the same as previous screendumps.
-
Most of the protection would be from the MCP6001 internal diodes to the supply. The diodes between the inputs are more like a fine print to that and may help a bit with transients.
The MCP6001 is specified with up to 2 mA at the input (which is rather low for an OP). With 10 K at the input this would be good for some 20 V. Because of the low values one may consider raising the resistors a little (e.g. 27 K), e.g. to allow the 50 V from the supply itself not to damage in input. Alternatively there may be a more tolerant OP (AFAIK TI has a similar one).
-
I forgot to mention that LM293 is now also powered from single rail that output stays within 0 to V+ range.
For limiting the output of the opamp this works, however:
This limits the common mode input range (or how much it can ""float"") of rprog with respect to the negative power output plug of the DCP405, doesn't it?
The whole DCP405 module is floating with respect to protective earth. In the DCP405 the negative input plug is a little above the GND of the module (mainly due to shunt). The opamp gives the DCP405 a differential input for rprog (X1-1 and X1-2 where X1-2 is not connected to GND of the module anymore). This differential input can be operated between the range of the power of the opamp it drives meaning the negative rprog input should be between 0 and +2.5V relative to negative power output plug. This is enough to allow connecting the rprog- and the negative output to the same potential (e.q. protective earth). I think this is an important use case (at least for me).
If a opamp with boarder input power is used the range also gets increased. E.q. it is also possible to have rprog+ at the same potential as the negative output.
I hope I'm not creating confusion. :-//
-
I hope I'm not creating confusion. :-//
No, you didn't, after all you started this interesting enhancement, and I'd like to add it into the next revision.
If LM293 is powered from dual rail then we need to limit "low" level with diode or something otherwise -V will appear on its output that I believe is not something that 2G08 would like to see on its input.
-
Most of the protection would be from the MCP6001 internal diodes to the supply. The diodes between the inputs are more like a fine print to that and may help a bit with transients.
The MCP6001 is specified with up to 2 mA at the input (which is rather low for an OP). With 10 K at the input this would be good for some 20 V. Because of the low values one may consider raising the resistors a little (e.g. 27 K), e.g. to allow the 50 V from the supply itself not to damage in input. Alternatively there may be a more tolerant OP (AFAIK TI has a similar one).
Huh, you're right, I overlooked that MCP inputs are floating. As @jan28 explained question is do we need to power it with dual rail, and in that case we have to search for other candidate since it cannot accept +/-5 V what is currently available.
-
The input OP should be powered by the same voltage as the CMOS switch chip. AFAIK the 74LVC1G 3157 is 5.5 max.
It should be OK to power the OP from 0 / 5 V. The input is kind of floating, but via the resistors there is a link. In many cases one of the inputs would be essentially tied to ground.
If an OP with higher supply (e.g. +-5 V is used), one would need some extra current limiting resisor before the switches. The OP than would no longer need to support single supply operation.
-
No, you didn't, after all you started this interesting enhancement, and I'd like to add it into the next revision.
If LM293 is powered from dual rail then we need to limit "low" level with diode or something otherwise -V will appear on its output that I believe is not something that 2G08 would like to see on its input.
I was not completely clear:
I think only the opamp (IC4A) needs dual rail, the comparators can run from single rail to GND. The opamp (with resistors and caps) shifts the rprog- input to GND. Dual rail of the opamp allows a wider range of this shift.
Trying to figure out the limits of the MCP6001 I noticed the rail-to-rail definition is almost rail to rail: 25mV above ground is the minimum output. This is fine for the drawn jumper configuration because 0V output is around 53mV, but if we want 0mV on rprog = 0V output by switchting the jumpers from GND to GCOM 25mV is not enough to reach 0V output.
-
A +-5 V supply for the OP could help for a larger range. The GND/ vs GCOM jumper would not make a big difference as the OPs ouput would still be the same, just the external votlage changes. Even the OP input would still see the same GCOM/2 for zero set point. There are plenty OPs for 10 V operation - starting from a 741, but also OPA202 if precision is wanted.
-
Ok, so in the latest version of the schematic I only need to change the input op amp with someone that has a split rail power supply like the suggested OPA202?
-
Ok, so in the latest version of the schematic I only need to change the input op amp with someone that has a split rail power supply like the suggested OPA202?
Yes
-
Regarding the scaling of the rprog voltages, I found a very simple 'poor mans' solution that is very flexible and doesn't require addition components:
The user can just put equal resistors on the rprog+ (X1-1) and rprog- (X1-2) inputs. You can to this to achieve almost any scaling to make it less sensitive (not more sensitive).
This works because the difference amplifier setup is such that the output of the difference opamp is (rprog+ - rprog-) * R4/R5
(R9 equals R5 and R11 equals R4 all the time to make this work). By adding additional equal resistors at the inputs (in series with the individual signals, not across/parallel) you effectively increase R5 in the formula.
Currently the rprog/output ratio is about 0.0625 V/V (increasing rprog with 62mV increases output with 1 V)
Adding 6k to both inputs makes the rprog/output ratio 0.1 V/V
Adding 150k to both inputs make the rprot/output ratio 1 V/V
The 0V offset due to GCOM gets amplified as well (to around 0.8V in case of 1V/V)
Just add this to the manual with formula and a table of some common example values (0.1, 0.5, 1 V/V...) and everybody has arbitrary scaling.
Personally I prefer the 0.1V/V above 0.0625 because it calculates a lot easier.
The formula if jumper is connected to GCOM:
Vout = 10k/(Ruser + 10k) * Vrprog * 16 or simplified: Vout = 160k/(Ruser + 10k) * Vprog
The formula if jumper is connected to GND:
Vout = 10k/(Ruser + 10k) * (Vrprog * 16) - (Ruser + 10k)/10k * 0.053
-
Ok, so in the latest version of the schematic I only need to change the input op amp with someone that has a split rail power supply like the suggested OPA202?
With a supply to the OP that exceeds 0-5 V one should also have a resistor at the OPs ouput, to limit the current to the switch chips (mainly ground side) and a diode to GND, so that the comparators would see very much negative voltage. So it is not a big changes.
The not on reducing the input sensitivity is good - if a 10 V FS range is wanted just add external resistance (some 30 K each from a cride calculation).
-
New proposal: Op amp model changed and its supply to split rails, D3 and R1 added for switches protection.
(https://i.imgur.com/lmFq44U.png)
-
IC5 pin4 line has to be something else: e.g. I_SET_OUT
-
The OPA202 can deliver quite some current (35 mA typical) in case of a negatvie signal. This could be a significant load and cause problems, e.g. if the external input is open and just picking up hum. As far as I understand the circuit connected to the set signals does not care very much about the signal impendance. So one could add another resistor (e.g. 1-2 K range) between die OP and D3 to limit the currrent.
-
... or just to move D3 after R1?
-
Die Switch chip likely alteady includes diodes to the negative supply, so behind R1 there is no real need for an extra diode. The tricky part is that with current through a substrate diode, the normal function is no longer guarantied and the normal set point my be effected. The signal is not that high in impedance, so it may still work - just have to test the swtich chip in real life.
-
Ok, I will make a small PCB to test this circuit so I will leave room to add a resistor on both sides of the diode D3.
-
The new MUX14D module is ready to be added to BB3. In fact it is a companion to the MIO168 (https://www.envox.eu/mixed-i-o-modules/) module that can bring more signals to the ADC inputs on one of the connected AFEs.
The module has two 7:1 multiplexers that can be combined into one 14:1. It is made with reed relays so that the switching speed is not high. The inputs are 2-wire instead of single ended which consumes twice as many pins on the connectors. It may be worthwhile to make a variant with single-ended inputs for more inputs per module. The outputs from the multiplexer also go to the external terminal, but can also be connected internally to the MIO (or some other module) via ADIB connectors (currently not mounted on the prototype in the picture below).
I also glued a "cold junction" sensor to the bottom of the lower terminal connector.
(https://i.imgur.com/Pg5KmWw.jpg)
Schematics in attachment.
-
A thing of beauty!
-
We are all going to need a bigger box!
All lame lines from 45 year old shark attack movies aside, will there be any options for some kind of auxiliary / expansion box for all of these wonderful boards?
-
One idea is to make an expansion chassis that could accommodate up to 7 non-power modules in the same form factor as the BB3 (i.e. those that do not need a Mean Well 48 Vdc converter). Communication with BB3 or PC could be via USB or Ethernet.
However, there are a lot of things to define: whether the AUX-PS and MCU modules will remain separate, or perhaps merge them into one? Should AUX-PS/MCU will be connected behind the new 7-slot backplane or should it be a module that goes into a dedicated (8th slot), will the FPGA be added from the beginning or will we just stay on STM32, etc.
-
Another prototype made by @goran.mahovlic of MCU-FPGA (ULX3S based) module is ready for testing. We now have a functional pass-thru FPGA of all DIB lines which will give us more flexibility in defining their functions and allow higher transfer speeds.
(https://i.imgur.com/aTCkIJW.jpg)
-
We started doing the first tests with AFE3 for the MIO168 module. Unlike AFE1 where all four analog inputs share the same GND, here we have two fully isolated channels for which TI isolators with DC/DC converters were used.
The first input (AIN1) is voltage only, the AMC3330 (https://www.ti.com/product/AMC3330) is used and has two ranges: ±50 V and ±450 V so it will allow measurement of AC mains up to 320 Vrms. The second input (AIN2) is current only, AMC3301 (https://www.ti.com/product/AMC3301) is used and also has two ranges: ±1 A and ±10 A. This in combination with the remaining two inputs which are combined voltage/current as in the case of AFE1, and with simultaneous A/D conversion I expect that there could be a usable solution for measuring input power, output power and the efficiency of AC/DC and DC/DC converters, battery chargers, etc.
(https://i.imgur.com/aLZptQy.jpg)
I have to say that the mentioned isolators look very promising. Here we come to one interesting detail: the problem of measuring large currents (e.g. over 4 A) where the TCR of the current shunt is very pronounced. I have already discussed this with @Kleinstein and complained that the ROHM of 0R010 (GMR100HTBFA10L0) used with a TCR of only ±20 ppm/K does not seem to be good enough. After all it’s just an SMT component in the 2512 packaging so that shouldn’t come as a surprise. I tested it on AFE1 where I have it on AIN3 and AIN4 inputs. I use the same with AFE3 on the AIN2 and AIN4 inputs with the difference that behind the one on AIN2 is the already mentioned AMC3301.
A thing that is interesting and I don't know how to interpret at the moment: when measuring a current of 5 A at the AIN4 input in a period of 15 minutes, I have a drift of +6 mA. However when measuring the same current on AIN2 (with AMC3301) in the same period and using the same current shunt I have a 0 mA drift!
The first thing that comes to my mind is that the current shunt (R11) on AIN2 is better cooled because there is more copper on the PCB. However, this is not true. The traces to the shunt (R32) on the AIN4 are longer, so there is more copper to keep it cooler. Perhaps this drift should not be attributed to the current shunt at all but to some other component. The schematics (which does not include the latest changes but is relevant to the prototype I am testing is attached).
-
A thing that is interesting and I don't know how to interpret at the moment: when measuring a current of 5 A at the AIN4 input in a period of 15 minutes, I have a drift of +6 mA. However when measuring the same current on AIN2 (with AMC3301) in the same period and using the same current shunt I have a 0 mA drift!
Is it possible to just measure the voltage across the shunt? 6mA over 5A is 0.12% which should be easily measurable. This way we eliminate the shunt. I quickly checked the schematic, but can't say anything specific. Can it be a board contamination with flux and some leakage currents?
Is the problem only present at 12A range? I'd check on smaller ranges if they drift too. I'd also use a hotair gun to warm up the board a little bit and see how that affects readings.
-
Some 0.1% drift for the current reading would need 50 K temperature rise to get his from 20 ppm/K TC of the shunt.
This is a bit much for the low value shunt. The fuses may be the larger sources for heat than the shunt.
Beside the TC, also the way the voltage sense is exactly connected could cause an error. It may effectively include some copper with the shunt. So it could be about the layout details at the shunt.
Some of the clearances on the board are quite small, e.g. the Ain3 input. So one should not consider the input suitable for direct mains use. More like a class 1 safety limit.
Die a 5 A current reading an not much extra series resistance in the sense line leakage currents on the board are likely not an issue.
-
AIN3 is not intended for more then ±240 Vdc, but ok more clearances wouldn't hurt. I have to check what is possible.
On the output of AIN2 high range shunt I have tiny filter, don't know if that helps in getting better measurement, but that shouldn't be connected with drift caused by rise of temperature (if we assume that is the major reason for drifting).
The exactly the same fuses are used on both AIN2 and AIN4 channels, so don't know how they could participate in such huge drift.
I'll try to see if 0.12% error is measurable directly on shunt as @exe suggested, also try to play a bit with hot air gun.
PCB is also everything but clean :). Lots of flux is all over it. I'll try to get rid off that mess. One more thing, although the same circuit is used for non-isolated input on AFE1 and AFE3 prototypes, results on AFE3 (6 mA drift) is more then three times better. I had 20 mA drift for 5 A on AFE1 in much shorter time.
-
I did the following simple experiment. I soldered ROHM Rsense to the PCB, measured the temperature before letting 5 A through it. After a few minutes the temperature stabilized at about 40 oC. So it turns out that the drift should be around 400 ppm which is 30 times better than 0.12% at the AIN4 input.
(https://i.imgur.com/Rx5tIce.jpg)
(https://i.imgur.com/zt58rLM.png) (https://i.imgur.com/x5iAX8w.png)
-
As I understand, some inputs use isolated amplifiers. Those can drift badly. I checked datasheets, they have 40-45ppm/C worst-case gain drift. So, I'd say, they can noticeably contribute to the total error. So, 20mA drift on those channels can be a bit different in nature.
I still hope it's just flux leftovers :). Most fluxes are slightly conductive, even if claimed "no clean". This is especially a problem in elevated temperatures. So, even if flux passes tests at 25C, it doesn't mean it will behave the same under 50-70C, or in humidity, or when it's electrically stressed (according to one flux chemist on youtube).
-
The thing is, it behaves better on AIN2 which has an izolator than on AIN4 without it. One possible explanation is that the TCRs of Rsense and Isolators are of different sign and cancel each other out?
-
The temperature of the isolator would change quite a bit less than the temperature of the shunt. So I don't think there is much hope for compensation.
One point could be that the TC of different shunt can be different. The 20 ppm/K number is just an upper limit. The actual TC is often lower, but should no be much higher. So it could be just good and bad luck.
400 ppm to 0.12% is only a factor 3. The fuse resistance would not directly comtribute, but the fuse would also get het. So for the complete board the remperature rise may be more than 20 K, though still likely similar for the 2 shunts.
The layout around the shunt may be the problem and effectively add a little copper to the effective shunt. The next higher current shunt should be more connected to the voltage sense side of the shunt. As far as one can see it from the picture it down not look so good.
-
Ok, as another exercise I tried to disconnect low/mid range protection from Hi range current path, like shown below (in fact, only the diodes needed to be disconnected). No more drifting! AIN4 shows good results just like AIN2.
(https://i.imgur.com/ZwhfQKq.png)
-
One possible explanation is that the TCRs of Rsense and Isolators are of different sign and cancel each other out?
I'd be surprised, but this is something that we can measure :). But you already did that, the resistor has much less tempco than 0.12% that we see, right? So, it's not a resistor then. You can also swap resistors to see if this makes a difference.
As of isolator tempco, you can gently heat it with a heatgun and see if it changes anything. Although, the thing is, heatgun is not an accurate test because it also heats surround components, the air temperature is not precisely controlled, etc. Also, fast heating may create additional mechanical stress which is not present when the board naturally heats up. However, still a good test, imho :).
However, if there is leakage due to flux, this one manifests quite fast when the board is heated (imho). So, when you blow hot air on the board, does the measurement drift? If so, then we can heat parts of the board separately to locate the place more precisely. My best guess is still flux leakage, but may be it's a half-broken diode or something else in signal path.
-
Ok, as another exercise I tried to disconnect low/mid range protection from Hi range current path, like shown below (in fact, only the diodes needed to be disconnected). No more drifting! AIN4 shows good results just like AIN2.
Good to see the drift gone, but normally the protection should not have that much effect. It should be very low leakage.
The MCP6001 come in 3 different pin-out versions. The OP is not absolutely needed - chances are it could be good enough also without it. However the diodes are kind off needed to protect the mid and low current shunt.
-
Ok, as another exercise I tried to disconnect low/mid range protection from Hi range current path, like shown below (in fact, only the diodes needed to be disconnected). No more drifting! AIN4 shows good results just like AIN2.
Good to see the drift gone, but normally the protection should not have that much effect. It should be very low leakage.
The MCP6001 come in 3 different pin-out versions. The OP is not absolutely needed - chances are it could be good enough also without it. However the diodes are kind off needed to protect the mid and low current shunt.
Perhaps I could try to move bottom end of diodes to the upper leg of Hi current Rsense, and remove IC4, R33, R34 completely:
(https://i.imgur.com/ORtC8hm.png)
-
In the meantime Martin added basic power and efficiency measurements. Here is the first test with DC-DC converter from eBay. So we have DC sourcing and measurement in the same chassis. We really now need el. load as the third module to have complete solution (at least for low power devices where e.g. 20-30 W of power has to be dissipated).
(https://i.imgur.com/tpVARVg.jpg)
-
Removing / not polulating IC4 / R33 / R34 could be an option. The diodes should still not cause trouble. If they would cause trouble with the highest current they would cause even more problems with the lowest current range. The diodes should still be relatively high resistance compared to 33 Ohms.
So one should still find out why the diodes cause trouble. Is there a significan common mode voltage at the current measuring channel. That is quite some voltage at the input ground (D4,D5,R31) ?
-
So one should still find out why the diodes cause trouble. Is there a significan common mode voltage at the current measuring channel. That is quite some voltage at the input ground (D4,D5,R31) ?
The JP6 is in place. Therefore the voltage is zero. Without it I can measure with DMM about 4 mVrms (AC), or 0.1 mV (DC coupled).
-
Your electronic load might be better off as a separate product. That to keep the heat out of the BB3 chassis and to allow for a higher power handling capability. All you would really need is a faceless box connected to BB3 via USB or a serial port. Keep it low cost by limiting power capability to 100 watts or less. Plus you save the third port for more interesting or complex modules.
In the meantime Martin added basic power and efficiency measurements. Here is the first test with DC-DC converter from eBay. So we have DC sourcing and measurement in the same chassis. We really now need el. load as the third module to have complete solution (at least for low power devices where e.g. 20-30 W of power has to be dissipated).
(https://i.imgur.com/tpVARVg.jpg)
-
i was wondering when the lack of slots would come up. I'm not sure how limited you are on addressable slots but keeping the same form factor for the expansion unit should be high on the required features list. This mainly to allow for easy stacking. I'd prefer off the shelf power supplies myself and would be OK with six slots if that is required to keep the box depth similar to the control unit. I'd probably would lean towards Ethernet for communications. USB could be better saved for user equipment, a printer or even an electronic load solution.
One idea is to make an expansion chassis that could accommodate up to 7 non-power modules in the same form factor as the BB3 (i.e. those that do not need a Mean Well 48 Vdc converter). Communication with BB3 or PC could be via USB or Ethernet.
However, there are a lot of things to define: whether the AUX-PS and MCU modules will remain separate, or perhaps merge them into one? Should AUX-PS/MCU will be connected behind the new 7-slot backplane or should it be a module that goes into a dedicated (8th slot), will the FPGA be added from the beginning or will we just stay on STM32, etc.
-
Could it be thermal EMF? The resistor pad - PCB solder joints make two thermocouples. If both ends are at the same temperature they cancel out. If one end is colder than the other you get a thermal gradient and a DC offset voltage. This will depend on layout, nearby components and orientation.
6mA indicates current on 10mOhm shunt is 60uV, which isn’t totally unreasonable.
Suggested test: run 5A * 15 min soak test, then disconnect the load and check the current measurement.
-
Firstly, my BB3 arrived Thursday and went together very well, all holes lined up and every nut, bolt and screw present and correct. Only two problems encountered though. When I took the MCU out of its bag something fell on to the bench. It was the USB socket, the solder was so dry it had fallen off, easy to refit but indicative of the dreadful quality of solder flow, a bit worrying for the future life exoentancy of these boards. On inspection the others look poorly flowed as well :palm: The second problem was that when powered up with either of the DCP405 modules installed the unit was in a reset loop, unplugging the modules enabled the unit to boot up ok. This was solved with a firmware update from v1.0 to v1.6.1 :-+ All working now, very happy and just waiting for the DCM224 hopefully later this month according to Mouser.
Have calibrated it with a newly calibrated DMM6500 and the accuracy and stability of the BB3 is really impressive. So far 10 out of 10, thank you to the developers, a great product. Now to start programming :-DD
With regards to the electronic load you are proposing to design, are you in danger of reinventing the wheel? There are plenty of loads available for very reasonable money already. I have used several different models over the years but this one from Tenma https://uk.farnell.com/tenma/72-13210/dc-electronic-load-prog-30a-120v/dp/2848407 is an amazing unit for around 250 euro. It is spot on accurate and comes as standard with USB and ethernet, from a business point of view could you not just utilise something like this and save a lot of development effort.
In fact spend time producing a 2 and then a 4 quadrant module that interfaces with the Tenma :clap: I already use it with a power supply to make a crude 2 quadrant test bench to run intelligent charger tests.
Thanks again for a great project, Mike
-
Firstly, my BB3 arrived Thursday and went together very well, all holes lined up and every nut, bolt and screw present and correct. Only two problems encountered though. When I took the MCU out of its bag something fell on to the bench. It was the USB socket, the solder was so dry it had fallen off, easy to refit but indicative of the dreadful quality of solder flow, a bit worrying for the future life exoentancy of these boards. On inspection the others look poorly flowed as well :palm: The second problem was that when powered up with either of the DCP405 modules installed the unit was in a reset loop, unplugging the modules enabled the unit to boot up ok. This was solved with a firmware update from v1.0 to v1.6.1 :-+ All working now, very happy and just waiting for the DCM224 hopefully later this month according to Mouser.
Have calibrated it with a newly calibrated DMM6500 and the accuracy and stability of the BB3 is really impressive. So far 10 out of 10, thank you to the developers, a great product. Now to start programming :-DD
With regards to the electronic load you are proposing to design, are you in danger of reinventing the wheel? There are plenty of loads available for very reasonable money already. I have used several different models over the years but this one from Tenma https://uk.farnell.com/tenma/72-13210/dc-electronic-load-prog-30a-120v/dp/2848407 (https://uk.farnell.com/tenma/72-13210/dc-electronic-load-prog-30a-120v/dp/2848407) is an amazing unit for around 250 euro. It is spot on accurate and comes as standard with USB and ethernet, from a business point of view could you not just utilise something like this and save a lot of development effort.
In fact spend time producing a 2 and then a 4 quadrant module that interfaces with the Tenma :clap: I already use it with a power supply to make a crude 2 quadrant test bench to run intelligent charger tests.
Thanks again for a great project, Mike
Hi Mike and thanks for the helpful feedback. I don't know if you followed (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/) what we went through in the first production batch of BB3 and, I would say, the criminal actions of the Bolek & Lolek bros, so it's no wonder that the USB socket fell out. I believe that no other problems will arise and that BB3 will serve you well.
It's strange that the DCP405 r2B11 (green PCB) was causing problems with 1.0, but it's good that it's working with the latest firmware now.
Regarding BB3 programming, I think the real fun is just coming because we are working on EEZ Flow, I will soon start writing a bit more about this in the https://www.eevblog.com/forum/testgear/ (http://[url=https://www.eevblog.com/forum/testgear/)]Test equipment[/url] section of the forum. In the meantime, feel free to install EEZ Studio and maybe play around with examples of MicroPython scripts that can be downloaded to BB3 with few clicks.
Regarding the mentioned electronic load: yes, it will look like a reinvention of the wheel, but the whole BB3 is something like that :). In terms of price, if I manage to make a new module, it will hardly be as attractive as the mentioned TENMA. Such prices are impossible to achieve with production in the EU and with modest batches (100 or less pieces). However, what such a module could offer is convenient integration with other modules with GUI just as in the case of existing modules.
By the way, @wizard69's idea from post #558 isn't bad at all. It should definitely be taken into account.
Yes, a 2- and 4-quadrant DC power module would certainly make more sense, it has been talked about for years. I guess something will happen about that sooner or later.
-
A few words about the problem with drifting when measuring current. It seems I needed to re-solder that section and clean it better. Now it looks quite fine at least for currents up to about 5 A, i.e. in accordance with the most accurate DMM currently available to me: Fluke 287 which is not a miracle of technology :).
I also tested with higher currents, i.e. 9 A and found out a bit more about how much thermal stress this can be for a fuse (rated for 10 A). I naively left it covered and without the fan working. Here's what I got:
(https://i.imgur.com/8zf2p1N.jpg)
I tested it again, but this time without a cover and with the fan on. A temperature of about 60 oC at the ends of the fuse terminal seems acceptable to me.
(https://i.imgur.com/KqTXMrd.png)
-
Good morning Prasimix, thank you for such a complete reply to my post. I was considering a major resoldering job but have decided to run with the green boards as they are and see how things progress.
Strangely the MCU, AUX-PSU and back plane are green PCB but both the DCP405 are blue PCB, what does the blue PCB material signify, are these froma different manufacturer or a different production run?
Yes I researched the forums thoroughly before ordering, I installed EEZ Studio a while ago and have been learning about this for a while, I admit I am struggling a bit with the GUI design and interfacing to a python script but the "Hello World" tutorial is a good introduction to work on from. What with this and learning the Keithley Text Script Builder (runs Lua based script) plus the fact that I am an old school hardware engineer, who is not trained in programming at all, I certainly don't seem to have enough hours in a day :phew:
The comments on the electronic load were not meant to be taken too seriously but with the interfaces available ( I forgot to mention it has RS232 as well) and the fact it readily connects to EEZ Studio I intend to explore the possibility of doing something with it when I find time :scared: I agree that a separate enclosure to accomodate more slots is looking the best way forward, if this is merely a slave module to BB3 then it could also be placed out of the main equipment rack so saving front row bench space.
I would like to think that the 2 and 4 quadrant modules become a reality as the load development progresses, the possibility of future modu was a major factor in my decision to go for a BB3. A module that can sweep 2 quadrants supply, by that I mean supply a voltage to sweep both negative and positive would be a good first step perhaps :-+
It is good the way you include the forum in the loop when developing ideas, keep up the good work,
Mike
-
Hi Mike, Please note that a number of BB3 kits from the first production batch (green PCBs) were completed with DCP405 modules from the second production batch because AssemTec Europe (aka Bolek & Lolek) never managed to deliver all the ordered DCP405 modules (thus further increasing our loss). The blue modules are version r3B3 and cannot work with the v1.0 firmware. It was not written in the building instructions which I have now corrected. I'm glad you were able to handle it yourself.
Blue PCBs come from another PCBA contractor, and as much as green PCBs are badly soldered, so much these blue ones are possibly the other extreme: from the first some components fell off themselves that I had to solder them again, from others the solder is so good that it needs to be equipped with quality heat gun and possibly a preheater plate so that the components can be detached.
MicroPython scripting certainly requires a lot of skill if you want to add a GUI. However, all the blame is on me as there is still a lack of extensive documentation for EEZ Studio and more described examples of MicroPython scripts (I believe that Chapter 16 (https://www.envox.eu/eez-bench-box-3/bb3-user-manual/16-scripting-with-micropython/) of the User manual helps at least a little). Writing quality documentation is a full time job and we should have at least one dedicated person for that. I believe this will improve as EEZ Flow (conceived as an open source alternative to NI LabVIEW and Keysight VEE) progresses as we intend to add some wizards as well and finally fully document EEZ Studio.
-
I also tested with higher currents, i.e. 9 A and found out a bit more about how much thermal stress this can be for a fuse (rated for 10 A). I naively left it covered and without the fan working. Here's what I got:
Ah, fuses... This seems to be a common problem. Check this thread, and may be my message here https://www.eevblog.com/forum/blog/eevblog-1377-the-amazing-unpredictability-of-fuses/msg3483916/#msg3483916 (https://www.eevblog.com/forum/blog/eevblog-1377-the-amazing-unpredictability-of-fuses/msg3483916/#msg3483916) . TL;DR: fuses can get very hot and don't trip reliably unless heavily overloaded. Not sure what to suggest here.
-
Basic power analysis in the AC domain has been added. This is something you can’t get easy with DMM and DSO.
The 47R in series with 20u was used as a load for the test to have an active and a reactive component. The calculated Irms can be compared to what DMM measures:
(https://i.imgur.com/hKwZLzk.jpg)
Vertical and horizontal view:
(https://i.imgur.com/iWJe60n.jpg)
Here I have a dilemma for which I would need your opinions. If we are in the AC domain the NPLC should be 0. In that case if the current and voltage are measured it should actually display the RMS values. Is it acceptable to then add the option to select AC or DC mode or should it be done in a different ("smarter") way?
-
The AC power analysis looks nice. One starts to see the limited screen size, but it is still OK.
The front-end has no AC coupling (with rather high resolution ADCs this is not a real problem) and thus no need to switch between AC and DC mode. The more normal choice is a combined AC/DC mode with multiple possible results to show. Just for a single channel one could have: DC (average), positive and negative peak values, peak to peak value, RMS (DC coupled) , RMS (DC subtracted) and possibly even more. The averaging time is a prameter that can apply to both DC and AC, though with AC it really makes sense to only choose full periods. With just numbers on the screen very fast does not make much sense.
With enough space there is relatively little need for just a simple DC and AC reading. I would more consider the combined DC + RMS the natural choice and the user decides to ignore the number he may not need.
For the RMS there is the RMS reading with full bandwidth and the std. dev of the slower DC readings which is kind of a slower fitlered RMS value.
With 2 channels combined there are additional readings like the ones shown for power and also correlation (kind of lock in function - practical use may need an expternal input amplifier, but this is not a big problem).
So one has a large number of possible results to display and choose. So it is kind of pick some 6 values to show. For convenience there may be preset combinations like the power analysis as shown, or single channel with something like DC, RMS(AC) and maybe Std. dev for DC
-
Many thanks @kleinstein. In addition to the vertical and horizontal views, the results of the power analysis will be possible to display in a maximized view, similar to what we have in post #555 (https://www.eevblog.com/forum/projects/eez-h25005-a-possible-successor-of-eez-h24005-programmable-power-supply/msg3565013/#msg3565013) where voltages, currents, powers and efficiencies are displayed.
It looks like there will be a lot of work to be done so the functionality would be gradually added through multiple firmware versions. Some of the things we will try to calculate in real time, some more demanding such as harmonics analysis can be done on a recorded sample.
Having combination preset seems like a good approach: in fact it's the answer to my dilemma, but I see that for a start it would be good to add next to DC and RMS and Std.dev for DC.
I will need to review what the power meters of others have to offer, if anyone has a particularly interesting/attractive model to recommend, please let me know.
-
... and the power measurement for AC/DC converter (my abandoned CF-DIC project) directly connected to 230 Vac:
(https://i.imgur.com/amJGUQM.jpg)
Same thing for off-the-shelf Mean Well LRS-150F-48 used in BB3:
(https://i.imgur.com/ZyAi8EX.jpg)
-
In case anyone is concerned about the safety of the connection to the 230 Vac mains, here is one close-up image. Everything is properly insulated:
(https://i.imgur.com/XjVlHMi.jpg)
-
The connectors are rated for 250 V, but at some areas (e.g. around Q1) the clearance does not look like it is up the standards for mains safety. It depends a bit which inputs are actually used. It can work, but there is some risk and there could be quite some damage from an arc over.
-
The connectors are rated for 250 V, but at some areas (e.g. around Q1) the clearance does not look like it is up the standards for mains safety. It depends a bit which inputs are actually used. It can work, but there is some risk and there could be quite some damage from an arc over.
You're probably talking about AFE1, this is AFE3. Here is how it looks like:
(https://raw.githubusercontent.com/eez-open/dib-mio-afe3/master/Images/EEZ_DIB_AFE3_PCB_top.png)
Probably I should cut PCB over L1, R1, R3, R5 and between X1 (pin 1 and 2) and F1 to get extra clearance.
-
The 2 isolated inputs (should be the 4 lower pins on the board and the 4 upper pins on the connector when build into the BB3 should be OK for mains. It is the other 2 input where the spacing is too close for mains, especially around Q1 and R13.
The board picture also shows the weak point at the link from R35 to R32. Ideally R35 should have separate contacts for current and voltage and R32 connected to the voltage reading contacts. With more solder for this link the drift in the current may be reduced.
Another point I just notices is that the lowest current range (33 Ohms shunt R30) may have problems with 48 mA, as the diodes would start conducting. So the maximum usefull current would likely be lower, more like 30 mA.
For a different reason the mid range is likely also not really useful to 1.2 A as was noted in the schematics - likely more around 0.5 A. With more current the FETs may get quite warm and help heat up the resistors. One may have to consider a smaller fuse (e.g. 630 mA).
-
Good morning Prasimix, another great project, the BB3 seems the answer to everything ;)
I notice that, I believe, the Q is not correct but I assume this is just a software fix as the others look reasonable enough, is this so?
With all these new features and modules coming on stream a big extension box may be needed :-+
Do you have any production time line for various modules yet?
Regards Mike
-
It is the other 2 input where the spacing is too close for mains, especially around Q1 and R13.
OK, but we have OK2 to disconnect path to Q1 when AIN3 input is in voltage mode. Do we still need some correction in that area?
(https://i.imgur.com/JveAaaF.png)
The board picture also shows the weak point at the link from R35 to R32. Ideally R35 should have separate contacts for current and voltage and R32 connected to the voltage reading contacts. With more solder for this link the drift in the current may be reduced.
Fixed:
(https://i.imgur.com/cRYs1oX.png)
Another point I just notices is that the lowest current range (33 Ohms shunt R30) may have problems with 48 mA, as the diodes would start conducting. So the maximum usefull current would likely be lower, more like 30 mA.
For a different reason the mid range is likely also not really useful to 1.2 A as was noted in the schematics - likely more around 0.5 A. With more current the FETs may get quite warm and help heat up the resistors. One may have to consider a smaller fuse (e.g. 630 mA).
Fixed, R30 changed to 20R (22R was on the border).
-
Good morning Prasimix, another great project, the BB3 seems the answer to everything ;)
I notice that, I believe, the Q is not correct but I assume this is just a software fix as the others look reasonable enough, is this so?
With all these new features and modules coming on stream a big extension box may be needed :-+
Do you have any production time line for various modules yet?
Regards Mike
Yes, it's possible that Q is not calculated correctly, that is work in progress.
We initiated a test production batch of new modules, i.e. PREL6, SMX46, MUX14D and MIO168 + AFE3. They should be ready next month somehow in line with the opening of our web store where it will be possible to buy them (as well as assembled BB3).
-
With a maximum range to 240 V peak, the input 3 is not really suited for leasuring mains and not meant for this. It would still be good if it would normally survive an accidential connection to mains (230 V AC). For this the photomos relay does not offer much protection, as the porblem may happen with current measurement, so the clearance should also be behind Ok2. It is only past Q2, that there should be no higher voltage. One may still want clamping diodes (e.g. BAV199) parallel to R15.
Anyway the input 3 would still not get a CAT2 rating.
In addition the main part of the MIO168 board is also not that much protected. So it would need some special care to use mains with the 2 isolated inputs.
I see that there is not really much space left on the AFE3 board, so one may have to compromise in some areas, possibly even dropping current measurement for the input 3 alltogether.
For the current shunts with input 4, the middle shunt is a little tricky: The diodes used for the protection limit the voltage to some 1.5 V ( one could lower this a little by using Schottkey diode for D8 + D9, not that practical for D6,D7) or so. So worst case there can be quite some power / current, at least until the fuse blows. This may requite a relatively high power rating for the shunt. So it would help if the second current range would be smaller. A lower value shunt makes things only more difficult.
The other point is that the current would also need to flow through the FET switches and these are also limited. The FETs would also add to the heat near the shunts and there current rating is only valid with adequate cooling. In some respect the resistance from the FETs also helps in limiting the power, but they still contribute to the burden and overall heat. With some 1.5 A max for the FETs this would requite at least some 1 Ohms total resistance and thus more like at least 0.8 Ohms for R32. So with the given MOSFETs the maximum would be at around 500 mA for the range.
Finally there are 3 shunts to covver the whole current range. With coarser spacing one could get more sensitivity to low currents. The ADC has quite high resolution and could thus get away with the shunts well more than a factor 10 appart. So I would more consider ranges of 10 A (maybe less for good accuracy), 300 mA and 10 mA or even 10A , 100 mA and 1 mA.
-
With a maximum range to 240 V peak, the input 3 is not really suited for measuring mains and not meant for this. It would still be good if it would normally survive an accidental connection to mains (230 V AC). For this the photomos relay does not offer much protection, as the problem may happen with current measurement, so the clearance should also be behind Ok2. It is only past Q2, that there should be no higher voltage. One may still want clamping diodes (e.g. BAV199) parallel to R15.
No, input 3 with only 240 V peak cannot measure 230 Vac, whose peak is 325 V. That is clear. Maybe it’s not clear my listing of ranges, and maybe I should write Vpp everywhere or specify an RMS value so it would be 170 Vrms or Vac if I may say so.
Anyway the input 3 would still not get a CAT2 rating.
In addition the main part of the MIO168 board is also not that much protected. So it would need some special care to use mains with the 2 isolated inputs.
I see that there is not really much space left on the AFE3 board, so one may have to compromise in some areas, possibly even dropping current measurement for the input 3 altogether.
Since the Cat II is the minimum that should be met to directly measure mains voltage, I’ll probably need to rearrange the PCB a little better. For the purposes of certification, I see that it needs to survive a test of 1390 Vac for 5 seconds and a pulse of 2500 V.
My question here is should some extra protection be placed on the input to survive 2500 V surges? I don't know how DG212 switches will survive this. Maybe to protect them with TVS?
Your idea to take out the current measurement on AIN3 now makes a lot of sense. This will provide space on the PCB for the components to be arranged differently. By the same logic I think I will throw out the voltage measurements on AIN4 so it will be just a current input.
The MIO168 module itself does not have any special protection other than being entirely floated. The mains voltage insulation relies on the quality of the 8-pin connector (WE 691322310008 (https://www.we-online.de/catalog/en/search?search=691322310008)) on the AFE and it is rated 300 Vac. What else could there be done?
For the current shunts with input 4, the middle shunt is a little tricky: The diodes used for the protection limit the voltage to some 1.5 V ( one could lower this a little by using Schottky diode for D8 + D9, not that practical for D6,D7) or so. So worst case there can be quite some power / current, at least until the fuse blows. This may requite a relatively high power rating for the shunt. So it would help if the second current range would be smaller. A lower value shunt makes things only more difficult.
The other point is that the current would also need to flow through the FET switches and these are also limited. The FETs would also add to the heat near the shunts and there current rating is only valid with adequate cooling. In some respect the resistance from the FETs also helps in limiting the power, but they still contribute to the burden and overall heat. With some 1.5 A max for the FETs this would requite at least some 1 Ohms total resistance and thus more like at least 0.8 Ohms for R32. So with the given MOSFETs the maximum would be at around 500 mA for the range.
Finally there are 3 shunts to cover the whole current range. With coarser spacing one could get more sensitivity to low currents. The ADC has quite high resolution and could thus get away with the shunts well more than a factor 10 apart. So I would more consider ranges of 10 A (maybe less for good accuracy), 300 mA and 10 mA or even 10A , 100 mA and 1 mA.
High range with a current shunt of only R010 makes no difference whether 10 or less amps will be measured because even with a maximum PGA = 12 it is still only 50% FS of the ADC. Maybe that shunt can double but we’ll have a higher burden voltage.
The real problem is Q3, Q4 heating for higher currents (e.g 900 mA). I could either put bigger MOSFETs there or maybe better shorten the mid range to say 500 mA. With the currently selected 0R22 and PGA = 2 we would have pretty well covered that range.
-
The DG212 switches would not survive 2500 V directly, but they can take quite some current surges to the internal parasitic diodes. So if the resistors in front would limit the current they should stand a 25 mA surge. This may cause a upset in the function and maybe a latchup, shorting the supply, but the supply is relatively weak, which is a good thing. It may need some diodes / TVS to prevent the supply to rise too much.
Getting a proper CAT2 rating is hard for such a modular system and especially for a crammed board with so many functions in a limited space.
At least this would requite incompatible connectors (e.g. larger spacing one for the high voltage part).
A mixture of protected and low voltage only parts is still a problem and may be difficult with the standards.
A possible option would be to have the card inside the BB3 low voltage only and have a connector that also provides power. So the input part with AMC33.... for channels 1 and 2 would be in an external box, that than can have proper mains isolation. So the channels 1 and 2 in the BB3 box would be only slightly protected voltage inputs with additional power for either the high voltage box or maybe an alterntive input like a small TIA and photodiode.
For tests like measuring a SMPS one would ideally use an isolation transformer and would thus not be directly mains connected. Still there is a chance for users cutting corners.
For the current ranges the shunt for the 10 A range has to be low value to limit the heat. Ideally one would a much larger form factor, but this needs quite some extra space and has higher costs. The current limit is not a hard limit: short peak may be higher and at 10 A the accuracy is likely allready reduced. Chanes are the best accuracy would be around 3 A or so, which is OK. I understand that 10 A would be nice, so that the combined current of 2 power modules could be measured without much risk for the fuse. So reducing the high current range is not really an option. Cutting the mid current range is less of an issue and makes things easier. So I don't understand the step in reducing the shunt from 0.33 to 0.22 ohms. The protection more wants a shunt in the 1 Ohms range and thus more like 200 mA for the 2nd range.
-
Cutting the mid current range is less of an issue and makes things easier. So I don't understand the step in reducing the shunt from 0.33 to 0.22 ohms. The protection more wants a shunt in the 1 Ohms range and thus more like 200 mA for the 2nd range.
The main reason for choosing the 0R22 shunt is that it is the highest value that exists in the ROHM GMR series (i.e. GMR100HTBFIR022) which has an excellent TCR, and 3 W dissipation in 2512 which I believe would survive a fuse break which we can reduce now from 1.25 to 0.63 A if the mid range is reduced to 500 mA.
-
The availability of good shunts is an argument I have not looked at before. Still it would likely need larger FETs. The current FETs (BSS214) would likely not survive the time until a 2 A surge blows a 600 mA fuse. Lower resistance FETs are an easy change.
With some 2 V, the peak current for the shunt may reach some 5 A before the diodes really kicks in.
-
Good morning Prasimix, happy to say my DCM224 arrived from Mouser on Tuesday. All installed with no problems :-+
My question is that when calibrating voltage and current how many cal points would you suggest and at which values. The reason I ask is that I added a few extra cal points but am now having issues with it reading way out below 100mA and voltage not really useable below 1.6v. This sems the same on both channels so suspect it is to do with my calibration. I followed the same method as for the DCP405s (as in the instruction manual), both of these are absolutely spot on accurate. I realise the DCPs are a more capable supply than the DCM224 but would like an indication of the performance I should expect from the DCM224.
Thanks for any advice you can offer.
#Regards Mike
-
Sorry, one more question I forgot, below 2.5 volts (approximately) the current limit operates correctly but the LED does not change to red, this is the same on both channels. Not a complaint just would like to know if this is expected.
Thanks
-
DCM is not even closer to DCP, especially when comes to current limit accuracy, so think of it as auxiliary power for not sensitive loads. What you're experienced is not related to calibration, so calibration is two points should be enough.
Some of DCM could report about 100-150 mA even without any load connected, that is still a mystery to me. It is not offset value, but simply "idle" value, and it starts to display correct value as current increases (i.e. over 100-150 mA).
-
Sorry, one more question I forgot, below 2.5 volts (approximately) the current limit operates correctly but the LED does not change to red, this is the same on both channels. Not a complaint just would like to know if this is expected.
Thanks
The problem with CC is that the LT3763 does not have a built-in mode indication, so this is done on a trick with a single comparator and guessing the mode is not accurate in all cases.
-
Thank you for the information, much as I thought.
I have now recalibrated voltage and current on both channels with 2 cal points and it seems much more accurate.
As usual, impressed by the product and support :-+
Regards Mike
-
The first preview of func. generator: BB3 as half- or full-wave power rectifier. It can generate both 100 and 120 Hz, up to 80 V, or 10 A (with two DCP405)
https://www.youtube.com/watch?v=isNy7CYQwT0 (https://www.youtube.com/watch?v=isNy7CYQwT0)
-
Hi, a simple question if you know the answer, hopefully someone can help.
When I try to assign my digital io to UART mode the option is not listed, what am I doing wrong?
I am running 1.6.1 firmware
Thanks in advance, Mike
-
You're too fast :) UART is coming in v1.7, you can expect it in a week or two.
-
Ooops, sorry about that, it is shown in the online instruction manual though |O
Thanks for the info, look forward to 1.7 coming Mega 25609 at the ready :-+
Regards Mike
-
Sorry, for confusion. I'm usually try to keep in sync online manual with the latest firmware revision, but due to some "difficulties" with new website I published it prematurely.
-
Not a problem, thanks for the instant support, loving my BB3 8)
Over the last 50 years I have used numerous different power supplies but this is way ahead of even most of the very latest. I had never even considered some of the features offered but now I am using them I wonder how I ever managed without them. In terms of bang per buck I don't think this can be bettered :-+
-
Thanks for the kind words. Now we "only" have to find a way how to spread the word and generate some sales that we can continue materializing other ideas that popped up during development and what other backers already suggested here and on the discord server.
-
Regarding the R4 failure issue I have had a look at mine with my thermal imager and the resistor is running at ambient, on a fluke 189 ac voltage is only 1 volt across it, on a scope it is showing very short duration pulses approx +-3v. One thing I did notice though is that the Live and Neutral wires to the Meanwells are reversed compared with the schematic. Under very close inspection R4 does look very slightly discoloured compared with R6, one other point is that I initially only had two modules installed and then a few weeks ago added a third so now running three Meanwells, could this be of any significance :-//
-
Got a few pics of the waveform on R4, doesn't look as though it would bother a 2watt resistor, or am I falling into a trap for young players, as Dave would say?
EDIT- this is the waveform ACROSS R4, just to be clear :palm:
-
It is strange, perhaps you got Mean Well of premium quality :). Anyway, the best way to check if it is overheating is a thermal camera... you just need to have it. If you think that the problem is present, add a 4u7/X2 as stated on GitHub.
-
As I said in my post I have looked at it with my thermal camera and it is running at ambient now although it looks as though at some time in the past it may have been thermally stressed by the v ery slight discolouration. Could the recent addition of a third Meanwell have made a difference I wonder |O
-
Huh, odd number of Meanwell's to cancel odd harmonics? :-//
-
Well the P.F. is a disaster that's for sure :-DD
-
Good morning Prasimix, I wonder if you can help with a problem I have with my BB3?
I was using it this morning, all 100% normal. I had to go out for a while so did a proper shutdown, ie select Shutdown and wait for the instruction to turn off mains switch, but on my return I turned on the mains switch, as normal, and it now just has the standby light on and does not respond to screen tap, HELP please |O
Regards Mike
P.S. one other clue, maybe, is that a couple of days ago it hung on the start up screen with just the first OK lit, power cycling restored normal operation so I did not think any more of it.
-
It's probably in standby mode, or display is turned off: please click and hold anywhere on the dark screen to see what will happen.
https://www.envox.eu/eez-bench-box-3/bb3-user-manual/6-getting-started/ (https://www.envox.eu/eez-bench-box-3/bb3-user-manual/6-getting-started/) (See Section 6.2).
Regarding Display On/off check https://www.envox.eu/eez-bench-box-3/bb3-user-manual/9-system-functions/#bb3_man_power_control (https://www.envox.eu/eez-bench-box-3/bb3-user-manual/9-system-functions/#bb3_man_power_control) (Section 9.6.)
-
Firstly, thank you for lightening quick reply, other manufacturers could learn a lot!
Naturally I had tried those things before bothering you.
A brief recap of problems I had on delivery, this has a green cpu module, aux psu and backplane with blue DCP405s and DCM224. On receipt the USB socket had fallen off the cpu board and was loose in the bag, this was refitted with no problem. It would then not boot with PSU modules fitted, cured with firmware upgrade.
I have now opened the BB3 and gently tapped/pressed the cpu, no reaction. Power cycled and now all working again, looks as though there may be more poorly soldered joints on the cpu, what do you think.
I have checked that it now also goes into and out of standby as expected :-//
-
Hm, green PCB comes from notorious "Bolek&Lolek" manufacturer in Poland. Fallen USB socket was reported by multiple backers, and fortunately all of them managed to solder it back successfully. If something else is badly soldered on your MCU module is now hard to say, I spent considerable time trying to test all modules before shipping, but as we can see many didn't survive shipping.
Please keep an eye on it and report here if there are more problems or for a faster response on our Discord server. Also pay attention whether there is any suspicious message in the Event log (if there was an error the icon will change color to red).
-
Will do.
I did note there were scratches and scuffs on the underside of the cpu board while refitting usb socket, not a good sign but it has been working fine for a couple of months now, thanks for the information.
Nothing red in event log.
Regards Mike
-
@Make G and others, could you please report similar issues in the future under https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg3586888/#msg3586888 (https://www.eevblog.com/forum/crowd-funded-projects/eez-bench-box-3-sequel-to-eez-h24005/msg3586888/#msg3586888) to build up evidence if we eventually end up in court (certainly not because I would initiate it!).
-
Hi Prasimix, further to posts 601 - 602 a week or so ago, in this topic, my BB3 with the notorious green board is still causing me serious problems.
It still will not always power on correctly, sometimes showing a black screen with standby light on, power cycling ususally corrects this, but far more seriously it resets completely and randomly with no input from me. By this I mean it can be just turned on doing nothing but with the outputs turned on, not connected, I will hear a beep and when I look across the workshop the BB3 has reset, I see the ethernet symbol flash as it reconnects and all outputs are now off.
This is really causing me doubts about the useability of this power supply, certainly for long term tests and analysis.
PLease could you offer any help or, hopefully, a solution.
Thank you and regards Mike
-
Hi All
I have got one of the crowd supply bare board kits that until today had been working okay, it is setup with 3 DCP405 modules (all originally from the junkyard pile) and is running firmware V1.7.
I was using it today to emulate/replicate a battery charger power supply for a power tool and as such had setup channel 1 to output 21V with a 360mA Current limit (Down Programmer disabled) and had it charging the battery for 3 or 4 hours when it shut off with an "AUX OTP Tripped" error.
I have opened the unit up and found that R4 on the AUX-PS module was burnt (also slightly charred the surface of the PCB just below it), my research lead me to issue #108 on github, having seen the information there I replaced the resistor and added a RC snubber to one of the Meanwell power supplies as suggested but still have issues.
It appears that it doesn't matter if I how many Meanwell supplies I have connected (as long as it is at least 1), R4 will start to nuke itself within 2 or 3 minutes, it will do this even with all ouptuts turned off and nothing external connected, The second time I replaced it I tried changing the resistor for a 3W through hole version of the same resistance.
What I am wondering is if this is likley to be an issue with the Triac Q2 or something deeper?
Also should I forget trying to repair this AUX-PS module and just replace it with a newer version?
I don't know if it makes any difference but my incoming supply voltage is always at the top end of the spec - we usually get approx 251VAC at 50Hz.
Thank you
Jem
-
What I have found so far is that the problem is related to Mean Wells. This should be checked by putting a simple load (say a light bulb) instead. Also maybe you should check/replace OK1.
-
I forgot to mention if someone is interested we have in stock bare PCBs (SKU 00052 (https://www.envox.eu/product/aux-ps-bare-pcb/)) and assembled r3B5 modules (SKU 00078 (https://www.envox.eu/product/aux-ps-module-r3b5/)) which don't use triacs.
-
I have replaced OK1 but it is still doing it (although it is a bit slower than it was), I think that the long term fix will be to replace the AUX-PS board with the newer version, the only problem with that is that I am not VAT registered so can't buy from prasimix and will have to get some blank boards made from the gerbers.
Jem
-
Sorry if I am out of order on this, but...
I am not VAT registered so can't buy from prasimix
Why does one need to be VAT registered to buy from prasimix?
-
That's apply only for UK after Brexit, since we are not able to collect UK VAT. Sorry for that.
-
Oh, that's annoying.
There's a small airfield not 20 miles away, and France is a short hop from there. Maybe I should get a pilot's license :)
-
Oh, that's annoying.
There's a small airfield not 20 miles away, and France is a short hop from there. Maybe I should get a pilot's license :)
... or you can get direct flight to Zadar where is our warehouse (return ticket is €27) :box:
(https://i.imgur.com/FMDfMjI.png)
-
That is seriously tempting!
-
Right, it's cheaper then DHL shipping ;)
-
Indeed, and two PSUs would fit in hand baggage. Hmmm.
-
There seems to have been some progress here recently, it says BB3 is supported. Has anyone had a chance to try it so far? Two facts should change: the number of channels to be from 1 to 6, and place a link to a new (https://www.envox.eu/eez-bb3/) page.
https://sigrok.org/wiki/Envox_EEZ_Bench_Box_3 (https://sigrok.org/wiki/Envox_EEZ_Bench_Box_3)
(https://i.imgur.com/asj6f7b.jpg)
-
@Jan28 is progressing well with electronic load module for BB3. You can follow his work on Discord: https://discord.gg/dhYMnCB
(https://i.imgur.com/nl0uLbq.jpg)
-
Mike G - Are you UK? (You post a UK Farnell link). If so, how did you import your BB3?
Thanks
-
Another great BB3-ready module designed by @wergor whose progress you can follow at: https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/ (https://www.eevblog.com/forum/oshw/libretimebase-a-controller-distribution-amplifier-for-rubidium-frequency-stds/)
(https://i.imgur.com/OjMQfki.jpg)
-
Mike G - Are you UK? (You post a UK Farnell link). If so, how did you import your BB3?
Thanks
Hi m0rjc
No I am not currmtly in the UK, I am in Europe, but have access to the UK Farnell website.
I believe you can only purchase from Envox with a UK VAT number.
Regards Mike
-
Hi, I live in The Netherlands and just tried to order the BB3 via Mouser but they say they cannot ship it due to regulations. I thought that living in the EU meant we could freely buy and ship goods across the EU? With the BB3 manufactured in the EU there shouldn't be a problem. Or does NL or Mouser have special rules?
-
Mouser is an US corporation and since last summer, due to the new EU regime, they have stopped exporting everything that does not have a CE certificate. I tried to explain to Mouser that the BB3 is a kit and not an assembled device but without success.
-
Hi S0urceror, I sympathise, I have the same problem. Going back a few months Mouser was definitely the "go to" supplier as they shipped free with all duty paid to Europe, I managed to buy three over a few months, they changed the rules while my last purchase was on the flight over here, just made it :-+ Hopefully if anyone finds a way around this crazy problem they will post it here.
Regards and good luck in your search (if you manage to buy one you will not be disappointed) Mike.G
-
That explains. Thanks. What are alternative ways to get hold of one?
-
I really don't know the answer, I have given up trying. Crazily it seems impossible to buy one in Europe due to not being CE marked, the world has gone mad :-//
-
Yesterday I emailed Crowd Supply asking why BB3 was not shipped to EU without CE marking even though it is a kit, this is their reply.....
Hello,
Thank you for contacting Crowd Supply! The CE regulatory framework applies to nearly all products sold on Crowd Supply, whether they are kits or finished products. While it's true that individual components (i.e., capacitors, microchips, etc.) do not fall within the scope of CE, any assembled circuit board generally does fall within the scope of CE. For example, a manufacturer of computer video cards would need to CE mark their cards before the cards could be sold directly to consumers, even though the video card itself could be considered as part of a kit.
Regards,
Tanner
Oh well :-//
-
Maybe a reshipper could be the solution. If a couple of buyers joined together the rate might even approach reasonable!
Or perhaps an Easter holiday to certain foreign parts might acquire a little bit of extra weight on the return.
-
I would be up for that
I also have a friend in US who could forward on to us in EU but I would rather wait for June when my tax money comes in.
-
Regarding CE, and I am sure it has been asked before albeit I haven't seen it......can't the guys not self-certify the BB3.......It's a good part of the whole CE system.....?
Ian
-
Looks like Elektor has it, and it's in the spring sale-out action.
https://www.elektor.nl/envox-eez-bench-box-3-bb3-2-ch-modular-test-measurement-solution (https://www.elektor.nl/envox-eez-bench-box-3-bb3-2-ch-modular-test-measurement-solution)
-
Thanks Morris !
-
I think you can buy stuff directly from Denis, just ask him on discord. Or, he also has a webshop: https://www.envox.eu/store/ (https://www.envox.eu/store/) .
-
Bench Box 3 in action with @IanJ:
👉 https://youtube.com/watch?v=S8okMaAKYiw
-
hello friends, i have to decide which to get:
* rigol dp832
* this base chassis + then add channels to it
liking both of them, for what they are. basically for small home lab want a dependable psu with some exta niceties (such as for charging batteries and other such convenience etc). and to be multi channel too - so of course the dp832 fit the bill pretty well
however last week saw this BB3 for the first time. and can see it might also be worth investigating too. but what do you guys think? either/or, one or the other? or both, then which one to get first?
i ask because the BB3 is more difficult to understand being such an open platform. and with many more option. but assuming i bought the base unit. then added my own (home made) power channel add in cards myself? that would seem like a similar ballpark cost? then how would these units compare?
-
I have both and rarely use the DP832. But that's mostly because it is on my main bench where the choice is the Rigol or a HP6632B - the HP has a worse user interface but somehow gets most usage. The BB3 is on my desk where it powers whatever I'm programming.
If I could afford it, I'd buy another BB3 to replace the Rigol. I wouldn't mess about making my own power channels though, unless they did something which the available ones don't (which seems unlikely).
-
Hi fellow-BB3-fans,
I have 2x DCM220's available for sale if that helps anyone add extra power supply output channels for a low cost.
(Apologies if this cross-posting is not allowed)
https://www.eevblog.com/forum/buysellwanted/fs-2x-envox-dcm220-power-supply-modules-for-bb3-chassis/new/#new (https://www.eevblog.com/forum/buysellwanted/fs-2x-envox-dcm220-power-supply-modules-for-bb3-chassis/new/#new)
If of relevance, please reply in the for sale thread.
All the best,
Dan
-
Hi,
Does anyone have any (of the five different types) of complete PCBs spare that they want to sell?
I've got the case and bare PCB kit and would like to skip trying to source (component shortages) and solder (the STM32 especially) them myself.
Thanks.
Richard
-
Wonderful progress on the open hardware BB3-CM4 project (funded by NLnet). A few pictures, courtesy of Intergalaktik (https://intergalaktik.eu/).
Feel free to check design, and follow progress on GitHub: https://github.com/intergalaktik/bb3-cm4
(https://i.imgur.com/CEfBjqE.jpg)
(https://i.imgur.com/S38aAbD.jpg)
(https://i.imgur.com/JziOhIg.jpg)
-
Seeing is believing: BB3 GUI runs on Raspberry CM4! And it is very fast, i.e. responsive! 💯
One crazy detail: the original BB3 has a 480x272 resolution display, and the CM4 uses an 800x480 display. Resize is done in a few clicks in free and open source EEZ Studio (not quite ideal, but more than satisfactory for presentation needs)!
https://www.youtube.com/watch?v=SRumQEken4A (https://www.youtube.com/watch?v=SRumQEken4A)
-
so prasmix, does this mean that cm4 can (in future) replace stm32 mcu within bb3 control board? ... however that would need new control board pcb right?
since last time (months ago) i asked and you said no changes, for sake of necessary certifications / testing / approvals
-
The fact that we are limited with CE certification in case we resume the production of completed BB3 does not mean that others cannot have great fun modifying it :). We will see how things will go further, but this design is an excellent candidate for a successor, whether the CM4 Raspberry module is used or, e.g. a new one based on STM32H745.
-
I spent some time to assembly the first EEZ KiCad library that includes parts for MCU module imported from Eagle. I had a tough time trying to adjust the paths to the folders (3d models, etc.) and I don't know if I really succeeded. Feel free to download it here: https://github.com/eez-open/eez-kicad-library
When installed, it appears in the KiCad Plugin and Content Manager:
(https://i.imgur.com/SKXbjrL.png)
By the way, I played with the import from Eagle and started with the MCU module in which the following modifications were made:
- Replaced the Ethernet PHY
- Replaced mini-USB AB with USB-C
- Replaced the battery with a supercap
- +5V output on front panel with programmable switch and current limit
- Added isolated RS485 port 🙂
It would look something like this:
(https://i.imgur.com/FWWdBDk.png)
(https://i.imgur.com/rejdzg9.png)
Migration to USB-C requires an additional IC because the new specification does not support ID pin and OTG as it was the case with previous specifications. I found that TI has two chips that solve that problem: one is programmable via I2C (TUSB320) and the other is non-programmable TUSB321, which I chose, which may not be the best choice (I have to eventually try it).
Why RS485? Because there was already interest in communicating via it in environments where there are, for example, PLCs and similar devices that use RS485. Why isolated? Well, because efficient insulation is easy to obtain and protect BB3. Since the isolated power supply for the B-side was added, the question arises whether to add also isolation to the existing I/O on the front panel of BB3.
-
We started with the migration of BB3 modules to KiCad 7. The first published is the AUX-PS module.
https://github.com/eez-open/modular-psu/tree/master/aux-ps
(https://i.imgur.com/6pqTjaD.png)
-
Do you have anything to do with the Mouser page: https://www.mouser.ca/ProductDetail/Envox-Experimental-Zone/CS-BB3-08?qs=A6eO%252BMLsxmSeQD1tVPyeKw%3D%3D (https://www.mouser.ca/ProductDetail/Envox-Experimental-Zone/CS-BB3-08?qs=A6eO%252BMLsxmSeQD1tVPyeKw%3D%3D)
They show a full supply which is obviously not the case as on github you've stated its just one module (DCM224).
-
Do you have anything to do with the Mouser page: https://www.mouser.ca/ProductDetail/Envox-Experimental-Zone/CS-BB3-08?qs=A6eO%252BMLsxmSeQD1tVPyeKw%3D%3D (https://www.mouser.ca/ProductDetail/Envox-Experimental-Zone/CS-BB3-08?qs=A6eO%252BMLsxmSeQD1tVPyeKw%3D%3D)
They show a full supply which is obviously not the case as on github you've stated its just one module (DCM224).
Yes, CS-BB3-08 is confirmed by prasimix as just the DCM224 module.
I reported the bad descriptions to Mouser over a year ago, and they never changed it.
-
Here is a table of Mouser part numbers if it will help anyone when ordering what they still have in stock. If we succeed in resuming production of BB3, completely new part numbers will appear for assembled units and not kit versions, as was the case until now.
(https://i.imgur.com/8D5E76Z.png)
-
You can now follow @Jan28 (https://www.eevblog.com/forum/profile/?u=450501)'s progress with the electronic module in the BB3 EEZ-DIB form factor also on GitHub: https://github.com/fietser28/EL-Load (https://github.com/fietser28/EL-Load)
Fantastic work!
(https://i.imgur.com/13J7ffO.png)
-
@goran.mahovlic from Intergalaktik.eu (https://intergalaktik.eu/) finalized STM32H7 module in CM4 form factor for BB3-CM4 module. Project is now available on GitHub: https://github.com/intergalaktik/bb3-cm4/tree/main/EEZ_BB3_CM4_H7
(https://i.imgur.com/mULbL5F.png)
(https://i.imgur.com/FagoQcQ.png)
-
Hi All
I am finally getting round to finishing the assembling of some more modules for my 2nd BB3 and have one that ia throwing an error message, I haven't managed to find a list of the possible error codes and explanations anywhere so thought I would ask on here.
The module in question is a DCP405 R3B3 and the message that I am getting is is "Ch1 IOEXP fault match detected" with a continuous rapid beeping and inability to close the message, this has also sometimes caused the BB3 to enter and exit standby repeatedly even though the power on self checks come back as okay.
Does anyone know what the code set criteria is for this fault code? I assume that it is one or more of the input signals to IC14 that it is moaning about but not sure which one.
For info incase it matters - I am using an R3B3 MCU with firmware V1.7.6
Thank you
Jem
-
Check if your PCB has JP2 on bottom side, and if yes then cut it and check once again. Be also sure that I/O Expander IC is soldered correctly.
-
Yes I had JP2 on the bottom - I have another 3 of these modules to complete - will I need to cut it on all of them?
The soldering on the IC looked okay but when I tested between adjacent pins there was a short between pins 1 (~set_DP) and 2 (OE) - must have been a really small whisker as I still couldn't see it at 30x magnification - Looks like my next investment might have to be a microscope.
-
You can cut JP2 if you wish, that is RESET line that comes from MCU and in some rare situation could generate instability hence it's removed in the latest revision.
-
Hi,
Really like the retractable feet on my BB3 and want to use them on a home made design for something else......where can I get them?
BOM just says:
A-951-A-0-G-0
Adjustable feet (pack of 2) Altinkaya, Turkey
Ian.
-
These?
https://www.altinkaya.eu/shop/a-951-tilt-foot-set-4pcs-set-729#attr=1072 (https://www.altinkaya.eu/shop/a-951-tilt-foot-set-4pcs-set-729#attr=1072)
It seems you can buy direct.