Friday, November 23, 2018

PIC32MZ/EF Pin Slew Rate Control

If you look very carefully at the PIC32MZ/EF processor data sheet you will find a few references to the ability to set individual pins Slew Rate. This functionality essentially changes the driver output current in several discrete levels. This then changes the achievable Slew Rate of the pin, or: “How fast the pin transitions from one logic level to another”. This is useful in controlling ringing on traces and meeting EMI emissions requirements.

While FPGA’s have Slew Rate control on nearly all their output pins, the PIC32MZ/EF only has this available on selected pins.

Two registers attached to the port registers control the Slew Rate of the selected pin and each pin can be set independently of the others.

The Slew Rate control registers are,

    SRCON0x, SRCON1x

Where ‘x’ is the port letter designation (A, B, C … K)




Figure 1: Section 12:2 of the PIC32MZ/EF data sheet gives a brief description of the Slew Rate functionality. Also note that the table lists: Slowest, Slow, Medium and Fastest – yet the enumerations in Harmony list these as: Slowest, Slow, Fast and Fastest. Showing just how hard it is to keep ‘comments’ and ‘code’ synchronized, using the same terms!


To find the ports/pins that allow this control, search the data sheet for: ‘SRCON0A’, B, C, etc… This should take you to the tables in section 12.5 of the data sheet titled: “I/O Ports Control Registers” (Be careful that you are looking at the proper table for the exact package of the device you are using). The SRCONx bits are currently listed at the bottom of each port register table.

The port pins that allow Slew Rate control on a PIC32MZxxxxEFx064, a 64 pin device can thus be found as follows,

    Port B: RB14, RB10, RB9, RB8 RB5 and RB3
    Port C: No pins
    Port D: No Pins
    Port E: RE3, RE2, RE1, RE0
    Port F: RF1, RF0
    Port G: RG9, RG6
   
Similar lists can be quickly made for the other package types.

It can be seen that this is not every pin in the PIC32MZ/EF-064 device. So what is the logic here?

#1 – There are a few high speed, 50 MHz SPI ports available on this device and they have specific requirements of what pins must be used for high speed operation.

    • 50 MHz Max on SPI2: Pins RB3 &RB5
    • 50 MHz Max on SPI3: Pins RB10, RB9 & RF0

    These Fast SPI pins are all Slew Rate controllable

#2 – The REFCLKOx pins can be mapped to Slew Rate controllable pins.

#3 – In PIC32 devices that include a DDR SDRAM interface, the drive strength of that interface is also controllable as a whole. See the Harmony enumeration: “DDR_PHY_DRIVE_STRENGTH”.


Controlling the Pin Slew Rate

There are several Harmony 2.x functions available to control the Slew Rate of the pins.

Note: See Harmony Help for exact details on using these functions.

* See if the Slew Rate functionality even exists for your PIC32 device,


* Get the current Slew Rate setting of a port pin,



* Set the Slew Rate for a pin or a group of pins on a port (i.e. Channel),



The Slew Rate is specified as one of the following enumerations,



The ‘channelMask’ is a UINT16 that has a ‘1’ in the pins bit position for the pin you want to change, otherwise the pins strength remains the same and is not changed.

For example, to set just RB3 to the ‘Slow’ Slew Rate,



To Set pins B3 and B5 to the ‘Fast’ Slew Rate,


The various PLIB functions above must be called manually in your PIC32 Project as there are currently no Harmony Configuration Settings for the pins Slew Rates.

This is easy enough to do with a ‘Standard’ Harmony Application in the App_Initilize() function as shown in Snippet 1 below.


Snippet 1 – An example showing how to set an individual pin to a selected Slew Rate in the Harmony App_Initialize() function, this function is located in the file App.c.


What Does Each Setting Do?

The PIC32MZ/EF data sheet is a little vague on the exact nature of the various Slew Rate setting, so I made some measurements on one of my proto boards.

First thing is to compare a normal pin with a Slew Rate controllable pin. Note that the default Pin Slew Rate is set to Fastest for the Slew Rate controllable pins (See the note on the bottom of figure 1).

