A large part of circuit design is about making trade-offs between speed, cost, power consumption and so on while meeting some design specification that can often be traced to Signal to Noise ratio (SNR). Yet, possibly for pedagogical reasons, SNR is often under-emphasized in undergraduate classes. Remember those amplifiers you heard/read about years ago ? This post will demonstrate a canonical application of amplifiers and show you how to measure SNR of a signal captured from an Arduino.
Sunday, January 26, 2014
Saturday, December 7, 2013
Interpreting the fourier transform
A friend of mine, who is a designer, asked me how the Fourier transform is interpreted. I'm turning my answer into a blog post in the hope that this might help non EE/math people in dealing with real-world signals.
Monday, March 18, 2013
Templating with web.py for Circuit Design
When describing circuits to computers, have you ever felt that the languages for EDA, be it SPICE or Verilog or whatever are not flexible enough ? Well, I have. Coding regular structures such as adders, ring oscillators, multipliers etc. with popular languages in EDA can be a pain. A couple of weeks ago, I was checking out a synthesized ring oscillator to build a time-to-digital converter (TDC) [1]. Building long chains of inverters by hand is drudgery and SPICE does precious little to help in automation. At first, I tried writing a python program with string manipulations that generates verilog code, but quickly came to realize that its way more natural to have snippets of python inside verilog. Now, that needs a bit of work to get going. Thankfully, web developers solved this problem long ago for programmatically generating HTML. I used web.py 's templating engine to write verilog code that describes a ring oscillator (in case you are surprised by the fact that I used verilog rather than SPICE, the whole idea is to create the TDC with standard cells).
Thursday, June 9, 2011
NTSC demystified - Cheats - Part 6
Throughout this series of articles we've seen a number of "cheats" or non-standard signals which simplify NTSC signal generation. This post summarizes them.
NTSC demystified - Implementation - Part 5
Now that we understand how NTSC color coding works and the math behind it, it's time to think of ways to implement color coding. Knowing the math helps because that knowledge equips us to abuse the system and implement color using simpler/cheaper hardware.
Saturday, May 21, 2011
WAV Player with LPC1768 and SD card
After porting the SD card low-level IO functions that my project team had written for the AVR Atmega 8-bit series about a year ago, integration with elm-chan's FAT FS was seamless. Keeping the connections suggested by Mike, the SD card posed no difficulty at all.
Playing a WAV file with a microcontroller is a "hello world" equivalent when interfacing with the SD card. For this, the motor control PWM peripheral looked ideal since I needed the main PWM peripheral for something else. An RC low pass filter of 330 ohm and 0.1uF is good enough to filter out the PWM frequency and its harmonics while leaving the audio signal intact.
Playing a WAV file with a microcontroller is a "hello world" equivalent when interfacing with the SD card. For this, the motor control PWM peripheral looked ideal since I needed the main PWM peripheral for something else. An RC low pass filter of 330 ohm and 0.1uF is good enough to filter out the PWM frequency and its harmonics while leaving the audio signal intact.
Friday, May 20, 2011
Interfacing with SD card gotcha
Elm-ChaN's tech notes on interfacing with SD card is fantastic. There are, however, some things left unsaid. Today, my colleague Thejasvi and I discovered two aspects not explicit in that tutorial.
1. The way /CS signal should be handled.
Before sending a command, make /CS low. Get the response, data packets ( if any ). Now, it is essential to make /CS high before sending the next command.
2. After one command is complete. That is to say, a command is sent and a response is got (mostly R1 response) , do NOT make /CS high. The card will go out of sync and wont accept new commands properly. After the R1 response is got, send atleast one dummy byte(0xFF) and then make /CS high. Now it is ready to accept new commands. This is probably because the card is completely inactive if no data is transmitted to it as no clock signal goes to it. My conjecture is that it needs a few clocks to resynchronize after a command-response before it can accept a new command. Thus the dummy byte after the R1 response.
1. The way /CS signal should be handled.
Before sending a command, make /CS low. Get the response, data packets ( if any ). Now, it is essential to make /CS high before sending the next command.
2. After one command is complete. That is to say, a command is sent and a response is got (mostly R1 response) , do NOT make /CS high. The card will go out of sync and wont accept new commands properly. After the R1 response is got, send atleast one dummy byte(0xFF) and then make /CS high. Now it is ready to accept new commands. This is probably because the card is completely inactive if no data is transmitted to it as no clock signal goes to it. My conjecture is that it needs a few clocks to resynchronize after a command-response before it can accept a new command. Thus the dummy byte after the R1 response.
Subscribe to:
Posts (Atom)