Reverse Engineering Communication Protocols (Part 2: Software Writing)

To summarize where we left off, we have the control scheme for the device, but no way to easily control it, we need a control algorithm.

First we must decide on a programming language. In these types of scenarios I prefer to use python, for a few reasons. The few things I’ve done with python, -which seems to be growing at an exponential rate for me lately- it’s easier to implement and test a design. I know python is extremely slow compared to C, C++, or even Java, but it’s 100% portable code, and if I had to guess my time efficiency is 10:1 python to cpp.

My goal for a control scheme was to have a single class for the power supply object, that way later on electronic loads could be easily added. The second thing I needed was some type of control loop, where I could give it a set of parameters, and it would continuingly send those commands to the unit. I also wanted to something that could essentially ‘auto-find’ the device on the USB bus rather than me having to manually specify the port and settings each time. That’s where I used pyusb, and pyserial packages. Since I’m using windows, I use the device manager to look up in the details tab->Hardware Ids, which displays both the vendor id, and product id. By using these, I can have the program auto find the device each time I plug it in. Another benefit of going this route is the possibility to create a single user interface, but a backend process that auto configures based on the device being used.

If you examine the file you’ll see the device description didn’t change much if at all from that control scheme prototype. Through instantiation it tries to find the device. You set the parameters through a function, and control the device with an unending ‘control’ loop. I then continued to build on that structure trying to keep the power supply object monolithic so that I could add more devices easily, and electronic loads at a later time. With how many support calls I’ve dealt with this issue, it’s nice to be able to finally provide a solution.

When I finally finished the script, and the device was working, I then moved on to the PPS2116A. I used many of the same methods as previously referenced, with once exception. Hantek provides a SDK programming guide that helped to implement all the necessary functions. Very interestingly, the PPS used a very similar control scheme to the csi305db at least in terms of the string. The difference being it used a single string series for each set of parameters, thereby not needing a control loop. As an example, to set the voltage send ‘su0000\r\n’, and current send ‘si0000\r\n’. The sdk guide came in handy considering there were many more functions such as output control, measure voltage, etc showing how much more sophisticated the PPS was over the 305db.

The last hill to climb was the electronic load, and the automatic control scheme…..Read third article

Leave a Reply