Using a standard CMOS loading test circuit [1], I measured a normal pin and a Slew Rate controllable pin, a plot is shown in figure 2 and 3. The various Slew Rate settings of a fast pin are shown in figure 4. Table 1 summarizes all the results.


Figure 2 – Rise time comparison of a normal pin and a Slew Rate controllable pin at their fastest settings.

 

Figure 3 – Fall time comparison of a normal pin and a Slew Rate controllable pin at their default settings.



Figure 4 – Effects of the various Slew Rate Settings applied to a test pin.

  

Table 1 – Tabulated Slew Rates of the various Pin types and Slew rate settings.


Wrapping It Up

The Overshoot seen in the figures at the fastest pin Slew Rate setting is undoubtedly a result of my test fixture being less than optimal. Normally the Oscilloscope probe would be located very close to the devices driving pin to minimize the parasitic inductance of the trace. In my ‘Quick-N-Dirty’ test jig, I used a MINI32MZ PIC-On-A-Stick module, this interfaced to one of my own breakout boards. The length of the trace from the PIC32 pin to my Oscilloscope probe is approaching 1 inch and even worse for a fast pules is the 0.1” header strip that the pulse has to traverse from the PIC32MZ to my breakout board and test load. These header strips add quite a lot of inductance to the overall path.

This, through leads to a great demonstration of why Slew Rate control adjustments are so useful in digital applications. My less than perfect test fixture is a ‘real’ PCB and I have seen much worse designs than what I had, still look at the amplitude of that ring I was able to make in just an inch!

In the fastest setting shown in figure 4 that little, high frequency ‘ring’ can cause all sorts of EMI emissions issues. In the worst case the ringing can be so bad as show up on the leading edge of the pulse, or be so high in amplitude to possibly cause double clocking.  This is why the PIC32 devices that have an external DDR SDRAM interface have Slew Rate controls on all the pins associated with those ports. It is much easier to set the output pin Slew Rate to control EMI and ringing than to add, then adjust, a bunch of series resistors in each output line on a PCB to control the rise time and overshoot problems.


Notes:
[1] The standard CMOS loading circuit is 15pF in parallel with 1 Megaohm to ground. The measured rise time of the Oscilloscope used was 1.2 nSec. The Oscilloscope rise time was not corrected for in the rise time plots. It is corrected as noted in the tabular results.


Article By: Steve Hageman www.AnalogHome.com

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.


Note: This Blog does not use cookies (other than the edible ones).

Wednesday, September 12, 2018

How I spent my Summer Vacation

I remember in the 5th Grade, at the beginning of the school year we were tasked with writing 500 or some such words on that very subject. I didn't like the assignment, perhaps because I didn't really do anything that I thought was noteworthy. I do remember listening to many faraway lands on Knight Kit and Magnavox Shortwave radios, plus looking at the Stars and Planets with my trusty Tasco Telescope.

But this year was way more fun than that!



I built this small footprint Data Acquisition System.

  • 32 Bit MCU @ 250 MHz with Floating Point Unit
  • 5 x 16 Bit ADC's
  • 3 x 16 Bit DAC's
  • 3 x DDS Chips
  • +/- 1 Amp Precision Current Source 
  • 6 Analog IO Pins
  • 8 Digital IO Pins
  • Thermometer + Barometer
  • Real Time Clock
  • Onboard EEPROM
  • MicroSD Card for Data Logging
  • 6-30 VDC Input Power @ 1 Watt
  • Reduced 2 x 4 Inch Footprint

Article By: Steve Hageman www.AnalogHome.com

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.


Note: This Blog does not use cookies (other than the edible ones).

Sunday, June 10, 2018

Improving Code Quality with Microchips MPALB-X IDE and XC32 Compiler

Authors Michael Barr [1], Les Hatton [2], Robert Martin [3] and a host of others basically plead with programmers to use more formal code analysis techniques, such as: “Static Analysis” during the design phase of all embedded projects.

Addition of these steps is not time consuming or even expensive in most cases, the payback is usually justified by preventing even a single problem in shipped code.

Recently I have moved all my Microchip PIC development to their MPLAB-X and XC32 compiler. This saved a nominal sum per year in compiler updates, because this Microchip tool chain is free and it makes my clients also happy to be able to get the development tool chain for really the cost of a very simple programmer / debugger.

The XC32 compiler is a version of the venerable GNU GCC compiler geared especially for the MIPS based PIC32 product line. This tool chain also includes their rather all encompassing ‘Harmony’ software framework that handles all the driver and peripheral initialization and provides a consistent Hardware Abstraction Layer when programming any of the PIC32 devices.

Note: This article applies to MPALB-X version 4.15 and greater and XC32 Version 2.05 and later, the current versions as of June 2018.

Improved Static Analysis for Free:

The first step to better code is to turn all the GCC warnings, this is accomplished by supplying the ‘-Wall’ switch to the compiler options window [4], as shown below.



   Add All Warnings to the XC32 compiler options

‘Wall’ or ‘Warnings All’ will enable all the possible compiler warnings, but it doesn’t go out of its way to mark every library function as a problem. I find that it only adds three or four warnings from a previously cleanly compiled project. The errors it finds are mostly relevant and easy to deal with. You will find unused variables, bad definitions and improperly initialized variables.

I’m not sure what level of warnings are enabled as default in XC32, but you should definitely not compile without ‘all warnings’ turned on. It’s absolutely free, so use it.

GCC supplies a push/pop mechanism to disable specific warnings at various places in the code.

For example the function,

void foo(void)
{
    int32_t unused = 0;
}


will produce a warning: “warning: unused variable 'unused' [-Wunused-variable]”

This warning (or other warnings) can be disabled at the ‘function scope’ like this,

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
void foo(void)
{
    int32_t unused = 0;
}
#pragma GCC diagnostic pop


The above works to disable this specific warning at the ‘function level’


Trying to disable this warning inside a function will not always work and may be ignored.

void foo(void)
{
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wunused-variable"

    int32_t unused = 0;

    #pragma GCC diagnostic pop
}

The above does NOT work to disable this specific warning inside a function.


If you think about the above example, this makes sense. How could the compiler know that the variable is unused until it hits the final closing brace ‘}’ ? So by extension this example does work,

void foo(void)
{
    #pragma GCC diagnostic push
    #pragma GCC diagnostic ignored "-Wunused-variable"

    int32_t unused = 0;
}
#pragma GCC diagnostic pop


The above does work to disable a specific warning inside a function, but not for a single variable. This will disable the ‘unused variable’ warnings for all variables between the ‘ignored’ and the ‘pop’.


For more information in the GCC diagnostic pragmas see Reference 5. Also note that Microchip makes no mention of this functionality in their documentation so it should be considered: ‘Undocumented’.


Improved Static Analysis for very little cost:

The next level of static analysis is to use a ‘Lint’ program [6]. First developed for UNIX in the mid 1970’s, but not widely used with regularity much of anywhere else because of the lack of suitable executables.

In the mid 1980’s when I first started writing C code, there was a program advertised called PC-Lint [7] and it sold for probably $300 then. That was a lot of money. Today the same program, but updated for 30+ years sells for $400. That’s not so much money when you consider the cost of giving one bug to your customers. In fact now, it’s downright cheap and will pay for itself if it finds a single problem! There are a few open source version of something like Lint, but nothing that compares to a reasonably priced, finished commercial product like PC-Lint.

MPLAB-X contains an optional plug-in to enable PC-Lint functionality inside the MPLAB-X environment. It is fairly easy to get going, but it took me probably 3 hours to get it working inside MPLAB-X the first time. I might be able to save you some time with the following instructions.

Installing the MPALB-X Plug-In:

Start MPLAB-X and install the PC-Lint Plug-In
    Tools - > Plugins - > Available Plugins
    Select: “PC-Lint Plugin”, and finally select: “Install”.


