element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Personal Blogs
  • Community Hub
  • More
Personal Blogs
Legacy Personal Blogs Creating an Instrument Control Board
  • Blog
  • Documents
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: Andrew J
  • Date Created: 26 May 2020 1:17 PM Date Created
  • Views 10207 views
  • Likes 13 likes
  • Comments 62 comments
Related
Recommended

Creating an Instrument Control Board

Andrew J
Andrew J
26 May 2020

Introduction

Jan Cumps, jc2048 and Robert Peter Oakes are building an electronic load with what they call a Booster Pack control board to front end.  I've found it really interesting to look at what is being done and decided I wanted to have a go at something similar without just replicating what they have done.  I also wanted to have a go at playing with a DAC and ADC so it seemed like a good tie-in.  More specifically, these are the questions I'm asking myself:

  • Could this be a generic control board for any instrument?  Jan's and Peter's has been designed alongside a Load/Power Supply but it's pretty generic and it strikes me that it ought to be possible to provide a software library for a board such that an application could be built on top of it, specifically for the purpose required.  Jan has layered his software in a similar manner.  A downstream instrument would be required of course, and that may have to reflect back to chosen components on the control board, but could the fundamental design be such that significant change would not be required?  Making it modular should facilitate that.
  • Could I create such a software library that could be used by applications built on top?
  • Make it SCPI programmable - I've been intrigued by Jan's approach to testing automation and it seems worthwhile understanding this protocol.
  • I want to make it independent of a PC for running - so wholly self-contained.  Jan's and Peter's are connected to a PC for automation and for power when full isolation from the power components is required.  If it will need connecting to a PC, I want to be able to do say without making board adjustments.
  • Like Jan and Peter I also want to protect the attached MCU.  I've previously burnt a £76 pound Arduino building my PSU because I slipped when probing and sent 15V into some mV analog inputs!  Whilst it is still somewhat functional I've learned that lesson and don't want a repeat.
  • How accurate can I make it?  Rather than just having software compensation, can more be done in hardware (Jan has/is already investigating this as well.)

 

I had intended to just write a one-piece post showing what I'd built rather than a multi-post description but Jan has expressed an interest in collaborating, a chance I jumped at, so I'm starting now.  The fact we're building different solutions for the same purpose should give us different insights, I hope.

 

So far, I've been working on a design and I'm ready to create a PCB for prototyping.  I'm sure that I don't have a final design yet but I have been trying things out on a breadboard as I go along and realised, somewhat belatedly, that it's now cheaper to get prototype PCB boards made up than buy DIL adapters for the ICs; depending on size, it's even cheaper than buying prototyping board!

 

It is a long read so...

 

TL;DR;

This is the start of a project for creating a modular instrument control board using DACs and ADCs. I'm trying to make it modular enough to be expandable, for example I'm considering adding a EEPROM module to hold calibration/compensation data.  It's as much about the fun for me of investigating DACs and ADCs (and Op Amps as it happens) as a 'solution' to a 'problem' I have.  In this post, I'm describing the approach to prototyping and component selection for the design I've created, and I am presenting my 'stake in the ground' design, broken down into its modules:

  • Power
  • Isolators
  • Reference supply module
  • DAC
  • ADC
  • Compensation module
  • Real Time Clock module
  • Fan module
  • Board I/O module
  • Off-Board Control module

At least in my imagination, I can see this as the front-end for a number of headless instruments, but that's much further down the road.  In a separate post I describe my choice of DAC, ADC and Op Amp.

 

Full Schematic

Here's what I've come up with after a number of trials with breadboards; iterations whilst choosing components; and finding, and resolving, problems.  At this stage, it's just a reasonably well developed 'stake in the ground' and is likely to undergo changes following prototyping which I cover off later.

Kicad files can be downloaded from Github.

There is a larger image in the attached PDF.

 

image

 

The schematic is grouped by module.  I used global labels as they are a bit clearer to see than net labels but serve the same purpose.  Interactions between modules are via these global labels so I'm hoping that it's easy enough to follow.  This block diagram should help:

image

 

Component Selection

This post became rather too long so I decide to offload this section to its own post Instrument Control Board - Component Selection.  I describe the choices I made when deciding on the DAC, ADC and Op Amp to use.

 

Power Module

image

In order to drive all components I need the following rails:

  • +12V for the fan module and the DC/DC Isolator to power the Isolated side.  This is provided by a high-efficiency 12V DC/DC regulator.  In turn, this provides a base voltage for creating the other rails. I've provided a bypass diode for it.
  • +5V for the majority of ICs on the board.  I've actually chosen here a SMD version of a stalwart LM7805 as it has a low noise output; I do have a high-efficiency 5V DC/DC regulator (same model range as the 12V one) but it has up to 75mV ripple on the output.  Again, I've provided a bypass diode for protection.
  • -5V for the Op Amps to alleviate any issues with signals close to 0V.  This is charge pump that inverts the +5V rail.

I also chose to insert a schottky diode to block any reverse voltage that may arise if things go catastrophically wrong with any attached instrument (I would expect that to have its own additional protection.)  I can't place this on the 5V rail because of the voltage drop so those elements would valiantly lay down their lives!  The DC/DC Isolator allows me to provide power across the isolation barrier from a single power source and mitigates the need for two power cables into any case, or for an attached MCU to be powered from an external source.  The capacitors on the output have been chosen based on some measurements I made when it was on a breadboard so may change when I test on a PCB.  In fact, any output noise doesn't seem to impact the operation of components on the isolated side.

 

