Circuit Design

ICRS: Power Board Prototype Design

kelliott121 Contests, Projects , , , , , , , , ,

SchematicBoard

The design for the board to supply power to both the Pi Zero and robot modules is fairly simple. It’s two components are a single-cell, LiPo charging circuit based on the MCP73831 and the Pololu adjustable step-up regulator. The charging circuit is fairly straightforward so I’ll just explain the step-up circuit which takes the output voltage from the single cell battery, passes it to the four pin input side of the step-up regulator, and gets back a boosted voltage from the second four pin output side of the regulator.

I also added four beefy diodes between the regulator and the 5V supply for the system. My reasoning behind this was to provide the ability to use multiple power boards, and therefore multiple LiPo batteries, in the system. Each regulator is limited to roughly three amps of current with the multiple boards, Arduinos, and the Pi Zero taking up a fair chunk of that. I was worried that the regulator wouldn’t be able to supply enough current to the motors and so I added the diodes so that multiple power boards could be safely put in parallel. I also decided to use an adjustable voltage regulator so that the output voltage of the regulator could be set higher than 5V so that the actual voltage seen after the diodes would be 5V after the diode forward voltage.

ICRS: Motor Board Prototype Design

kelliott121 Contests, Projects , , , , , , , , , ,

The first board I’ll go over is the Motor Board prototype. It’s fairly simple; excluding the Arduino that handles communication and control it only consists of encoder connectors and a dual H-bridge. My planned use for this prototype will be to control the main drive motors of the robot base module. The schematic and PCB are shown below.

Schematic

Board

H-Bridge

I’m using an L293D chip for the motor driver. As shown in Figure 10 of the datasheet, each half of the chip can function as a bidirectional motor controller. By driving PWM signals to the control inputs of the chip, the speed of the motors can also be controlled. Unfortunately, each half of the bridge can only handle up to 600mA, which is relatively low, but it’ll sufficient for controlling the basic motors I plan on using on the prototype robot.

Encoders

The encoders I’m using are KY-040 Rotary Encoders which will measure the number of rotations of the motors and provide feedback to the motor controller. The linked description explains how the encoders work better than I can, but essentially the Arduino will measure the speed and number of rotations that the motor is travelling at and apply more or less current to the motor to get it to the desired end position. I plan on using a basic PID loop for this which I will cover in a later post.

In addition to the encoder connectors on the left, I’ve also added a basic debounce circuit in the top left of the schematic. Because these encoders use mechanical switches, they’re subject to mechanical bouncing of the switch contacts and so I plan on using a capacitor to act as a low pass filter and absorb these bounces and clean up the encoder signal.

PiGRRL Switch: Creating the Controllers

kelliott121 Projects , , , ,

With the screen chosen and working, the next step for creating the PiGRRL Switch was prototyping the controllers.  Initially, I wanted something cheap and easy like a breakout board that acted as a Bluetooth HID joystick.  I was immediately drawn to Adafruit’s EZ-Key which acts as a Bluetooth keyboard.  At the time I’m writing this, however, it’s out of stock and seems to have been for a while.  Additionally, because it acts as a Bluetooth keyboard and not a joystick, it rules out any possibility of adding analog controls in the future.

Another alternative to a Bluetooth HID breakout would be taking apart a cheap Bluetooth joystick and putting it in a 3D printed casing.  However, I decided this would greatly reduce the design flexibility of the controllers and might make it difficult to reconfigure the controllers on the fly (i.e. using two JoyCons as one controller vs. using them as two separate controllers).

So with those two options off the table I decided instead to use a Bluetooth serial bridge.  The HM-10 BLE and HC-05 Bluetooth 2.0 modules are both cheap and plentiful and provide a good solution at the cost of some extra work.  These modules can be hooked up to the UART of an Arduino and paired via Bluetooth.  Once connected, it acts as a virtual serial port in Linux, allowing the serial data to be read just as if the Arduino was connected via USB or FTDI.  The only exception to this is that it doesn’t support firmware loading wirelessly.

2017-03-13 22.18.32

