Monthly Archives: June 2012

**********Stereo Audio VU meter on Arduino**********

via coolarduino

This blog is a sequel of “Tears of Rainbow”.  Using the same hardware set-up of Gigantic RGB LED display, I decided to re-work software a little bit, in order to display the true RMS amplitude of musical content. Video clip on youtube:                       VU_Meter   640×480                                      VU_Meter_HD

Objective:

  • Stereo input, process both channel;
  • Full audio band, 40 Hz – 20 kHz;
  • Fast update rate of visual output.
  • Precision Full-Wave  measurements. 

To process stereo input, this time arduino is switching ADC multiplexer every time when it finish sampling input data array (size=128). Two channels “interleaved” with frame rate 78 Hz, so during each frame only one channel sampled / processed, and update rate per channel is equals to 78 / 2 = 39 Hz, which is more than enough for most audio applications.

 I’m using FFT Radix-4  to extract RMS magnitude of audio waveform, and this is why:

1.  Sampling rate in this application is 10 kHz. How I achieved  20 kHz stated in objective section, doing sampling only 10 ksps?  >>>Aliasing!<<<   What is considered to be nightmare when we need spectral information from FFT output, aliasing in this project is really helpful, reflecting all spectral components around  axis – 10 kHz back “to the field”. As all bins going to be sum-up there is no issue, only benefits. Due aliasing, I’m able to use low sampling rate, and reduce CPU workload down to 52%.

2.  In order to get accurate magnitude calculation of RMS,  which is defined as square root of the sum of squares divided by number of samples per specified period of time:    V(rms) = √ ( ∑ Vi ^2 ) / N) DC offset  must be subtracted from the input raw data of each sample    Vi = Vac + Vdc   (if you remember, AtMega328 ADC needs DC offset to read AC negative half-wave).  The problem here, DC offset value is never known with high accuracy due bunch of reason, like voltage stability of PSU,  thermal effects, resistors tolerance (+/- 1 or 5 %), ADC internal non-linearity etc. Cure for this, which works quite well for monitoring electrical grid power, high pass filter (HPF). Only instead of single 50/60 Hz frequency of power line,  I have a wide frequency range, starting from 20 Hz and ending at 20 kHz. When I feed specification of the HPF:

  • Sample Rate (Hz) ? [0 to 20000]                     ? 10000
  • Desired stop-band attenuation (dB) [10 to 200] ? 40
  • Stop-band edge frequency Fa [0 to 5000]         ? 0
  • Pass-band edge frequency Fp [0 to 5000]        ? 40

to  Parks-McClellan FIR filter design algorithm (one of the most popular, and probably, the best) it provides the result:

  • …filter length: 551 …beta: 3.395321

551 coefficient to be multiplied and sum up (MAC-ed) every 100 usec! No way. I’m not sure, if it could be done on 32-bits 100 MHz platform with build-in MAC hardware, but there is no way for 8-bit 16 MHz Arduino.

IIR filter wouldn’t make much difference here. It has lower quantity of multiplications, but more sensitive for truncation and rounding error, so I’d have to use longer (32-bits?) variables, which is not desirable on 8-bit microprocessor at all.

And here comes FFT Radix-4, which easily fulfill this extra-tough requirements in the most efficient and elegant way. All I have to do, is just NOT include bin[0] in final sum, and all DONE!. TOP-FLAT  linear frequency response  40 Hz – 20 kHz  ( -3 dB ), with complete suppression of DC, and low frequency rumble below 20 Hz attenuation.  Linearity is better than +-1 dB between 80 – 9960 Hz.

Last things, audio front-end. As VU meter was designed in stereo version, I’ve build another “line-in”  pre-amplifier based on this kit: Super Ear Amplifier Kit

Link to Download a sketch:  Stereo_VU_Meter.

 

Modified Stereo VU meter, Logarithmic scale, 8 bars per channel, spacing 6 dB.

Dynamic range: 8 x 6 = 48 dB.  Stereo_VU_Meter(Log10).
 Next blog:   Extending dynamic range to 72 dB! 

A Concise History of AMD’s Roadrunner Server for OCP

via Open Compute Project

Finally, a Reason to Be Thankful for Airline Delays

