element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Members
    Members
    • Benefits of Membership
    • Achievement Levels
    • Members Area
    • Personal Blogs
    • Feedback and Support
    • What's New on element14
  • Learn
    Learn
    • Learning Center
    • eBooks
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • Experts & Guidance
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Dev Tools
    • Manufacturers
    • Raspberry Pi
    • RoadTests & Reviews
    • Avnet Boards Community
    • Product Groups
  • 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
Open Source Hardware
  • Technologies
  • More
Open Source Hardware
Blog ARMP - (Nearly) Complete Schematics
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Open Source Hardware requires membership for participation - click to join
Blog Post Actions
  • Subscribe by email
  • More
  • Cancel
  • Share
  • Subscribe by email
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: michaelkellett
  • Date Created: 23 Aug 2020 4:42 PM Date Created
  • Views 912 views
  • Likes 8 likes
  • Comments 3 comments
  • armp
Related
Recommended

ARMP - (Nearly) Complete Schematics

michaelkellett
michaelkellett
23 Aug 2020

I had hoped to to have completed the basic design by now but I've spent a lot of today thinking about

power supplies, but not getting quite far enough to commit to paper (or CAD).

The idea was always to have a a separate power conversion board, so there is no reason that the rest

of the design can't be offered up for discussion without the psus.

 

All the schematics will be posted as .pdf s but it's probably easier to have the blurry .jpgs in this blog for

instant reference.

 

I've added a second sigma delta converter to the design so it has the ability to accurately measure the

output current. At the expense of yet another relay it could also measure output voltage. The reasons for

doing this is so that those who want can use voltage control of the output, and those who want to measure

complex load impedances are able to do so.

 

A small digression is necessary here to explain my thinking, because it affects other decisions as well.

My intention with this design is not to end up with a commercial product but something that can be made

and be useful but is also capable of being re-purposed and tinkered with. With that in mind it already

has optional things that you can leave out and far more support for debugging and expansion than

most commercial devices. It must also be admitted that it is not designed to a commercial standard,

and will probably require tinkering ! Although I have spent quite a lot of time on the design it is only

a small fraction of the time and testing that I would expect to devote to a paid for design for production.

 

image

The ADC and DAC section has grown an extra ADC, as discussed above, but is otherwise very little different.

The second ADC is driven by an amplifier running from dual supplies so it could drive the ADC input negative

which might do it harm - so it has to be protected by D21 and D22.

For a more complete description check out the earlier blog about the ADC, DAC and FPGA sheet.

 

image

This is one of those dull schematics that could almost be a spreadsheet, but there is a little bit of stuff

worth pointing out.

The processor has two external flash memories, U17 which is 4kbits and for calibration data and U15 which will be

64 or 128 Mbits and is for data. I've found, through bitter experience, that it pays to keep them separate.

U16 is the FTDI USB interface chip which looks like a COM port to a PC that connects to it.

U13 is a precision voltage reference for the micros ADC and DAC. U14 is a a reset chip which will reset the

processor if the battery voltage is too low.

J6 is the connector to the Riverdi display - its connections and some extras are duplicated on PM1 which is a

PMOD compatible connector which can be used for a different display if required.

There are three more PMOD connectors, two have access to processor serial ports and are intended for Bluetooth,

expansion or whatever. PM4 is connected to otherwise unused pins on the FPGA (actually one of the pins is shared

with the user control connector but I shall try to avoid connecting anything to it.)

 

image

Finally we have the output section.

This has taken more work and thought than I expected when this project started.

 

Dave Martin has been urging from the start that we should provide more drive voltage than was my original plan

and I was already thinking along those lines when he posted his useful measured data the other day. This data

makes it clear that more volts would be a good idea.

This new design goes as far as we can without excessive cost or risk of electric shock.

I'm using OPA551 amplifiers which can work with 60V maximum Vspan and deliver a maximum of 200mA (more like 100mA in real life.)

The design of the current source has changed from my earlier efforts and is significantly improved. In the original design both amplifiers

were connected as current sources operating in opposite directions. This required 4 precision resistors per amplifier and still had

problems with balance and offsets.

In the new design U19 is configured as a current source but U20 is configured as a unity gain inverter so that its ouput voltage is

equal to but opposite in polarity to U19's. U19 controls the current but U20 doubles the voltage compliance - but U20 doesn't need

any precision resistors.

There's another twist which gets rid of offsets in the current which can be caused by errors in the resistors around U19 - C69 AC