The next step was setting up the initial design on a breadboard.  Above is an Arduino Pro Mini, four pushbuttons wired to the digital pins, and the HM-10 BLE module.  I decided to use the HM-10 because of the lower power requirements (BLE being an initialism for Bluetooth Low Energy).  The code for the Arduino reads the values from the digital pins and prints out eight characters to signify which buttons are pressed (‘1’ for unpressed and ‘0’ for pressed).  Right now I’m using a byte for each button which is wasteful, so I’ll go back at some point in the future and make the code more efficient so each button is represented by a bit.

2017-03-14 22.50.16

Once everything was wired up and running I had a lot of trouble finding an app that could connect to the HM-10 as a serial terminal.  Apparently the BLE standard has a lot of bells and whistles that make configuration a bit more difficult.  After trying several different apps I eventually found Serial Bluetooth Terminal which can connect to both BLE and regular Bluetooth devices via a serial terminal.  Above is screenshot of my phone connected to the controller with the button status being transmitted.

2017-03-14 20.31.24

2017-03-14 20.31.37

With my proof of concept working, I soldered everything onto a proto-board, this time with eight buttons to serve as a D-pad and four action buttons.

With that complete the next step was connecting to the Raspberry Pi over a serial terminal.  Unfortunately, this was much more difficult than I expected.  I could pair and connect to the HM-10, but couldn’t find a way to mount it as a serial terminal.

2017-03-15 21.01.17

Rather than continue further down the rabbit hole, I decided to drop the BLE module for now and switch to the HC-05 modules I bought as a backup.  Those have been around for years and have been used extensively with Arduino and Raspberry Pi.  Once that module was paired and connected, mounting it as a serial terminal was as simple as using the following commands to connect and then print out the values read from the module:

sudo rfcomm bind /dev/rfcomm0 <MAC Address>
sudo cat /dev/rfcomm0

2017-03-17 19.20.25

2017-03-17 22.01.22

Lastly I connected the controller, screen, and Raspberry Pi to battery packs and verified everything still worked as suspected.  Success!  The next step is writing a program for Linux that reads the button data coming off the serial port and uses it to emulate a controller for the console.

OpenADR: Battery Charger PCB

kelliott121 Contests, Projects , , , ,

 

Schematic

ChargerSchem

Above is the final circuit for the four cell LiFePO4 charger.  I tweaked a few parts of the original design for safety, testing, and power considerations.  A diode has been added after the main voltage output to allow for the capability to parallel multiple battery packs.  Another thing is that I’m using generic PNP and power resistors so that the maximum charging current of the design can be adjusted as necessary.  Since the charging current of a battery is loosely based on its capacity (see C Rating), allowing for a wide range of currents makes it theoretically possible to use any battery size.  I also plan on using a charge current of ~100mA for my first go at this.  Doing so allows the batteries to charge slower and give me more resolution when testing the charging circuitry.

BOM

The components I’m using from this design are as follows:

Board

ChargerBoard

One last thing to note is that I purposefully chose to use through hole parts for the sake of debugging.  The excess space and exposed connectors make it easier to use alligator clips to measure the voltages and signals, making sure that everything is operating as it’s supposed to.

Next Steps

Soldering, assembly and testing!

OpenADR: Battery Charger Simulation

kelliott121 Contests, Projects , , , ,

With the charging circuit already designed for the LiFePO4 battery charger, I had to figure out a way to simulate a battery in order to simulate the circuit.  A battery is really just a voltage source with some internal resistance, so for the purposes of my simulation I just placed a .02 Ohm resistor in series with a voltage source.

LiFePO4 discharge curves
Source

To be realistic, I had the voltage source roughly follow the charging voltage curve of a LiFePO4 cell.  Just to be thorough, I also slightly varied the voltages of each of the four cells so that they were always slightly out of balance.  This better reflects real world conditions since cells are never identical and the circuit needs to be able to properly balance cells.

circuit

For each of the four duplicate cell circuits, I measured the current through the battery cell (using R2, R3, R10, & R14), the current through the TL431 (using R4, R7, R11, & R15), the current through the PNP transistor (using Q1, Q2, Q3, & Q4), and the voltage across each cell.

Results_thinner.PNG

The results show almost identical voltage curves for each of the four circuits.  The charging voltage of the constant current circuit follows the voltage of cell, maintaining a consistent 1A of current through each of the cells.  Once the desired 3.65V is reached for each of the cells, the current rapidly tapers off and maintains that voltage, continually trickling top-off current to each cell.  The transistor is then turned on and routes the excess current around the battery, correctly balancing each cell.