The whole board is supplied from a +15V (minimum) supply - typically, a wall-wart or similar.  The red dotted line indicates the isolation barrier which the DC/DC Isolator straddles.

 

Isolators Module

image

The dotted red line is the isolation barrier and I term the left side, Side A, and the right side, Side B.  I have two isolators to cover what I need and the I2C isolator is self-explanatory.  The digital isolator uses a modulated RF carrier rather than light like an Opto Coupler.  The channels are fixed direction but I only need one input direct from Side B of the board - an alarm signal from the RTCC.  On Side A, the global labels connect direct to the Off-Board Control Module (essentially, direct to the MCU); Side B global labels connect direct to the relevant IC or module:

  • LDAC_A|B: This is a control signal for the DAC that synchronises the output of channels (Load DAC).  By pulling high, the Input Register for channels can be updated with a new output value without actually changing the the DAC Register value, which drives the output value; when it is pulled low the new values are transferred to the DAC Register and output simultaneously.
  • LDAC_CMP_A|B: LDAC control signal for the DAC used in the Compensation Module.
  • RESET_A|B: A reset signal for the DAC (not the Compensating DAC) that sets all the outputs to the power up value - zero in the case of this board.
  • PWRSIG_A|B: A passthrough to the Board I/O Module of the current state of the power button - High is Power On; Low is Power Off.
  • FAN_A|B: A signal to the Fan Module to turn the fan on (High) or off (Low).
  • RTCC_MFP_A|B: A signal from the RTCC module indicating that an alarm has triggered - this is passed to the MCU.

 

At startup, the digital isolator will default to output LOW on both sides:

  • LDACs: any DAC output change in this state will change immediately.
  • RESET: the DAC will not power up correctly (it will require a positive action on behalf of the Software Library to resolve this.)
  • PWRSIG: power is off.
  • FAN: Fan is off
  • RTCC_MFP: No alarm is triggered.

So, apart from RESET, this is fine.  There's no way around this start up behaviour if I want the ability to control the device RESET as the LOW output from the digital isolator will override any pull up resistor.

 

Reference Supply Module

image

This module will provide a reference to any other IC that needs it.  On the control board this is:

  • The MCP4728 DAC used in the compensation module.  This has its own internal 2.048V reference and each channel can either use that or Vdd (in this case, 4.096V) individually.
  • The AD5696R DAC used for output (pre-compensation).  This runs on its own internal 2.5V reference which has better specifications than the REF5040 so I will be using that internal reference.  However, looking at the graphs in the datasheet, this DAC performs better with an input voltage around 4V than it does at 5V.  As long as VDD has a minimum voltage of Vref + 1.5 (4V) then the internal reference can be gained up by x2.

The additional components are used for noise reduction and to trim the output and are as specified in the datasheet.  The 1uF capacitor works with internal resistors to create a low-pass filter with a cut off frequency of 10Hz.  The 10uF output capacitor, C33, is required and needs an ESR of <= 1.5Ohms, but preferably 1Ohm <= C33 <= 1.5Ohms.  The datasheet is quiet on specific values but gives a range of 1uF to 50uF and an example of 22uF.  That seems to work for Jan and Peter too.

 

DAC Module

image

I'm using a 16-bit, 4 Channel DAC which is driven over an I2C interface.  DAC outputs A, B and C go to the compensation module and DAC output D goes straight to the Board I/O module.  The Vref pin is an output of the internal 2.5V Vref; this DAC can take an external Voltage Reference but its internal reference specification is very good - better than a REF50XX for example.  This output also goes to the compensation module as there is no way to trim or otherwise adjust its value.  The GAIN pin drives the actual Vref value and thus the output value range; as configured with the connection to Vdd, it will provide a gain of x2 with an output range for the DAC channels of 0V to 5V.  I may decided during prototyping to reconfigure this to a gain of x1 (0V to 2.5V.)

 

The RESET pin works in conjunction with the RSTSEL pin.  RSTSEL drives the power-on reset function and, as configured, all channels will start up to zero scale - the other option is midscale; when pulled LOW, RESET will actually reset the DAC outputs to the level determined by RSTSEL.  When the board powers up, RESET will be held LOW automatically by the output from the Digital Isolator - as mentioned earlier, this will prevent the DAC from powering up properly - so before actually using the DAC, this pin must be pulled high and a delay incurred for the IC to correctly power up to its zero scale level.

 

Internally, the DAC has two registers for each channel.  Values to output on the channel are written into the Input Register.  This register is then copied to the DAC register and the output generated.  When that copy occurs is controlled by the LDAC pin (Load DAC): only when it is pulled LOW will the copy occur and the output adjust to its new level.  If constantly held low, all output is 'instantaneous', i.e. a write into the Input Register is copied to the DAC register immediately. When LDAC is high, that copy does not occur.  This will allow each channel to be updated (serially, through an I2C command) and then all channel outputs changed simultaneously by pulling LDAC low.  This allows for synchronisation of output.  The channels impacted by LDAC can be masked so it's possible to use this pin over a subset of channels.

 

I'm using the 4.096Vref to drive this DAC, rather than the +5V rail, as the graphs in the datasheet indicate it is a lot more accurate at around 4V input.  This is not being used to drive any Voltage Reference for the DAC to work as noted above.

 

ADC Module

image

The ADC I've chosen is a 16-bit, 4 channel IC from Microchip and the incoming ADC connections are straight from the Board I/O module.  It uses its own internal Voltage Reference limiting inputs to +-0V to +-2.048V and each channel can be used in a differential mode.  I haven't designed this to do that, yet, but I think I'm likely to do so; for example, measuring across a current sense will be more accurate if the kelvin feed is passed into the differential inputs of a channel.

 

I have chosen to buffer each of the incoming connections and provide for a Low Pass Filter between the OpAmp and the ADC input, as recommended in the datasheet.  I'm struggling to calculate an appropriate value for the LPF because there doesn't appear to me to be enough information given in the datasheet (see my notes in the post on Component Selection) so the resistor and capacitor shown here are placeholders and I'll use the prototype to see if I can improve things.  I've also provided input protection to the ADC in the form of fast switching, low current leak diodes that will route any high +ve or -ve voltage away from the OpAmp.  All of this I will be testing and validating in the prototype and it may well be that this whole input stage is removed!

 

Compensation Module


image

This is the most 'contentious' module and the one most likely to disappear I suspect.  The concept I have for this it to take the DAC outputs, which will suffer from internal errors (zero scale, offset, gain) and trim these through a differential amplifier via a compensating signal from a second DAC.  So, from the DAC module, I'm passing DAC channels A, B and C straight into this module.  The compensated output is passed straight to the Board I/O module but also into an ADC which will convert the value for feedback into the compensating routine.  The idea is that the compensating routine, in the software library, will adjust the compensating DAC output to 'trim' the output signal.  I'm not thinking that this occurs automatically all the time, but when the compensating routine is run, e.g. when the output is powered off or under instruction of the application that runs on top of the library.

 

I'm also passing in the DAC Vref signal (as a voltage follower) to see if I can trim the DAC outputs taking into account the actual value of the Vref used.  This does mean that one of the DAC outputs, DAC D, is not being compensated.

 

Do I think this will work?  Well, I have my doubts.  The ADC that is reading the values suffers from its own internal errors so that's going to impact any result, ditto the compensating DAC.  Offset and Gain errors can be trimmed in the software and that may well turn out to be good enough.  Also, it may be that it works well enough that having a manual calibration approach rather than automated approach is a better solution.  Whatever, it feels like an interesting challenge to investigate in the Prototype before I make any final decisions.

 

The DAC shown in this module are 12-bit ICs and not ideal for trimming 16-bit outputs.  If the prototype shows this approach works then I'll change it.

 

Real Time Clock Module

image

I thought it would be useful to provide some clock functionality, perhaps for timing of measurements.  It would seem that keeping track at a resolution better than 1 second is quite expensive and given that the time has to be retrieved over I2C not sure that's worth it.  So, this module will be accurate to 1 second - any further resolution would need to be finagled on the MCU (e.g. by taking a microseconds timestamp before/after the I2C read) and taken as 'reasonably accurate'; it would seem a reasonable trade-off.  This module has a dual alarm function as well, accessed from the MFP, which is routed back through the Digital Isolator to the MCU.  The MFP can be alternatively configured to output a square wave so I'm also routing the output to the Board I/O module in case it is useful.

 

I'm providing the means for a battery backup so that any configured date/time/calibration data can be stored - this will allow for relative measurements over a number of days for example or even just to keep a date/time on display on the MCU.

 

Fan Module

I can easily envisage many instruments requiring mechanical cooling based on feedback of temperature through one of the ADC channels.  It's going to be up to the application to determine when to turn on / off a fan but the software library will actually do it.

image

 

FAN_B is directly connected to Pin 11 (B5) of the digital isolator.

How it works

There are many designs on the internet for controlling a fan.  I've made some assumptions here:

  • 12V supply required
  • up to 0.5A current drawn
  • two wire
  • Activation driven by the MCU

There are 388 (as of writing) on the UK.Farnell website with no delivery surcharges and a wide range of operating current that meet these assumptions so they seem reasonable.

 

The 12V supply is fed out to the connecter and the diode (an SMD 1N4001 equivalent) is there to deal with any back-emf.  The MJD122 (a SMD version of TIP122) is used to actually control the turning on/off of the fan as follows.  The MCU can turn the fan on by pulling a digital output high which is reflected across the Digital Isolator, Pin 11 (B5), pulling the base of the MJD122 high, turning the transistor on into its saturation region allowing 12V to flow over the fan to ground.  When the MCU pulls the digital pin low, voltage at the base falls to 0, turning the transistor off causing an open-circuit for the fan turning it off.

The Digital Isolator, SI8661 can source 4.8mA typical/7.2mA max from a pin so I need to ensure that the limit isn't exceeded.  Calculations based on a range of current required by a fan of 100mA to 500mA

 

Ib = base current; Ic = collector current; Vbe = voltage base-emitter; Rb = base resistor; hFe = DC current gain aka beta

500mA:

From the datasheet: with an Ic of 0.5A, hFE  is 2000; with an Ic of 0.5A, Vbe = 1.4V

Ib = Ic / hFE = 0.5/2000 = 250uA

The base resistor needs calculating;

Rb = (Vin - Vbe) / Ib = (5.0 - 1.4) / 250 * 10^-6 = 14,400 Ohms

100mA:

From the datasheet: with an Ic of 0.1A, hFe is 500; with an Ic of 0.1A, Vbe = 1.25V

Ib = Ic / hFE = 0.5 / 500 = 200uA

Rb = (Vin - Vbe) / Ib = (5.0 - 1.25) / 200 * 10^-6 = 18000 Ohms

Also, calculate the minimum resistor size for the current limit, 4.8mA:

Rb = (5.0 - 1.4) / 4.8 * 10^-3 = 750 Ohms

Rb = (5.0 - 1.25) / 4.8 * 10^-3 = 782 Ohms

 

A resistor between 750 Ohms and 18000 Ohms is needed: I've chosen 2K2 Ohms to provide a safety overhead but not overly limit the current in case the fan requires more at startup.  Also I have that value on-hand.

 

Board I/O Module

image

Not really a module, just a set of headers that would be used to connect to any instrument.  It's worth mentioning that if I change the ADC inputs to allow for one or more differential inputs, then J5 would change to provide more incoming connections.

 

Off-Board Control Module

image

Off-board controls are all on 'Side A' of the isolation, with power provided by the DC/DC isolator.  I want to be able to drive this from a suitable MCU so I'm not providing header connectors for any specific device.  I will use my 4Duino because I have it to hand and I'm more familiar with Arduino coding - I've covered the 4Duino elsewhere - here and here -  so I won't go into much detail but the advantages I see here are:

  • Built in touch-capable LCD so no separate powering or control circuitry required
  • Built in ESP8266 for Wi-Fi access so no need to connect to a PC for remote control.
  • Built in SD card for data storage (e.g. logging profile data for off-board processing)

I have also made provision for a momentary power button to toggle the board output on/off - using a momentary button means I won't need to have any complicated syncing routing between any touch button on a screen and the button state which would be needed if it was a latching type.  A rotary encoder will provide an alternate input mechanism for selecting options or entering control values.  These are manual controls to supplement a touch interface.

There is a 14-pin header on the board for connecting power to the external MCU along with the control lines to/from Digital/Analog/GPIO pins.  The design schematic shows how I intend to connect the 4Duino to the board; the global labels on connections 14 - 7 go straight to the isolators.

 

Prototype Design

I've described above the stake-in-the-ground design but I want to explore some of these modules and concepts a bit more.  I've realised that it's actually cheaper to get some PCBs made up than it is to buy DIL adapters for the parts so I will be doing that.  It also gives me some time to get up to speed with creating tests and using Labview - Jan's approach to testing really appeals.  I have breadboarded quite a bit of this already (not compensation) so I do know that fundamentally, or at least electrically, the design will work.

 

So for the prototype I'm going to concentrate on the DAC, ADC  and Compensation modules.  I also want to do this in the context of the power supply and isolation components to see how (if) they impact control and accuracy.  Specifically, I want to cover the following with the prototype:

  • Characterise different ADCs with different performance and functionality specs.  I've picked the Microchip MCP3428, Texas Instruments ADS1115 and Analog Designs LTC2487.  These are all 16-bit, Sigma-Delta converters.  I will use jumpers to route signals where I want them, e.g. individual ADCs, or all ADCs.
  • Test the OPA4192, so for each ADC: 1 channel buffered with Low Pass Filter (LPF) using the ADC to apply gain; 1 channel gained-up by x2, with LPF; 1 channel buffered with no LPF, ADC providing gain; 1 channel unbuffered with the ADC providing gain.
  • Test various compensation approaches with an Analog Devices AD5696R DAC and Microchip MCP3428 ADC.  Here, I will use one DAC channel to provide an offset amount to another DAC channel; one DAC channel compensated with the approach documented by Jan here, from the AD white paper, figure 6; and one DAC channel uncompensated that I could use to pass its output straight through to the ADC circuit (or just measure it.)

image

 

I'll describe the DAC compensation and ADC modules but the others are pretty much the same as described above.

 

DAC Compensation Module

image

Here, you can see that I will ask the AD5696R to output a signal through one or more of its channels:

  • VoutA goes to a terminal block which I can either link directly into the ADC module inputs or run a load, say a resistor, and measure the voltage drop across that through the ADC module.  Although each channel is characteristically different, this will give me a baseline behaviour to measure against as well as additional flexibility in the prototype.
  • VoutB is fed into a compensation configuration as described in the AD paper linked above.  The values I've chosen generate an offset of 5mV according to the calculation and I assume that can be adjusted with the potentiometer.
  • VoutC is used to generate an offset compensation signal that is subtracted from VoutD's signal to adjust for that error.  In theory, I can read the 'actual' output through the ADC and dynamically adjust in software to get the signal I want.  I say in theory because of course there are other errors in that signal path and the ADC will introduce errors of its own, but I think it will be an interesting exercise nonetheless.
  • Vref is used to determine the internal reference voltage used to generate the DAC output as I'll need to account for that in any software compensation.

 

As the DAC outputs are being read and converted by the ADC, I can also characterise that and look for software compensation of its readings.

 

The aim of this is to determine the likelihood of improving accuracy of DAC output and ADC measurements through software and hardware.  The three different approaches should give me some flexibility; I couldn't think what to do with the additional OPA192 input so I've tied it off.  If anyone has any ideas, let me know.

 

ADC Module

image

