Evan's Long Cable MEM Work
From SeedWiki
Contents |
5/11/10 -- 6 Mics working
I have no idea what made this work, but somehow disconnecting the two bad microphones seemed to do the trick. Here's a recording of me saying "Hello World" on all 6 channels. Currently my IPCore simply saves the bitstream into BRAM.
 |
Here are all the wav files to listen to:
- Channel 1: http://seed.ucsd.edu/mediawiki/images/9/90/Hello-world-1.wav
- Channel 2: http://seed.ucsd.edu/mediawiki/images/7/72/Hello-world-2.wav
- Channel 3: http://seed.ucsd.edu/mediawiki/images/e/e4/Hello-world-3.wav
- Channel 4: http://seed.ucsd.edu/mediawiki/images/f/fc/Hello-world-4.wav This one sounds like it has more noise on the line
- Channel 5: http://seed.ucsd.edu/mediawiki/images/b/b5/Hello-world-5.wav
- Channel 6: http://seed.ucsd.edu/mediawiki/images/8/81/Hello-world-6.wav
Observations:
- Channel 4 is worse than the rest -- this microphone must be somewhat defective too.
--EvanEttinger 20:35, 11 May 2010 (UTC)
5/10/10 -- 8 Mics and some Trouble
I hooked up 8 mics to the FPGA board, and made changes to my IPCore so that it saves the bitstream of all 8 into BRAM (1st 8 bits are a checksum of the last 24 bits which are interleaved bits for all 8 channels). Here are the results of me saying "Hello"
 |
Observations
- Microphones 1 and 7 appear to be dead. I'm fairly certain that it's the microphones themselves since I've switched the pins that they are connected to and the same behaviour is observed.
- There is some very low frequency noise on all channels (~16 Hz). I have no idea where this is coming from, but it definitely is not from my IPCore since my checksums are always working out. This is something that is happening in each of the microphone channels -- notice that it occurs at the same time in each of the microphone channels. I've tried switching how the mics are connected across the pins and the same behavior is observed. I'll need to investigate further to try and hunt down it's source...debugging suggestions appreciated =).
--EvanEttinger 23:16, 10 May 2010 (UTC)
3/31/10 -- Audio out through AC97
It took me a while, but I finally got PCM data to the AC 97 chip so that an analog signal comes out of a headphone jack on the fpga board. I implemented a sinc5 filter in verilog (modeled after a sinc3 filter that I found in an analog devices datasheet). I changed the clock rate of the mic to 2.4 Mhz so that using a decimation rate of 50, you can get to 48Khz easily (or 150 to get to 16 Khz). The AC 97 DAC gets PCM audio at 48Khz and converts it to an analog signal. I use microblaze to poll an exposed register from my sinc5 core that calculates this PCM data. The microblaze C program grabs the new audio when it appears and sends it to the AC 97 controller which packages the data appropriately for the codec.
This is a link to the wav recording:
 |
--EvanEttinger 23:45, 31 March 2010 (UTC)
2/9/10 -- Ultrasonic
We put the lego mindstorm depth sensor up close next to the microphone and here's what the result is (sampling rate = 100 Khz):
 |
There's a clear pure signal around 32.5 Khz that this microphone easily picks up. It also looks like there's some pulses it's using near 40 Khz -- but that may just be residual fft bleeding from the robot talking (it talks whenever it's close to something, in this case the microphone, so it was talking repeatedly too). I think the speaker that they use in the depth sensor is pretty weak since it only detects objects that are really close to it. We couldn't really see anything in the audio signal when it was farther away (say past a foot or two). But with a stronger speaker there certainly is potential here!
--EvanEttinger 00:09, 10 February 2010 (UTC): According to this page (http://www.lsu.edu/deafness/HearingRange.html) we'd want to use a pulse in the range of around 100 Khz to avoid making Gary's dog angry, and any other animals that may come by. This means we'd want a sampling rate of around 200 Khz which is very possible with the MEMs (even the MOTU can sample at 196 Khz so we could try and see what kind of response our current mics have). How do we generate a strong sound source at around 100 Khz?
--Yoavfreund 02:38, 10 February 2010 (UTC) The simplest way would be to use a wave generator from one of the hardware labs and connect it to a small loudspeaker from radio-shack. Bhiksha Raj's co-author has a design for a doppler-effect speaker+mic that costs 10$-20$ in parts. Another one that is very cheap and probably better than the Lego one is: http://www.sparkfun.com/commerce/product_info.php?products_id=639 you can find many others if you google "ultrasonic range finder".
2/8/10 -- A long recording
Here it is. I implemented my plan below and everything sounds good to me -- you can even hear me hit enter on the keyboard to start the workstation program that grabs the audio =)!
--Yoavfreund 23:12, 8 February 2010 (UTC) Excellent! However, the recording in the .wav file seems to have very low volume, can you fix that?
--EvanEttinger 23:45, 8 February 2010 (UTC): Sure, I just amplified it all up by a constant factor. The new wav file should be louder. Here's a zip file containing the bit file grabbed from bram and matlab files to do the delta sigma demodulation: http://seed.ucsd.edu/mediawiki/images/e/ee/Evan_talking.zip
--Yoavfreund 03:55, 9 February 2010 (UTC) Excellent! the recording sounds very clean! I think we can ask Tom Guminski to mount for us 7 more microphones. I would also like to see what the response of the microphone is to high frequencies. I will talk about this tomorrow with John Hildebrand from Scripps.
 |