Next Steps

Overall everything looks correct and is performing as expected, so next up is putting this all on a PCB.  My next post will show the final schematic and board layout for the charger.

OpenADR: Battery Charger Circuit

kelliott121 Contests, Projects ,

Since I decided to use a 4S LiFePO4 battery in my previous post, I’ve been looking online for charger design resources and examples.  From what I gathered from several sources, I’ve come up with what I think is a circuit that will work for charging the LiFePO4 batteries.  Before I go into the details of the circuit, however, let me briefly cover the basics of LiFePO4 charging.

LiFePO4 Charging Basics

Most of what I learned about LiFePO4 charging comes from this article which goes into great detail about the charging specifics, but which I’ll summarize here for the sake of brevity.  LiFePO4 uses what’s called CC/CV, or constant-current/constant-voltage, charging.  This means that a constant amount of current is supplied to the battery when charging begins, with the charger increasing or decreasing the supplied voltage to maintain the constant current.  Once the battery reaches a certain voltage, 3.65V in the case of LiFePO4 batteries, the constant-current phase stops and the charger supplies a constant voltage to the battery.  As the battery gets closer to fully charged, it draws less current until it’s full.

Constant-Current Circuit

LM317

The constant-current circuit was easy enough.  The popular LM317 regulator has a constant-current configuration, shown by Figure 19 in this PDF.  Based on the equation in the attached PDF diagram, a 1.25 Ohm power resistor would result in 1A of constant current.

Constant-Voltage Circuit

The constant-voltage circuit was a little more complicated to design.  The difficulty with supplying a voltage to four batteries simultaneously is that the voltage needs to be evenly distributed to each of the batteries.  This is called cell balancing.  Without it, one battery may charge faster than the others, resulting in a larger voltage drop across that particular cell.  As the battery pack becomes more charged, the individual cells will become more unbalanced, resulting in wasted energy and decreased performance.  Once I took this into account, I realized I needed to both keep a consistent voltage across the battery terminals, and redirect current away from the battery when it had completed charging so that the other batteries could finish charging as well.

With this in mind I looked into using Zener diodes.  These operate like regular diodes by only allowing current to travel in one direction, up to a certain point.  Unlike regular diodes, however, they allow current to travel in reverse when a threshold voltage is exceeded.  They’re commonly used in power supplies to prevent voltage spikes.  When there’s a spike in voltage that exceeds the threshold, the Zener starts conducting and acts as a short circuit, preventing the voltage spike from affecting the rest of the circuit.  The problem with Zeners, as outlined in this post, is that they have a “soft knee” with a slow transition to conductance around the threshold voltage.  This results in inaccuracies in the threshold voltage required for the Zener to conduct, making it too inconsistent to use as a voltage limiter.

Luckily that posts outlines an alternative.  The TL431 acts like a Zener diode, but has a much sharper curve and a programmable voltage threshold.  By using a voltage divider with a potentiometer, it’s possible to tune the TL431 circuit to conduct at exactly the desired voltage.

CellCircuit

Above is the circuit I implemented.  Because the TL431 has a maximum current rating of 100 mA, I opted to use a PNP transistor as an amplifier.  When the threshold voltage of 3.65V is exceeded the TL431 conducts, turning on the PNP transistor and providing a short circuit to route current around the battery cell.  The complete charger is made up of four of these circuits in series with the high side connected to the constant-current circuit discussed above.

Improvements

Once I’ve verified that this circuit works and properly charges a battery, there are a few things I’d like to eventually go back and add to this circuit.  The first is an undervoltage detection circuit.  Lithium rechargeable batteries become useless if they’re ever fully discharged.  This full discharge can be prevented by cutting off the power from the batteries before they reach the absolute minimum cell voltage.  This is ~2V in the case of LiFePO4 cells.  A circuit similar to the one for maximum voltage detection could be used to check for the minimum voltage and disconnect the cells, preventing permanent damage to the battery pack.

I’d also like to add an output for the total battery pack voltage so a microcontroller can measure and detect the state of charge for the pack.  This would involve using a voltage divider to provide a divided down voltage within the measurement range of standard microcontrollers.

Next Steps

