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.

[Jeroen3]

You do know the stm32f407 has 3 separate SAR ADC conversion blocks?
You can synchronously interleave them, and you van use parallel memory.

[embracin]

You do know the stm32f407 has 3 separate SAR ADC conversion blocks?
You can synchronously interleave them, and you van use parallel memory.

Yes I have had much fun with them. But their sample rate (max 8.2MSps after a bit of over clocking) is too low for this application. I need a minimum of 10Mhz memory and a second record time.

As way of an update, the project start date is approaching, and I am running into supply problems due to the copious amount of red tape my university has imposed  . The FIFO memory I want is out of stock, and I am having trouble finding anything with a similar enough memory to price ratio. As a result I am re-evaluating the FPGA and SDRAM alternative. I like it from the outset as I can get an 256Mbit SDRAM for about $4 where the 128Mbit FIFO was $36. The only thing I need now is an FPGA. After watching Dave's videos on FPGA's and searching the web, I have determined there may be a significant learning curve. Naturally I want to start with a development kit, but I have no idea where to start, what I need, what the FPGA needs/has etc and have limited time to get stuff going .

Long story short, I need some help choosing an appropriate FPGA development board I can get for under $100 in South Africa. If I can find a viable alternative, I may change the basic design, but I need help with the design. The supplier I use is: http://za.rs-online.com/. The best I can find for my price range is an:

• Altera MAX V CPLD Development Kit (yes, its not an FPGA)
• iCEblink40-LP1K Evaluation Kit
• ispMACH 4000ZE Pico Developmen

I have looked at the Cyclone IV DE0-Nano, but its out of stock at my local supplier and I am hesitant to import stuff. Any FPGA that I get needs to be able to interface to a 12bit parrallel output ADC and 1 or more SDRAMs (eyeing the A43L4616AV-7F from AMIC) at 50Mhz at most. It must also interact with a STM32F4 (serially or parallel) preferably or write to SD CARD. Power consumption is not vital, but lower is always better. It needs to be relatively easy to learn, and come with a programmer.

What would you suggest?

[nctnico]

I think its a very good idea to run the memory at 50MHz to avoid timing issues. You'd still need to use timing constraints on the FPGA though. IMHO the hardest part of the design is to get the SDRAM memory interface going. I'd look for a readily available SDRAM controller implementation and use the FPGA it was developed for. You probably end up with Xilinx or Altera 

[Marco]

dram is messy

DRAM is messy, but there are a large number of ARM modules and boards which come with DRAM.

[marshallh]

Go for the DE0-Nano. Why?

1. Signaltap.

This allows you to see in realtime what your code is doing, how it is interacting with external devices, and turn weeks of pain of suffering into a few minutes of insight and resolution.

You can't simulate everything. And with those boards you listed, you (as a fpga newcomer) will be completely blind as a bat, stabbing around in the dark because you will not be able to write 100% HDL the first time.

Running sdram at 100mhz is easy peasy, but you will want a scope to make sure your clock is offset correctly (i.e. the external sdram fed clock is -70 phase shifted). Someone's probably already figured that out for the DE0-nano and has the number somewhere. It's a ballpark value, no need to be precise.

The FPGA also has internal block ram that you will need to utilize as a small local FIFO so that you can work around intermittent occurences like RAM autorefresh (you cant defer forever), bank changing, etc. SDRAM is not terribly complex but it has timing gotcha's that you need to know about before trying to use it.

[nctnico]

Go for the DE0-Nano. Why?

1. Signaltap.

This allows you to see in realtime what your code is doing, how it is interacting with external devices, and turn weeks of pain of suffering into a few minutes of insight and resolution.

It is a powerful solution but not the only one. In my FPGA designs I have 8 to 16 'debug' pins connected to a header.  I put important signals into a debug multiplexer which drives the debug pins. With a logic analyser I can easely see what the FPGA is doing. The multiplexer is controlled by a microcontroller which writes the proper settings in the FPGA. In most cases I just leave the debug feature in the design. When the design needs to be debugged later on its just a matter of hooking up the logic analyser and tell the microcontroller which signals should be output.

[Marco]

Is it really worth all this effort?

I'd research which one of the many ARM processors with development boards has the ability to do high speed DMA with GPIO and attach it to a ADC1610 demo board and handle everything else in software ... at least for an initial prototype.

These ARM boards are only 50$, is this really going to be made in enough volume to justify so much time to whittle that down by using programmable glue logic and SRAM buffers with interleaved ADCs? (If that even whittles it down to begin with, might end up costing more.)

[nctnico]

This seems to be a graduation project where the requirements where carefully designed to steer students towards using an FPGA  O0

[embracin]

Is it really worth all this effort?

I'd research which one of the many ARM processors with development boards has the ability to do high speed DMA with GPIO and attach it to a ADC1610 demo board and handle everything else in software ... at least for an initial prototype.

These ARM boards are only 50$, is this really going to be made in enough volume to justify so much time to whittle that down by using programmable glue logic and SRAM buffers with interleaved ADCs? (If that even whittles it down to begin with, might end up costing more.)

In reality the real question is this: can I pick up these cheap ARM boards here? More often than not no, or not at that price. I would love to use my STM32F4 Discovery board to do all the processing (it is the backup plan however), but if you read the earlier posts, you will notice the monumental memory requirement.

In reality the requirements of this project was just to design the sensor. I researched existing designs and found the design to be rather trivial. The supervisor realised this in the preliminary report and gave me free reign on the project. There was a list of requirements and of all my wacky ideas, this one met the criteria, so here I am.

[Marco]

More often than not no, or not at that price. I would love to use my STM32F4 Discovery board to do all the processing

I was talking more about ARM microprocessor boards, which generally come with plenty of DDR2.

Some of the Freescale microcontrollers boards also come with DDR2 BTW.

[dciliske]

Reading through this thread, it seems that the ideal setup is a high power ARM M-series, or a low power ARM A-series/PowerPC processor module is what you would be looking for (150-400MHz core speed), with a dedicated external memory bus, and 64-256MB of RAM. You can then use the processor to generate your sample clock(s), toggling their hardware timer pins. You'd then want to map the individual ADCs to the memory mapped regions associated with each external chip select, DMA the ADC's result to a internal SRAM buffer which then gets DMAed to the main RAM buffer. Then when the sample is complete, you can simply record to flash/SD card/transmit over a high speed comlink (Ethernet or RS485 come to mind).

That said, I might be a little biased on this, since I'm primarily a software guy (but I have written a program to do DMA driven ADC readings from the processor's internal ADC).

-Dan

[embracin]

Hi all,

Wrapping up the project now  , as far as the proof of concept goes, and thought I'd come here to thank everyone for their suggestions and ideas.

Thought while I was at it I'd share some images of the results obtained. I used this system at 4MSps to sample a change in waveform from a university signal generator. From a 1kHz sine to a 1kHz trianglewaveform. I have 6 zoom levels, each 10x the previous.  I also have a comparison of the system I made to a Rigol Scope on the same input. My system is the waveform on the left.

Again thank you all for your help and assistance

Regards
Jarren