The AMD Roadrunner server project was conceived at the end of the first Open Compute Summit, in Palo Alto in June, 2011. Thanks to an airline’s global system-wide outage, Grant Richard, Matthew Liste and myself were marooned overnight at SFO. During those 8-10 hours we talked a great deal about the many potential use cases and applications of Open Compute technologies and thought leadership. Some time before, we had reviewed many topics, including:

  • Open Compute’s data center power and cooling efficiencies
  • Geographic locations
  • Server and power distribution rack modules

The one that I recall being front and center was OCP’s open motherboards and server chassis.

For context, Grant and I have known one another for many years through our prior team participation and technical leadership in building two of the largest HPC scale-out compute grids in financial services. The size and scope of these compute grids are confidential but were not far away in terms of size in relation to the Web 2.0 community.

In the past we needed to simplify and reduce motherboards of unnecessary proprietary components, open up and simplify management software, maximize hands-free management software, and so on, in order to make them work efficiently for us. This behavior was similar to Facebook’s early days’ server OEM experiences. Despite our numerous attempts in the past to influence design, none of the server providers listened to our needs. Although not an ideal design, we maximized power efficiency and automated system management as best we could.

What jumped out at us last summer at the OCP summit was that for the first time the non-hyperscale world could access many of the same design points, ODMs, simplifications and “freedom of choice” advantages indigenous to the hyperscale Web 2.0 world. This open access led to an evolution in thinking.

Building a Team to Design the Square Peg to Fit a Round Hole

In the summer of 2011, we — Fidelity Investments and Goldman Sachs — shared ideas and observations around figuring out how to test and benchmark using the OCP servers for HPC and cloud infrastructure. At the time the biggest issues were:

  • How to get the OCP servers to fit into traditional legacy data centers. Specifically, traditional 19″ racks. Long story short, we could not.
  • How to expand the ODM participation, Open Compute server availability and expand access.

By September of 2011 we discussed expanding our collaboration to include other firms and colleagues across financial services, and in October held an initial meeting to seek out those also interested in participating.

In the Fall of 2011, in collaboration with Fidelity, Goldman Sachs hosted an exploratory meeting with 10 other financial services firms to explore and discuss interest in forming a working group around Open Compute-enabled compute hardware and management. The vast majority of firms agreed there was great value in doing work together and collaborating around Open Compute.

A Roadrunner Born from a Lunch Napkin

At the October, 2011 NYC Open Compute Summit we ran into Walt Cataldo and Bob Ogrey of AMD. Over the years I had heard Bob’s name as being a key contributor to numerous hyperscale motherboard designs for a number of significant Web 2.0 firms and felt very fortunate to meet him.

Walt and Bob invited me and a lead architect from Fidelity Investments to lunch to talk about Open Compute. Our conversation concentrated on our huge interest in OCP and working through some of the aforementioned hurdles and limitations.

Nothing negative, just working through how to get things to fit into traditional data centers and enabling multi-vendor access to OCP server technologies. By the end of the lunch meeting, Bob had created an open motherboard design outline literally on a turkey sandwich napkin and committed to formalizing it into a design specifications document. That’s when the Roadrunner project was born.

At the end of 2011 we received the initial Roadrunner design document and in early 2012 we received an impressive update that evolved and expanded to include CAD diagrams. At a high level, the key design points for Roadrunner include:

  • Create and enable an open source x86 motherboard project
  • Be a universal motherboard, in terms of size, being able to fit in both a legacy 19″ data center rack and an OCP data center rack
  • Closely manage ODMs and only allow component selections that maximize reliability and power efficiency; do not allow a $0.50 savings to undermine quality, efficiency and reliability.
  • Approach, enable and collaborate with as many ODMs and integrators as possible
  • Maximize optionality and flexibility of add-on silicon choices such as 10GbE chipset selection via “mountable modules”, not PCIe … “mini-card / daughter-card silicon add on”
  • Open Standard Baseboard Management Controller (BMC) in sync with Grant Richard’s Open Compute Open Hardware Management initiative
  • Fit across a wide variety of non-proprietary 1U, 1.5U, 2U, 3U and 4U mechanical stamped sheet metal enclosures supporting both 2.5″ and 3.5″ disc drives
  • Minimize semiconductor and on-board silicon to reduce both purchasing and operating costs
  • Be a universal motherboard, in terms of functionality, supporting 70-80% of target enterprise infrastructure use cases, including:
  • HPC grid computing
  • Cloud server IaaS & PaaS nodes
  • Web application utility infrastructure server for Linux distributions
  • Developer tools utility infrastructure servers
  • Web application server developer platforms
  • Multi-hypervisor next generation VDI
  • Open source SQL servers
  • Big Data scale-out servers
  • No SQL server nodes
  • Cloud scale-out distributed object store nodes
  • Data caching
  • Messaging
  • Content management
  • Content search
  • Application servers for numerous proprietary software stacks, market data infrastructure, and so forth.