I drew up the circuit schematic described above in LTSpice, a free circuit simulation tool.  Despite LiFePO4 batteries being safer than LiPos, I’m still erring on the side of caution and will check my work every step of the way.  Simulation seems like the next best option to actually testing a physical circuit.  My next update will outline my simulation parameters and the results I saw.

OpenADR: Much Ado About Batteries

kelliott121 Contests, Projects , , , ,

This post is going to be less of a project update, and more of a stream of consciousness monologue about one of the aspects of OpenADR that’s given me a lot of trouble.  Power electronics isn’t my strong suit and the power requirements for the robot are giving me pause.  Additionally, in my last post I wrote about some of the difficulties I encountered when trying to draw more than a few hundred milliamps from a USB battery pack.  Listed below are the ideal features for the Nav unit’s power supply and the reason behind each.  I will also be comparing separate options for batteries and power systems to see which system best fits the requirements.

Requirements

  • Rechargeable – This one should be obvious, all of the current robot vacuums on the market use rechargeable batteries.  It’d be too inconvenient and expensive for the user to have to constantly replace batteries.
  • In-circuit charging – This just means that the batteries can be charged inside of the robot without having to take it out and plug it in.  The big robot vacuum models like Neato and Roomba both automatically find their way back to a docking station and start the charging process themselves.  While auto-docking isn’t high on my list of priorities, I’d still like to make it possible to do in the future.  It would also be much more convenient for the user to not have to manually take the battery out of the robot to charge it.
  • Light weight – The lighter the robot is, the less power it needs to move.  Similarly, high energy density, or the amount of power a battery provides for its weight, is also important.
  • Multiple voltage rails – As stated in my last post I’m powering both the robot motors and logic boards from the same 5V power source.  This is part of the reason I had so many issues with the motors causing the Raspberry Pi to reset.  More robust systems usually separate the motors and logic so that they use separate power supplies, thereby preventing electrical noise, caused by the motors, from affecting the digital logic.  Due to the high power electronics that will be necessary on OpenADR modules, like the squirrel cage fan I’ll be using for the vacuum, I’m also planning on having a 12V power supply that will be connected between the Nav unit and any modules.  Therefore my current design will require three power supplies in total; a 5V supply for the control boards and sensors, a 6V supply for the motors, and a 12V supply for the module interface.  Each of these different voltage rails can be generated from a single battery by using DC-DC converters, but each one will add complexity and cost.
  • High Power – With a guestimated 1A at 5V for the logic and sensors, 0.5A at 6V for the drive motors, and 2A at 12V for the module power, the battery is going to need to be capable of supply upwards of 30W of power to the robot.
  • Convenient – The battery used for the robot needs to be easy to use.  OpenADR should be the ultimate convenience system, taking away the need to perform tedious tasks.  This convenience should also apply to the battery.  Even if the battery isn’t capable of being charged in-circuit, it should at least be easily accessible and easy to charge.
  • Price – OpenADR is meant to be an affordable alternative to the expensive domestic robots on the market today.  As such, the battery and battery charging system should be affordable.
  • Availability – In a perfect world, every component of the robot would be easily available from eBay, Sparkfun, or Adafruit.  It would also be nice if the battery management and charging system used existing parts without needing to design a custom solution.
  • Safety – Most importantly the robot needs to be safe!  With the hoverboard fiasco firmly in mind, the battery system needs to be safe with no chance of fires or other unsavory behaviors.  This is also relates to the availability requirement.  An already available, tried and true system would be preferable to an untested, custom one.

Metrics

The rechargeability and safety requirements, as well as the need for three separate power supplies, are really non-negotiable factors that I can’t compromise on.  I also have no control over whether in-circuit charging is feasible, how convenient a system is, how heavy a system is, and the availability of parts, so while I’ll provide a brief discussion of each factor, they will not be the main factors I use for comparison.  I will instead focus on power, or rather the efficiency of the power delivery to the three power supplies, and price.

Battery Chemistry

There were three types of battery chemistry that I considered for my comparison.  The first is LiPo or Li-Ion batteries which currently have the highest energy density in the battery market, making them a good candidate for a light weight robot.  The latest Neato and Roomba robots also use Li-Ion batteries.  The big drawback for these is safety.  As demonstrated by the hoverboard fires, if they’re not properly handled or charged they can be explosive.  This almost completely rules out the option to do a custom charging solution in my mind.  Luckily, there are plenty of options for single cell LiPo/Li-Ion chargers available from both SparkFun and Adafruit.

