Programmable DC Electronic Loads with the BK8600 - Review

Table of contents

RoadTest: Programmable DC Electronic Loads with the BK8600

Author: shabaz

Creation date:

Evaluation Type: Independent Products

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: There are not many options! The 8600 series was attractive because it was likely to have been built based on the experience from the earlier 8500 series.

What were the biggest problems encountered?: Nothing major. LabVIEW is not as popular for some engineers, so some time was needed to build some open source software. This wasn't a problem, but did consume some time. But in the end It was rewarding to see that it was not difficult to interface to the BK8600 via USB.

Detailed Review:


The BK Precision 8600 Electronic Load in a nutshell provides an adjustable current sinking capability when it is applied to a DC source. It also has microcontroller-based closed-loop feedback; since V=IR and P=VI it follows that by measuring voltage and current dynamically it is possible for a microcontroller to automatically adjust the amount of current sinking in order to implement modes of operation that can provide a constant resistance or constant voltage or constant power. Non-constant (varying) loads are also possible if desired. These can be useful for observing dynamic behaviour of the DC source as the load changes.

BK Precision’s 8600 series has seven models covering operation up to 30A/150W for the base 8600 model and up to 60A/1.2kW for the top-end 8616 model8616 model. For the RoadTest the model supplied was the 8600 version, order code BK8600BK8600.



I was interested in trying out the BK8600 Electronic Load for Internet of Things (IoT) related projects. In fact the BK8600 can be used for more than DC power supply testing. For IoT projects the load would also have uses for testing analog and digital outputs (for example for driving lamps).



It would also be useful for testing many energy sources that have complex behaviour that needs to be characterised. In my case, I wished to examine solar panels. This RoadTest examines several use-cases and explores how to make the most of the BK8600 through software automation.


How Does it Work?

The easiest way to picture a DC load is to imagine a variable resistor connected to the source equipment under test. By monitoring the voltage across the variable resistor and the current passing through it, it is possible to adjust the variable resistor to set any desired current. If the source changes, or if the source has internal resistance, then that can be compensated by changing the variable resistance until the measured voltage and current are of the desired values.


In an electronic DC load, the measurement and adjustment of the variable resistance are automated using a control loop. The diagram below shows an approximation of how the BK8600 can function at a high level (note – the BK8600 actually incorporates multiple processors and more advanced circuitry – this diagram is just demonstrating what end functionality is embedded inside the BK8600, not how it is implemented). The heart of the control loop can be implemented in hardware or for more flexibility as algorithms in software.



User Interface

The BK8600 is easy to use, I did not find myself needing to reach for the user manual too often (incidentally, the user manual is well written). There are plenty of buttons and a shift key for accessing the menu options. The vacuum fluorescent display is large, very bright and clear, and because it is alphanumeric and there is space for reasonable amounts of text, the menu options are easy to follow. I also liked the fast update rate; the readings on the screen update around three times per second (this is a visual estimation). The buttons have a beeping tone but the user can disable this sound from a menu option. The power button is unusually long, and I did accidentally power off the BK8600 when I brushed against the switch by mistake. It is minor and easy to fix; I cannot actually fault the controls or user interface too much.


Setting up the BK8600

The BK8600 Electronic Load comes with some very large (6mm) threaded posts for connecting up the source that is to be tested. At the rear is a connector for additional signals that are used less frequently. I decided to build up a set of cables that I could dedicate for Electronic Load test purposes.


For the front cables I used M6 lug terminalsM6 lug terminals and redred and black banana connectorsblack banana connectors and some 2mm2 wire (see Make your own Test Leads for more information).



A rear connector comes with the BK8600 and it offers screw connections for some features like external triggering, fault alert, and remote sensing to allow the BK8600 to make accurate measurements much like a 4-wire measurement with a bench multi-meter. I wired two croc clips for remote sensing purposes. I used ferrules for a reliable termination at the screw connector end.



The depth of the instrument is 387mm and that is quite good. The workspace in the photo below has less depth compared to desks in most labs, and there was no issue with using it. It is also extremely quiet! The fan will only kick up in speed when it needs to.



