Electronical and Electromechanical Explorations

This blog organizes and presents some of my various projects and musings related to taming wild electrons and putting them to work. Projects are listed down the right side of the page.

Thursday, December 25, 2014

On Usability (rant)

In my last post, I concluded that I need to master the use of user interface components, especially displays.  And so, of course, I think you should too!

<rant>

Embedded products are famous for having crap usability.  That doesn't make it okay.

Typically there are (at least) two aspects of an electronic gizmo -- the internal circuitry (the technical bits under the hood) and the interface to its user.  This could be a programming or electrical interface if the project is a component for use in larger systems -- and usability is important for those things as well -- but that is not what I am writing about today.

Older engineers like me tend to get fossilized in our thinking and resistant to change.  For example, like it or not the technological advances and design work that led to the iPod, iPhone, and all that followed really did revolutionize the usability of handheld devices (the same way that mice and windowed displays revolutionized the usability of PCs).   Deal with it. 

If that idea doesn't make you unhappy, you probably can skip the rest of this post!

Certainly not every project needs to be burdened with a high-resolution touch screen, but maybe your project would actually benefit from that.  Look at the reasons you resist the idea... are they good informed reasons or stubborn biases or laziness?

Some issues:

Cost: These days, adding a touch screen to a project that otherwise doesn't even need a microcontroller adds around $20 (with some effort) to a hobbyist one-off project.  I don't know the cost in quantity, but obviously less.  Compared to the cost of whatever the alternative would be, it may or may not be more important than the usability benefits.

Difficulty: this is probably the main reason people avoid using modern UI components... it takes time to learn about and implement them.  And, since it is peripheral to the important bits under the hood, it can seem like silly overkill from a development perspective.  Realize, though, that this is only true until you add some abilities and experience to your toolbox and skillset.  And ask yourself whether you really want laziness to be the driver of your design.

Actual Usability Benefit:  If an optimal interface for your device is really one button and a three digit display, that is awesome!  Nice job focusing!  give your user a pleasant and responsive knob and readable appropriately-sized digits that are easy on the eyes and update at an appropriate speed, and you are done.  But features do tend to creep in... if you find that buttons are ending up with multiple functions in different circumstances, other buttons are switching "modes", you are cycling through different meanings for the numbers in the display, or if multiple settings need to be manipulated using that same three digit display.... stop!  You have probably evolved a crap UI...
  • Rule of thumb: if your device isn't pretty much intuitively obvious to a slightly-dimmer-than-average member of your intended user-base, you have failed.  That varies depending on the user base of course.... But if your user needs a written manual, you have probably failed, except for minor features of highly complex gear where users are expecting to spend hours learning the device anyway. 
Details: Of course, other things are involved... for example:
  • Size:  if the device is tiny, that MIGHT exclude some UI options.  However, it might not! A little touchscreen might be at least as space-efficient as a few dedicated buttons and a numeric LCD.
  • Wasted Power.  Only really an issue for a battery-powered device where you are counting milliamps.  There are ways to change power levels on microcontrollers during times when the display doesn't change, backlight power can be used intelligently, and so on -- but there certainly are circumstances where power consumption is an issue... a device that runs out of battery power way faster than its user expected is probably even more crap than one that is difficult to use.
  • Environment:  if the device needs to be usable underwater or in conditions that must remain pitch dark, or be used while driving a car, etc, that obviously limits the ways its user can interact with it...
Distaste:  Maybe you just personally don't like all this modern garbage.  I am actually not going to ridicule this reason.... there are others like you who will appreciate your device, and nobody should spend their limited time on things they hate.  And older technology of course was often awesome!  I have one of those old Tektonix analog oscilloscopes and not only is its UI a brilliant piece of design, but the feel of using it is very pleasant.  If you are going to let passions like this drive your design choices, it is still important -- maybe even more important -- to avoid compromising that passion.
  • Intuitive design is still important... and probably even more difficult.   now the important thing is laying out the buttons and knobs, providing feedback with LEDs and meters, labeling things clearly on your panel, etc.  Do it right!
  • Use quality components.  Crappy buttons and gnarly knobs aren't old-school chic, they are just crap to use, and always were!
Of course, usability isn't just about which bits of hardware you decide to use.  Whatever interface you choose, it will be a bunch of work to get it right.  If you aren't willing to do that work, then admit that you are playing.  Communicate what you learned, share your experience experimenting -- but don't be confused: you haven't made a product and the world doesn't really need another frustrating device ("open source" or not).

</rant>

:-)

Programmable Load 1: Concept, Motivation, Goals