--EvanEttinger 20:55, 8 February 2010 (UTC): One issue is that we're sampling the microphone at 2.7Mhz and you cannot get down to 16 Khz by simply dropping every Kth sample for some integer K. So what you're hearing here is really using a sampling rate of 16.071 Khz. It's not a huge problem in terms of calculating TDOAs, but in terms of the audio working well with other programs, it may be problematic. I haven't really looked into linking several Digital Clock Managers together so that we can get to a 2.4 Mhz clock rate and then easily drop samples from there to get to 16 Khz.
Anyways, I'm not really sure where we want to take this project from here anyways. Now that we know that it works we can start using our imaginations on where we want this project to go I guess =).
2/8/10 -- Short recordings
Here's some really short recordings that sound recognizable at least to me! This indicates that the microphone is working!
Evan saying "ahhh"
 |
Evan saying "zzzz"
 |
Here is some MATLAB code to recover this audio:
clear;
fid=fopen('count.txt','r');
A=fscanf(fid,'%x');
fclose(fid);
count = 0;
S = zeros(length(A)*27,1);
for i=1:length(A)
x = dec2bin(A(i),32);
s1 = sum(x(6:end) == '1');
s2 = bin2dec(x(1:5));
if(s1 ~= s2)
count = count + 1;
fprintf('ERROR(%d): (%d,%d) - %x\n', count, s1, s2, A(i));
end
start = (i-1)*27+1;
S(start:start+26) = x(6:end);
end
S = 2*(S - 48) - 1;
sr = 2700000;
DEC_FAC = floor(sr/16000);
fs = sr/DEC_FAC;
mic = sinc_decimate(S, 5, DEC_FAC);
mic = mic - mean(mic);
mic = mic(10:end);
plot(mic);
soundsc(mic,fs);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
function y = sinc_decimate(x,m,r)
% y = sinc_decimate(x,m,r) Decimate x by m-th order sinc of length r.
x = x(:)';
for i=1:m
x = cumsum(x);
x = [x(1:r) x(r+1:end)-x(1:end-r)]/r;
end
y = x(r:r:end);
--EvanEttinger 17:50, 8 February 2010 (UTC): The zzzz one doesn't look perfect, but maybe that's just the way it is. I'm going to try and set it up so that I can get longer recordings today for a better test. My idea is to have the IP write 0/1 at the first word to indicate whether it's done writing the top 1/2 of BRAM or the bottom 1/2. Then, the workstation will poll this memory location constantly and whenever it changes it will grab the most recently completed 1/2 of BRAM.
--Yoavfreund 19:16, 8 February 2010 (UTC) Great work! Your plan sounds good!
2/6/10 -- Reading bits from Mic correctly
After much struggle, with the help of Chip Scope I was able to narrow down where the issue was with recording from the Mic. Now I am confident that the data we're getting is being read correctly from the microphone in the sense that the checksums are correct on each line. Here's a page showing the verilog code that didn't work, and the one that did: MemVerilogComparison
Now the things to check are:
- Are these bits decodable into coherent audio? SigmaDeltaAttempts
- The sampling rate for this microphone is 2.7 Mhz. The mic spec says that 2.4 Mhz is the optimal operating clock for the microphone. A nice property of 2.4 Mhz is that it is a multiple of 16 Khz so we could simply decimate the signal without having to worry about fractional samples. 2.7 Mhz is not evenly divisible by 16 Khz. I looked into changing the clock that's driving the microphone and I think it may be difficult using digital clock manager modules seeing that they can only multiply and divide clock rates by integer amounts within a certain range (2-24 if I recall correctly). If we used a few DCMs in parallel then we could acheive 2.4 Mhz, but I'm not sure if that's ok to do without degrading the clock signal?
--EvanEttinger 00:22, 7 February 2010 (UTC)
Long Cable MEM Info
 |
- ADMP421 on Analog Devices web site
- Datasheet says "Fourth order Delta-Sigma modulator". Is this enough information?
- Page 9 says "refer to ADMP421 Application Note and codecs respective datasheets". I could find the ADAU 1361 datasheet, but not the Application note.
