Sunday, December 28, 2014

DIY Antenna Improves RasPI ADS-B Reception Range




-----
Almost all the aircraft flying overhead broadcast tracking information on 1.09GHz via ADS-B.  ADS-B is an open protocol.  So what?  Well, it means you can decode it.  

Once we learned about this our focus was set on building a rig to track overhead aircraft using the Raspberry PI.  You can read all about the setup here.
----
The Software Defined Radio (SDR) we used comes with a small whip style antenna.  Fine for testing purposes, but we wanted to extend our reception range.  

The FlightAware forums turned us onto what looked like a simple low cost way to DIY a small quarter wave antenna that had proven results.  The antenna design is by "atouk" and documented in a .PDF titled "My First ADS-B Antenna".  The design is so straight forward you really only need to go off the dimensioned line drawing above, but the "My First ADS-B Antenna" document is worth the download.
----
It took about ten minutes to build the antenna.  We went through a three step process to gauge it's effectiveness.
  • Step 1:  Chart reception with the cheapie stock OEM whip antenna placed in a closet on the 2nd floor.
  • Step 2: Chart reception of the DIY quarter wave antenna placed in the exact same location as the OEM whip in Step 1.
  • Step 3: Chart reception of the DIY quarter wave antenna raised into the attic (actually only a few feet higher)
-----
Here are the Step 1 (OEM whip) results.  Click on image to enlarge:
-----
Here are the Step 2 (DIY quarter wave, same position as QEM whip) results:

Okay, we show improvement!  Notice the 'spider' chart outer rings are showing aircraft.  Also, the sharp rise in plane count on December 14th.
-----
Here are the Step 3 (DIY quarter wave, moved to attic) results:

Moving to the attic yielded only a slightly higher plane count on the daily graph.  But check out the  the 'spider' chart;  it does seem to indicate better coverage.
-----
The DIY quarter wave antenna is absolutely an improvement over the SDR OEM whip antenna and well worth the very small time and cost investment.  Our roof decking has a 'shiny stuff' radiant barrier on it.  The thought is the radiant barrier may be acting like a big metal blanket thrown over the antenna.  If we moved the antenna outdoors there would certainly be more improvement.  But for now our DIY quarter wave antenna will rest happily in the attic helping the Raspberry PI collect ADS-B data 24/7 and report it to FlightAware.
-----
Thanks for the visit and let us know how your rig improves!

Thursday, December 25, 2014

Tektronix MDO3000 as a MP3 Player


-----
A friend of mine got a Pono music player this Christmas.  The claimed advantage of the Pono player vs other music players is better sound fidelity.

So what does the Pono player do different?  Normal CD music is sampled at 44,100 times per second (44.1Ks/S) and 16-bit resolution.  The Pono is capable of playing music with an increased sample rate of 192,000 times a second (192Ks/S) and 24-bit resolution. A quick web search yields page after page of audiophiles debating these fidelity claims and we will leave that discussion to the experts.
------
Since Pono advocates see benefits in increasing sample rate from 44,100 times per second to 192,000 times a second, then just think about how awesome really turning up the sample rate would be!!!  But how?  Enter the Tektronix MDO3000 which can sample at an amazing 2,500,000,000 (2.5Gs/S) times per second and that's a lot!
 -----
The Tektronix MDO3000 is a benchtop instrument that has some truly amazing capabilities that push it way beyond being just an oscilloscope.  One of these features is the Arbitrary Function Generator (AFG) that can capture signals from any of the analog channels and play them back on command.
----
In the video below, we set the Tektronix MDO3000 to sample at a lazy 1,000,000 times per sec (1Ms/S).  Then we use a PC to play a MP3 music file for capture into the instrument's waveform memory via analog channel 1.
-----
Next, with a few button clicks the music waveform we just captured is loaded into the instrument's AFG to make it ready for playback.  Simple.
-----
The Tektronix MDO3000 AFG output is BNC connector on the back of the instrument.  We connect to the AFG and plug into a speaker.  The result: The most impractical (and expensive) MP3 player available, but with an impressive sample rate many, many times higher than the Pono player.
-----
This whole experiment means nothing, of course.  We did it simply because "we could".  If you do decide to go with a Pono (or a Tektronix MDO3000) as a music player remember that much of the sound quality is determined at the time of the original recording and not just at playback.  Also your headphones, speakers, listening room, ears, etc...
-----

Saturday, December 13, 2014

Propagation Delay of a 74HC04N Hex Inverter

-----
It takes some time for an electrical signal to travel down a wire or through a logic gate.  Not much time, but some.  It's called propagation delay (tpd) or "prop" delay.  We had a 74HC04N on the breadboard from our recent Rasperry PI CPU Usage Tachometer project and decided (for reasons unknown) to measure the prop delay of this chip.  The 74HC04N is a simple IC that turns a logic "0" into a "1" and turns "1" into a "0".  It has "six" gates to "invert" digital signals; thus the name "hex inverter".

