CaptureWidget

Hi Guys,

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.

http://www.akm.com/AppsNotes/AN120516.pdf


Cheers,
 
Last edited:

1audio

Member
Paid Member
2004-03-24 5:16 am
SF Bay Area
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).

Look at the DSP's in this block diagram. Block Diagram (SBD) - Pro Audio Mixer - TI.com I'll check with TI to see which ones to use. There is enough power to do some processing in the DSP before it comes back to the system.

Also an option is the ADI Sigma Studio stuff: SigmaDSP Processors | Processors and DSP | Analog Devices
 
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).

Look at the DSP's in this block diagram. Block Diagram (SBD) - Pro Audio Mixer - TI.com I'll check with TI to see which ones to use. There is enough power to do some processing in the DSP before it comes back to the system.

Also an option is the ADI Sigma Studio stuff: SigmaDSP Processors | Processors and DSP | Analog Devices

What's available for development software for these DSP for free?
What I've seen from the manufactures is big $$$.
 

mkc

Member
Paid Member
2002-06-24 7:32 pm
Denmark
Hi,

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.

Best regards,
Mogens
 

1audio

Member
Paid Member
2004-03-24 5:16 am
SF Bay Area
I have both TI's and ADI's dev tools (free downloads) and except for things like Dolby, DTS and other uninteresting stuff its all free.

The current need would be to mix two or four ADC's to get better SNR. I'm not sure what else but anything from level detection to DC offset. Being software it can always be added later.
 
I have both TI's and ADI's dev tools (free downloads) and except for things like Dolby, DTS and other uninteresting stuff its all free.

The current need would be to mix two or four ADC's to get better SNR. I'm not sure what else but anything from level detection to DC offset. Being software it can always be added later.


So the free version of ccs5 will work then.

I was thinking two ADC mixing all for channels.

Does TI have any really small DSP. I have to the hay soon so I can't look now.
 

mkc

Member
Paid Member
2002-06-24 7:32 pm
Denmark
Hi David,

A FPGA would be nice. However, one could also consider changing the CPU as mentioned before. ST has a cortex M4 variant STM32F407VGT6. It's reasonably priced and could perhaps be an option. As far as I remember it only has one I2S port.

Best regards,
Mogens
 

1audio

Member
Paid Member
2004-03-24 5:16 am
SF Bay Area
How small? Some are in chip scale packages. Or smaller in function? Many options.

My guess is that we would need 2-4 I2S in and 1 I2S out. Needs to run 192 KHz sample rate, lower power and cheap. I'll see what's possible in the next few days.

We are playing with a TI part that could do both USB and DSP, but working code is some ways off for the USB.
 
How small? Some are in chip scale packages. Or smaller in function? Many options.

My guess is that we would need 2-4 I2S in and 1 I2S out. Needs to run 192 KHz sample rate, lower power and cheap. I'll see what's possible in the next few days.

We are playing with a TI part that could do both USB and DSP, but working code is some ways off for the USB.

I meant small in functionality which equates to small in size as well.
Yes 4 in and one out. I don't think 192 is all that fast for these things. They can probably go a lot faster. Programming USB is a pain. I rather just modify existing code for that which is what I did with the PIC. And then there's the driver issues.

Let's keep it as simple as possible for now. Mods can come later.
If it gets too complicated we'll never get it done. Do you have the time?
 
Hi David,

A FPGA would be nice. However, one could also consider changing the CPU as mentioned before. ST has a cortex M4 variant STM32F407VGT6. It's reasonably priced and could perhaps be an option. As far as I remember it only has one I2S port.

Best regards,
Mogens

I don't have the time to learn a new language. If I had the skills I would consider it.
The SDR/Audio widget is open source but it is protected. Unless the owners want to switch processors I don't think that's going to happen.
 

mkc

Member
Paid Member
2002-06-24 7:32 pm
Denmark
I don't have the time to learn a new language. If I had the skills I would consider it.
The SDR/Audio widget is open source but it is protected. Unless the owners want to switch processors I don't think that's going to happen.

I understand. Although the existing Audio widget code is in plain C. I think it would be doable to port that.

However, considering the wish for keeping the orginal widget HW, I woild suggest an FPGA. How about contacting Ian here on the board and hear if he could be pusuaded to help?

Mogens
 
I read the app-note at http://www.akm.com/AppsNotes/AN120516.pdf. Interesting stuff!

Doing math on I2S signals is a big hassle. If the bits were only to come out LSB first we could use inline adders. My instinct says:
1) 4-channel I2S input if we find an MCU setup which supports that.
2) FPGA. I've done similar things in Xilinx+Verilog, and the summing seems quite straightforward.

The trouble with 1) is that a lot of code is AVR32-centric in the existing project. The trouble with 2) is IMHO cost and complexity. The Xilinx tools are free (beer).

It is very doable to make an MCU program which receives a binary file and uses it to flash the config memory of an FPGA using SPI and GPIO. Starting from scratch, such a setup would first boot the MCU's bootloader, then program the MCU, then fill the FPGA's config memory, and then start the application on each consecutive reboot.

A SPARTAN-3A 50K is more than enough. DigiKey says it's [email protected] Add to that a couple $ for the config memory and a fee to get it assembled.

Here's my suggestion: Don't let the need for summing rule this out. Let's come up with a nice PSU and analog design. I can handle the FPGA parts and organize a group buy of assembled units.

Børge
 
Here's my suggestion: Don't let the need for summing rule this out. Let's come up with a nice PSU and analog design. I can handle the FPGA parts and organize a group buy of assembled units.

Børge

Page 19 of the AK5394A datasheet has an input circuit shown and described. S/N+D is 105dB, gain -14.5dB, fc=320kHz for the LPF, and fc=0.7Hz for the HPF. I guess the bias is to center the analog signal between ground and VA+ (5V).

I'm sure some of the analog mavens here can do better than a S/N+D of better than 105dB, but maybe not... I don't know what the THD would be for this circuit.

Anyway, I'm sure everyone has already read the data sheet...

I've also attached the input circuit TI recommends for the PCM4222, using the OPA1632. Maybe there's even better performing differential opamps out there, I don't know.
 

Attachments

  • AK5394A input fig 9.JPG
    AK5394A input fig 9.JPG
    46.2 KB · Views: 160
  • OPA1632 input for ADC.JPG
    OPA1632 input for ADC.JPG
    49.5 KB · Views: 157
I suggest the first kick at the can would be to build the simpler, single AK5388 mono-design shown in Fig.1 of the app note. It has a simple mux for the output and puts off the fussy FGPA work until later.

It would allow the creation/testing of the analog input stages , clocks and power supplies. The output of the card would be plain vanillia I2S. Theoretically the card should be able to mate with any I2S engine, commercial or open-source.

George