Controlling Test Equipment Easily

The next step was to examine automation.



Unlike some test equipment such as multi-meters and oscilloscopes that traditionally are often (although not always) used standalone, an electronic load is a device that especially benefits from automation for design engineers. This is because the design engineer is very interested in making adjustments and seeing the effect and for Electronic Load use-cases the adjustment can be complex and the effect may need processing, conversion and graphing.


The BK8600 electronic load offers the ability to perform adjustments in load value, and has measurement capabilities built-in. It is supplied with example software based on National Instruments LabVIEW and this is extremely popular for large testbeds especially for engineers in production environments. For a design engineer I feel that quicker and simpler control and monitoring software can be useful. LabVIEW is very full-featured but I often encounter problems when using it on PCs that already have different versions of National Instruments VISA drivers installed for controlling other test equipment and I do not want to risk breaking existing installed software for other test equipment.


A design engineer might not have the time or dedicated computer (or virtual machine) to build out a static testbed that will work reliably for just one test scenario without affecting other software installed on the machine. Furthermore not everyone is experienced in developing for LabVIEW because it uses a graphical oriented system for defining much of the test procedures.


The BK8600 has RS232 and USB connectivity options on the rear panel. I decided to use the USB connection since my laptop no longer has RS232 capability without an adapter anyway. By default the BK8600 is set up to use RS232 so the user needs to explicitly enable USB in the menu options.


Once the device is plugged in, a device appears in the /dev folder on the PC (I used Linux since everyone can run this for free in a virtual machine, regardless of their host operating system). From there it is easy to start interacting (using read and write functions) with the BK8600 using a communication format called SCPI (short for Standard Commands for Programmable Instruments). I used the C programming language for this. However, not everyone knows C either.



So, I decided to implement a type of gateway in C, that would allow users to send an instruction using HTTP, and the gateway would extract it from HTTP and send it to the BK8600. With few tweaks it would be adaptable for any test instrument that uses SCPI (and most do).