Installing PC-Lint:

With the advent of User Account Controls (UAC) in Windows 7 and later it is much harder to get software to play properly, because many programs need elevated privileges to have access to certain directories, etc.

The default install location for PC-Lint is in “C:\Program Files(x86)\PC-Lint”, this is a problematic directory when running with UAC enabled, and I wasted an hour trying to get configuration files properly written until I gave up and re-installed PC-Lint off the root directory here: “C:\PL-Lint\”, then no problems at all. Just do this and save yourself time!

Even with the very latest PC-Lint version you won’t get the latest XC32 compiler initialization files or ‘.Int’ files. You will need to go to the Gimple website (www.gimpel.com/html/pub90/co-xc32.lnt ) and get this file,

    co-xc32.Int

Save the file in this directory,

    C:\PC-Lint\Int\

Don’t run the PC-Lint supplied configuration file builder (CONFIG.exe) it won’t know about the latest co-xc32.Int file anyway and it will just need to be manually modified anyway.

Instead just make a file named: ‘XC32-std.Int’ in the directory: “C:\PC-Lint\”

Place these lines in the file,

//  Microchip MPLAB XC32 C, -si4 -sp4,
//  Custom lint options file for XC2 V2.x

co-xc32.lnt

C:\PC-Lint\options.lnt  -si4 -sp4
-i"C:\Program Files (x86)\Microchip\xc32\v2.05\pic32mx\include\lega-c"


You may need to modify the exact path and name depending on your circumstances. Here you can see that I am using Harmony Version 2.05 and I use the ‘Lega-c” library and include files.

If you are in doubt as to the exact path to use, just open up your projects ‘stdio.h’ or some other well known system header file and see what the path is by hovering on the file name tab in the GUI, then use that.

Make sure that there is a file called: “Options.Int” in this directory also: “C:\PC-Lint\”. Right now this file can just have a single empty line in it.

Now setup the PC-Lint interface in MPLAB-X. Select: Tools - > Options → Embedded and then select the PCLint tab at the right hand side as shown below. Then click: OK.



Set these options as above on the PC-Lint configuration screen.


Right click on your main projects name, then select: “Generate PCLint Dependency Files” You should see this in the PC-Lint output window.

If the directory is not writable these files will not be written correctly and you will waste another hour trying to figure out why. To be safe, re-generate these files every time you switch and start working on another XC32 project. Just think of it as “Getting Latest” from your source control.


Let’s go Linting:

This step will seem daunting and you will wonder why you did all this in the first place. Why? Because your first ‘Lint’ will produce about 20 pages of warnings.

Let’s try it – Select a small ‘c’ file from your project, like “App.c” for example, right click on its name and select: “Lint this file”.

Have no fear – 99% of those warnings will be the same complaint about some name probem or some header file, etc. These warnings that can be easily suppressed.

Just open the file: “C:\PC-Lint\options.Int” file and start adding errors to suppress the spurious warnings. In 30 minutes, by checking half a dozen of my code modules, I was easily able to get rid of all the ‘chaff’ and get down to those few simple things that should be checked or fixed.

Here is the “Options.Int” file that I ended up with,

// Please note -- this is a representative set of error suppression
//                options.  Please adjust to suit your own policies
//                See  manual (chapter LIVING WITH LINT)
//                for further details.

-w3     // Overall warning level (3=default) Settings 2 and 3 are OK.

-e586   // function 'printf' is deprecated.
-e793   // suppress message about extern identifiers being more than 31 chars long
-e9045  // non-hidden definition of type 'struct
-e9058  // unused outside of typedefs
-e970   // Use of modifier or type '_Bool' outside of a typedef
-e9071  // defined macro '_APP_H' is reserved to the compiler
-e537   // repeated include
-e950   // Note 950: Non-ANSI reserved word or construct: like: '_nop()'

-passes(2) // Make 2 passes on the code


