Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Community Manager
1,584 Views

Is the Edison a good choice for sampling 6 analog microphones at 11 kHz each?

I am working on a project that requires me to analyze data from 6 microphones at the same time. I need to sample each of them at a minimum of 11 thousand samples per second. My (C++) program will process the data in real time and search for known patterns. It is important that the microphones be very small and I am currently using ADMP401 microphone breakouts from Sparkfun. Will I be able to accomplish this with an Intel Edison?

So far I have been testing my Intel Edison with one microphone through an MCP3002 analog-to-digital converter. It uses SPI for communication, and while I can turn up the SPI frequency well into the MHz range on the Edison, there is a delay of 220 to 240+ microseconds between the SPI clock sequences of each sample read. I am reading the ADC with spidev and the ioctl function in a loop that has nothing else in it. Because of the delay, my effective sampling rate is never better than about 4.5 kHz. I used an oscilloscope on the SPI clock line to verify that my SPI frequency was as fast and I instructed in my code, but the delay between samples is mostly in the 220 to 240 microsecond range regardless of the SPI frequency. I tried the same code (with a different device file name, of course) and sensor/ADC setup with a Raspberry Pi and noticed a 60 to 80+ microsecond inter-packet delay, which, when added to the actual SPI communication time, achieved an approximately 10 kHz sampling rate. I doubt that the delay is solely due to the processing time of the MCP3002, since its datasheet says that it can process 75,000 to 200,000 samples per second, which corresponds to a sampling interval of 5 to 13 microseconds.

To address the SPI delay, I did some research and came upon https://www.raspberrypi.org/forums/viewtopic.php?t=19489 this thread which spawned http://www.bootc.net/archives/2012/05/19/spi-on-the-raspberry-pi-again/ the project discussed here. If I tried to build my own kernel (am I saying that right?) for the Edison with this approach, would it lessen the inter-packet delay or just improve the clock frequency within each packet? Should I write a Linux device driver or kernel module as discussed http://stackoverflow.com/questions/22632713/how-to-write-a-simple-linux-device-driver here? I have no experience with these approaches. Are they different approaches?

I have looked into simultaneous sampling ADC chips. I figure that since I am potentially within reach of sampling one microphone through the MCP3002 at 11 kHz, I could connect all 6 of my microphones to a simultaneous sampling ADC and focus on getting the inter-packet delay consistently under 80 microseconds.

Another issue I face is that the delay between packets is variable. With the Edison, it is typically 220 to 240 microseconds, but often over 300. With the Pi, it is typically between 60 and 80 microseconds, but often over 100. My data processing will suffer if I can't sample the microphones at consistent intervals.

Someone recommended using an FPGA. Is that appropriate? I am open to changing anything and everything about my approach.

-Jason

7 Replies
Highlighted
Community Manager
17 Views

Hi Jason_Maker,

 

 

Thank you for the detailed description of your issue. This behavior you describe about the SPI was a known issue. The delay between the SPI clock sequences of each sample read was described in previous threads and I believe that this issue is not resolved yet. The suggestions made to improve the sampling speed you seem to already have taken into account. I'll recommend you to look at some useful threads about the SPI and its capabilities, you may find something useful here:Nevertheless, I'm going to investigate further on your case to see if there have been any updates that might help you achieve a better sampling rate. I'll post the information I find here.

 

 

-Sergio

 

0 Kudos
Highlighted
Community Manager
17 Views

Hi Jason_Maker,

 

 

The delay between samples in the Edison SPI driver is acceptable for most used cases and it could be inadequate for fast sampling applications. A hardware solution like a FPGA would normally provide a better solution compared to developing a performance optimized SPI driver, which may or may not achieve the sampling rate your project required.

 

 

-Sergio

 

0 Kudos
Highlighted
Community Manager
17 Views

Hi Sergio,

I have been writing a device driver kernel module for a Raspberry Pi while I wait for the headers for my Edison. Yesterday I got to the point where I was able to sample audio from one microphone through an SPI ADC at 165 kHz. There is virtually no delay between SPI clock sequences in my driver. I used direct memory access of the SPI registers to accomplish this. I am excited about trying the same thing with the Edison, but I looked at the http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z36xxx-z37xxx-datasheet-... datasheet for the Atom processor and I can't figure out the addresses for the memory registers. In the datasheet, the registers are all listed with a "Signal Name" rather than a hexadecimal memory address. I don't understand how I would use mmap and ioremap without having the actual numeric memory address locations. Where can I find the register addresses?

-Jason

0 Kudos
Highlighted
Community Manager
17 Views

We'll do some research about the register addresses. We'll come back to you soon.

 

 

-Sergio

 

0 Kudos
Highlighted
Community Manager
17 Views

Hi Jason_Maker,

 

 

Thank you for your patience. We've looked for information about the register addresses, but I'm afraid, I couldn't find anything I was able to share. I know this may not be the outcome you expected, but some features on the Edison, such as the registers are not publicly available.

 

 

Please let us know if you have any other questions related to this case. We'll be waiting for

 

your response.

 

 

-Sergio

 

0 Kudos
Highlighted
Community Manager
17 Views

Hi Sergio,

That is very unfortunate, since I cannot use the Edison for my company's device without that information. Hopefully you understand how frustrating it is for a developer to have this critical information withheld from them. Please pass on this sentiment to whomever is responsible for the policy.

-Jason

0 Kudos
Highlighted
Community Manager
17 Views

Hi Jason_Maker,

 

 

We understand you're upset with this outcome. We wish there was more we can provide in order to help you, but this decision is out of our control. We hope you find a way to continue to work with the Edison and contact us again if help is needed. We'll make sure to pass your feedback to the proper team.

 

 

Regards,

 

Sergio

 

0 Kudos