Second is LiFePO4 batteries.  While not as popular as LiPos and Li-Ions due to their lower energy density, they’re much safer.  A battery can even be punctured without catching fire.  Other than that, they’re very similar to LiPo/Li-Ion batteries.

Lastly is NiMH batteries.  They were the industry standard for most robots for a while, and are used in all but the latest Roomba and Neato models.  They have recently fallen out of favor due to a lower energy density than both types of lithium batteries.  I haven’t included any NiMH systems in my comparisons because they don’t provide any significant advantages over the other two chemistries.

Systems

  1. 1S Li-Ion System1S Li-Ion – A single cell Li-Ion would probably be the easiest option as far as the battery goes.  Single cell Li-Ion batteries with protection circuitry are used extensively in the hobby community.  Because of this they’re easy to obtain with high capacity cells and simple charging electronics available.  This would make in-circuit charging possible.  The trade-off for simplicity of the battery is complexity in the DC-DC conversion circuits.  A single cell Li-Ion only has a cell voltage of 3.7V, making it necessary to convert the voltage for all three power supplies.  Because the lower voltage also means lower power batteries, several would need to be paralleled to achieve the same amount of power as the other battery configurations.  Simple boost converters could supply power to both the logic and motor power supplies.  The 12V rail would require several step-up converters to supply the requisite amount of current at the higher voltage.  Luckily these modules are cheap and easy to find on eBay.
  2. 3S LiPo System3S LiPo – Another option would be using a 3 cell LiPo.  These batteries are widely used for quadcopters and other hobby RC vehicles, making them easy to find.  Also, because a three cell LiPo results in a battery voltage of 11.1V, no voltage conversion would be necessary when supplying the 12V power supply.  Only two step-down regulators would be needed, supplying power to the logic and motor power supplies.  These regulators are also widely available on eBay and are just as cheap as the step-up regulators  The downside is that, as I’ve mentioned before, LiPos are inherently temperamental and can be dangerous.  I also had trouble finding high quality charging circuitry for multi-cell batteries that could be used to charge the battery in-circuit, meaning the user would have to remove the battery for charging.
  3. 4S LiFePO4 System4S LiFePO4 – Lastly is the four cell LiFePO4 battery system.  It has all the same advantages as the three cell LiPo configuration, but with the added safety of the LiFePO4 chemistry.  Also, because the four cells result in a battery voltage of 12.8V-13.2V, it would be possible to put a diode on the positive battery terminal, adding the ability to safely add several batteries in parallel, and still stay above the desired 12V module power supply voltage.  LiFePO4 are also easier to charge and don’t have the same exploding issues when charging as LiPo batteries, so it would be possible to design custom charging circuitry to enable in-circuit charging for the robot.  The only downside, as far as LiFePO4 batteries go, is with availability.  Because this chemistry isn’t as widely used as LiPos and Li-Ions there are less options when it comes to finding batteries to use.

Power Efficiency Comparison

To further examine the three options I listed above, I compared the power delivery systems of each and roughly calculated their efficiency.  Below are the Google Sheets calculations.  I assumed the nominal voltage of the batteries in my calculations and that the total power capacity of each battery was the same.  From there I guesstimated the power required by the robot, the current draw on the batteries, and the power efficiency of the whole system.  I also used this power efficiency to calculate the runtime of the robot lost due to the inefficiency.  The efficiencies I used for the DC-DC converters were estimated using the data and voltage-efficiency curves listed in the datasheets.

Due to the high currents necessary for the single cell Li-Ion system, I assumed that there would be an always-on P-Channel MOSFET after each battery, effectively acting as a diode with a lower voltage drop and allowing multiple batteries to be added together in parallel.  I also assumed a diode would be placed after the 12V boost regulators, due to the fact that multiple would be needed to supply the desired 1.5A.

 

 

Here I assumed that a diode would be connected between the battery and 12V bus power, allowing for parallelization of batteries and bringing the voltage closer to the desired 12V.

Conclusion

