This is a continuation of the discussion of a project based on the SDR-Widget and Audio-Widget. The project is a dedicated ADC-analog front end for the purpose of low distortion measurement. Continued from EMU0204 mods for FFT measurements.

this is interesting. It is quite doable to add ADC capability to the Audio-Widget project (see my signature below). I can give my present AB-1.2 a respin with new analog features. And I'm sure it is quite doable to reuse SDR-Widget code for the ADC support.

I take it from Borge's statement that the Audio-Widget at present doesn't have the ADC capture support.

George the rotary encoder will be vary handy for an analyzer set. In fact four would be handy. But I going to leave this for a completely different project because there are mixed desires here for functionality. The LCD is a handy tool for debugging it could be dropped when it no longer serves a purpose.

If we can make this modular by grouping unused IO pins to some type of header that mates with a connector, cable or otherwise. Perhaps we can come up with something and call it universal. Something that would support add-ons or offer other bits of control. No pun intended there.

Before I go any further with this is there any available processing power left in the SDR/Audio-Widget? How much other functionality can the Atmel support?

I'm posting a PDF from AKM I'd like everyone to have a look at if you haven't already.It describes the parallel use of two or more ADC to increase dynamic range and lower the noise floor. There are a number of approaches to doing this and we need to decide which is the best way. I'd like to open a discussion on this.

I think to avoid something like an FPGA, which would be over kill, between the ADC and processor the I2S of the ADC's could be multiplexed.This would require a bit more processing overhead, a buffer to hold the words, some simple integer addition and a bitwise shift operation for dividing to complete the task.

I had an good meeting with AKM some time ago and went over this application with Joel. He said that he could help with recommendations of suitable DSPs to do the necessary processing. They really are neither expensive nor power hungry. I'm using several in a Bluetooth headphone project now that can do 192 KHz or better running on 3.3V and using no power. We just need to be able to load the DSP code. I can get direction on either TI or ADI parts that can do this (and much more). We do not need FPGA's. They are nice but not necessary and way overkill in development for this application (and most audio ones today).

I had an good meeting with AKM some time ago and went over this application with Joel. He said that he could help with recommendations of suitable DSPs to do the necessary processing. They really are neither expensive nor power hungry. I'm using several in a Bluetooth headphone project now that can do 192 KHz or better running on 3.3V and using no power. We just need to be able to load the DSP code. I can get direction on either TI or ADI parts that can do this (and much more). We do not need FPGA's. They are nice but not necessary and way overkill in development for this application (and most audio ones today).

What signal processing do you think that would be advantage to process in the ADC?

I would suggest just get the data transfered to the PC. A couple of years ago I was a part of a team that made a inhouse high-speed trace/sw debugger tool. We ran high-speed USB and transfered ~20 MByte/s sustained. We could let it run overnigt without any transfer errors. I have to add that we ran bulk-mode. I think the USB connection should be ok for getting the data to the PC and use the processing power of that crunch the numbers.