In my linked post, Instrument Control Board - Component Selection, I make a comparison of three ADCs.  The reality seems that there is little choice in the market and each seemed to have strengths and weaknesses so I thought I'd give them all a go (although in my full design schematic I've drawn it up with the MCP3428.)  Each ADC's input signal path is through a jumper so I can test each individually, or any combination; the signal into each will be the same as it originates from a terminal block to which I can apply a signal.  I'm also testing the OPA192 in various configurations as well:

  • Ch1/0 is in a voltage follower set up with a LPF.
  • Ch2/1 is using the Op Amp to apply a gain of x2 again with a LPT.  This will hopefully give me a view on using the Op Amp to amplify the signal or the ADC's internal PGA.
  • Ch3/2 is purely a voltage follower with no gain or LPF.
  • Ch4/3 is without the Op Amp at all.  This plus Ch3/2 will hopefully give me a view on whether an Op Amp improves the signal at all.

I've provided a jumper to give the Op Amp power range between -5V/+5V and -5V/+12V to give me some flexibility in signals that are close to the rail.  For the MCP3428 that is irrelevant as its maximum input voltage is limited to 2.048V but the other two ADCs have a greater range.

 

The LPF is merely a placeholder as I've found it hard to calculate as the datasheet for the MCP3428 doesn't provide enough information.  Admittedly, I didn't check the other two in great detail in this aspect but the LTC3487 datasheet does state a requirement for the RC filter to have a time constant of < 580nS.  The values I have here give a TC of 10us, much greater than that - a 50nF capacitor with 10Ohm resistor would give a TC of 500ns (5e-7s) - so it will be interesting to see how that behaves compared to the inputs without the LPF filter.  I can of course change these values to see how it impacts behaviour.  In fact I may do some more work on that before the prototype PCB comes as 50nF is way greater than the MCP3428's sampling capacitor of 3pF and likely so for the other two ADCs.  I think the balance will be providing enough of a resistance for the Op Amp whilst keeping the capacitor high enough to act as a reservoir for the sampling capacitor.  10nF and 50Ohm would still give a TC of 500ns.

 

Summary

The above describes what I hope is a workable design and a reasonable way of testing it - much of the core element has been verified on a breadboard and I've written snippets of software to prove communication and control.  I have purposefully tried not to replicate what Jan et al are doing so that I can gain a better understanding of designing reasonably complex circuits myself and how they work in practice.  I feel ready to continue prototyping with a PCB so I can make better assessments of accuracy, noise etc. and see what needs changing/improving.  Now future weeks/months will be taken up playing around with the prototype and improving my experience of analysing and adjusting signals - should be a great deal of fun.  I'll make further updates as comments to this post unless there is something that I deem warrants a separate one.

 

I've attached PDFs of the schematics and the KiCad files are in Github.

 

Further Posts

Creating an Instrument Control Board (this post)

Instrument Control Board - Component Selection

Instrument Control Board - Prototyping the Power section

Attachments:
imageCB_Design.pdf
imageCB_Prototype.pdf
  • Sign in to reply

Top Comments

  • Jan Cumps
    Jan Cumps over 5 years ago +5
    I'll elaborate a little on the firmware / software. I'm still drooling over your hardware approach - so well designed. The eload has a core API. Representing all functions of a programmable load. I also…
  • jc2048
    jc2048 over 5 years ago +5
    I didn't know whether to comment on this or not. I don't have direct experience of this kind of analogue electronics, so best to regard these comments as 'thoughts' or 'musings' rather than advice. They…
  • fmilburn
    fmilburn over 5 years ago +4
    Very nicely done
