High Speed Analogue Logger

[embracin]

Hey all.

In short: I need a fast (>100Mhz) micro controller or ADC system.

I've been given an unusual assignment. I need to design a data logging system, capable of getting samples from an ADC at 10Msps (preferably higher) and store it into memory for later analysis. The kicker is that the exact time of these events could be any time during the day. The exact shape of this waveform is what we are trying to capture  and the duration could be >50us. Effectively we are trying to reproduce an oscilloscope with a few minor differences. There may be multiple of these events in a period, and the ability to store them in memory before moving them to storage (sd card or similar) is important.

The ADC is not necessarily the issue, these can be found rather easily. The implementation thereof is a stepping stone to come to later. The issue is to find a micro controller or a development system that can perform these operations fast enough, with enough memory, while maybe performing some processing, to trigger digitally etc.

Personally I have had experience with various micro controllers from Microchip products (everything from 16f to dspic33f), Atmel (arduino) and ST arm processors (particularly STM32F407). The first 2 are not fast enough and the latter may be an option, given my soft spot for the discovery boards after I spent a week setting up the compiler and IDE.

Seeing how I discovered the ST ARM micro controllers in these forums, I was wondering if anyone here knew of boards may meet my needs. If the micro controller has its own fast ADC even better.  Ideally the system should also come with a programmer. The inclusion of device based displays (LCDs) is not important. Power consumption is not vital, but the system may have to operate for long on Pb or LiPo batteries.

I have tried watching tear downs of digital oscilloscopes to try probe and maybe reproduce their operation, but that seems bit more complex than desired and I don't really have the facilities or budget to solder FPGA's. Neither do I need to drive a large display.

There is always the possibility that in my haste, I missed an existing product which may meet these requirements. Budget is an issue. The end system might be scattered around outside or on a roof and as such I can't really put RIGOL scopes with Raspberry Pi's everywhere (although the idea does sound appealing).

Thanks for spending the time to read the story. I know its a drag to read it all, but I feel the more I say in the initial post, the less I have to repeat myself later.

Regards and Thank You.
Jarren

[c4757p]

I don't really have the facilities or budget to solder FPGA's.

You can't solder a TQFP-100? I can do that in my garage... I definitely would recommend an FPGA. You might be able to get it going on a good microcontroller with a heap of effort, but the FPGA will cost about the same and makes all that data-shoving a breeze.

I feel the more I say in the initial post, the less I have to repeat myself later.

You must be new here. 

[digsys]

What "bulk rate" will the data come in at? At bulk 100MHz, there are very few options for memory storage. Flash is out of the question,
dram is messy, so you're left with Battery backed SRAM, but that can get expensive, depending on the PEAK data volume.
Questions would be - @100MHz : total counts in 1mS / 100mS / 1S .. then per hour / day? If it is VERY short bursts with long (many Secs
or minutes) per burst, the approach will be MUCH simpler than sustained bursts - in which case it have to be an FPGA coupled to SRAM,
then piped to Flash or other high speed storage.

[embracin]

You can't solder a TQFP-100? I can do that in my garage... I definitely would recommend an FPGA. You might be able to get it going on a good microcontroller with a heap of effort, but the FPGA will cost about the same and makes all that data-shoving a breeze.

Excuse my mistake, I meant Ball Grid array soldering, typical of higher end devices. Again I trusted the idiot that runs the supply shop  .

What "bulk rate" will the data come in at? At bulk 100MHz, there are very few options for memory storage. Flash is out of the question,
dram is messy, so you're left with Battery backed SRAM, but that can get expensive, depending on the PEAK data volume.
Questions would be - @100MHz : total counts in 1mS / 100mS / 1S .. then per hour / day? If it is VERY short bursts with long (many Secs
or minutes) per burst, the approach will be MUCH simpler than sustained bursts - in which case it have to be an FPGA coupled to SRAM,
then piped to Flash or other high speed storage.

Hopefully it is short bursts of approx 100us, every few seconds at worst case ms. In reality we are not entirely sure. I cannot mention yet the application due to legal leg yanking, but the true timing of this measurement is not truly available. That is why Ideally I want a small amount of digital processing available to be able to change the triggering. The lab demonstration will be short pulses with long delays. The field readings will change the way the system is approached.

[c4757p]

Excuse my mistake, I meant Ball Grid array soldering, typical of higher end devices. Again I trusted the idiot that runs the supply shop  .

There are a lot of FPGAs available in high pin count QFP packages. Annoyingly, there aren't many low pin count ones, though. This isn't really an application that requires a "higher end" FPGA, really any old FPGA will do. This is pretty far short of a full DSO.

Hopefully it is short bursts of approx 100us, every few seconds at worst case ms. In reality we are not entirely sure. I cannot mention yet the application due to legal leg yanking, but the true timing of this measurement is not truly available. That is why Ideally I want a small amount of digital processing available to be able to change the triggering. The lab demonstration will be short pulses with long delays. The field readings will change the way the system is approached.

"Bulk data rate" as in, how fast do the individual bits come in from the ADC? We're trying to figure out what kind of device needs to be at the direct interface to the ADC.

[embracin]

"Bulk data rate" as in, how fast do the individual bits come in from the ADC? We're trying to figure out what kind of device needs to be at the direct interface to the ADC.

Depends on the ADC i can get my hands on. I am not really sure what exactly you are asking. The way I am interpreting it, is if the ADC puts the bits out instantly, or whether it has some form of internal buffer. I have been eyeballing an AD9235 and similair products, which outputs the data is parrallel. My limited understanding thereof is that with 20Msps at 12bits we get a datarate of 240Mbps.

[digsys]

By "bulk rate", I (we) mean - what is the highest #data bytes you'd expect in one contiguous block ie 1KBytes, 10K, 100K, 10MBytes
That's the killer - getting all that bastids into memory FAST. Long ago, in the days of the XT, before FPGAs / EPLDs I had to interface
several very high serial data streams into a PCXT. The trick was to feed each COM DIRECTLY into FIFO SRAM (in the end I made my
own, as they were expensive back then). The awesome thing about FIFOs is - clock in at any damn speed - read out at any speed.
As long as you don't fill it !! With a big enough FIFO, you can use a $1 legless MPU to re-process to more durable / cheaper memory.
You wouldn't even need DMA hardware. All you need to work out NOW is what the "average" amount of data these cheap MPUs
will need to sort.

[embracin]

By "bulk rate", I (we) mean - what is the highest #data bytes you'd expect in one contiguous block ie 1KBytes, 10K, 100K, 10MBytes
That's the killer - getting all that bastids into memory FAST. Long ago, in the days of the XT, before FPGAs / EPLDs I had to interface
several very high serial data streams into a PCXT. The trick was to feed each COM DIRECTLY into FIFO SRAM (in the end I made my
own, as they were expensive back then). The awesome thing about FIFOs is - clock in at any damn speed - read out at any speed.
As long as you don't fill it !! With a big enough FIFO, you can use a $1 legless MPU to re-process to more durable / cheaper memory.
You wouldn't even need DMA hardware. All you need to work out NOW is what the "average" amount of data these cheap MPUs
will need to sort.

Sounds absolutely Brilliant!! I knew I needed some form of buffer. I thought Id use the STM32F407's 100kB of memory as buffer, but FIFO is what I actually have been looking for. I think at 20Msps for about 100us (Worst case) that's 2000 Samples at 2bytes a sample (16bit worst case) thats 4kB (32kbit) a shot. Ideally I would parallel a few so that if an event occurs while pulling out the data I can still capture it. My only problem with a FIFO would be that there may be a delay after the event before the trigger happens. In that case would I rather need the equivalent of a cyclic array? So that after the trigger I can get the pre trigger samples.

Thanks again for your idea.

[digsys]

My only problem with a FIFO would be that there may be a delay after the event before the trigger happens. In that case would I rather
need the equivalent of a cyclic array? So that after the trigger I can get the pre trigger samples.

On a separate project I fed the "data" stream (or Trigger pulses) to parallel counters / timers. That way I could do similar to what you
require. In  my case, I needed to know inter-packet delay times / drop-outs. If there are a LOT of them, a small EPLD/FPGA could work
well here. It's always a trade off between #discrete ICs against - bugger it, let the big fella do all the work :-)

[embracin]

This will be my last reply of the day 

On a separate project I fed the "data" stream (or Trigger pulses) to parallel counters / timers. That way I could do similar to what you
require. In  my case, I needed to know inter-packet delay times / drop-outs. If there are a LOT of them, a small EPLD/FPGA could work
well here. It's always a trade off between #discrete ICs against - bugger it, let the big fella do all the work :-)