Looking at the facts and power efficiencies I listed previously, the 4S LiFePO4 battery is looking like the most attractive option.  While its efficiency would be slightly lower than the 3S LiPo, I think the added safety and possibility for in-circuit charging makes it worth it.  While I’m not sure if OpenADR will ultimately end up using LiFePO4 batteries, that’s the path I’m going to explore for now.  Of course, power and batteries aren’t really in my wheelhouse so comments and suggestions are welcome.

Big Seven Segment Display

kelliott121 Projects , , ,

Recently at work my team was throwing around the idea of real-time feedback by adding a big counter to the workspace to keep track of things like time left in the development cycle, number of static analysis warnings, etc.  For that reason I decided to build a large Seven Segment Display to provide that continuous visual feedback.  I designed the display completely from scratch to serve as a simple project that utilized a wide variety of skills.  Below I go through each step of the process and how each part works.

Mechanics

2015-07-24 17.30.41

For the actual segment part of the display I used transparent PLA from Hatchbox.  I didn’t have any trouble with how these turned out and am happy with the filament.  I had to do some experimentation with infill percentage in order to get the right amount of light passing through.  I believe in the end I settled on 20%.

2015-07-24 17.30.51

Here’s a close up of the semi-transparent digits.  Two 5mm LEDs fit snugly into the holes int he back.

2015-07-25 22.18.20

 

The individual segments are designing to press fit into black PLA frames.  I “welded” the four separate frames together using a 3Doodler to extrude plastic into the gaps.  For aesthetics I only welded the backs of the frames together, so while they’ll stay connected the seams won’t hold up to much abuse.

Electronics

Segment_Schem    Segment_Board.png

To keep board size small and reduce complexity I designed individual boards for each segment.  They only consist of two 5mm through hole LEDs, a current limiting resistor, and a 0.1″ header to connect to the main board.

2016-04-03 17.59.20

Here’s a pic of the boards soldered up and hot glued into the display.

Controller_Schem

Controller_Board.png

The control board is just a breakout for the TPIC6B595 which is a high current shift register that can power LEDs and be daisy chained together using SPI.

SparkFun ESP8266 Thing - Dev Board

I’m using the Sparkfun ESP8266 Thing Dev Board as the brains of the project.  This nifty little WiFi controller is Arduino-compatible and allows me to communicate with the display without needing to connect it to a USB port.

Firmware

Like I mentioned above, I’m using the SPI bus to communicate to each individual LED controller and daisy chaining them all together.  All that’s required is to write out four separate 8-bit numbers to set the appropriate LEDs.

The server side of things is the most complicated part of the project.  I borrowed heavily from the Web Server example in Sparkfun’s hookup guide.  The Thing board hosts a web server which accepts GET requests with the number to set the display two.  It then parses the string version of the number and converts it to the correct 8-bit sequence to set the seven segment display.

Software

The client side of things involved writing a Python script to submit the GET requests based on what data is being measured.  The current example is going through a directory and counting the occurrences of “if” in the code.

Source

As always, the source code and 3D files will be up on my Github.  I’m travelling this weekend, but will upload all the files Monday night.

Improvements

2016-04-08 12.43.14

While the LED display was plenty bright in my dim home office, I found out that they weren’t nearly strong enough to overcome the bright fluorescent lights at my office.  It’s difficult to see in the picture above, but it’s hard to read the numbers from more than a few feet away.  When I originally designed the display I erred on the side of caution and ran the cheap eBay LEDs at ~3mA.  Unfortunately, this was not nearly enough.  While it would be relatively easy to swap out the resistors to increase the current to the LEDs, I’m also unhappy with how much the plastic segments diffuse the light and think just making the LEDs brighter would only exacerbate the problem.

For version two I think I’ll experiment with two different ways to fix the problems above.  One option would be to use “straw hat” LEDs instead of the generic 5mm kind.  These LEDs have improved light diffusion.  I could also use hemispherical holes in the plastic digits, rather than cylindrical ones, so that the light is directed in a wider pattern.

Another option would be using WS2812B.  In conjunction with an improved plastic digit to help with light diffusion, this LED would greatly simplify the electronics of the display.  These LED modules have built in resistors and control logic, allowing them to be daisy chained and controlled via a serial interface without any need for the shift register control board that I used for version one.  WS2812Bs are also RGB LEDs, so another benefit is that the color would be controllable.

