0
\$\begingroup\$

I'm a phd student in aeronautical engineering, and I'm designing a custom sensor device for my research. I've figured out the initial stage of the device, which involves converting the analog signal from my sensor to a digital signal using an ADC. At this stage, I've selected TI's ADS7047 for its compact size, differential input, and high sampling rate (2-3 MSPS). I've attached a very basic diagram of the device and what I am trying to accomplish.

At this stage, I'm trying to learn what to look for in selecting a device to drive the ADC and transmit my data to a wireless receiver. For my application, I am targeting the ability to write and transmit each data point individually, matching the sampling rate of the ADC. At this point, I'm hoping to learn: 1) what type of SoC device would be the best to use for driving the ADC and writing the data to transmit, 2) what parameters or capabilities should I be looking for to achieve the processing speeds that I am targeting (acquire, convert, write, and transmit 2-3 million samples/data points per second), and 3) how can I determine the bit rate required for my application (sending one data point file every 300-500 ns)?

enter image description here

\$\endgroup\$
10
  • 1
    \$\begingroup\$ bandwidth = SPS*bits, plus transport costs. that's really high though, i've not seen anything that can keep up with that rate, maybe a Pi. \$\endgroup\$
    – dandavis
    Dec 23, 2020 at 2:41
  • 1
    \$\begingroup\$ Why is there a separate ADC? Many MCUs can have built-in differential ADC with better specs, so selecting a proper MCU you can skip the ADC to begin with, so in theory you have an XY problem, the problem is not selecting a best MCU for ADC but best tools for the whole job. \$\endgroup\$
    – Justme
    Dec 23, 2020 at 8:14
  • 1
    \$\begingroup\$ How long do you need to collect data? Could you store the data and retrieve it later? \$\endgroup\$
    – Mattman944
    Dec 23, 2020 at 8:21
  • 1
    \$\begingroup\$ @tlfong01 thank you, that guide does look like a great entry point for troubleshooting signal issues! You provide a few extra points that I'll look at for my design beyond the initial recommendations provided in the datasheets. \$\endgroup\$ Dec 23, 2020 at 16:30
  • 1
    \$\begingroup\$ @Mattman944 storage and retrieval is possible, but not guaranteed. The device is meant to be a sacrificial component for measurement during an impact event, so while the circuitry may survive, I can't guarantee that it will. That said, the event duration is rather short. If I work out a precise triggering system, the duration of data collection can be less than 1 ms. \$\endgroup\$ Dec 23, 2020 at 16:34

1 Answer 1

3
\$\begingroup\$

I will start by saying that this looks like a better fit for a low end FPGA (like an Artix-7 or Spartan-7) rather than an MCU. But in any case I will address which kinds of MCUs might be appropriate first.

The ADS7047 uses a SPI bus. The datasheet says that you can achieve 3Msps with a SPI clock of 60Mhz.

https://www.ti.com/lit/gpn/ads7047

  1. what type of SoC device would be the best to use for driving the ADC and writing the data to transmit

For many lower end MCUs (like PIC or AVR, PIC32 or AVR32) the SPI clock is limited to 1/4th the system clock frequency. To get a 60MHz SPI clock you would need to use a 240MHz oscillator. But those kind of parts don't support using an internal clock at that speed. A parallel output (rather than SPI) ADC would be better suited if you plan to use a lower end MCU. But don't use a lower end MCU because you won't be able to process the samples anyways.

Going yet more powerful would be something like an ARM cortex M7 or A9 MCU or a Power PC MCU. They might support SPI clocks close to 60MHz. But servicing 3 million SPI transfers per second is going to consume A LOT (if not most) of the CPU time.

There are a few of options to work around this.

  • Pick a dual core part. One core manages the ADC, the other core does other stuff.
  • Pick a part with an IO co-processor. The MCP5674 has an ETPU IO processor that can be used to manage the transfers. Also some of the freescale HCS12 processors have an XGATE coprocessor that might be used if you can find a part that is fast enough.
  • Pick a part that lets you manage the SPI transfers via the DMA controller.
  • Pick a part that is really fast (like several hundred MIPS).
  1. what parameters or capabilities should I be looking for to achieve the processing speeds that I am targeting (acquire, convert, write, and transmit 2-3 million samples/data points per second)

As a starting point assume that you will need several tens of clock cycles to process each sample. In that case you probably need something that can execute on the order of 100 million instructions per second, but if you an get something faster do it because its really easy to run out of processing power if you are not careful. A Cortex M7, Cortex A9, or Power PC can achieve this type of processing.

If you CAN use an FPGA, that would probably be a better fit for this kind of high rate data processing. A $35 XC7A35T Artix-7 FPGA would probably work. There would be almost no risk of running out of processing power in this type of application.

  1. how can I determine the bit rate required for my application (sending one data point file every 300-500 ns)?

For the wireless (including overhead) you are looking at sending at least 50Mbps. Most of the low-end wireless stuff is out in that case. You would need to use 802.11g or higher to get those kind of bit rates.

But keep in mind that wireless transmissions have to share spectrum with others (which reduces the available throughput), and messages sometimes get lost due to interference. If you need the data in real-time without much loss then wireless might not be a good option. If you can live with some latency, but no data loss then wireless can work but you are faced with the possibility of having a large buffer at the transmitter to hold data while you correct transmission errors.

If you can, it would be better to use a hard-wired data link (fiber optic, 10/100 Ethernet, a few RS485 lines, etc).

\$\endgroup\$
4
  • \$\begingroup\$ Would you be more specific why this is more a job for an FPGA? And why handling 3 Msps of ADC data takes a lot of CPU time, as at that speeds DMA is anyway used whether SPI or whatever interface is used. And many MCUs already have built-in ADCs that support DMA. \$\endgroup\$
    – Justme
    Dec 23, 2020 at 8:18
  • \$\begingroup\$ @user4574 Thank you very much for your detailed response! To clarify, a parallel output ADC is one that has a separate output pin for each bit, correct? I've also seen recommendations for using an MCU with an integrated ADC. How would that impact the required processing power of the MCU? \$\endgroup\$ Dec 23, 2020 at 16:58
  • \$\begingroup\$ @scpaulson42 Yes a parallel output ADC has a separate data line for each bit. You can retrieve the entire sample using one read of an IO port rather than one bit at a time. I recently did a project using a parallel ADC storing 8-bit samples at 2Msps using an AVR MCU running at 20MHz and there was processing power to spare (but not enough to run something like wireless also). \$\endgroup\$
    – user4574
    Dec 23, 2020 at 17:14
  • \$\begingroup\$ @scpaulson42 Using an integrated ADC offers advantages in that reading the samples out of a register is usually quick and there may be greater integration with the DMA or other features in the MCU. There are some MCUs that offer internal ADCs with sample rates at 2~3Msps but most of them don't. Internal ADCs also tend to have worse specifications than external ones. Also like you said, the ADC specs are typically not listed in the product tables when selecting an MCU so it becomes hard to find one with the right specs. \$\endgroup\$
    – user4574
    Dec 23, 2020 at 17:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.