In April, 2012, version 1.0 of the Roadrunner document was distributed by AMD to a group of interested firms for their review. All were invited to a series of conference calls designed to solicit their feedback.

Twelve firms were invited and only one formally declined. Eight firms provided detailed feedback on the document. In a nutshell, it was all positive and constructive feedback, no show stoppers were identified!

Which brings us to today, soon after the third Open Compute Summit.

Whew … so that’s the very long short story on the Roadrunner project’s history!

Peter Krey is a consultant for Fidelity.

Audio Input to Arduino

via coolarduino

The easiest way to connect an audio signal to your arduino, is to build a simple 3 components (2 resistors plus cap) circuitry shown on the first drawings on right side. Disadvantage: there is no amplifier, and consequently sensitivity would be low, hardly enough to work with headphones jack output.  For low level signals, like output of electret microphone, amplifier is necessary. Here is the kit, which included board, electronic components and NE5532 Operational Amplifier IC:

  Super Ear Amplifier Kit

Other option, from SparkFun Electronics:

  Breakout Board for Electret Microphone

Note: I don’t recommend to replace NE5532 OPA with popular  LM358 or LM324 due their pure frequency response above > 10 kHz.

*Having nice frequency performance and low noise figure NE5532 the same time has one serious disadvantage, operational amplifier isn’t rail-to-rail. This shouldn’t be an issue in color-music and such applications. Alternative option would be MCP6022,

Configuring AtMega328 ADC to take input samples faster:

void setup() {

   ADCSRA = 0×87; // freq = 1/128, 125 kHz. 13 cycles x 8     usec =  104 usec.
// ADCSRA = 0×86; // freq = 1/64,   250 kHz. 13 cycles x 4     usec =   52 usec.
// ADCSRA = 0×85; // freq = 1/32,   500 kHz. 13 cycles x 2     usec =   26 usec.
// ADCSRA = 0×84; // freq = 1/16 ,    1 MHz. 13 cycles x 1      usec =   13 usec.
// ADCSRA = 0×83; // freq = 1/8,       2 MHz. 13 cycles x 0.5   usec =  6.5 usec.
// ADCSRA = 0×82; // freq = 1/4,       4 MHz. 13 cycles x 0.25 usec = 3.25 usec.

ADMUX    = 0×40;                          // Select  Analog Input 0

ADCSRA |= (1<<ADSC);                 // Start Conversion

Timer1.initialize(T_PERIOD);           // Sampling with TimerOne library
Timer1.attachInterrupt(iProcess);

}

Reading and storing samples to array via ISR ( Timer Interrupt Subroutine ), Timer1 in this example:

void iProcess()
{
static uint8_t n_sampl;
if (ADCSRA & 0×10)
{
int16_t temp = ADCL;
         temp += (ADCH << 8);
          temp -= sdvigDC;    
    ADCSRA |= (1<<ADSC);
xin[n_sampl] = temp;
}

if (++n_sampl >= FFT_SIZE )
{
n_sampl = 0;
process = 1;
}

}

Don’t like to solder all this components from the drawings above? Here is easy way around, if you, by chance, have a spare USB speakers. Something like this:

Note: Speakers should use USB port as a power source, not AC power outlet!

1.  Open box up, and look  what kind of chip (IC) Power Amplifier inside, on the PCB board:

2.  TEA2025 in this example, but could be different in yours. Not big deal, just write down the name, than go on-line and try to find a data sheet for your particular chip. My favorite links:  1   and   2.  From the data sheet you will find pin numbers of two outputs, for left and right channels. Just solder couple of wires to ground and to any of outputs and that’s it!

