We will be using direct digital synthesis to generate the call of the northern cardinal. Specifically, this adult male northern cardinal recorded by Gerrit Vyn in 2006. This bird was recorded in Texas, but cardinals are also common in Ithaca and throughout the eastern United States. If you pay attention when you're walking through campus, you may hear one singing. The males are a very striking red. You can read more about the cardinal here.
A northern cardinal
Cardinals have a variety of songs and calls. We will be synthesizing on of its most common songs, which you can hear in the first ten seconds of the recording below:
Here is a screenshot of the spectrogram for the song that we'll be synthesizing. Cardinals and many other songbirds produce almost pure frequency-modulated tones. As can be seen in the spectrogram below, the cardinal sweeps through frequencies from ~2kHz to ~7kHz. We'll assume that the dominant tones (the darkest lines on the spectrogram) are significantly louder than all other frequencies (the lighter lines). We'll only synthesize these loudest frequencies. The generated song sounds quite realistic under this assumption. Your synthesizer will be controlled via a keypad.
Experience shows that students prefer these webpages short. For that reason, please see these external pages for additional information which will be critical to completing this particular lab.
Direct digital synthesis (DDS): This is the algorithm that we will use for sound production. This is a powerful algorithm, a good one to understand deeply.
Birdsong synthesis via DDS: This webpage deconstructs the Northern cardinal's song, and synthesizes it via DDS.
Keypad: Your birdsong synthesizer will be cotrolled via a keypad. Please see this page for examples of and information about the the keypad that we will be using.
Sound synthesis page: Generally speaking you want to make pleasant sounding synthesis. You may want to look at the sound synthesis page. I suggest starting with a linear attack of about 1000 samples, a decay of about 1000 samples, and a sustain as long as necessary for a 130ms chirp/swoop.
DAC datasheet: The SPI DAC you will use is the MCP4822. The DAC analog output is marked DACA or DACB on the SECABB. The SPI connections are supplied on the Big Board (SECABB), as long as you connect the DAC_CS jumper. Section 5.1 and 5.2 of the MCP4822 datasheet discussed the way the the DAC uses SPI. The edge connector pin marked DACA or DACB will go (optionally through a low pass filter) to an audio socket, to be connected to the green audio plug of the speakers. If you are going to design a lowpass filter for the DAC, then you need to know that the input impedance of the speakers is around 10 Kohm.
Audio socket. The pin nearest the socket is ground. Left/right channels are wired together.
I suggest that you organize the program as follows. If a different organization makes more sense to you, that's ok. This is just a suggestion.
Protothreads maintains the ISR-driven, millisecond-scale timing as part of the supplied system. Use this for all low-precision timing (can have several milliseconds jitter).
Synthesis ISR uses a timer interrupt to ensure an exact 44KHz synthesis sample rate.
DDS of sine waves
DAC output
Sample count for precise timing of sounds
Main sets up peripherals and protothreads then just schedules tasks, round-robin
Keypad Thread
Scans and debounces the keypad and any other buttons you may use
Your state machine must debounce all 12 keys.
Parses the command (if any) and updates state variables (play mode, sound list, etc.)
Waits for 10-30 mSec using PT_YIELD_TIME_msec(time), then repeats.
Play Thread
Waits to be semaphore-signalled by a different thread
Plays the sound associated with each button press recorded in the global array by setting up the DDS parameters associated with each sound
Maintains playback timing using the sample count from the timer ISR
Timing of all functions in this lab, and every exercise in this course will be handled by interrupt-driven counters, (including the builtin functions in ProtoThreads) and not by software wait-loops. This will be enforced because wait-loops are hard to debug and tend to limit multitasking. You may not use any form of a delay(mSec) function.
Did you turn on interrupts? The thread timer depends on an interrupt.
Did you write each thread to include at least one YIELD (or YIELD_UNTIL, or YIELD_TIME_msec) in the while(1) loop?
Did you schedule the threads?
Did you ask to initialize the TFT display in the code, while not having a TFT on the board?
Does the board have power?
If your program reboots about 5 times/second:
Did you exit from any scheduled threads? This blows out the stack.
Did you turn on any interrupt source and fail to write an ISR for that source?
Did you divide by zero? A divide by zero is an untrapped exception.
Did you write to any non-existant memory location, perhaps by using a negative (or very large) array index?
If your thread state variables seem to change on their own:
Did you define any automatic local variable? Local variables in a thread should be static.
Are your global or static arrays big enough to clobber the stack in high memory? You should be able to use over 30kbytes.
The oscilloscope is essential for debugging this lab (and every lab). The oscilloscope is the only way of deciding if -- It doesn't work! -- results from hardware or software.
By the end of lab session in week one you must have either built and tested your own board or tested a prebuilt board.
Before you test, be sure to attach the chip-select jumpers for the Port Expander, TFT, and DAC.
The current version of Protothreads is 1_3_2. All example programs using this threader may be found on the Development board page. Download the ZIP file on this page to get all the libraries and substitute in the following source code: Program example 3, DDS_Accum_Expander_BRL4.c on the Development board page is the basis for this lab.
Run this example.
For most of the semester you will be using the TFT LCD for output and debugging. You will need to use some of the graphics library calls described in the test code in this lab. Test code: TFT_test_BRL4.c -- displays color patches, system time, moves a ball, generates a slow ramp on the DAC, and blinks the LED. Run this example.
You may want to refer to the ProtoThreads page for the general threading setup.
Basic keypad interface working. You should be able to press 1 on the keypad and hear exactly one swoop sound (not necessarily amplitude modulated) and you should be able to press 2 on the keypad and hear exactly one chirp sound.
Timing of all functions in this lab, and in every exercise in this course will be handled by interrupt-driven counters, not by software wait-loops. ProtoThreads maintains an ISR driven timer for you. This will be enforced because wait-loops are hard to debug and tend to limit multitasking
Write a Protothreads C program which will:
The program starts in play mode. The program will play the swoop sound when the 1 key is pressed and the chirp sound when the 2 key key is pressed. Each sound will play for 130ms, exactly once, independent of the duration of the button push.
The program will produce 130ms of silence when the 3 key is pressed. This is mostly useful in record mode (see below).
In play mode, the program will play the recorded sequence of sounds. The sounds will play with an amplitude envelope that you choose. There may not be any clicks, pops, or other audio artifacts.
The program should have two modes:
Upon power-up or reset the system should go into play mode and play a sound for each button press (swoop for key 1, chirp for key 2, and 130 ms of silence for key 3).
Pressing and holding a separate button (not the keypad) or toggling a switch puts the system into record mode so that each button press is recorded for later playback. Recording continues until the record mode toggle is released. The duration of each button press does not affect the recording.
The program should include two frequency sweeps (the swoop and chirp) that you can hard-code.
There should be no clicks, pops, or other audio facts of synthesis.
When you demonstrate the program to a staff member, you will be asked to play back a sequence of sounds which simulates the birdsong above, and to play back a random sequence of swoops/chirps/silences. At no time during the demo can you reset or reprogram the MCU.
In addition to the above, ECE 5730 students should synthesize another Northern Cardinal song, shown below. You may deconstruct this song into 4 sound primitives, as illustrated below. Fit these frequency sweeps to functions using similar analysis to that shown at the top of this document.
Each of these 4 sound primitives should be mapped to 4 additional keys on the keypad.
You may fit to any function that you like. 2 linear functions and a parabolic function sound nice.
You can also synthesize songs for other, more challenging birds like the Baltimore oriole. (If you're lucky, you can spot these in Ithaca too. They're gorgeous and have a very distinctive song).
By plugging the Pic into the microphone input of the PC, we can record the sound that it generates and create a spectrogram of the Pic-generated birdsong:
In [19]:
samplerate,data=wavfile.read('./Bird.wav')frequencies,times,spectrogram=signal.spectrogram((data[80000:191000,0]+data[80000:191000,1])/2.,samplerate)plt.pcolormesh(times,frequencies,spectrogram,shading='gouraud')plt.ylabel('Hz');plt.xlabel('Time (sec)')plt.title('Spectrogram of PIC-generated birdsong')plt.ylim([0,10000])plt.show()
