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 the status of the developments with this AC-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, also described on this Blog, like the VBA Curve Tracer and the Differential Probe.
He started a Blog post on Hackaday that can be found here : Dynamic Electronic Load | Hackaday.io
At this moment, we have finished the design of the new version and the board is in production at my sponsor PCBWay.
I'm still working very hard on the software side, because this instrument will do some things a bit different, compared to many other DIY designs.
I'll explain that later in more details but here are two pictures to hopefully wet your appetite:
The initial target specifications:
Input voltage: 1..100VDC
Reverse polarity protection to -100V and a 15A fuse.
DUT disconnect by a relays
Maximum current of 10A @ 40V (needs to be verified)
Maximum power 150W (tested & verified outside of the enclosure)
Volt Accuracy: 0.2%
Current Accuracy: 0.6%
Power input: 12VDC Wall-wart 1A with reverse polarity protection to -24V and PTC fuse
CC, CV, CP, CR and Battery discharge modes.
GUI: 128x128 OLED 1.5' color display and rotary encoder
Temperature controlled fans
Testing the V4 prototype
This version 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.
I then started to experiment with the ESP32, a dual core processor that is much faster than the Arduino Nano.
The next step was to test the ADC that we were planning to use, the 16-bit ADC1115.
With this prototype, I still used the 16-bit PWM functionality, but we were already planning to use a hardware version.
So all the changes and additions culminated in a new prototype, that we called V5.
Testing the V5 prototype
Version 5 incorporated the ESP32, the ADS1115 ADC, the REF5040 4.096 Voltage reference, the 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 also 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 level convertors, and I used a 4-channel circuit board Manhattan style to implement that.
We then figured out a different circuit for the CV mode, eliminating an extra DAC that we were planning to use. Using that would actually be cumbersome to drive with the user interface so the new method uses CMOS switches to switch from the CC mode to the CV mode.
Unfortunately, we found out that using the heatsink I was planning to use, that would fit nicely in the enclosure I also wanted to us, could not handle the heat transfer. Things got really hot! I measured the NFET package 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!
That called for a different heatsink. Unfortunately, larger ones are very hard to find. We found two 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 to blow the air through. Unfortunately, that calls for a small diameter fan and they have difficulty getting enough air displacement, so they rotate faster, making a lot more of a whining noise. Which is why it is not our favorite.
The one on the bottom is the one I had been using. I purchased a number of them for other projects years ago. Unfortunately, I cannot find them anymore.
The different heatsink called for drastically different construction because 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 their own heatsink side.
This is why we ended-up with the contraption below. It does not need many PCB changes, so was relatively easy to do. The original fan is now moved to the bottom, getting its air from underneath the enclosure. The fan is blowing directly to the fins of the heatsink. We will use a second fan to suck the hot air out of the enclosure.
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.
Let me explain what you see on the above OLED display.
On the top, the actual DUT (Device Under Test) voltage, below it, the actual current.
Below that shows the mode (CC = Constant Current) the NFET's are driving the DUT (ON) and the actual DUT power in Watt.
Underneath the line is the parameter you set with the rotary encoder. The suffix changes with every mode. The last line shows the actual 16-bit DAC setting and the heatsink temperature.
Colors are used to warn the user of conditions like over temperature (90), over-power (150), negative DUT (wrong polarity) Voltage too high (>100V), voltage too low (<1V), over current (>10A), etc.
The discrepancies in the display values for set/actual current are caused by the fact that I don't use the sense inputs all the way to the source yet.
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. There are not many 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. 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 enclosures that are very wide, and not very deep. They are unsuitable for our requirements, but it's up to the makers to select what they want.
The enclosure we selected is the TEKO AUS33.5 and is on order. The top one is the one I was planning to use, but it is not deep and high enough. We settled on the bottom one. TEKO is a German manufacturer but with a little Google-action, you can find them all over the world, or there are suppliers that send them all over the place. I use www.tme.eu a lot for my purchases, and they carry the enclosures.
So with this 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 fully working V5 prototype, we have redesigned the board for the new heatsink and made several other changes and corrections. This PCB is now on order with PCBWAY and I hope they will again financially sponsor this project by sending the boards for free.
The small TO220 heatsinks you see on top of the NFET's help to disperse their heat better, because they are not in the forced airflow. Instead of one 4-pin fan, we now have two connectors so the second fan that sucks the hot air out of the enclosure is also temperature speed regulated by the sensor on the heatsink.
We also switched to another OLED display, because the one I was working with is no longer available. We selected a commonly available version but that has a different pin-out that we fixed as well.
More later...