I was actually thinking i might use a FIFO for all data (clock it in and out), to keep a running score of the data. and then on trigger pulse data to a secondary FIFO, assuming no delays (which might be optimistic), I should be able to join the two together without significant loss.

I would think that an STM32F4 would be a nice micro, just because of its large capabilities: flash, fast core and I am familiar with it. I found a 128Mbit 75Mhz FIFO, which would mean that the solution would be capable of many future... improvements (and its not much more expensive than the 32kbit one, just below it), an AL460A. I do believe this shall suffice nicely, based upon a quick review of the datasheets.

Thanks again for your help.
 "Give that man a Bells"

On a side note I am looking to expand my experience/repertoire of micro controllers. What would you recommend.

[digsys]

Being a hardware / low level designer (machine code) designer, my current "perfect" IC range is -
www.silabs.com/products/mcu/pages/default.aspx
They have an awesome range of devices, and the mixed signal MPUs make designing a pleasure !!
Only downside (NOT being a fan of 8051 architecture) - Their "messy" register implementation in trying to keep it compatible !
But I got over that eventually :-), the on-board analogue/osc/reset/temp/etc is well worth it. They run at 25-50mips (CISC),
which is also a bonus, BUT there is an extra overhead in swapping bloody Function registers (I got over that too :-) )

Nice FIFO you found ! Almost want to make something to use it :-)

[nctnico]

I'd use a bunch of cheap USB oscilloscopes.

[ptricks]

Have you looked at the RX line of chips from Renesas ?
http://am.renesas.com/products/mpumcu/rx/index.jsp

One of the interesting things about these chips is they can execute instructions and read/write to flash at the same time with no performance loss and they can also include DSP functions.

[marshallh]

Well there are several ways you could solve this problem, with my own fpga background I'd probably use a lowend CycloneIII and some SDRAM and dedicate half it to a constantly updating ring buffer filled with the incoming sample data, then do some basic DSP for event detection and then copy the event from ring to the latter half of ram, then slurp it out using USB or some such.
At these speeds you are going to be having frustrations with MCUs that are simply not designed for this kind of constant dumb high throughput type task. This is bread and butter for an FPGA.

There will be a substantial learning curve, best get yourself a Terasic demo board with ram already on it and make a simple interface PCB to your ADC.

[glatocha]

Did you think about the FIFO memory?

You can burst in the data and then slowly put it to some flash or whatever you need. I just know some FIFOs are made by Texas but for sure another producers also.

[JVR]

Trying to catch some data from a Highveld lightning storm hey?

a Micro *should* be able to to the transfer, but if it was me:

Code: [Select]

ADC->FGPA<->FIFO/MEMORY
       ^
       Micro-> System


[glatocha]

Trying to catch some data from a Highveld lightning storm hey?

a Micro *should* be able to to the transfer, but if it was me:

Code: [Select]

ADC->FGPA<->FIFO/MEMORY
       ^
       Micro-> System


In that case what the fifo for?

I would do ADC -> FIFO -> uC -> MEMORY

add some fast clock to ADC/FIFO and on the FIFO/uC/MEMORY you don't have the time critical anymore

[embracin]

Trying to catch some data from a Highveld lightning storm hey?

a Micro *should* be able to to the transfer, but if it was me:

Code: [Select]

ADC->FGPA<->FIFO/MEMORY
       ^
       Micro-> System


Scary how you figured that one out... I have to do this project for my final year project, and I wanted to do as much of it as I could, without anyone telling me how to do it directly. The measurement is trying to capture the lightning impulse, which may not follow the ideal 1.2/50us curves, so i would like to have some form of over design.

Personally I was thinking along the lines of:

Code: [Select]

ANALOG                   ->          ADC->MICRO->SD CARD
     v                               ^
ANALOG TRIGGER - >DIGITAL LOGIC - >CLOCK


[JVR]

You left enough clues 

By all means, if you need help in up in JHB send me a PM.

considering what you are trying to capture, sample as fast as you can afford, and then post process

[embracin]

Just a quick update and cry for help.

TLDR: I need a ~50MHz time interleaved ADC clock generator.