Now, anyone can send instructions to the BK8600 using a web browser; just type the desired SCPI instruction in the browser address bar (e.g. http://xx.xx.xx.xx/FETC:VOLT ) and the BK8600 will get queried correctly and the result will appear as a text string in the web browser.


Taking this a few steps further, it means that engineers can program test scenarios into web pages and provided they send the correct requests over HTTP, the user can automate many tasks. From my perspective, this is handy because the user can simply create a new web page (in other words a single HTML file), or copy and modify an existing one, for performing any new task or test.


Furthermore, I can archive off the .html files into a folder or paste into a lab notebook so that I can always rerun the test scenario. No need for configuration files or remembering settings! Every time I need to run a slightly different test, I can just clone a HTML file and save it under a new name on my PC.


The code is published on github; it is proof-of-concept code but works well enough that I cannot see myself not using it whenever I turn on the BK8600. The code deserves a re-write, but it is easy to see how it works and make changes. If others make use of the code then it would be interesting if users shared their HTML files for different test scenarios. We could all make use of these by picking the HTML file closest to the desired test scenario and then modifying it.



From a software implementation point of view the code merely checks to see if the HTTP request looks recognisable as a SCPI command and passes it onto the BK8600. If the HTTP request looks more like a filename then the code will query the file system and serve up the requested web page. To execute a full test procedure the web page file just needs to contain JavaScript code to issue more SCPI commands as desired to implement the procedure. Any graphics and charts can be implemented in the web page too.


The code performs some minimal modifications to the incoming request in order to simplify SCPI command requests, and implements a few special local instructions too. As an example of a special request, a HTTP request containing ‘open_usb’ will prepare the software interface to become ready to accept SCPI commands. Another special request called ‘start_log’ is used to instruct the server to record measurements to timestamped files.


As an example, I wrote a HTML file called logger.html. When this web page is accessed, the user gets a live status of the current measurements from the BK8600 and live scrolling graph of current, voltage and power, and logging to the server.


It won’t replace an oscilloscope for observing rapid changes, but it is useful for logging things over a very long time and observing trends over long time periods. The code currently shows a graph of the past five minutes (logged every second) but it would be easy to rename a copy of the file to (say) long_logger.html and edit the file to any desired settings.


Working with Supercapacitors

Once I had the basic logging function working I discovered that one of the very flexible things about the BK8600 was that it was easy to capture data to a log file while continuing to manually operate the BK8600. As a result, I could concentrate on the test and be reassured that data would continue to be logged all the while.




I used this procedure to test out some supercapacitors. I had a 350F supercap rated to 2.7V. Firstly I carefully charged it using a power supply and resistor, until the voltage across the capacitor was 2.6V (this needs to be accurately monitored!), and then I disconnected it and attached it to the BK8600.


Next, I used the logger.html file to start a capture (just clicking on the ‘Start Logging’ button) and the scrolling voltage plot showed the voltage across the capacitor to be 2.6V. Current and Power graphs were at zero because no load had been enabled on the BK8600 yet.


It was easy to configure it to act as a 0.3 ohm load; just hit the CR button (for constant resistance) on the BK8600, then type in 0.3 followed by Enter, then then press the On/Off button to enable the load. Immediately I could see in the scrolling graphs the voltage gradually dropping as the capacitor discharged, and the current and power graphs updated in real time too.


With a little bit of effort it would be possible to compute the area under the curve and display the energy that was inside the capacitor. I might implement that later in a fourth graph, and have a box for typing the resistance value and have a ‘Go’ button, and call the test procedure capacitor_logger.html for example.


Working with Solar Cells and MPPT

Maximum Power Point Tracking (MPPT) is something particularly useful with devices like solar cells and panels. The amount of power generated by these devices varies dependent on the amount of solar energy hitting the panel but it is also dependent on the specific load attached to it. If the load is heavy (i.e. low applied resistance) then the solar cell behaves like a constant current source and since P=I2R this means that the desire is to increase the applied resistance up until the point that the solar cell no longer behaves in this manner. At that point, since the current has remained constant, the power delivered to the load (resistance) will be at its maximum. At very light loads (very high resistance) the solar cell is no longer functioning as a constant current source and the power delivered to the load will not be at its peak.


Note that the maximum power point could vary dependent on temperature and amount of light hitting the cell.


There are different ways of implementing MPPT, some more accurate than others. The aim of using the BK8600 with solar panels was in order to characterise the panels, so that a decision could be made not only how to implement MPPT and how precise the MPPT method would need to be, but to also make a decision if the solar cells were any good and would generate sufficient power for the end application. These are important decisions to maximise the operation time for outdoor devices and so the BK8600 could really help here.



The test procedure is straightforward in theory; a load is applied and then the voltage across the cell and the current through it need to be measured to calculate the power being supplied to the load, and this test needs to be repeated at different load settings and different illumination levels.



The test procedure was implemented in a file called solar.html and it was run with a small solar panel (BP Solar polycrystalline panel, model MSX-01FMSX-01F shown in the photo above) as the device-under-test. It is a compact panel about the size of a CDROM case. The stars aligned in the UK (at least, the sun did : ) and it was possible to run a decent test in outdoor conditions.



It was a nice sunny day and the tests were run mid-afternoon. With the software it was dead easy. Just set the min/max voltage range in the web page and click the ‘Start Test’ button. The graph is drawn in real-time as the test runs.



The orange trace shows the power supplied to the load with the panel fully exposed to UK sunshine and the panel’s constant current behaviour can be seen from the near-straight line up to close to where the maximum power point is reached. At that point, 1.26W of power was possible when the applied load dropped the panel voltage to around 7.8V (open-circuit voltage was around 10V). This matches the data sheet closely to within a few hundred millivolts, and it can be concluded that the solar panel is very healthy; it is generating slightly more than the typical power expected from the data sheet figure. Armed with this knowledge, it is possible to design a circuit that makes good use of the energy collected by this solar panel in similar conditions. For a more fuller characterisation the test should be repeated at different temperatures and different light levels to check what difference it makes. Just out of interest, I also placed the panel indoors close to a window that was not directly facing the sun. The power output was (as expected) far lower.



The orange trace shows that the maximum power output was reached at about 5V. The red and purple traces are with the panel partially covered with a small scrap of paper. What I loved was that here I was observing two orders of magnitude less power (single-digit milliwatts) and the BK8600 provided decent resolution. I only graphed about a dozen points in my test procedure because this was sufficient to find the maximum power point with reasonable accuracy. The BK8600 measurements are in two modes, a high-res and low-res mode. If it is known that the current to be measured will be less than 3A then it is possible to go into a high-res mode where the resolution is 10uA. As a result, the BK8600 is quite good for milliwatt-level measurements as shown in the traces above. Lower than this is possible but at these extremes it would be advisable to use additional tools for logging the current to increase accuracy at very low levels. An example would be a multimeter which can measure and log current through a USB or Bluetooth connection such as the Keysight U1282A. A multimeter will of course be a lot more flexible and allow setting of one of many current ranges to get the best measurement to suit the desired task at hand.

The BK8600 can have around +-1.5mA offset in the set current, and the read current value, so it is not intended for all scenarios; a different type of product should be used in these cases such as a Source Measure Unit with load capability. Sometimes it is possible to construct a small load too, e.g. see this 3-in-1 source-sink-reference project which contains a 50uA current sink.


I also had another polycrystalline solar panel at hand, a slightly smaller Multicomp solar panelMulticomp solar panel rated for 0.8W power output. I subjected that to the outdoor sun too.



With this panel, I achieved 0.9W at about 3.5V panel voltage (the datasheet specified 0.8W at 3.85V so again this panel was very healthy). It is a great panel at very low cost, but sadly it is only available until stock is exhausted : ( I need to search for more panels to test!



In summary the BK8600 performed extremely well for the solar panel tests and I’m confident it is the right tool for this. The software worked very well for this use-case too.


Working with LEDs

In the world of IoT there is lots of interest in home automation. A very common need is LED lighting automation in the home as an example.


The BK8600 is advertised to be able to simulate non-linear devices like LEDs. As a result it is possible to use the BK8600 to test LED driver circuits. However, I was curious to see if it was also possible to use the BK8600 to test LEDs themselves. Basically it uses the electronic load, in conjunction with a basic power supply, and turns the two items into a more advanced power supply, suitable for driving an LED.

Here is how it works:



It relies on the fact that whatever current is flowing through the load must be equal to the current flowing through the LEDs. Therefore if the LEDs require 700mA drive current (this is one of the popular values for LEDs intended for room lighting) then the Electronic Load merely needs to be set to 700mA and the LEDs will operate. The DC power supply needs to be set to a voltage higher than the sum of the forward voltages of all the LEDs in the string of course.



This is extremely useful to characterize LEDs. Usually LED datasheets describe the forward voltage only at a specific current setting. By reading off the voltage on the BK8600 display, one can subtract this value from the DC supply voltage and determine the LED forward voltage at any given current value. I’m tempted to produce a led.html file for plotting exactly this.


Another use of the BK8600 is for the user to test out brightness levels at different drive currents. It is also possible to implement PWM to see its effect by programming the DC load to toggle between two currents. This feature is normally used to test DC power supplies for their behaviour under the dynamic load condition created by the PWM. Invoking PWM is easy to do from the front panel, by selecting the ‘Transition’ mode and selecting two currents (such as 700mA and 0mA) and then programming a frequency and duty cycle. Slightly non-intuitive, the user then needs to invoke a trigger action (such as pressing the ‘Trig’ key) before switching the output on. Anyway, the procedure works and it is possible to test out LEDs for lighting purposes. I used a Vishay 9-LED moduleVishay 9-LED module for the tests; according to the datasheet this had a forward voltage of between 27-36V so I used a 48V power supply. It worked great! If I had a minor feature request to BK Precision, it would be to modify the software to offer a dynamically adjusted duty cycle on the fly, if the user tries to modify the value in the configuration while the output is on.

By using the Electronic Load with the Vishay LED module, I was able to determine what PWM levels I would use to implement discrete dimming levels.



Another interesting thing that was noticed was that around 100uA of current flows through the load even when the load has its soft-key set to the ‘off state’ or even when the BK8600 is switched off. I don’t know if this is a bug or issue with my particular model, but it is technically within spec if the load is set to 0mA. I will check with BK Precision to confirm if this is expected behaviour in the off state too (I don’t think it is), and the recommended procedure to remove the DC supply to ensure no unexpected brief current sinking at times of switch-off. It may be a minor fault, but there is a three-year warranty which is a very positive thing.



There are an astonishing number of use-cases for a DC Electronic Load, and I am happy to see that the BK8600 provides a lot of flexibility for users to create their own test procedures and logging tools. The programming manual is extremely valuable and it allows users to get a lot out of the product. I hope people share their procedures for a variety of tasks.


I liked the super-easy-to-use menu system which was reasonably intuitive, and the quite good interfacing options. Ethernet would be nice, but I am happy that USB is available.



It is a very feature-rich product, and I plan to explore the BK8600 more, in particular additional dynamic tests including the ability to adjust rise and fall times and the ability to control the load using signals wired to the rear connector. Overall I’m very happy that the DC Electronic Load worked well for the scenarios that were tried (logging, discharge tests, solar panel MPPT tests and LED tests). I really hope others can make use of the software framework and the initial few HTML based procedures and build on them so that we all benefit from any improvements that we make. The code will be published on github in the next day or two and the link will be recorded here.


I also intend to try some more solar panels once summer arrives.


As with any complex product there are a couple of outstanding queries which I’ll address to BK Precision regarding the low current (100uA) observed in off state, guidelines on power-off procedure and a feature request (ability to perform PWM duty rate adjustment on-the-fly) and I’ll document the answers here when I get them.


The BK8600 is easy to use, provides deep insight into all sorts of circuits and devices and that means it will get used a lot in any lab.


Top Comments

  • I would be curious to see more about the dynamic behaviour of the output. touched on it in his review, but didn't go very far in teasing apart what was down to the instrument and what was down to the device being tested when it came to overshoot.


    (Please don't in any way take this as criticism, all three of you have done fine reviews concentrating on the application and use of the instrument; it's just personal interest on my part.)


    I'm interested because I've been designing a transistor version (constant-current only) as a vehicle for my Transistor blogs (the next phase will be introducing the various building blocks that make up the DC amplifier and servo loop). I'm also eagerly awaiting  and version to see whether I can get anywhere close to what they achieve but with a discrete design.  (See this for their work-in-progress thread: Programmable Electronic Load)

  • I would be curious to see more about the dynamic behaviour of the output. touched on it in his review, but didn't go very far in teasing apart what was down to the instrument and what was down to the device being tested when it came to overshoot.


    (Please don't in any way take this as criticism, all three of you have done fine reviews concentrating on the application and use of the instrument; it's just personal interest on my part.)


    I'm interested because I've been designing a transistor version (constant-current only) as a vehicle for my Transistor blogs (the next phase will be introducing the various building blocks that make up the DC amplifier and servo loop). I'm also eagerly awaiting  and version to see whether I can get anywhere close to what they achieve but with a discrete design.  (See this for their work-in-progress thread: Programmable Electronic Load)

  • Hi Jon,


    Thanks for reading!!

    It is very right for you to mention this, it's an important part of it's performance. I've been thinking about the best way to show uses for the dynamic capabilities beyond just plugging it into an off-the-shelf PSU, so the idea I've come up with is to test a project I have been working on for quite a while, which is the opposite of an electronic load, Building a Battery Simulator - Part 1 . The uses for an Electronic Load are so diverse, so I made a decision to just hint in the summary about the dynamic tests but get the software created first and use it to attack the use-cases like maximum power extraction from solar panels with MPPT that could also be of interest, until someone calls me up on it : ).


    I think dynamic tests will show that a DIY switched MOSFET placed close to the device-under-test could switch a load with a better response but that is to be expected; a test tool such as the BK8600 with all the fancy features has to be more general-purpose and have the connectors and long leads to connect to the device under test. In fact the datasheet specifies the slew rate and a settling time, but only offers typical values for the slew rate. I think it will be worthwhile to show a scope trace of the typical switching capability I see from the BK8600, and typical jitter (the in-built clock isn't designed to be so accurate, a user can feed their own control for the load from an external signal generator).

    And then show it with a use-case testing a voltage regulator output, in my case the battery simulator. Would that work for you?

  • , in essence, the design of Peter and me will also be an analog one. The only thing the microcontroller will do is set the current via a DAC. But regulation is done with opamps, very similar to Peter's original electronic load.

  • That all sounds good. I'd be very interested to see how it behaved being driven by an external signal generator because that would be a similar configuration to what I'll have. I'm kind of interested in where the bar is situated with a professional instrument and what I've got to do to beat it (or, being a bit more realistic, how far short I'm going to fall).


    One question I've been grappling with is how to actually test my circuit once it's built. For the situation where the target current changes but the output supply voltage remains fixed, I can maybe do it with a decent power supply with a lot of good decoupling on it. But for the other situation, where the target current remains fixed but the output supply voltage varies and the current sink is having to follow and adapt to that, it seems to me that I would need a power amplifier (that could cope with the current and at high frequency) to output that varying voltage. I was wondering if I could maybe find an audio power amplifier that could be adapted.

  • Yes, I know - I've been looking over your shoulder and reading the WIP (I don't like to comment there, because it feels like intruding on a personal conversation between the two of you).


    I phrased what I wrote badly - I meant I was doing a design with discrete transistors rather than with op-amps. It's a stupid thing for me to do - at base, I'm trying to design an op-amp, which isn't at all easy as I've discovered. I do have a slight advantage over those clever people who design such devices, though - my design doesn't have to be general-purpose and I can make it very specific to the job in hand, which I have done. The one thing I don't know yet is how it will perform in practice - it works nicely in the simulator, but that's without real-world parasitics getting in the way [and turning it into a high power oscillator].


    One thing I'm sure of - yours will have a much better UI than mine.

  • What makes this exercise different for me are these two things:

    I can really use an electronic load. That may be the best driver to work towards something that works.

    I have a partner in Peter that also wants this project to work. It's that extra boost that I sometimes need to keep focus on delivering something that fully works.


    Feel free to chime in on our design here on element14.

    It's not a 'design by committee'. Our main goal is to build that instrument that we both want. We're rather harsh on scope creep.

    On the other side, we do welcome good advice and we also like to be challenged when off-track.

    If we don't like your inputs we'll block you, report you as a spammer, hang, draw and quarter you.

  • Hi Jon,


    For the first scenario (target current changes, DC source at a fixed voltage) the supply with decoupling is a good method I think. For the second scenario (DC source voltage changing) instead of a power amplifier, an idea could be to just use a MOSFET to switch (say) 12V to the current sink, and have (say) 6V also applied to the current sink (through a diode). So, basically the current sink could have 6V and 12V applied to it on demand, allowing you to perform a step in DC source voltage and observe if the current sink can keep up with it.

  • Thank you - that sounds like a good approach. I'm trying to make it too complicated and then getting in a muddle over how to make the test set-up good enough to do a meaningful test.


    The two voltages could come from bench PSUs, so it's nice and simple to put together; it's reasonably fast, depending on how I drive the MOSFET; and the dissipation in the MOSFET would be quite low (as long as I keep the repetition rate fairly low).


    Your battery simulator posts are really interesting. Later on, I'm going to have to sit down and see if I can understand MK's linear version - too much for me to quickly assimilate now. Perhaps a version of that could be my next 'all transistor' design...