The Design Process of Building a DIY DC Dynamic Load
The conclusion of a very long time investigating the building of a combined AC-DC Dynamic Load (DL) led me to the realization that this is not really possible. At least not without making drastic compromises about accuracy and precision. The AC measurements do not need to be very precise and are, in my case, only occasionally needed, but DC measurements typically need to have the highest precision, stability and accuracy.
The attempts for this combined AC-DC DL are described in another Blog post. There is a lot of information there, so get some fresh Java and have a look. https://www.paulvdiyblogs.net/2022/08/dynamic-acdc-load-cc-cv-cw-batt.html
The above picture shows a stage in the development with the new DC DL prototype as the basis.
To help design this new version of the instrument, I asked for the help of my friend Bud. He is a real designer, and we've done a number of projects together, like the high current RPi UPS, the VBA Curve Tracer and the 100MHz Differential Probe all described on this Blog in different posts.
Bud started a Blog post on Hackaday mostly for the hardware design aspects that can be found here: Dynamic Electronic Load | Hackaday.io I have added that same information in a section below here, so it's all together in one place.
At this moment, we have finished the design of the new version and the final board V5.1 has been produced by my sponsor PCBWay.
Although we have a stable fully working system, I'm still tweaking the software side a bit, because this instrument will do some things a bit different, compared to many other DIY DL designs.
I'll explain that later in more details but here are some pictures to hopefully wet your appetite from the previous prototype V5: (this is almost the final version, read on...)
Specifications:
- Input voltage: 1..100VDC.
- Reverse polarity protection to -100V and a 10A fuse.
- DUT is disconnected by a relays for invalid inputs like reverse polarity.
- Maximum current of 10A @ 40V
- Maximum power 180W @25 degrees ambient temperature (heatsink temp 85C)
- Off state DUT current 1.9uA at 2V, 57.7uA at 60V.
- Volt Accuracy: 0.4%
- Current Accuracy: 0.4%
- Power input: 12VDC Wall-wart 0.5A with reverse polarity protection to -24V and PTC fuse
- CC, BT & CV modes with real-time operation in hardware.
- CP and CR modes have active regulation supported in software (resolution +/-156uA).
- Pulse/transient mode supported by an external Function Generator. 5V=10A
- Current monitoring with a DSO. 1V=10A
- GUI: 128x128 OLED 1.5' color display and a rotary encoder with dual button functions.
- Two temperature controlled fans.
- Protection for over voltage, over current, over power and over temperature limits
- Overall dimensions: 21cm long, 18cm wide and a height of 118cm.
- Weight: approx. 1110 grams
Testing the V4 prototype
This earlier version for the AC-DC attempt is still using the Arduino Nano as the processor. It also had provisions for an on-board transformer, but that got too hot so I took it off.
The Nano is not fast enough to process the CP and CR modes, which are regulated in software. At this time, I was planning on implementing the CV mode in software as well, but that did not work at all with this prototype. While looking for a faster processor, I eventually settled on the ESP32. It has all that we need, even though we won't be using the BLE and WIFI capabilities.
This was the first time I really started to work with the ESP32 so I started to experiment with it. This processor is not only much faster than the Arduino Nano, it has a dual core and it has a native RTOS. (real-time operating system) I was hoping that these major features would overcome the Nano limitations.
In the picture below you can see how I tested the ESP32 in-place of the Nano. I simply took the Nano out of it's socket, and used jumper leads to connect to the ESP32.
The next step was to test the ADC that we were planning to use, the 16-bit ADC1115 instead of the on-board 8-bit ADC from the Nano. The on-board ADC for the ESP32 has too many issues, so we can't use it with this application. The ADC1115 has double the resolution, the down side is that the communication with the chip through i2c is very slow.
In the above picture you can see that I wired-up the ADS1115 ADC on a break-out board. With this prototype, I still used the 16-bit PWM functionality, but we were already planning to use a hardware 16-bit DAC.
So after checking and verifying the changes, this resulted in a new prototype, that we called V5.
Testing the V5 prototype
Version 5 incorporated the ESP32, the 16-bit ADS1115 ADC, the REF5040 4.096 Voltage reference for the DAC, the 16-bit DAC8571, test hardware for the CV mode and Bud's vastly improved circuitry to drive the MOSFET's.
Unfortunately, we discovered a few layout issues that we needed to fix by jumper wires and Manhattan style additions. We also found that the ADS1115 was happy with 3V3 i2c voltage levels, but the DAC, that we could not test earlier because of its tiny package, did not. That called for two bi-directional 3V3 to 5V level convertors, and I used a 4-channel circuit board connecting it Manhattan style to test that. To be able to increase the i2c clock speed, I changed the 10K pull-ups to 2K2.
We then figured out a slightly different circuit for the CV mode, eliminating an extra DAC that we were planning to use. Using that earlier method would actually be cumbersome to drive with the planned user interface so the new method uses two CMOS switches to automatically change the configuration to use the DAC for the CC mode and also for the CV mode.
Unfortunately, we also found out that the heatsink I was planning to use, that would fit nicely in the enclosure I also wanted to use, could not handle the heat transfer. Not even close. Not only did things got really hot, we were far away from the specifications! I measured the NFET package temperature at well over 160 degrees C, and the heatsink temperature rose to almost 100 degrees, and that at a mere 90W for only a few minutes. Bummer!
The obvious solution is to use a different heatsink with a significantly larger surface.
Unfortunately, larger heatsinks are very hard to find, unless you go for the typical PC CPU coolers. The ones that are available literally tower above the NFET, and it's not easy to use them for two NFET's or find an enclosure for this construction.
We found two heatsinks that looked promising and I ordered both of them. Luckily, the most promising arrived early, so we could start to test with it. This is the one on the left. It has the largest amount of contact surface.
The one on the right relies on a fan at the end (or even both ends) to blow the air through. Unfortunately, that calls for a small diameter fan and they have difficulty getting enough air displacement, unless they rotate faster, making a lot more of a whining noise. Which is another reason why it is not my favorite.
The one on the bottom is the one I had been using. I purchased a number of them for other projects many years ago. I did an extensive search, but I could not find anybody offering them anymore.
The different heatsink called for drastically different construction because the length of the leads to the NFET's and the critical components on the PCB are very critical. We did not want to split the NFET's and give them each their own heatsink, or mount them on either side of the heatsink.
This is why we ended-up with the contraption below to just try it out. It did not need many PCB changes, so was relatively easy to setup and test. The original fan is now moved from the top to the bottom, getting its air from the bottom of the enclosure. The fan is blowing directly to the fins of the heatsink. We will need to use a second fan to suck the hot air out of the enclosure, which has some ventilation slots.
The first test already showed that we could now easily handle 90W for quite some time, which was not possible with the previous setup. The enclosure we selected later required us to rotate the heatsink 90 degrees horizontally, so a fan mounted on the back panel can suck the hot air out.
A longer-term test at 150W showed that we were on the right track. Everything stayed at manageable temperatures.
At this moment, let me explain what you see on the above OLED display.
On the top, you see the actual DUT (Device Under Test) voltage in blue and below it, the actual DUT current value in green.
Below that is a line that shows the mode (CC = Constant Current) the NFET's are driving the DUT (ON) and the actually calculated DUT power in Watt. The display is in red because the power approaches the maximum value and is there to warn the user.
Underneath the horizontal line is the parameter you set with the rotary encoder. The mA suffix changes with every mode. The last line shows the actual 16-bit DAC value (while testing) and the heatsink temperature in degrees Celsius. The color is orange to warn the user that the temperature is above 60, it turns to red above 90 degrees.
The colors are used to warn the user for conditions like over temperature (90), over-power (150), low (<1V) or negative DUT (wrong polarity), Voltage too high (>100V), over current (>10A), etc.
The discrepancies in the display values for set/actual current are caused by the fact that I for this test I didn't use the sense inputs yet so the drop in resistance due to the high power and long leads is not accounted for. Yet.
The User Interface to drive the instrument is kept as simple as possible, and I let the software do most of the setup underneath the hood.
The rotary encoder that you see mounted on the PCB is there so I can more easily test the setup with this prototype. It will later be placed on the front panel. In the CC mode, as you see above, you set the current by turning the knob. The knob currently has two speeds. If you turn it fast, the resolution goes to 10x so you get to your destination rather quickly. Short pressing the rotary encode button switches the DUT output to on and off, by turning off the drive to the NFET's. A long press switches to the next mode. You simply cycle through the modes in a loop, so from CC to CV, to CP, to CR and from the BT mode back to CC. When you switch to another mode, the output is automatically disconnected, and the instrument is prepared for the next measurement. The mA suffix you see in the Set line, changes with the modes, so from mA, to V, to W, to R and in the BT mode back to mA. There is no separate transient or "pulse" mode, because this feature can be used in all modes. That may not be very practical in all modes but the pulse functionality is as versatile as your function generator supports. (amplitude, frequency, pulse form, pulse width, rise/fall times and offset)
On the front panel, in addition to the rotary encoder and the OLED display, there will be two toggle switches, one for selecting the sense input terminals, and one to select power. There are two BNC connectors, one for the transient/pulse input and one for the DUT current output to a DSO. There will be an USB-C connector to the ESP32 that is required in the Battery Mode and also allows for updating of the firmware. And finally, two 4mm Banana connectors for the power connections and two 4mm Banana connectors for the sense inputs. Simple and efficient. And no, there is no keypad. It is not needed. I dislike keypads so did my best to design around it.
A suitable enclosure
The heatsink has been tested and verified that we can now easily get to 150W, but that is still outside of the enclosure. Because of the height of the contraption, we also had to find another enclosure that would accommodate this construction. Unfortunately, there are not many compact enclosures that answered our requirements.
We prefer a plastic enclosure, because the heatsink is connected to the DUT through the non-isolated NFET's and that can get up to 100V DC.
We also need to modify the enclosure to get enough air in and out. That's a lot easier to do with a plastic enclosure. And we want to be able to make a PCB-based front and back panel.
The height of at least 9cm dictates that you will get (instrument) enclosures that are very wide, and not very deep. They are unsuitable for our requirements, but it's up to the other makers to select what they want.
The enclosure we selected is from the company TEKO. They have many enclosure types, but we selected the AUS series that is pictured below. The top one in the picture below is the one I already used for several of my designs, and was planning to use. With the new hardware construction, it is not deep and high enough. The middle one is wider, but has the same height. We settled on the bottom one, the TEKO AUS33.5. TEKO is a German manufacturer but with a little Google-action, you can find them all over the world, and there are suppliers that send them all over the place. I use www.tme.eu a lot for my purchases, and they carry these enclosures.
So with this version of the prototype, I have been very busy with the testing, implementing and again testing the changes we needed/wanted to make, and all the while further developing the software.
Final Version 5.1 PCB
Based on the now fully working V5 prototype, we have redesigned the board for the new heatsink configuration and made several other changes and corrections. The PCB has been produced again by my sponsor PCBWAY. They financially sponsor this project by producing the boards and sending them to me for free. The turn-around is mostly within a week, and the quality is excellent.
The small TO220 heatsinks you see on top of the NFET's help to disperse their heat better, because they are in the forced airflow. Instead of one 4-pin fan, we now have two connectors (the white ones top left) so the first fan sucks fresh air to the heatsink and the second fan that sucks the hot air out of the enclosure. Both fans are temperature PWM speed regulated by the sensor on the heatsink.
We also switched to another OLED display source, because the one I purchased many years ago was no longer available. We selected a good quality and commonly available version but that has a different pin-out so we fixed that on the PCB as well.
Here is a quick sneak preview of the completed instrument . Note that I switched to even larger TO220 heatsinks on top of the NFET's to get rid of even more heat now that these fins are in the airflow of the second fan.
Here is an overview of the construction.
Battery Test Mode
https://www.paulvdiyblogs.net/2019/03/a-pretty-universal-battery-cell-tester.html
I modified the original code that was running on the Arduino, made it work in the ESP32 environment of the DL and integrated it into the main menu structure.
