For those who are interested you can grab the document archive and BOM for the SDR-Widget from this page
Yoyodyne Consulting/SDR-Widget
The ADC support electronics are a compromise as it is powered from the USB bus but the performance is acceptable
The SDR-Widget supports some bells and whistles you may want to drop (I2C/quadrature encoder/LCD display)
Regards
George
Yoyodyne Consulting/SDR-Widget
The ADC support electronics are a compromise as it is powered from the USB bus but the performance is acceptable
The SDR-Widget supports some bells and whistles you may want to drop (I2C/quadrature encoder/LCD display)
Regards
George
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,
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:
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
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 $$$.
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
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
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.
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.
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.
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?
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 $7@100. 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
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 $7@100. 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
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
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
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
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.