3. If printing on the IC body is unreadable, or couldn’t find a data sheet, it is possible to trace two wires from the speaker to IC. Most likely, there would be an electrolytic cap installed in series, between chip output and speaker. Solder a signal wire on the chip’s side of the cap, or near IC. There is a slim chance, of course, that IC wired-up in bridge configuration, and wouldn’t be any caps in series with speaker. It’s even better, just use ether of two speaker’s wires as a signal line, and ground as ??? a ground.

Be careful, use different color of wires for ground line and signal line. There would be no protection, and wrong polarity could damage an analog input of the arduino board, and in some occasions Power Amplifier IC. To prevent this, I’d strongly advise to install 10 kOHm resistor in series with signal wire.


When Less is More: Designing for Minimum Mass

via Nuts and Volts

If you’re a typical N&V reader, then sizing a component means defining its value, precision, power handling capacity, operating voltage, physical size, and precision. Take a typical carbon film resistor listed in the Mouser catalog (www.mouser.com) — a 2K ohm 1/4W 5% tolerance with axial leads. Although you may not have noticed in the past, if you download the full datasheet, you’ll see that the mass is about 226 mg per resistor. Now, go to the equivalent SMT resistor. You’ll see mass listings from 2-16 mg, depending on SMT size.

We’re Official!

via oshwa.org

We’re official! After getting denied (a couple times) in NY State, we successfully incorporated in Delaware. Yay! Step 1 accomplished :)  (Step 2 will be to tackle the paperwork for IRS non-profit status.)

We also created a mailing list for the Open Source Hardware Association. Sign up here please: www.oshwa.org/mailing-lists/  We will use this list to update folks on our progress, discuss directions for our goals and purposes, and use the list as our communication method to best serve you all. We’ll also be cross posting our news and updates to the Updates list (also found in the mailing lists link) as well. 

Drones (UDB4, OpenRelief, ARDrone + Kinect)

via OSHUG

Unmanned aerial vehicles (UAVs), or drones, are increasingly making the news, but when they do so it's usually because of their use in warfare. However, drones can be put to use in many other, far more positive applications. And at the twentieth OSHUG meeting we will hear talks on an experimental attitude and heading reference system (AHRS), using open source technology to build drones for use in disaster relief, and on a fun and novel method of flying drones via gesture control.

Using UDB4 for an Experimental AHRS

The UAV Development Board is a very versatile development board that has been around for the past five or so years, and which has been supported by small team led by William Premerlani. The board comes with a dsPIC30F4011 microcontroller, an MMA7260 three axis accelerometer and two dual-axis Inversense IXZ500 gyroscopes. It has supported various forms of platforms ranging from inverted pendulums to multicoptors. It has primarily been a development platform for experimenters and it is in its fourth major revision.

The talk intends to give a high level view of the MatrixPilot firmware as a general introduction to autopilots, with a demonstration of the Hardware in loop simulation to show how it behaves in flight for a fixed wing aircraft.

Anish Mohammed has been an electronics hobbyist and software hacker since his early teens. He spent almost a decade in research and development in security and cryptography, and these days he works for the Big Five in consulting. He is a confirmed UAV addict who owns a dozen AHRS/Autopilots, both open and partially closed, with interests in multicopters, fixed wings and rovers.

OpenRelief — Open Source Software and Open Hardware For Frontline Disaster Relief

This talk will explore how the OpenRelief team, inspired by challenges seen during the 2011 Tōhoku earthquake, is using Open Source Software and Open Hardware to create disaster relief tools. The first step is to develop a small drone that can take off from anywhere, recognize roads, people and smoke while also measuring weather and radiation. It can be built for less than 1,000 USD, and easily shares information with Open Source and proprietary disaster management systems. The goal is to gather critical information for relief workers on the ground, and contribute to getting aid where it is needed.

Karl Lattimer is an engineer who started early with electronics and programming, and has worked on all kinds of projects for many companies developing software to solve a wide variety of problems. He currently works for Codethink Ltd, an engineering firm based in Manchester, UK. Karl is enthusiastic about Artificial Intelligence, Computer Vision, Robotics and related engineering disciplines. He is a firm believer that we can engineer a future that is more sustainable, adaptive and integrated. His interest in OpenRelief stems from a desire to engineer solutions to the problems faced in disaster scenarios, and the desire to drive the permeation of robots into our everyday lives.

