Connected Devices: Lab Power Supply Project

Connected Devices: Power Supply

The vision for thingable.co is to have a place to further develop high level design principles of connected devices, and a place to share IOT projects guided by those principles. That gives us the opportunity to make IOT 2.0 much more than just theoretical. If all goes well, posts should be evenly split between the two. This one gets some thoughts out about the design of a personal connected device project.

My friend Jason and I (both EE students) decided we needed a good quality bench power supply (referred to as a power supply unit or PSU). With the hardware almost complete and tested we started talking about interfaces. He enjoys a more traditional instrumentation panel while I would love this to be controlled by my phone. Is there a better place for IOT than our own lab equipment? So we are going to be laying out the boards to allow for a modular controller and interface. Let’s go over some of the considerations and challenges needed for a connected power supply.

Requirements

There are a few requirements that need to be implemented for this to work out:

  • I2C for DAC and 2 ADCs (per channel)
  • An interface for a phone (and possibly a computer)
  • Connectable through LAN, and as a standalone device (and possibly online)
  • A secure and authorized connection (Possibly multi-user)

Our design (ok mostly his if I am honest, good job Jason) uses digital feedback through two ADCs and is controlled by a DAC. These are isolated on each of the two output channels and controlled with I2C. This is the circuit for one channel below, but the specifics of the hardware design are out of the scope of this post. Just ask if you want to know anything about it.

The circuit diagram for the PSU

The interface and connectivity requirements are the interesting part of this challenge to me. This process should be as seamless as possible. A user should be able to interact securely through any mobile device or computer. It would be nice to allow for multiple users to use this at the same time; Jason and myself work on other projects together and not having to hand a phone back and forth would be super useful. The connected PSU should also work with and without a local/internet connection; this allows for “connected device mobility” (a possible topic for further discussion).

Frameworks and Programs

Currently there are several ideas floating around about what to use to make this all happen. For my controller I have three ESP8266s (V1 x2 and V12) being shipped in from China now. I fried my old one with 5V, but quickly realized how powerful these little $3.50 wifi controllers can be. My hopes for these are to be able to send and receive JSON formatted data to control and monitor everything. The new Arduino SDK with ESP8266 support should work well for this application, but if I need to build a more custom solution I can look elsewhere.

The interface is currently being developed in web languages (html, javascript). As of now it is utilizing twitter’s Bootstrap and a jQuery project, jQuery Knob,  for working with knob and dial interfaces. In the future there are hopes for developing a strong framework to interface with IOT devices, but that is on the back burner for now.

Open Data Interaction

In the last post we talked about using the idea of interconnected data, and why pairing a device to a single app is poor design. Let’s expand that concept a bit and introduce “open data interaction.” Designing with this in mind means that the device will output each individual data stream and accept input for all the actuators separately; making it thingable! (ehhh see what I did there?) This is part of my growing list of topics to outline in detail, but we can cover how it applies to this project.

The connected PSU controls the voltage and current of two (maybe more) output channels. It senses the current and voltage with a few ADCs. Applying the concept of open data interaction means that the ESP8266 would output JSON containing the last measured current and voltage values, and accept JSON involving the settings the device should hold.

This entire process is agnostic to a particular user/machine interface. My original designs for this used the ESP8266 to serve html, javascript, and css data to the interface device. Serving the entire interface with these web languages would take up memory and processing on the controller. This would also violate the concept of open data interaction because it limits the interface of the device to web browsers. It may be beneficial to make other apps or server scripts to store or manipulate the output of the device.