As I think about various projects, I am realizing that what I really need most is some more test gear to help me discover and diagnose problems, which will inevitably occur.  I have a multimeter and a cheap Chinese digital oscilloscope (as well as an ancient rather limited analog scope), and a pretty nice RCL meter, but I feel as if I would become more effective if I had some more tools.

One useful tool that should be a reasonably simple project: a programmable load, to help test power supplies (both the lab supply I wrote about the other day and also the sort of routine power supplies that virtually every project needs.  I think this will be a good "first homebaked test gear" project to see through to completion, so it's time to begin!

The idea, of course, is to load down Circuits Under Test with some programmed current value so their behavior can be examined for proper operation.  For the most part, the most useful currents will be of "medium" size... from tens of milliamps to maybe an amp.  Additionally, I would like to be able to fairly accurately program in much lighter loads, down to under a milliamp, in order to:
  • Check the behavior of supplies in a "barely loaded" situation
  • Characterize the behavior of circuit elements besides power supplies in normal sorts of situations.
It would be handy (because of my interest in motor control) to have a much beefier programmable load, but I will leave that for another day so I don't get bogged down in the difficulties of high-power circuitry.

Additionally, there's a few other features I want:
  1. The ability to test transient response, from sudden increases or decreases in current demands.
  2. The ability to test a supply's behavior in response to "pulsed" current demands.
Those extra features shouldn't cause too much difficulty (at least I don't think they will), but they are more complicated to set up -- which means that a simple "one knob" user interface won't do the trick.

When that happens (which is most of the time, I think!), I really want to make sure to do a good job with the interface (I will add a separate rant about that subject when I'm done writing this).

It seems as if most of the projects I want to work on want some sort of display that is more than just a number.  And it also happens that I am interested in display devices.  So, part of this project will be to bite the bullet and grow stronger by having a good set of skills, methods, and tools for using displays in projects!

Monday, December 22, 2014

Lab Supply Project 1: Concept

A couple days ago I started watching the series of videos that Dave Jones (of the EEVBLOG) made about the design of a little lab power supply. Really great stuff!

He says that building a little power supply like this is a great project for budding electronics designers, and I think I agree... so now I got the bug.

The specs for the project as he gave them:


A couple things struck me as I watched the first few videos and thought about it a little...
  • A lot of effort has to be spent dealing with the peculiarities of components.
  • If I need to include a microcontroller anyway (for current/voltage control, reading buttons and knobs, and display), it might be interesting to push even more functionality into the MCU...
  • I think Dave gave up too easily on the zero volt output capability... at least I personally want a supply that can go down (very close) to zero volts.  I already have a supply that can go down to a volt or so...
  • One of my obsessions is motor control for CNC/robotic applications, including "servos", which are feedback controllers that accurately control the position or speed of devices.  It struck me that op amps are really like little servo controllers.  Hmm.... 
  • I am the Circuit Jerk, so one awful thing to do would be to skip all the elegant analog crap and try to use a microcontroller in place of op amps (or similar control loops inside regulator chips)... turn the whole thing into a software problem!

I think it could be difficult to get that to work properly, but Dave always says that the way you learn is to fail... so here's a sketch of the basic design I'd like to try to build:

Easy in concept!  Use an ADC to fetch the output voltage and current (and a voltage reference to use for calculations); use a DAC to control the pass transistor, code up a servo loop, and "Bob's your uncle!"

I'm pretty sure that the biggest problems will come from the latencies in the VOUT -> ADC -> ALGORITHM -> DAC -> BASE pathway.  One of the greatest things about op amps (besides their coolness and elegance) is their speed.  A relatively slow digital feedback cycle means that the always tough tradeoff between stability and response time will be an even bigger problem than in an analog circuit (and even there it can be bad, or so I have read, haha).  The biggest area of concern in this regard will be the transient response -- will this solution be too slow to be useful?  If a demand for more current leads to a drastic and long-lasting voltage drop, the circuit on the other side of VOUT could easily malfunction.  Yuk!  And even worse, a demand for less current could lead to a voltage gain large enough to fry sensitive circuitry.  Desperate efforts by the control loop to compensate can easily lead to overshoots in the transient response, which is a problem even for analog hardware.

Adding some buffering capacitance will certainly help, but as Dave pointed out in his videos, too much of that causes other problems...

Anyway, it should be interesting to try!

Now... in order to test this, I really wish I had a flexible current sink I could use for testing... maybe I will add yet another project to the list and build one of those first!


Friday, December 19, 2014

VoltAmp Meter: Input Circuitry 1

Since I want to start my exploration of lab test equipment with some relatively simple things, I am working on a basic two-channel (DC) voltage and current meter for bench use.  The idea is:
  • Link the grounds of the meter and the Device Under Test.
  • Report the voltage (relative to that ground point) of each channel.
  • Optionally provide a return path for the test point, so I can splice it into the circuit and report the current passing through that point.
I'd like to aim for good accuracy and resolution (but not insane), and make the user interface simple and pleasant to use.  And, because I like small things, I'd like the whole thing to come out relatively compact.  Since the purpose of this project is not to learn about dealing with high voltages or currents, I want it to be able to handle something like +/-50 volts, and measure current up to 5 amps.  However, I want the device to not be damaged by accidentally hooking up some reasonable level of overvoltage, or by hooking it to a circuit that wants to draw more than 5 amps.  And finally I want it to do a decent job displaying voltages down at least to 1 millivolt, and currents down at least to tens of microamps.

Note that this is not really a great requirements spec... for example, "good ... (but not insane)" is not very specific!  Since I'm just playing at the moment, though, I'm not going to worry about that.

There will be five inputs to the device:  IN1(+), IN1(-), IN2(+), IN2(-), and GND.

Making the device simple and pleasant to use means (to me) that it should auto-range rather than have buttons or knobs for the voltage and current range.  And having decent resolution through four or more orders of magnitude does require multiple ranges.

To start with, let's consider the input protection circuitry, starting with voltage measurement.  We need to not let anything bigger than 50-ish volts through to the main circuitry, without messing up the measurement.  I considered putting something like a 10:1 voltage divider on the input, but I don't really like that solution because it adds an order of magnitude to the amplification may need to do later (for small voltages), which will cause unnecessary noise to enter the system.

A better approach, hopefully, will be to prevent the higher voltage from reaching the sensitive circuitry by blocking it or shunting it away.

The idea that struck me right away is to use a high(ish) voltage FET as a switch, and set up the gate to only turn the switch on if the voltage is acceptable.  This is complicated a bit by the fact that the voltage coming in might be negative... I'm not really used to thinking about negative voltages (one of the reasons this project is a good learning experience!).

I found some schematics on-line for a couple of multimeters, and watched a great YouTube video on this exact subject (multimeter input protection) by the mighty Dave Jones of EEVBLOG, and nobody seems to use a FET-based scheme.  For now I'll put the idea on the back-burner and fiddle with it now and then.

I finally narrowed the options down to two different schemes:
  1. Use a varistor (e.g. a MOV) with an appropriate voltage as a shunt to GND.
  2. Use a pair of zener diodes (one for positive and one for negative) as, basically, regulators ... again shunting the excess to GND.  The problem with this is that dropping high voltage through a zener causes massive heat dissipation.  Even 50 mA of current when burning off 100 volts will produce 5 watts of heat.  So, instead of passing the current through the zeners, what about using the zeners to trigger a low-drop/low-resistance shunt device?  A triac seems ideally suited for this (since the voltage may be positive or negative).
In either case, we don't really want to shunt the input directly to ground; the current through that path could be very high depending on the characteristics of the DUT.  So I decided to put a current-limiting resistor right at the input (which shouldn't do any harm).