After much research we have decided that we need to sample at approximately 32Mhz (based on the bandwidth of our sensor) for about 1 second (the maximum duration 95% of lightning strikes)   . The memory requirements thereof are astronomical, requiring 32 MSamples, at, as per project requirements at >12bits (preferably 16bits) per sample, this means an overall memory requirement of at least 512Mbits (64MB) !!!!!  .

At this point any pre-built oscilloscope meeting these specs or similar equipment are far beyond our moderate student budget. In order to achieve these requirements it was deemed economical to time interleave four ADC's, as at most 128Mbits of FIFO can be easily attached to each ADC.

Now the design thereof was going smoothly until I realized that I needed to provide these ADC's with time interleaved clock signals  . I have tried to search for an IC that accomplishes this, however most of these IC's are designed for time interleaving of clocks in the 100Mhz-1Ghz bandwidth (LMK03000, AD9512 etc). As a result they come with a hefty price tag, and in a package that will be near to impossible to to both solder and create a board for, without much more expense.

In short I am wondering if anyone here knows of a rather simple IC or circuit that may achieve this time interleaved signal? 

Thanks for your time.

[nctnico]

Most FPGAs have clock modules which produce 0, 90, 180 and 270 degrees phase shifted clocks. With one of these it should be easy. Another method is to use an FPGA and clock a counter with 128MHz to create the interleaved clocks from there. Again the PLLs inside an FPGA are very usefull tools.

While being at it, you can use an FPGA to multiplex the data into seperate FIFOs. If you dare you could venture into using DDR memory. Its ideal for streaming and achieving hundreds of MB/s is a piece of cake. Yet the design effort can be large so using SRAM may be a quick fix.

[embracin]

Most FPGAs have clock modules which produce 0, 90, 180 and 270 degrees phase shifted clocks. With one of these it should be easy. Another method is to use an FPGA and clock a counter with 128MHz to create the interleaved clocks from there. Again the PLLs inside an FPGA are very usefull tools.

While being at it, you can use an FPGA to multiplex the data into seperate FIFOs. If you dare you could venture into using DDR memory. Its ideal for streaming and achieving hundreds of MB/s is a piece of cake. Yet the design effort can be large so using SRAM may be a quick fix.

Thanks for your advice, again budget and time is a big issue. Hence why I am staying with the FIFOs and STM32F4 design, as I am very familiar with the STM32 platform.

I actually realized what to do, just minutes after posting that query :

Take the 16Mhz clock (A), and divide it by 2, producing a 8Mz signal (B), use simple digital logic to complete the rest.
 

Code: [Select]

Signal 1 = B (0 degrees)
Signal 2 =OR( AND[A, NOT(B)] , AND[NOT(A), B])  (90 degrees)
Signal 3 = NOT(B) (180 degrees)
Signal 4 =OR( AND[A, B] , AND[NOT(A), NOT(B)]) (270 degrees)

This gives four 8Mhz signals, correctly offset as desired with reliable and accurate phase shifts, cheaper and easier than my other alternatives.

[nctnico]

That will result in glitchy clock signals. I suggest you use a CPLD (like the XC9500XL series from Xilinx) to generate the clocks with synchronous logic. Using a CPLD isn't hard. The software is free, the programmer is cheap the development time is low and the CPLD I suggested is available in a PLCC package, runs from 3.3V and is non-volatile (program once, run forever).

[vvanders]

Was going to suggest a CPLD as well. The devboards for Lattice are pretty cheap and the MachXO/XO2 have built in PLLs & FIFO IP, etc. The MachXO2 breakout board is $26 right now direct from Lattice. If you want to step up to their Flash FPGAs the Bravia board is ~$40 and comes with 1mbit of SRAM.

[embracin]

The problem with all those ideas, is availability and time.

The suppliers I am allowed to use( ), don't supply these boards, and I have only 1 week to build a working prototype, so no time for learning a new development system. Also the fact that my current design has about 0.5Gbit of memory for less than R1000~$100 dollars, and I can get the stuff to my computer with a system I am already familiar with is a big decision.

Maybe once these projects are finished (I have to test and calibrate this system), I can get a CPLD and a Cyclone developement board and play with those. Thats how I discovered the STM32F4 family, which is currently my go-to system (as the price here is much cheaper than all the arduino and PIC systems available).

As for the glitchy clocks, I have built a prototype (matching propagation delays of logic systems etc) and found the logic system to be fairly clean and reliable.