Hopefully I’ll get a chance to start on version two soon!

Maker’s Tablet: Multimeter

kelliott121 Projects ,

schematic

I decided to design and build my own digital multimeter for this project because I couldn’t find a suitably cheap USB multimeter.  Designing my own also let me flex my analog circuit design muscles as well as control the size and shape of the board.  Below are the different sections of the circuit and a brief explanation of how each works.

Vmeas

This is the voltage measuring circuit.  It operates by measuring the voltage between the two resistors in a voltage divider circuit with three selectable voltage ranges.  Turning on the 10kOhm resistor allows for a maximum of 10V, the 2kOhm resistor allows for a maximum of 25V, and the 470Ohm resistor allows for a maximum of 100V.  Details on how the resistor values were calculated can be found in the Instructables article where I found this design.

 

Imeas

The current measurement circuit uses a combination of Ohm’s law and a shunt resistor with a low resistance.  The voltage generated over the resistor is then amplified by a non-inverting amplifier.  With a gain of 5x from the amplifier, a 1 Ohm power resistor, and two 500mA resettable fuses, I can measure a maximum of 1A of current.

 

Rmeas

The resistance measuring circuit is the only thing I decided not to use from the multimeter Instructable.  The original circuit used a constant current source and Ohm’s law to determine resistance, but because I wanted a simpler circuit I just used another voltage divider with selectable ranges.  The only downside of this method is that the resolution of the measurement will now be non-linear, but I don’t think accuracy will be a huge deal for most of the circuits I’ll be working on so I’m not that concerned.

layout

Above is the final board layout that I’ll be using.  I kept most of the components as surface mount to minimize board size.  Now all that’s left is checking to make sure it actually works!

Maker’s Tablet: Xprotolab BNC Adapter

kelliott121 Projects ,

As I mentioned in my previous post, I was unhappy with the standard 0.1″ headers that the Xprotolab Plain used for measuring analog signals, so I created an adapter board that would connect standard BNC connectors to the oscilloscope header. BNC connectors tend to be the standard for analog signals due to their compatibility with coax cables which reduce the noise on analog signals.  In addition to routing the two oscilloscope channels to BNCs I added a third one to route the AWG waveform out of.  However, due to the voltage range only being +/- 2V, I decided to add some signal amplification to increase the range to +/- 8V.

Schematic

Below I’ll break the schematic down into pieces and explain the purpose of each.

 

xproto_con

This is the connector to mate with the Xprotolab Plain board.  Both oscilloscope channels, the oscilloscope trigger pin, and the AWG are broken out.

 

5v

Rather than adding a step up regulator to the board to boost the Xprotolab’s 3V to the 5V that is necessary for the Max680 circuit, I just left a connector on the board to feed the 5V supply.  Due to the large amount of USB components that will be in the tablet, I expect it will be easy to connect the USB power to this input.

 

trig_con

I’ve routed the external trigger for the oscilloscope to a 0.1″ header.  Because it’s a binary signal I don’t need to worry as much about high speed signalling and noise.

 

 

BNCs

These are the three BNC connectors for the two oscilloscope channels as well as the AWG output.

 

Boost

This is a boost converter that takes in 5V and generates +/- 10V to use for the amplifier rails.

 

Amplifier

This is just a basic inverting amplifier using one of the op-amps in the LM358.  It takes the AWG signal as an input and amplifies it up to a +/- 8V signal.  Due to the inner workings of op-amps, it’s not possible to use the full +/- 10V, so I rounded down to the next even number.  The resister ratio (R2/R1) needed to be 4x to achieve the proper gain to amplify the 2V signal to 8V.  However, because most resistors have a 5% tolerance, I used a 10kOhm potentiometer for R2 rather than a 4kOhm resistor so I could adjust the gain to be exactly 4x.

Layout

Here’s the final layout for the board.  Notice I didn’t use a powered plane on the top board layer like I usually do.  This is to prevent any power bus noise from interfering with the oscilloscope signals.  I also tried to keep the traces as thin as possible because thicker traces cause more signal degradation.  For anyone interested in ordering this board for themselves, it’s available on OSH Park here.  I kept all of the components as through hole parts to make soldering easier.