The varistor approach is much simpler and from what I can tell it is the standard method.  Still, I think for my first test board I will put in circuitry for both and just populate the pieces I want to experiment with.  Here's the schematic as it stands now:
Next up: Input circuitry for the current measurement!

Thursday, December 18, 2014

Processor Roundup

I've spent a lot of time over the last months checking out microcontrollers and low-power microprocessors, trying to figure out which ones fit my needs best... and the answer is (of course) that it depends on exactly which needs those are.  However, these are my selections:

Tiny:  Atmel AVRs.  Mostly because I am familiar with them and find them very easy to use.  For the most part, I don't see much reason to bother with 8-bit microcontrollers any more, but sometimes it's handy to plug in a little one to perform some simple function, and occasionally only a 5v rail is readily available, so they still have some uses.  AVR Studio is a nice development environment.

Tiny (alternate):  The little 8-bit PICs are cheaper... if I were ever to be in a situation where it meant a lot to me to save a few cents, that would be the way to go!

Simple, cheap, low power: Silicon Labs Geckos.  First of all because of their amazing power consumption, and second because of the amount of RAM and FLASH they cram in for the price.

General purpose:  STMicroelectronics STM32.  The STM32Cube/MX code generator / library thing is really nice now that it finally supports most of the chips, and there is such a huge range of features and packages... great stuff.  All else being equal I would reach for one of these.  I've been using the CooCox development environment to write code for these, which is pretty nice and free, although it takes a bit of effort to get it to work nicely with STM32Cube...

Powerful microcontroller: At $9, NXP's LPC4330 is one crazy chip!  Huge amount of RAM (264k), dual ARM cores running up to 204 MHz, SDRAM controller, LCD controller,floating point hardware, and the insane Serial GPIO subsystem make this thing a geek's dream come true... plus a 144-LQFP package that provides all the pins I could possibly need and still be solderable without major drama.  Writing code for it may be a rather steep learning curve, though.  Disadvantage: no on-chip FLASH (which isn't a huge deal, but it adds even more complication).

Next level:  I really really like Freescale's 128-LQFP i.MX233 processor.  This is right on the border of what I think I can work with at this point... much more on this chip in future posts!

Crazy power: Since someday I want to make a full-featured oscilloscope and other high-end gear, I'll want all the processing power I can get for those projects (budget is an issue though!).  Looking at the Raspberry Pi Compute Module, Allwinner A20 system-son-module, and the i.MX6.  No real think too hard about it at this point though!

Thoughts on a Cost-Conscious Bode Plotter

In my quest to design and build high frequency devices, one useful piece of kit would be something that can measure the frequency response of a bit of circuitry.  I think that this is one of the main functions of a device called a Network Analyzer -- but those are quite expensive tools.

It seems interesting to try to build something that performs just this one task, and (through this focus) keep the costs down.

So the idea is:
  1. Generate an accurate sine wave in the range of (say) 1 kHz to 100MHz or 200 MHz.  I don't have the chops yet to deal with signals in the GHz range, so I'll start with a more manageable frequency limit.
  2. Amplify the signal to a selectable voltage level.  Probably 5V - 10V is sufficient as a maximum, and for a minimum, whatever I can manage (ideally maybe 10mV or so).  For this purpose, it seems like being able to deliver the signal into a 50 ohm load is good enough, so 100-200 mA of current seems like a good goal.
  3. Deliver the signal to the Device Under Test.
  4. Probe the DUT at a desired point and deliver the voltage signal back to the test unit.
  5. Measure the peak and/or RMS of the return signal voltage.
  6. Perform this test repeatedly with different frequency values, under processor control.
  7. Display the resulting plot
 Each stage has its own challenges and requirements.

Sine Generation

After an extensive datasheet-reading expedition, I settled on the Analog Devices AD9951 400 MSPS Direct Digital Synthesizer chip.  It comes in a hobbyist-friendly LQFP package and can be had for $17 on eBay (I just ordered two).  The on-chip frequency tuning and 14-bit DAC should produce a nicely-accurate wave, and serial control lines should be pretty simple to control from a MCU.

Amplification

It shouldn't be too hard to find an appropriate op amp.  Researching the choices is my next task on this project.

Delivery/Return

A 50 ohm transmission line (using coax cable) should be able to deliver the signal with sufficient fidelity and current.

Measurement

A complete solution would incorporate an ADC with at least 400 MSPS... that approach would allow the measurement of phase information and make measurement of both peak and RMS values pretty easy.  But I'm not really ready to attempt such a high frequency ADC yet (and it would add significantly to the cost).  A future version of this tool might take this path.

For now, it seems to me that it should be enough to do one or more of the following:
  • Smooth the signal with a filter and sample the result at a low rate.
  • Build some sort of high and low peak detection/hold circuit and sample the output of that.
  • Use some sort of op-amp-based integration scheme to sum up the return signal.

Control

A general issue -- most of the projects I'm working on need MCU or CPU support (with varying levels of capability).  I will write a post soon about the choices I have made along these lines.  At any rate, it is not a huge hurdle.

Display

It would be good to be able to save the result for offline analysis if desired (maybe on an SD card or else transmitted over a USB link to a PC).  Besides that, the display aspect is another general issue, as most of the projects I'm interested in require some kind of decent display.  I will be making lots of posts about displays in the coming months, as it is something I spend a fair amount of time on and will continue to do so until I have a display system I am happy with.

More to come!


Wednesday, December 17, 2014

Hello, World!

I'm always working on bunches of projects.  I'd like to use this blog to report on them in case they are of interest to others (and to keep a record for my own reference).  I don't have any school or job-related training in electronics, but I do think it is very cool to understand and build things -- and self-regulated internet learning is pretty effective if one is motivated to persevere!

At present, most of the projects I'm interested in working on fall into a few categories:
  1. Lab and test equipment.  I'd like to work my way up to my own versions of full-blown powerful gear, like a high-bandwidth oscilloscope / signal analyzer, but I will tackle some smaller projects as stepping-stones.  I really like the idea of building my own lab gear, and expect to learn quite a lot in the process.  
  2. Motor control, CNC machinery, and robotics.  The electronic and software sides of physical manufacturing devices fascinate me, so I'm exploring circuitry to drive those things.
  3. Tiny circuits.  Making miniature electronics and electromechanical systems.
Plus, of course, other random cool things...

Anyway, I hope and plan to write about my adventures, starting today!