Now that wasn’t so bad after-all – Now I can just Lint my files one by one and see the warnings / errors that really show up. I had a number of iffy initialized variables, some missing ‘defaults’ in Switch statements and a few of the dreaded,

    If(test)
        foo();


instead of,

    If(test)
  {
        foo();
  }

Constructs.

Most importantly I found a few real problems (like copy and paste errors) that would have prevented proper program operation and would have cost me debugging time to fix.


Gimpel offers this sage advice for first time “Linters”,

“If you've never linted your code before, you may want to modify the warning level initially.  Try running with -w1 to report only errors.  After you've fixed the resulting errors (or suppressed those that you don't want reported), run with -w2, and so forth. “


Further Reading:
Hopefully this tutorial will get you at least 80% of the way to where you want to be, in a very short period of time. For more information, the Gimpel website has a FAQ list that provides helpful hints and the PC-Lint manual is full of further in depth information.

You may also want to consider "Breadboarding" your C code on your PC before placing it on your target Embedded System, these two posts show how I accomplish this,

* Breadboarding Embedded Code
* Breadboarding Embedded Code - Part II


References:

[1] Micheal Barr The Barr group. Prolific writer about best ‘C’ practices,
    https://barrgroup.com/content/barr-group-embedded-c-coding-standard-now-available-free-embedded-systems-designers

[2] Les Hatton, Author of: “Safer C”, McGraw-Hill, 1994

[3] Robert Martin is a frequent speaker at programming conferences. Many of his talks can be viewed on Youtube.

[4] There are a number of other compiler options available, I find that this one is the best for catching stupid mistakes without marking every single library function as non-compliant. For other possible options see the XC32 Compiler Users Guide – Yes there is actually a manual and as near as I can tell Microchip keeps it up to date.

[5] GCC Diagnostic Pragmas manual page,
    https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html

[6] LINT    https://en.wikipedia.org/wiki/Lint_(software)

[7] Gimple Software PC-Lint, Version 9.00L is the current version.
    http://www.gimpel.com/html/pcl.htm

PC-Lint has been called the longest continuously available software product in the history of mankind, since it has been available from the 1980’s until now.


Article By: Steve Hageman www.AnalogHome.com

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.


Note: This Blog does not use cookies (other than the edible ones).

Monday, December 18, 2017

Custom Build-A-Box

One thing that many Analog Engineers who work on very low noise and low frequency circuits figure out very quickly is that even simple room air currents destroy the achievable accuracy of our circuits.

Most of us first figured this out when we hooked a Strip Chart recorder to our designs output for a day and, much to our surprise (and dismay) the output would invariably track the day and night room temperature variations very well. We managed to build a thermometer when all we really wanted was a very low drift amplifier.

Air is not only good to breathe but, it has a thermal mass, it has a temperature and it has a thermal transfer coefficient. When air circulates around a low noise / low frequency design it either heats or cools the circuit and normally in a not so evenly manner. This gives rise to all sorts of thermocouple effects that are exasperated by the air induced temperature gradients.

The first thing that most of us grabbed when we observed this effect was observed was some cardboard box that was dutifully placed on the circuit in question to keep the room air currents off of it.

But the ‘Fun’ has just begun...

Modern semiconductor packages are so small and thin now that many designs are now sensitive to IR light. Yes the IR light that your fluorescent lights give off is enough to bombard the IC’s transistors with photons because the packages are now transparent to IR light. This can also cause unexplained circuit drifts. Again a ‘Cardboard Box’ is the solution (Keep the circuit in the dark!).

Even light and air currents take a back seat to Long Wave and AM radio stations messing with your circuits. If you have never worked a few blocks from an AM radio transmitter, well let’s just say you have sure missed some fun hours of debugging there [1]. Those Florescent lights are major EMI ‘aggressors’ here too. Not the ones on the ceiling, as they are usually far enough away. The real trouble makers are the ones on your lab bench or even the microscope light. Yes, my microscope light is a real circuit ‘destabilizer’ - a ‘double whammy’ with IR and EMI bombardment!

Even a “Dark Cardboard Box” won’t filter out RF, so naturally, we just wrapped the box with aluminum foil or copper tape! There! A job sorrta well done...

Then Vs. Now

That was then, when our breadboards were spread all over the lab bench. Today our breadboards are finished products and may well ship to customers. This makes finding a suitable “Cardboard Box” to ‘tighten up’ the finished design very difficult indeed.

3D Printing to the Rescue

A 3D printer can quickly make any size or shape “Plastic Box” that you want, when you want it.

In a current design, I needed to get some air current isolation from the main circuit to the very sensitive and high gain Analog Front End. Years ago I would have hacked something together with scissors, an X-Acto knife and the cardboard off the back of a paper tablet. This would take a while and it would have looked pretty amateurish by the time I wrapped it with Electrical or Kapton tape.

For this design I just imported the Step model of the Analog PCB [2] into Design Spark Mechanical [3] as shown in the figure below. In less than an hour I had drawn the top and bottom of the box I wanted fabricated right around the PCB model and exported it as a STL file to my 3D printer.

The Custom Box was designed around a 3D accurate STEP model produced by my Altium PCB software. In less than 2 hours the box was printed as shown below.



The finished design as viewed from Design Spark Mechanical. The design is simply 'drawn' around the 3D accurate exported Altium PCB Model.


The actual finished two halves of the 3D Printed Box. Note the cutouts where the IO connectors have to go. For a real design I would have used Black Material because it looks more ‘professional’ but yellow shows up better in the photos.  


Bottom of the custom 3D box installed on the main board. The Analog Front End IO Connectors fits in the blue connectors that poke through the cutouts that I made in the 3D printed box bottom.
  



The base and top of the 3D box as it fit on the main electronics PCB. Way better fit than cardboard ever was.
 

The custom 3D box covers the analog front end board well. The Analog Input connectors in this particular design are BNC connectors.



Since I wanted EMI shielding also (you never know where your design may end up [1]), I sealed the box together with my some of my favorite copper tape. Be sure to always use the copper tape with conductive adhesive. The Copper tape enclosure is ‘grounded’ by electrically connecting the copper tape to the BNC’s with an overwrap.


Conclusion

3D printers are certainly handy, not only in Robotics Projects but in making custom, 21st Century “Cardboard Box” replacements in less than 3 hours start to finish – and they look better too.

Certainly a more professionally looking finished job and better working instrumentation too boot!


References / /Notes:

[1] I once worked for a company making instrumentation products that had a manufacturing plant in Puerto Rico. About a mile from the plant was a 1000 foot tall Navy Communications antenna. It did not broadcast continually, but when it did you couldn’t test anything at the plant site! Thank goodness the broadcasts happened very infrequently, otherwise we would have had to move!

[2] Altium has native 3D PCB design. Exporting a 3D Step model of any design is a “one click” operation. Then that model can be imported into any modern #d Drafting Package.

[3] Design Spark Mechanical – A very easy too use, free program from RS / Allied.
https://www.rs-online.com/designspark/mechanical-software


Article By: Steve Hageman www.AnalogHome.com

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.


Note: This Blog does not use cookies (other than the edible ones).

Wednesday, December 13, 2017

An Interesting Breadboard and Circuit – The “Greatbatch Pacemaker”

My good friend Mike Seibel recently reminded me of a breadboard that he saw in my cube when we worked together at HP in the late 1990’s. The breadboard is still around and it intrigued me then as it does now… Here is the complete story,

Decades ago in 1995 I saw an interesting “Breadboarding Technique” that I had never seen before in an issue of the IEEE Spectrum magazine [1]. There was this full page picture of a chap named Wilson Greatbatch holding a manila folder with a simple circuit drawn AND attached to it. Mr. Greatbatch had built the breadboard right on the folder where he drew the schematic. That circuit was one of the first Pacemaker Circuits ever developed. The scan below is a poor quality reproduction, because in the original full page picture I could clearly make out the circuit and component values (Figure 1).

I had never seen anyone build a breadboard on a manila folder like this and I was intrigued by the designs oscillator and charge pump voltage doubler, so I built one of my own using my most common breadboarding technique – parts soldered directly to a piece of copper clad FR-4 (Figure 2).

I really didn’t think the circuit would run all that long, so to “prove my point” - I powered it with a used Lithium cell taken from a flash camera when it would no longer power the camera anymore.

Then I hung the running circuit on my lab wall and every few months I would see it, pull it down and test it to see if it still worked. To my unbelievable surprise it continued to work until about Mid 2010.

That’s around 15 years, even when I gave it every opportunity to fail early by powering it from a nearly dead battery in the first place. As usual, the circuit: “Had the last laugh” on me!

The article about Mr. Greatbatch went on to tell how Mr. Greatbatch developed the first Pacemaker by removing the wrong part from a 1 kHz oscillator that he was trying to build and it started to Squegging at about a 1 Hz rate with a narrow output pulse – and it hit him – “This is a Heartbeat!”. Again, a circuit ‘fail’ had the last laugh and a multi-billion dollar industry was born.

I could only hope that more of my “circuit failures” would lead to good things, but alas, most of my failures just lead to smoke or other parts that die sympathetically in one big chain reaction. At least I have never set a Lab on fire (yet!).

So take note of interesting circuits you see, give them every chance to fail, and they will surprise you every time!



Figure 1 – A poor scan of the original article picture. I was easily able to see the circuit and values in the original picture. What caught my eye originally was the breadboard Mr. Greatbatch drew and built on a Manila folder! (Picture originally copyright 1995, IEEE Spectrum).



Figure 2 – My prototype built with my usual breadboarding style – parts soldered directly to a piece of FR-4 Copper clad. 



Figure 3 – The schematic of Mr. Greatbatch’s original circuit. I especially liked the clever voltage doubler at the output. Mr. Greatbatch’s original circuit had a DC blocking capacitor on the output that I did not include, since I was not going to actually ‘Pacemake’ anything. The original circuit used 2N Something transistors, I used the very popular 2N3904 and 2N3906 transistors in my version. The current source “IG1” at the input is just a ‘kick starter’ that pulses 100 mA for 10 nanoseconds to get the oscillator running for the Spice Simulation.





Figure 4 – The output pulse is 2 x 2.8V peak to peak because of the clever voltage doubler My circuit ran at around 53 Beats per Minute. The width of the pulse is around 1.5 milliseconds.

[1] Adam, John A., “Profile: Wilson Greatbatch”, IEEE Spectrum, March 1995



Article By: Steve Hageman www.AnalogHome.com  

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones).

Saturday, December 2, 2017

Li-Ion Notebook Battery's :: The facts of life….

The latest generation of Li-Ion batteries as used in notebook computers are quite long lived. I currently use a HP ZBook Laptop that has a 60 Watt hour flat Li-Ion battery pack. HP Supplies a battery test utility that I have used every month since getting the PC. It records the number of charge cycles and the current full charge capacity of the battery.

 


Battery pack design as used in my HP ZBook Notebook.

My normal usage is that the PC is plugged in 50% of the time, and I might drain it nominally 20 to 50% when it is unplugged. About once a month I will drain it pretty far down doing something offline for a number of hours (like running some experiment in the lab).

The “Total charge cycles” counter counts a charge cycle when the battery gets a full charge capacity put in it. It doesn’t matter if the charge is fully 100% or ten charge cycles of 10% - both of these count as one full charge cycle.

Over the past 27 Months I have averaged about 10 charge cycles per month, that’s probably less than a real “Road warrior” would do I’m sure.

The battery capacity has decreased better than advertised. The rule of thumb is that these Li-Ion batteries will loose around 10% of their capacity per year. This battery has been loosing just a little less than 6% per year.


 
The loss of capacity in this particular battery as measured every month.

Article By: Steve Hageman www.AnalogHome.com   

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project.

Note: This Blog does not use cookies (other than the edible ones). 
 

Thursday, October 5, 2017

Friends Don't Let Friends Use Un-Shielded Inductors

Yikes – I saw another one of these power supplies in a high sensitivity receiver. You've seen them too, those sweet little problem solver DC/DC converter modules (figure 1).

 


Figure 1 – These sweet little DC/DC modules sure solve power problems, but...

Yes, they solve power problems but they cause all sorts of havoc with the sensitive Analog Signals, especially in wideband systems. I have seen many issues over the years with unshielded inductors and in fact my standard design catalog of parts only lists shielded inductors for this very reason.

An unshielded inductor does not enclose the magnetic field (or the electric field for that matter) and ‘will’, notice I didn't say 'may', because it 'will' couple switching noise into other parts of the system.

Into PLL Synthesizers, RF front ends and IF circuits these little beasts spew their evil. In analog radios the noise level was high enough that you would probably never notice the issue, but with wideband digital radios and other measuring circuits that have dynamic ranges of 90 dB and more the problems are hard to miss.

There are a few alternatives,

1) Only buy a DC/DC module with shielded inductors. Downside: That's hard to do because cost is everything in these designs and shields cost money, so shielded designs are not easy to find.

2) Build your own DC/DC using good shielding. Downside: Your design will almost certainly be bigger and probably cost more too.

3) Add secondary shielding to the power modules: Downside: Size and cost.

4) Don’t do anything and hope for the best. Downside: Your product is cheap, but doesn't work very well, if at all.

To demonstrate the problem, I setup a magnetic / electric field probe [1] a few inches from the operating DC/DC module as shown in figure 2.

 


Figure 2 – A measurement of the ‘spew’ was made with a small probe placed a few inches from the operating DC/DC converter module.

Measuring the resulting field produced with an oscilloscope trace as shown in figure 3.

 


Figure 3 – The probe measurement for the unshielded inductor of the DC/DC converter.

To demonstrate how simply shielding the inductor works, I located a Ferrite ring of the proper size in my junk box of parts. The Ferrite ring was a bit tall but otherwise it was a perfect fit diameter wise as can be seen in figure 4.

 


Figure 4 - I found a Ferrite ring in my junk box of parts that fit this inductor early perfectly.

With the probe in the same location as it was when the measurement of figure 3 was made, the Ferrite ring was added to the DC/DC operating on the PCB and another measurement was made as shown in figure 5.

 


Figure 5 – The probe measurement is vastly improved simply by adding a Ferrite shield to the inductor of the DC/DC converter.

The reduction in measured field strength is obvious, it’s is nearly a 5:1 peak-peak voltage reduction, just by adding a Ferrite ring around the switching inductor!

As noted above it may be difficult to find commercial DC/DC modules that use any shielding, especially in the low cost open frame market segment. In these cases enclosing the power section in a steel can type of shield on your PCB will help. A small steel can PCB shield like is shown in figure 6 is effective at shielding electric and magnetic emissions over a broad frequency range. The use of shields especially when combined with proper analog grounding techniques [2], noise reductions of 25 to 50 dB are typically obtained.

 


Figure 6 – These low cost, semi-custom shields are a rel lifesaver when designing with high noise switching (or digital) circuits around sensitive analog. Place these shields both the analog sections and the noise generating circuits for maximum effectiveness.

Remember: Be a good friend and don't let your friends do the wrong things, if they do anyway, be sure to hand them a shielding can!

Notes:

[1] This home made probe consists of a cut in half torrid wound with 10 turns of magnet wire. The signal is fed through a 50 Ohm coax line to a 20 MHz bandwidth limited oscilloscope input that is terminated in 50 Ohms at the oscilloscope.

[2] Proper analog grounding is defined as: Adequate separation between analog traces AND maximum, unbroken ground planes everywhere else.



 

Article By: Steve Hageman www.AnalogHome.com    

We design custom: Analog, RF and Embedded systems for a wide variety of industrial and commercial clients. Please feel free to contact us if we can help on your next project. 

This Blog does not use cookies (other than the edible ones).