interfacing 8 channels ADC with micro

[el00]

Hello, I need to interface a high end 8 channels ADC to a microprocessor or microcontroller.
The candidates are ADS1278, CS5368, AD7768, AK5558VN.
I know how to handle all the part related to the analog, power etc. I would like to interface with something that can handle the data, stream them into a TCP or UDP stream, and optionally store into some non-volatile memory. Sample rate should be between 100k and 200k, so ideally 192k.
The only think that I would like to avoid is using FPGA.
Using a microcontroller is very difficult, because you need to handle a large amount of data with limited resources.
Therefore, I think the best is to use some microprocessor that can run linux. However, it seems that only the last one is supported, which is fine, but in the end the difficult part is to design a PCB with RAM.
Having the system working in hardware is the final goal because I know someone who can do the software and the linux kernel fine tuning, but I need to give to him a working device, I cannot ask him to do the debugging, and I don't want him to start from scratch but for example having a 2 channels driver and changing it to 8 channels is fine.

Do you know if there is any module or breakout that contains a microcontroller + RAM with connections on some kind of connector so that I can design the rest of the PCB with the ADC?
Or, if there is any project on the web to start similar project? Thank you

 

[KlausST]

Hi,

It all depends on your requirements.

First and maybe simplest approach: Use an 8Ch audio system. I guess there are ready to buy 8 channel systems.
Audio broadcast via ethernet is rather common, too.


But if you are focussed on
* DC performance
* lossless (compression) transfer
* repeat on erronous frames
* real time processing
* low / constant delay
* care for low ethernet bandwidth (high traffic by other devices)
* or ....

Then you may expect problems.

*****
I often see that one claims to need 24 bits. But indeed a CS5368 with -105dB THD+N isn´t much better than a good 16 bit ADC. And to get -105dB you need extremely clean supplies, clean and stabel VRef, low noise digital communication, low noise analog filter and/or amplifiers. Since it uses VA as voltage reference, means you need to be very carful and use extremely low drift VA_Supply. Every noise on this supply will be seen in the digital data. If you are not very careful with this you get down to 10 bit performance or worse.

32 bit resolution is rediculous, a pure marketing phrase.

Klaus

 

[el00]

Hi,

[...]
Klaus

Klaus, thank you for your reply. I never mentioned 32 bit in fact, I know very well that they are useless. However, between 16 and 24 bits, I have enough experience in analog design to take advantage from the difference, and I have already designed systems with 24 bits that go beyond the limits of a 16 bits where you cannot get rid of the quantization noise which is 76uV.
That said, I am interested in making my own board for geometry purposes mainly. I cannot fit a commercial board in my system.
I know very well how to design silent power supply, a silent acquisition module and how to decouple the analog board from the digital world to reduce noise. Where I don't have enough experience is around interfacing high speed digital like RAM, that's why I would prefer to use a pre-made module to mount on top a custom board.
This is why I was asking for a sample design. Buying an existing module is not a workable solution. But thank you anyway.

 

[danadakk]

PSOC .....

Whats onchip, multiple copies in many instances, 20 bit DelSig,
onboard mux up to 32 inputs, precisions Vref....DSP.....SAR

Need diff channels, simple change to onboard mux. More channels, not issue.

CORRECTION, ignore this post, at 20 bits sample rate way too slow for 192K SPS target.


Regards, Dana.

 

[KlausST]

Hi,

You mentioned AK5558 ...it's datasheet states it's a 32bits ADC.
It sounds you are upset by me mentioning the 32bit. I surely did not mean to offend you ... rather the marketing guys.
And I gave feedback on technical problems and not about you personally.

So your question is focussed on the RAM ... but I see you gave informations about ADCs ...and no technical informations about the RAM, type, size, interface, microcontroller and/or PLD...
Also you don't give any of the missing informations (see post#2). I can not decide them for you.

I indeed don't know what information you are after.

So I can just work with what I have ... and do some basic timing math:
192kSmpl/s x 3 bytes x 8 channels .. is just a bit more than 4.5Mbytes/s. If you have a SRAM with 8 bit bus, then this means a cycle time of more than 200ns. This is not considered a fast RAM. Even slow SRAMs with parallel bus should be able to handle it.

You say microcontroller is difficult ... but then you try to use a Linux system.
Generally any OS needs processing power. This means if you run your sampling code with Linux it will be slower and more timing critical than without Linux.

Your task is some "digital signal processing", thus maybe a DSP (digital signal processor) is what you need.

Klaus

 

[el00]

Klaus, nothing personal. I did not feel offended.
I was only trying to clarify that the focus of the post was not about what ADC to adopt, but about how to interface it in order to get a data stream. In any case the data must be handled in 32-bit chunks, both with 24 and 32 bits.

The main objective is to stream out the data, and possibly to have a local copy on a solid state memory. Some RAM is required for buffering, but since UDP is acceptable, and re-transmission is not required, there is no such a high demand for large of fast RAM. Buffering should be kept at minimum.
I think I will opt for some SoM or CoM that I can plug on a custom motherboard, where I will take care of the analog part and the connectors.
Linux is ok, the power consumption of a small embedded computer is acceptable.
My main constraint is noise (I can handle it by designing the analog part) and geometry. That's why I need a custom motherboard, but I can accept a pluggable module on top.
Thanks.

 

[FvM]

You don't want programmable logic (FPGA) and probably neither a PCB full of discrete logic ICs, so you are stuck with uC that are fast enough to handle the data stream, e.g. ARM processor with DMA features or DSP.

 

[el00]

You don't want programmable logic (FPGA) and probably neither a PCB full of discrete logic ICs, so you are stuck with uC that are fast enough to handle the data stream, e.g. ARM processor with DMA features or DSP.

ok, but why not CoM's (Computer on Module)?