Flying an ARDrone Like a 7-year Old Child

Controlling a Parrot ARDrone using URBI, python and an MS Kinect camera, allowing people to fly it by holding their arms out and pretending to be an airplane like a small child. This was in truth an exploration in how to couple independent projects and to explore and exploit the APIs presented by the kinect and the drone's software.

Ben O'Steen is a freelance developer with an interest in the fuzzy divide between physical and digital spaces, such as how we perceive and use objects differently based on how they are (re)produced, presented or controlled. Currently, he can be found working on digital library and archive projects for academic institutions, art installations and his newly completed 3d printer.

Note: Please aim to arrive for 18:00 - 18:20 as the event will start at 18:30 prompt.

Sponsored by:

Drones (UDB4, OpenRelief, ARDrone + Kinect)

via OSHUG

Unmanned aerial vehicles (UAVs), or drones, are increasingly making the news, but when they do so it's usually because of their use in warfare. However, drones can be put to use in many other, far more positive applications. And at the twentieth OSHUG meeting we will hear talks on an experimental attitude and heading reference system (AHRS), using open source technology to build drones for use in disaster relief, and on a fun and novel method of flying drones via gesture control.

Using UDB4 for an Experimental AHRS

The UAV Development Board is a very versatile development board that has been around for the past five or so years, and which has been supported by small team led by William Premerlani. The board comes with a dsPIC30F4011 microcontroller, an MMA7260 three axis accelerometer and two dual-axis Inversense IXZ500 gyroscopes. It has supported various forms of platforms ranging from inverted pendulums to multicoptors. It has primarily been a development platform for experimenters and it is in its fourth major revision.

The talk intends to give a high level view of the MatrixPilot firmware as a general introduction to autopilots, with a demonstration of the Hardware in loop simulation to show how it behaves in flight for a fixed wing aircraft.

Anish Mohammed has been an electronics hobbyist and software hacker since his early teens. He spent almost a decade in research and development in security and cryptography, and these days he works for the Big Five in consulting. He is a confirmed UAV addict who owns a dozen AHRS/Autopilots, both open and partially closed, with interests in multicopters, fixed wings and rovers.

OpenRelief — Open Source Software and Open Hardware For Frontline Disaster Relief

This talk will explore how the OpenRelief team, inspired by challenges seen during the 2011 Tōhoku earthquake, is using Open Source Software and Open Hardware to create disaster relief tools. The first step is to develop a small drone that can take off from anywhere, recognize roads, people and smoke while also measuring weather and radiation. It can be built for less than 1,000 USD, and easily shares information with Open Source and proprietary disaster management systems. The goal is to gather critical information for relief workers on the ground, and contribute to getting aid where it is needed.

Karl Lattimer is an engineer who started early with electronics and programming, and has worked on all kinds of projects for many companies developing software to solve a wide variety of problems. He currently works for Codethink Ltd, an engineering firm based in Manchester, UK. Karl is enthusiastic about Artificial Intelligence, Computer Vision, Robotics and related engineering disciplines. He is a firm believer that we can engineer a future that is more sustainable, adaptive and integrated. His interest in OpenRelief stems from a desire to engineer solutions to the problems faced in disaster scenarios, and the desire to drive the permeation of robots into our everyday lives.

Flying an ARDrone Like a 7-year Old Child

Controlling a Parrot ARDrone using URBI, python and an MS Kinect camera, allowing people to fly it by holding their arms out and pretending to be an airplane like a small child. This was in truth an exploration in how to couple independent projects and to explore and exploit the APIs presented by the kinect and the drone's software.

Ben O'Steen is a freelance developer with an interest in the fuzzy divide between physical and digital spaces, such as how we perceive and use objects differently based on how they are (re)produced, presented or controlled. Currently, he can be found working on digital library and archive projects for academic institutions, art installations and his newly completed 3d printer.

Note: Please aim to arrive for 18:00 - 18:20 as the event will start at 18:30 prompt.

Sponsored by: