Tuesday, November 27, 2012

Instant On Demand Learning

Well – You have to love the internet...

My trusty Compaq Mobile Workstation had a LCD Hinge break, the Laptop is a really nice performer so I didn't want to upgrade as it's got some more years in it.

So I searched around for a replacement hinge. In 5 minutes I found an online retailer that claimed to have the part. I was all set to order, but first I did a search to see if they had any reviews. They did – on their PC sales they got good reviews, but on the parts side everyone was disappointed.

What to do next – I searched eBay for the part – found a guy 500 miles away with the hinges, ordered them over a holiday weekend and the parts arrived Monday morning via first class mail. Now that's service.

The next problem was in trying to figure out how to take the Laptop apart. These things are always easy once you see how it is put together, but unless you know that – something is going to get broken.

No Problem – Just search YouTube for some videos on repairing Laptop Hinges – I could not find my exact Laptop model, so I just watched a few videos of similar sorts of HP Laptops. That was close enough.

45 minutes later I had my laptop apart and the hinges replaced. I even improved the Laptop some by placing a few more strips of household double sided tape under the keyboard which made it much more solid in a few spots.

In the past I have used the YouTube “Quick Learning” method for many other projects – such as,

* Figuring out how to properly tension my Garage Door springs
* How to upholster a headboard with fabric
* A quick refresher on Plumbing
* How to drill ½ inch holes in Concrete
* Learn about the latest Semiconductors via brief Webinars

And on and on....

You just have to love the Internet for “Instant On Demand Learning”.

Steve Hageman

Thursday, November 15, 2012

Can you use an Agilent 34401 DVM as a Waveform Digitizer?

EDN Has published an article written by me this very subject

"Use a DVM to directly digitize low-frequency noise (Part 1 and 2)"

The project I was working on involved measuring 0.1 to 10 Hz noise not only for RMS and peak-to-peak values in the time domain, but using an FFT Analyzer in the frequency domain also. I was all ready to get out a bunch of equipment and make a special test fixture, but then I remembered that my Agilent 34401 can make readings very fast and I set about exploring what can be done with just the meter itself.

When we think of DMM's we normally think of measuring very slowly moving DC signals. This month takes a look at what performance can be acheived, Next month we will take a look at how to verify the performance of our DVM as a Waveform Digitizer.

Steve Hageman

Saturday, October 27, 2012

What PCB Material do I need to use for RF?

EDN Has published an article written by me on the subject of,

"What PCB Material Do I Need to Use for RF"

A discussion with actual data to help designers faced with some of some of the myths regarding the need for exotic PCB  materials to do RF work up to 6 GHz and beyond. You might be surprised how well FR4 really performs.

Link: "What PCB material do I need to use for RF?"

Steve Hageman

Saturday, August 25, 2012

Noise Floor De-Embedding and Cross Correlation

EDN Has published a article written by me on the topic of,

Measuring small signals accurately: A practical guide

This topic is of interest to anyone who needs to make spectral based measurements near or below the measuring instruments noise floor. 

Topics include:
* Noise floor De-Embedding
* Cross Correlation

#1 - Many articles have presented the "Noise Floor De-embedding" technique, but none have presented what happens if your estimate of the actual noise floor is wrong. I show with graphs the result of mis-measurement of the instruments noise floor.

#2 - Cross Correlation is a well known technique of using two instruments a a lot of vector averages to get a result that can be below a single instruments noise floor. In plain language I simplify the math involved so that even non-DSP engineers can understand the technique.
A sample project is provided in C# for experimentation.

Steve Hageman

Thursday, July 12, 2012

A Trip Through Quality

We have posted a multipart article series on EDN about some things I have learned over the years about quality and how to test electronic products to ensure quality. Some things that work and some things that don't work are noted in the series.

The Blog posts can be read here,

Steve Hageman

Wednesday, June 27, 2012

The practicing instrumentation engineer's guide to the DFT

Steve has published a series of articles on EDN Magazine about engineering uses of the DFT and FFT. The seires Discusses practical implementation of the Discrete Fourier Transform in instrumentation applications. The series of articles focuses on the often forgotten "Calibration" factors and dispels some myths about DFT's and Windowing data in general.