couples the feedback which makes U19 a current source - which reduces the DC offsets to minimal amounts.

If you really want to do DC coupled work, then link out C69, or better still, remove C69 and reduce the value of R75. (In current

source mode R75 = R73, so if you open the R76/C69 arm of the bridge U19 works as a unity gain inverter. If you then reduce R75 to

R73/20 U19 will have a gain of 20 and the input voltage that would have given you 10mA will now give you 20V, but U20 will drive the

other output to -20V , giving 40V across the terminals.)

 

The maximum output the OPA551s will manage is about +/23V, so we can get about 44V pk (and 88V pk-pk) into the terminals

once the drops across the resistors R74, R79 and R82 are taken into account.

 

PTC1 and PTC 2 are protection devices which will limit the current flowing into the protection diodes on the amplifier outputs if

a large external voltage is applied. The PTCs work by getting hot, which takes time, so you still need resistors to limit the maximum

current. ZD1 and ZD2 are there to stop the external fault current from pulling the power supply voltage too high.

 

R82 is a current sense resistor and the voltage across it is measured by U21. The INA149 amplifier shown is very expensive (about £7)

but it does have a good enough common mode rejection to measure the current accurately. There are cheaper high input voltage

difference amplifiers but they won't be very accurate. RL4 allows you, at the expense of losing half the voltage on the output, to get rid

of the common mode voltage on the current sense resistor - and then you can use a cheap part for U21.

 

U22 provides a half supply reference voltage for U21 and U223 provides the necessary complementary signal to drive the ADC.

 

It's a lot of bits and a fair amount of expense to measure the output current properly - you could decide not to bother and for

some applications this will probably be fine - but we won't really know until we try it, (For impedance measurement accurate source

measuring is essential.)

 

 

image

This is the pcb from the component side, you can just make out the display in yellow on the other side. I won't start the

layout until there's been some discussion (and I add in the bits I've forgotten.) There is a prize of infinite Kudos (but nothing

else) to whoever spots the missing things !!

 

 

 

There's quite a bit to digest there I'm happy t  to answer  questions and receive suggestions.

 

MK

  • Sign in to reply

Top Comments

  • kltm
    kltm over 3 years ago +1
    Loops really interesting, I’ve been doing quite a bit of work on the case layout.
  • michaelkellett
    michaelkellett over 3 years ago in reply to shabaz +1
    It might be worth a quick look at how the FTDI/Bridgetek display controllers work just to make sure we don't end up with a clash of abstractions ! I've stalled on this waiting for feedback. That's not…
  • michaelkellett
    michaelkellett over 3 years ago in reply to shabaz

    It might be worth a quick look at how the FTDI/Bridgetek display controllers work just to make sure we don't end up with a clash of abstractions !

     

    I've stalled on this waiting for feedback. That's not intended to apply pressure - I understand that people have things to do.

     

    Since the next bit of work (for me) would be to do the board layout, which has no function other than to be an ERM, I'm not going to start it unless

    I get the feeling that there is a good chance of something useful coming out of it.

     

    There will be a bit more stalling, (on my part) because I have a RoadTest to do.

     

    MK

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • shabaz
    shabaz over 3 years ago

    Hi Michael,

     

    Sorry for the delay responding, I've been looking through the schematics, and will hopefully have some feedback soon. I had written some notes but misplaced them : (

    Regarding software, I've installed the STM IDE, and was happy to see that the desired elements of C++ are supported (just classes and a few bits of C++ coding preferences are all I care about mainly, and the compiler shouldn't bloat that). I've set up a development folder where I can compile and test quickly locally (i.e. x86 target) to reduce development cycle time since I don't need to build against the real target each time. And I have started work on a generic display system (kind of similar to how Linux does it, but micro-sized) where it doesn't care what is rendered to the screen, but it will manage areas and layering. It's efficient, it doesn't ever store the entire display content. This way people have complete freedom on UI and content style to enhance the display to be as basic or as pretty as desired, and it's separated from the guts which will manage what is displayed and send the content to the display. I'll share it once it is fleshed out a bit. It should work with any display or microcontroller (provided C++ is supported), so it can be reused in future for other projects too.

    I didn't initially plan to work on the display portion first, but since it ties in with event handling for user input and measurement events, it will help me construct the remainder of it too if I mentally have to think about the display aspects.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • kltm
    kltm over 3 years ago

    Loops really interesting, I’ve been doing quite a bit of work on the case layout.

    • Cancel
    • Vote Up +1 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 © 2023 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