----
For our measurement setup we used the Tektronix MDO4104B-6 oscilloscope.  It has plenty of what it takes to make this simple prop delay measurement and we had one handy. Since passing through one gate inverts a digital signal, passing the signal through two gates (or any even number of gates) will invert that signal back to it's original logic level.

Here is a 5VDC signal propagating though two gates.  The yellow trace is the input and the blue trace is the output after passing through two gates.  Using the scope cursors we measure the prop delay at 12nS  (nS or nanosecond = 10EE-9 seconds).  That's an average of 6ns per gate.
-----
Here is a 5VDC signal propagating though all six gates.  Again, the yellow trace is the input.  The blue trace is the output.  The scope cursors measure the total prop delay at 33.2nS (as well as some signal degradation from loading) for an average of 5.53nS per gate.
-----
Is that prop delay good or bad?  Well, we have to consult the device datasheet.  For a 5VDC setup NXP specs their 74HC04N at 7ns per gate typical, so our chip is beating the spec!  As far as it being good or bad depends on your application.  For most low speed hobby projects prop delay isn't even a consideration.  If you are designing high speed circuits then race conditions and prop delay specs become important to your design.  
-----
UPDATE: Special thanks to all the .EDU sites for checking in!

Thursday, December 11, 2014

Raspberry PI CPU Usage Tachometer


We had an old car tachometer laying around the labs (beats me why...) that seemed perfect for some type of project.  But what?   Since it is pretty common to see a car looking tachometer as a CPU usage meter on the desktop of a PC we decided to create a hardware version of this for the Raspberry PI.

Basically what we are going to do is read the CPU usage on the Raspberry PI.  Then convert that CPU usage value into a corresponding frequency.  That frequency will be output via GPIO on the Raspberry PI pin 11 to drive the tachometer.
----
First step is to characterize the tachometer and find out what type of frequencies made the needle move.  The Tekronix 3252C made easy work of that.

----
The spreadsheet below shows what frequencies move the tachometer needle to what position.  
We also used this spreadsheet to calculate a multiplier to adjust the CPU usage reading on the RaspPI to a 0 RMP to 8000 RPM reading on the car tachometer.  It's a pretty simple calculation and you can see how it is used in the Python source code below.
-----
The tachometer needs 12VDC to power it, but the input signal to move the tachometer needle needs to be 5VDC.  A 7805 voltage regulator solves that problem.  Also, to buffer the RasPI GPIO a 7404 was used to drive the RasPI signal into the tach.  The connection looks like this:
----
Using some Python code the end result is this:

In the video you can see how moving the mouse around on the Raspberry PI increases the CPU usage making the tachometer reading increase.  When the Chromium web browser is launched the CPU usage goes to 100% and the tachometer needle 'redlines'.
-----
The Python code is straightforward.  Drop us a line if you decide to duplicate the build!


#
# Program makes a simple car tachometer read CPU usage percentage.
#
# WhiskeyTangoHotel.Com - December 2014
#
# To run this program you must first do a one time install
# of the following from the terminal commans line.
#
# sudo apt-get install python-pip python-dev
# sudo pip install psutil
# sudo apt-get install python-psutil
# see: http://sourceforge.net/p/raspberry-gpio-python/wiki/PWM/ for PWM info

import time
import psutil
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BOARD)
GPIO.setup(11, GPIO.OUT) # Pin 11 drives the tachometer

#p = GPIO.PWM(channel, frequencyHz)
p = GPIO.PWM(11, 200) # move the tach needle to about 1/2 scale
#p.start(dc)   # where dc is the duty cycle (0.0 <= dc <= 100.0)
p.start(50)
print ' '
print 'SELF TEST: Tach to about 1/2 scale for 5 seconds...'
time.sleep(5)   
print ' ' 

i = 0 # just a counter
adjust_cpu_to_hz = 3.8   # adjust_cpu_to_hz is calculated on the tach characterization spreadsheet.
# Tektronix 3252C was used to feed input into the tach to create the
# characterization spreadsheet.  Discover how many Hz needed to move needle.

while(True): # loop forever  
i = i + 1
# read the RasPI CPU Usage. Store the value in var cpu_usage.
cpu_usage = psutil.cpu_percent()
# use adjust_cpu_to_hz to scale the cpu_usage result to Hz within the tach's range
p = GPIO.PWM(11, cpu_usage * adjust_cpu_to_hz)  
p.start(50)
print 'Run #:', i, '  ', cpu_usage,'%', '    ', cpu_usage * adjust_cpu_to_hz,'Hz out to tach'
time.sleep(3)   # allow x secs to give the CPU a breather
p.stop()     # stop PWM (also end of while loop)

input('Press return to stop:')  
p.stop()     # stop PWM
GPIO.cleanup() # Take out the trash
----