Links to the articles at EDN Magazine

Friday, June 15, 2012

Bit/Bang SPI Speed of PIC18F6722

With all this work on uP's and ATMEL UC3 C Compiler Optimizations, I decided to take a look at one of my old workhorse processors the Microchip PIC16 and 18F families. I program these devices using the CCS PIC-C compiler.

Similar to the last post about UC3 processor timing when running Bit/Bang SPI type of IO quickly threw together some sample code for the PIC18F6722. I set the PIC up to run on a 10 MHz Oscillator with the 4X Internal PLL, giving a program instruction running rate of 10 MHz (the clock in these devices runs at 4 times the actual instruction rate).

The CCS compiler has a series of high level IO commands similar to the ATMEL ASF pin IO commands[1]. This mode is called “FAST_IO” and what it does is allow you to set the direction of the port pin then using a high(er) level command to set any Pin anyway you want it (using the output_bit() function).

I also built a function using direct IO. This is where C really hits the road! In CCS C we are able to directly define any bit or pin in a port using a #bit directive, then just using PIN = 1; or PIN = 0; in my program we can set that pin as requested with just one CPU instruction.

So on to the testing - since the CCS compilers that I use are always optimizing and there are no real optimization switches, we get just one number for comparison - the clock frequency of the Bit/Bang IO function (the code is very similar to the previous post on UC3 IO Optimization[1]).

Using FAST_IO the SPI clock pin frequency was: 560 kHz

Using direct Pin Banging the SPI clock pin frequency was: 716 kHz

Not blindingly fast compared to the UC3, but the PIC was using lots less power and is fast enough for many useful applications, in fact we have been using PIC's to successfully control all sorts of things from: Temperature Chambers to Cellphone Monitoring Radios since 1994.

Steve Hageman

[1] Previous Post: http://analoghome.blogspot.com/2012/06/atmeluc3-32-bit-processors-and-gcc.html

Thursday, June 14, 2012

ATMEL UC3 32 Bit Processors and GCC Compiler Optimization - Part 2 - Timing

To test the ATMEL GCC Compiler Optimization with respect to loop and IO timing I wrote a simple little SPI type data output routine that simulates bit/bang IO with high level ASF commands. Specifically I wrote a little function that takes a data value, shifts it and actuates a clock pin. The usual thing one does for bit bang IO.

Figure 1 - Here is the code that I used to simulate a Bit/Bang SPI routine, very basic. I used a high level “ioport” command from the ASF framework to set the pins, just to see how fast this ASF method could be.

I set the ATMEL EVK1104 Eval Board to a 66 MHz Internal Clock Frequency and just called the spi_test() routine from a number of places in a simple main.c program, this was to prevent the function from getting inline optimized out. I also made sure that the variable spi_data was not optimized away by making it dynamic in all the calls and by defining it in the main program as volatile.

Now for the results of this test. As can be seen from Figure 2, no optimization is a pretty bad idea for a program such as this as the clock was measured in kHz, not MHz! All the other optimizations had about the same speed increase (within 1% or in the 10's of nSeconds of each other).

Figure 2 - As can be seen in the data, no optimization is a pretty bad idea when doing bit bang IO if you want any speed at all. Using a 66 MHz CPU core clock the SPI clock speed came out a respectable 2.7 MHz when optimized, not blindingly fast, but fast enough - and this was using the high level ASF commands to bang the pins around with.

All the optimizations have some issues: In debugging or in the way the code may or may not actually work, so it is best to study some of the options first before you commit to actual plans.

The code was compiled in AVR Studio 6 that was current on 6Jun12.

Steve Hageman

Wednesday, June 6, 2012

ATMEL UC3 32 Bit Processors and GCC Compiler Optimization

We have been working on some 32 bit applications here in the lab using the ATMEL 32 Bit UC3 Processors. The AVR GCC compiler has various optimization levels and there is a lot of information on the web about what the various levels do and what we should be using (or at least opinions as to what we should be using). 

Being an engineer - I like actual data, so I took one of ATMELS rather large DSP applications that has a LCD GUI and I ran it through all the optimization levels just to see what the code size improvement is.

Well, there you have it. For this big application (200k of Flash Used!) the results of the best to no optimization is just under 10% reduction in size, I did not try to measure execution speed as the -O0 code seemed to run the GUI just fine.

The AVR32-SIZE is the actual flash memory usage. Just for comparison I also plotted the raw HEX file size. As can be seen the % decrease in the HEX file tracks the actual reduction in the flash memory usage very well.

All the optimizations have some issues: In debugging or in the way the code may or may not actually work, so it is best to study some of the options first before you commit to actual plans.

The code was compiled in AVR Studio 6 that was current on 6Jun12.

Steve Hageman

Sunday, May 13, 2012

Co-Planar Waveguide over Ground - Techniques Update

I've been using a RF Layout Technique for over a decade now that is called “Co-Planar Waveguide over Ground”. The principle advantage over plain old Microstrip is that for a given substrate thickness you can achieve a narrower line width than you can with a comparable Microstrip line. This is great for RF work because we are now extensively using 0402 sized components in our high density circuits and a 0402 capacitor on a regular Microstrip line just doesn't fit well, unless the substrate thickness is very, very thin.

A few years ago I wrote a “Design Idea” for EDN titled: "Make a quick-turnaround PCB for RF parts" [1]. I have recently updated that article to include suitable line widths for Rogers 4350B material and the 0.050” Line widths that many RF modules use [1]. That article showed how to make a PCB that works well way above 10 GHz on those simple, overnight FR-4 protoboard processes!

Figure - A picture of a sample Co-Planar Waveguide over Ground (CPWG). This 50 ohm trace was fabricated on a very low cost 0.062" thick "overnight" protoboard. The CPWG line width was set to 0.032" and as can be seen 0603 and SOT parts fit very well on this construction. But CPWG has other advantages as well - read on to find out more.... 

But Co-Planar over Waveguide techniques have other benefits too. One of them is that there is less field spewing into the air around the RF trace (compared to Microstrip), this not only reduces crosstalk to other circuits (thereby increasing isolation at no extra cost) but it also makes the circuit less sensitive to other conductive objects around it. What other conductive object can you get near a RF trace you might ask?

Well shields are very conductive and we want our circuits to be as small as possible and this includes shield height as well. As shown in the next article, Co-Planar Waveguide over Ground layout techniques have great advantages in these situations also.

As a follow on article to the Co-Planar trace article I recently published a paper titled: "Benefits of Co-Planar Waveguide Over Ground" on the PCB Design 007 Website [2].

So go ahead and give Co-Planar Waveguide over Ground a try - your circuits will only work better with less variation to shields and other “things” nearby and your parts will fit better.

Steve Hageman

[1] "Make a quick-turnaround PCB for RF parts", EDN, December 15, 2010 
Expanded version of that article is available here, 

[2] “Benefits of Coplanar Waveguide Over Ground”, PCB Design 007, March 21, 2012

Wednesday, April 4, 2012

Solid State Disk Drives

Affordable Solid State Disk Drives (SSD) are here!

Recently I had the opportunity to test one of the new Intel 320 SSD's. These drives come in a standard 2.5" notebook SATA 2 configuration - so for most modern Notebooks or Embedded PC's they drop right in.

The drive is very well protected, being housed completely in an aluminum shell, with no exposed electronics or PCB's at all. Extremely well done.

First I cloned a laptop drive to a Intel 160 GB / Model 320 SSD.

* That took about 2 hours of continuous running
* The drive was just slightly warn to the touch at the end,
probably 10 Degrees C cooler than my conventional disks,
so the SSD uses less average power too.

For speed testing I compared several operations against a 7200 RPM, 160 GB Conventional drive that was about 50% full. The SSD was cloned with exactly the same data, etc. The operating system is Windows XP Professional.

Speed comparisons (Minutes : Seconds),

Action ..................Disk........SSD.......Speed Ratio
Altium Designer........32.........18..........0.56
Open Office...............8..........3...........0.37
116MB File Copy....15...........6...........0.4
Check Disk..............4:54......48..........0.16
Backup Disk............25:00....11:00......0.44

Quite a speed improvement over a conventional drive. The other big improvement is that I no longer have to worry about accidentally "Bobbling" the Notebook and crashing a head.

I have been using the Intel  320 daily for 5 months with no issues in my primary laptop.

These are just the thing for rugged or harsh mobile applications as they are drop in replacements for that standard 2.5 inch Notebook SATA drives.

Something to consider now that the cost is getting very reasonable and your PC will be much faster too.

Steve Hageman

Friday, March 30, 2012

Gaussian Random Numbers for DSP Applications

We Hardware Engineers prefer to test our control and analysis programs on live hardware, but sometimes that is not possible. So we need to write programs that simulate our input or output signals and test with software until we can get our actual hardware again (This is code for: "Pry it out of the hands of the Software Application Developers").

Recently I have been working on FFT processing of RF Digitizers and I don't always have access to a working hardware. It is easy to generate Sine waves and two tone signals in C#, but it is not so easy to generate simulated noise.

I needed a routine for Gaussian Random numbers to represent ADC noise in my signal processing FFT and Windowing testing. So I came up with this little routine based on a classic technique called: "The Polar Method" by Dr. Marsaglia and published in 1962. This implementation brings the classic Fortran work to C# and .Net.

The routine accepts these input parameters:

Int32 size => The size of the data array to produce
double scaling_vrms => The magnitude of the noise in Vrms in the Frequency domain, scaled for DFT size.

The routine scales the noise so that if you DFT it with a standard DFT or FFT routine the noise will always be the requested spectral value regardless of the size of the DFT (or equivalent noise bandwidth). You can strip this scaling out if you wish to.

For instance if you request 1uV RMS noise and 1000 or 10,000 data points the routine will scale the noise output so that you always get 1 uV RMS of noise output for both sizes of DFT's. This scaling is for 1/N scaled DFT's and FFT's (Most are) and saves you from having to calculate the noise bandwidths for a given DFT size.

The routine also guarantees that there is no DC offset value by subtracting the average value of all the random values near the end of the routine.

Figure 1: A Histogram of 10,000 numbers generated by the Gaussian Noise routine. As can be seen the generated noise is decently Gaussian.

Figure 2: 1000 generated points when the requested value was 1 uV RMS. Note the scaling factor is for the frequency domain. The Gaussian Noise output looks just like real noise.

Figure 3: The results of a non-windowed 100,000 point DFT. The requested scale factor was 1 uV RMS and the output is spot on. You can also see that the spectral density is constant so the noise is not only Gaussian but White (or flat with frequency) as well.

Figure 4: With the Gaussian Noise routine it is a simple matter to make any signal to noise ratio that is desired with a simple call to generate some noise for any signal. This is the result of a 100,000 point DFT with a 1 volt RMS,  C# generated sine wave with 100,000 points of 1 mV RMS noise added. This created a simulated 60 dB Signal to noise ratio with very little effort allowing me to generate very lifelike signals for testing even without using the actual hardware.

Now everyone is happy (well, hopefully that is) - I have lifelike signals to use in my calibration and test software development and the application developers get to spend a few days with actual hardware. There just never seems to be enough actual hardware to go around.


I hope you find the routine and the testing results useful.

Steve Hageman

Note: An earlier version of the code posted had the wrong scale factor. The actual scale factor is Sqrt(2).

Sunday, February 12, 2012

Binary Bits - C# Version

Some years ago in EDN [1] I wrote about a set of Visual Basic routines that roughly paralleled the bit manipulation features that we enjoyed in C. Well folks, VB Classic is dead or at least has no future and we here at AnalogHome have long ago moved on to C# .NET which is a really powerful language.

Alas, C# still is missing some features that make for fast and easy hardware control. Specifically when programming SPI, I2C or other serial based devices we need to be able to rotate bytes or words and shift successive bits out for our hardware devices.

So as a follow on to that “Turn of the Century” article I have developed a set of routines that allow for shift right, shift left along with set get and clear a specific bit in any byte or word.

With these routines as a basis for your own code you can now easily manipulate individual bits in a byte or word and hopefully be faster at programming that hardware from your PC.

Bit manipulation routines included here,

Input: input_num can be any length 1 to 32 bits (but need to be cast to a UInt32)
bit: 0 = LSB, 1, 2 . . . 8 = MSB on 8 bit number, etc,
but not greater than 31 or the width of the input number

Return: Is either the state of the bit (For GetBit) or the new number after the operation is completed.

public static byte GetBit(UInt32 input_num, byte bit)
public static UInt32 SetBit(UInt32 input_num, byte bit)
public static UInt32 ClearBit(UInt32 input_num, byte bit)

The shift routines include,

Input: input_num: is an unsigned int of either 8, 16 or 32 bits in length.
Return: The bit shifted out
The original number, shifted is returned as a reference parameter to the method.

public static byte ShiftRight_8(ref byte input_num)
public static byte ShiftRight_16(ref byte input_num)
public static byte ShiftRight_32(ref byte input_num)

public static byte ShiftLeft_8(ref byte input_num)
public static byte ShiftLeft_16(ref byte input_num)
public static byte ShiftLeft_32(ref byte input_num)

Some implementation notes: A C# purist would object to having different methods for different word sizes and it is true that these routines can be built that way (just as they can be built a million different ways) but I find that in my use it is easier to keep in mind what byte or word size I am working in and then using the appropriate shift routine. That's the way I think and it roughly parallels the way my embedded C compilers implement their shift routines.

[1] http://www.edn.com/article/505052-ActiveX_control_brings_bit_manipulation_to_Windows.php

Sunday, January 29, 2012

How to Format Numbers in Engineering Format using C#

I once had a nice Network Analyzer that worked very well, except for one very annoying thing. The display was in Scientific Notation, not Engineering Notation. So for instance when it displayed 100 Hz it actually printed on the screen 1.00E+02 Hz, not the more familiar 100 Hz or even 100.0E+00 Hz. Since Engineers think in terms of numbers grouped in powers of 3, like: Milli, Nano, Micor, Pico, etc.... this was is rather annoying.

But what about today - today we write engineering programs on a PC that doesn't know about engineering notation either, which is rather crazy since HP Calculators have known how to do this since the original HP-35 from 1972. So here it is 2012 and our PC's still can't do Engineering notation nativity.

This is pretty easily solved and I have been writing these programs myself since my first Apple ][, today I use a PC and program in C# and I thought I would share my current method of converting a Double to Engineering Notation in C#.

There are many ways to do this from: Converting the number to a string first and manipulating the string into Engineering Notation, to iterating in on the number format in a loop. The method That I will present here is the tried and true use of LOG10() to find the magnitude of a number, then grouping that by threes to find the proper range, looking that range up in a table and finally formatting the number with the proper number of significant digits.

The routine below is a small static class that works with version of 4.0 of C# .NET. No special tricks are used. (Note:If you remove the optional arguments, the routine will work with earlier versions of C#)

To call the routine you can just use the format,

String snum = ToEngineeringFormat.Convert(number, sig_digits [Optional], units [Optional]);

Where the number is the number to convert to a string in scientific notation. sig_digits is the number of significant digits to display in the resulting string. And units is the units string to append to the resulting string. This would be like “Hz” or “F” or “Tesla”, etc...

sig_digits and units are setup as optional parameters in the routine that I use.

In engineering format it really only makes sense to have a minimum of 3 Significant Digits in the result.

This is because you can have 3 digits in a number before or after the decimal place inside of one range. For instance you can have 999 Hz and this wouldn't probably make sense to round to one or two digits. If you need this - you probably need to round your numbers first using some bounding method.

Some Examples,

Significant digits set to 3
Number Converted result
1.234567 => 1.23
12.34567 => 12.3
123.4567 => 123
1234.567 => 1.23 k
12345.67 => 12.3 k
123456.7 => 123 k
1e-10 => 100 p
1.111e-9 => 1.11n
1.234e+11 => 123 G

Significant Digits set to 5
1234.5678 => 1.2346 k {Note: the trailing 5 was rounded up to 6}
1.2345678e-5 => 12.346 u {Note: the trailing 5 was rounded up to 6}