Parents
  • jc2048
    jc2048 over 5 years ago

    I didn't know whether to comment on this or not. I don't have direct experience of this kind of analogue electronics, so best to regard these comments as 'thoughts' or 'musings' rather than advice. They might be helpful, or not. Something to think about, but feel free to disagree. And I might have things wrong or be worrying at things that don't matter.

     

    Minor mistake: C26 looks like it's the wrong way round.

     

    The switching converters are noisy. RS6 datasheet says 50mV max and TSR1 says 75mV max [both measured 20MHz B/W]. Neither would be a problem with digital logic. Not so sure with an analogue board. The RS6 will also push noise back out of its input, so your 12V rail potentially will be very noisy. How much of that will your 7805 stop? The higher frequency end will skip through via D4's reverse capacitance [and contaminate the ground], so the regulator doesn't stand a chance with that. Even with the noise lower down, it won't do too good a job and you're then betting everything on a couple of decoupling capacitors. Of course you might then say that the OPA4192 has a PSSR of 0.3uV/V (better than one part in a million), but look at the graph of PSRR against frequency. The figure they give you is for 1Hz, or something like that, because that's where the chip is at its best. By the time you're up to 1MHz, the PSRR has reduced to about 20dB (ie one part in ten) which means a lot of noise just running through the op amp and appearing at the output. So you'll be back to relying on the decoupling. Speaking of which, it's always a good idea to have a decoupling capacitor right at the device pins.

     

    Powering chips from a reference feels wrong to me. The DACs include digital stuff that will inject noise onto the reference.

     

    You might have problems with the reference stability if you have multiple tants hanging on the output. It will complicate getting the ESR right.

     

    Although the OPA4192 has a good input-referenced noise figure [5.5nV/root Hz], it also has a fairly high GBW figure (about 10MHz). That means, for a unity gain buffer, 17.4uV at the output. I think that's an RMS value, so the excursion is more [unlike a sinewave, for noise I seem to remember a figure of 6x is a reasonable approximation for the pk/pk value - might be wrong there]. In practice, the noise will be a little higher, because the 5.5nV is just the white noise [thermal and 'shot' noise] and doesn't include the low frequency 1/f ['flicker'] noise. You can deal with it either by restricting the bandwidth [if you don't need it] by choosing a slower op amp or by modifying the feedback network, or by simply filtering what comes out, or by doing multiple conversions and averaging.

    • Cancel
    • Vote Up +5 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Andrew J
    Andrew J over 5 years ago in reply to jc2048

    Thanks Jon/Jan - feel free to comment away, I'm always interested in insights which I follow up on.  Good spot on the capacitor, it must have got inverted as I was moving stuff around.

     

    I hadn't considered the extra capacitance on the REF5040 and you're right it likes a specific ESR range on the output which is hard to achieve with tantalums - the one I chose for the ref output seems to have the right ESR at low frequency but of course I'm paralleling that up!

     

    Noise: that's been a real frustration for me.  I've spent days reading around the subject, doing calculations and so on and getting nowhere.  I follow (and understand) various white papers and end up with what feels like crazy figures.  For example, I followed a TI reference paper with calculations and whilst their example ended up with something like 64nH and 66uF for an LC filter, my calculations gave something like 66nH and just under 1mF!  Even calculating a low pass filter for the op amp outputs gave me a figure of around 56kOhms for the R which can't possibly work for the ADC.  The biggest problem being that datasheets just don't give all the necessary information.

     

    I swapped a 5V TSR for a LM7805 (SMD equivalent) because of the noise but I had expected that to work reasonably well: the spec for this part show a ripple rejection of 65dB with a Vin of 11V (I'm using 12V) at 120Hz and from the graphs, ripple rejection ranging from 80dB at 10Hz, 68dB at 100Hz and 70dB at 10kHz.  The graph for attenuation as a function of output voltage, 5V, gives a ripple rejection of 80dB.  I'd assumed that this was the frequency that noise was attenuated at (so higher frequencies would be attenuated) - is this wrong?  Perhaps I'd be better off without D4 if it's going to negate any noise attenuation benefits - it would be easier to live with the loss of a cheap part in the event of catastrophe than having to deal with noise pollution?  I'd put it in really to deal with any capacitive load that might get connected.  There are other means of mitigating disasters with, say, a DC load connected.

     

    For the 12V TSR, I could certainly swap that for an LM7812 equivalent and I had thought about it.  I already have the 12V TSR and I'd assumed that its output being used to drive the RS6 and a Fan, ripple wouldn't matter so much for those and I was expecting the 5V regulator to attenuate it.  The RS6 as a DC/DC isolator actually had the lowest output ripple of the variants I checked out but isn't great in any case: the digital side on the breadboard certainly worked ok and I was measuring about 30mV pk-pk ripple.  I just couldn't identify an alternate way of getting isolated power to the digital side of the board but if you have any other ideas that don't involve either additional power supplies from the wall or plugging into a PC's USB port I'd be very interested to hear them.  Again, I'd looked at putting a filter on the input side of the RS6 but ran into the same problems of not having enough information from the datasheet and calculating ridiculous values - actually, the datasheet gives an input filter for dealing with EMI but I thought that was a different thing.  I'd also tried modelling something in LTSpice but I struggled to work out the correct way of representing it.  In the PCB that I'm working on, I've separated the grounds for the RS6 and the rest of the circuit and tied them together at the Vout pin - I couldn't figure out a better approach from my limited experience (this is from my prototype, not the main schematic, so reference ids may be different):

     

    image

     

    As for the LM2776 vs the LM2662 that Jan references (Jan, you mention LM3662 but I think you meant LM2662), there both switched capacitor inverters but I suspect that I may have an additional problem.  The LM2776 operates at a much higher frequency and ripple is dictated by both output current and input voltage and, according to the graphs, is likely to be in the low 10s of mV - I couldn't find equivalent graphs in the datasheet for the LM2662.  I suspect I don't have a big enough Cout but even so it may be that the load from the Op Amps it is driving may be too low and it will end up pulse skipping and output ripple is the poorest at low loads.  Ultimately the Op Amps are buffering the signal into the ADC inputs which will only be drawing small currents. Now, I had assumed that any load on the Op Amp output would be coming from the positive rail, not the negative rail, given that the output will always be positive - is that a bad assumption?  Not that that helps in this case anyway!  I'd also thought, I'm guessing incorrectly from what Jan says, that because the -ve supply is there to allow me to get close to 0V output then any ripple would be well outside the range that it would have minimal impact (-5V dc with around 20mV pk-pk riding on it.)

     

    And the OpAmp?  How does any one make a decision given the thousands of available options??  It struck me that the choice has to be a trade-off - which is what I did and described in my other post.  I'd considered that the noise was reported at the low end of frequency and not the whole story, but as part of decision making just took it that low was better and it was a parameter that was generally comparable across options as they all stated the spec in their datasheet!  I suspect that if I looked and found a slower Op Amp I'd be trading that off against something else.  My understanding of Unity Gain Bandwidth is that it is a point where gain is 1 and higher gains are achievable as the bandwidth reduces such that maximum gain will be below the cutoff frequency, defined by the Open Loop Gain.  For the OPx192, the Open Loop Gain is 110dB-126dB, say, 115dB so the cutoff frequency is about 17-18Hz.   For a DC signal (and I understand there will be an AC element riding on that) will the gain bandwidth product actually be relevant?  I thought not but...as you mentioned it, now I'm looking, particularly as you referred to 17.4uV and I can't work out how you calculated that - could you give me a clue? Yes I can and I can see what you are getting at. Ultimately, I tried to find an Op Amp with errors within 0.5LSB of the ADC but I'll look again.

     

    Sorry for the long post, but I wanted to respond to you and Jan where I'd gotten to thinking through to a design.  I have no mentor to steer me in the right direction except the kindness of you guys who comment.  I think I need to go back and revisit:

    • noise from the RS6 and LM2776
    • determine if the LM2776 is even the right part
    • dig more into GBW impact on DC signals and whether there is a 'better' Op Amp.

     

    Thanks for commenting, really appreciate it.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • jc2048
    jc2048 over 5 years ago in reply to Andrew J

    Sorry, I didn't follow up on your reply.

     

    I wasn't trying to say that your choice of op amp was a bad one. Although not as good as the very best low-noise bipolar parts, it's got a more than respectable noise figure. I was trying (somewhat badly) to indicate that one of your enemies with all this was going to be noise and was using that as an example of how you could easily generate enough noise, by doing something that ought to be as simple and transparent as buffering as signal, to reduce your 16 bits to 15 effective bits without hardly trying.

     

    What I hadn't picked up on though is that the ADCs are delta-sigma parts and I don't really know how that affects things. The ADS1115 part says that it samples at 250kHz to give 15SPS at the output. It also shows a frequency plot of an internal digital filter, which would suggest that it might reject quite a lot of the noise. So that might suggest that the RC filter is to stop noise from higher up aliasing down to the area where the digital filter couldn't take it out. [But I'm very unsure about that, so regard it as a speculative theory.]

     

    Did you consider a MOSFET for the fan control? The dissipation isn't that high for the darlington, but you've still got to dissipate it in the board with an SMD part. And 12V? That's another source of noise added to that power rail.

     

    You might consider some resistance between the ADC inputs and the diodes on the ADC Module. It would save the protection in the event that you accidently connected an input to a voltage rail outside of the 0 to 5V. There might be a case for some between the diodes and the op amp, too [on the basis that the internal protection for the inputs might come into effect closer to the rails than the external diodes and end up having to take most of the fault current - I haven't checked the datasheet]. You could always swap the resistors for links if they did have any measurable effect.

     

    Not very sure about just two GND connections on your connectors shared between so many lines (with some of them power and some digital). I know you don't want loops, but is that really the way to do it? [Genuine question. I don't know enough about this sort of design to say, but having a reference ground sharing with power returns doen't feel like the way to do it to me.]

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
Comment
  • jc2048
    jc2048 over 5 years ago in reply to Andrew J

    Sorry, I didn't follow up on your reply.

     

    I wasn't trying to say that your choice of op amp was a bad one. Although not as good as the very best low-noise bipolar parts, it's got a more than respectable noise figure. I was trying (somewhat badly) to indicate that one of your enemies with all this was going to be noise and was using that as an example of how you could easily generate enough noise, by doing something that ought to be as simple and transparent as buffering as signal, to reduce your 16 bits to 15 effective bits without hardly trying.

     

    What I hadn't picked up on though is that the ADCs are delta-sigma parts and I don't really know how that affects things. The ADS1115 part says that it samples at 250kHz to give 15SPS at the output. It also shows a frequency plot of an internal digital filter, which would suggest that it might reject quite a lot of the noise. So that might suggest that the RC filter is to stop noise from higher up aliasing down to the area where the digital filter couldn't take it out. [But I'm very unsure about that, so regard it as a speculative theory.]

     

    Did you consider a MOSFET for the fan control? The dissipation isn't that high for the darlington, but you've still got to dissipate it in the board with an SMD part. And 12V? That's another source of noise added to that power rail.

     

    You might consider some resistance between the ADC inputs and the diodes on the ADC Module. It would save the protection in the event that you accidently connected an input to a voltage rail outside of the 0 to 5V. There might be a case for some between the diodes and the op amp, too [on the basis that the internal protection for the inputs might come into effect closer to the rails than the external diodes and end up having to take most of the fault current - I haven't checked the datasheet]. You could always swap the resistors for links if they did have any measurable effect.

     

    Not very sure about just two GND connections on your connectors shared between so many lines (with some of them power and some digital). I know you don't want loops, but is that really the way to do it? [Genuine question. I don't know enough about this sort of design to say, but having a reference ground sharing with power returns doen't feel like the way to do it to me.]

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
Children
  • Andrew J
    Andrew J over 5 years ago in reply to jc2048

    Don't worry Jon, I didn't take it personally image

     

    I did take your comment about GBW and run with it though, as I note in a response further down this thread - basically, I didn't find anything better that wasn't trading off against another parameter!  Better choices (perhaps) were single input 0V-5V which could be powered as -2.5V to +2.5V but that requires the creation of an extra two power rails; it also then limits incoming signals to 2.5V.  I had considered this originally but decided that reducing resolution from 5V to 2.5V was not what I wanted at this stage. By that, I mean that the choice of ADC may change that decision: the MCP3428 has an input limit of 2.048V so clearly having an Op Amp with a +2.5V rail wouldn't be an issue; however the other ADCs can take an input unto Vdd (5V) so if prototyping says 'go with the ADS1115' for example, then +5V is what I want - I need to keep options open at the moment.

     

    Having said that, if you can identify an Op Amp that has a better balance of specifications I'm all ears, seriously.  The parametric search parameters tends to limit what can be searched for to reduce the thousands down to a manageable number so Heaven only knows what I may have missed!

     

    Delta-Sigma ADCs, as I understand it, will deal with a fair bit of the noise through the digital filter and oversampling process.  There's still potential for aliasing noise into the signal before it reaches the ADC input and the recommendation is to put a simple passive RC filter between the Op Amp buffer and the ADC input.  I have placeholders for such with nominal values and is something I'll look at in the prototype.  Datasheets don't always give enough information to determine what the RC values should look like and there's a tradeoff between too high an R for the ADC, too low an R for the OpAmp and too high a time constant for the ADC sampling time.

     

    "Two ground connections on the connectors" - do you mean in the Board I/O module?  I think I ended up with two because I had a 6-way connector on hand and didn't want to leave one connection floating whereas really that shouldn't have distracted me and this should be a 5-way connection (or 17-way altogether.)  Anyway, that's not the point of your comment so a bit by-the-by: I do think I'd have to be very careful allowing the creation of ground loops and I must have things referenced to one point.  I would envisage one of two things happening at the Board I/O: the ground connection is a star point for the down stream components; or the board I/O connector(s) are removed altogether and the 'control board' circuit incorporated into the wider solution schematic and ground adjusted accordingly.  Ultimately, everything must route back to the source of the relevant power rail, without creating the possibility of ground loops, including the components on the Control board - there lies the danger, I think, in providing multiple routes back for those components. 

     

    Did I misunderstand your comment?  I'm happy to explore this further as, frankly, ground seems easy to get wrong and hard to get right!  I've had trouble in the past - one such example: I just couldn't get a voltage/current/power sense IC working properly because I had it connected to a different ground reference point than the Arduino 'talking' to it.  Ultimately, they both routed to the same ground but clearly there was an issue there in how I'd connected them both to that point.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Andrew J
    Andrew J over 5 years ago in reply to Andrew J

    I found an interesting note here (Analog Design paper on Linear Design), jc2048 (Jon):

     

    There are a number of important points to be considered when making signal and power connections. First of all a connector is one of the few places in the system where all signal conductors must run in parallel—it is therefore imperative to separate them with ground pins (creating a Faraday shield) to reduce coupling between them.

     

    Multiple ground pins are important for another reason: they keep down the ground impedance at the junction between the board and the backplane. The contact resistance of a single pin of a PCB connector is quite low (typically on the order of 10 mΩ) when the board is new—as the board gets older the contact resistance is likely to rise, and the board's performance may be compromised. It is therefore well worthwhile to allocate extra PCB connector pins so that there are many ground connections (perhaps 30% to 40% of all the pins on the PCB connector should be ground pins). For similar reasons there should be several pins for each power connection.

     

    This would seem to back up your comment about 'just two GND connections'.  I'll take the time to read through the paper in more detail.

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • jc2048
    jc2048 over 5 years ago in reply to Andrew J

    My concern was mixing up the zero volt reference with the power return. I hadn't gotten as far as considering crosstalk between the signals.

     

    Say your ground connection was 10mR [two parallel connections with 10mR at each end] and the supply current stepped by 10mA, that develops a voltage of 100uV between the two sides on the ground [which is supposed to be a fixed, identical reference for both]. That's quite significant if you're trying to digitize in 38uV steps. Of course my 10mA is plucked out of the air, because I don't know what's on the other side, but you've given me the clue there may be some digital stuff there by the SDA and SCL lines. Whatever the actual figure, it's digital noise you'd presumably prefer not to have added to the signals.

     

    It would seem from the document that you're quoting that an accepted way to deal with that is to minimise the resistance as far as possible through multiple connections. I though there might be a way of separating the power from the signal ground, but there isn't really, is there? If the multiple ground connections aren't more or less equal, everything then takes the easy, lowest resistance path [at low frequencies].

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • jc2048
    jc2048 over 5 years ago in reply to Andrew J

    Having said that, if you can identify an Op Amp that has a better balance of specifications

    The LT1028 has a voltage noise figure of 1.1nV/rootHz. But it's a bipolar part and other specs may be worse. The current noise at the input is part of the penalty you pay. There is, however, a good section in the datasheet on noise. It deals with the noise from the source resistors connected to the inputs too.

     

    Really I was trying to draw your attention to the fact that white noise is a function of bandwidth. If you give a noise figure [from an oscilloscope trace, or whatever], then you should state the bandwidth it was measured over. (If you look at those converter datasheets, the noise figure is over 20MHz. So it might be that they've simply used the 20MHz bandwidth limit on the oscilloscpe as the filter.) So, to reduce it, you need to restrict the bandwidth. In this case you'll use a filter, but for conditioning a slow sensor, a slower op amp might be appropriate if it does everything else you want.

     

    Here are a couple of app notes that have useful stuff on op amps and noise

     

    https://www.analog.com/media/en/technical-documentation/application-notes/AN-358.pdf

    https://www.analog.com/media/en/reference-design-documentation/design-notes/dn015f.pdf

    • Cancel
    • Vote Up +3 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • Andrew J
    Andrew J over 5 years ago in reply to jc2048

    It should be easy enough to separate power and digital lines with ground between at the connectors.  What I do like about that document is the acknowledgement that the recommendations they give may not actually be possible to achieve when laying out an actual board!!  Useful to bear in mind...

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube