# Continuously log data from an oscilloscope

I have a pin which is being toggled every 100ms by an MCU. I need to plot a graph which consists of the variation from the desired interval . That is the number of times it moved away and was toggled for 101ms or 98 ms and so on. I tried to do it with a scope but the memory seems to be limited. I can capture a maximum of 50000 lines as csv . Even if I reduce the sampling rate , it is nowhere close to the 4 hours of data I need to capture. What kind of an instrument should I be looking for? Is there any easy way to achieve this?

• Does your scope have a GPIB interface or similar that you can use to stream the data to a workstation? – whatsisname Jul 17 '14 at 15:53
• It has a GPIB interface but I am unsure as to whether the GPIB interface supports continuous data logging. The scope I am using is home.agilent.com/en/pd-1945059-pn-DSOX2012A/… – user2578666 Jul 17 '14 at 15:55
• The Open Logic Analyser from Dangerous Prototypes would be ideal for this. – John U Jul 17 '14 at 15:55
• For 4 hours? Does it have that kind of memory? – user2578666 Jul 17 '14 at 15:58
• Few instruments have hours of memory, but your PC probably does. Get yourself a basic CY68013A eval board / "logic analyzer" and use the open-source sigrok package to stream to disk, then analyze in your language of choice. Actually at your timing rate you could consider using the sound card recoding at 44.1 KHz and look for the peaks of transients (the input circuit will A/C couple the signal). – Chris Stratton Jul 17 '14 at 15:58

Streaming data constantly to a computer rather than using one long acquisition will most likely be easier to implement and makes use of a computers large available storage. Because you only need digital data a usb logic analyzer is probably the cheapest and easiest option.

Couple of options come to mind:

1. Depending on your oscilloscope you should be able to stream data to a pc to analyze quickly enough so that your 50000 sample buffer never fills up. I would contact your scope manufacturer and read through the manual to see if this is possible and if so the best way to implement it.

2. Use a data acquisition card from national instruments or some other company to continually acquire and analyze data. The benefit here is that you can use a program such as Labview to make set up and testing a bit easier if you don't have much programming experience. Make use of the digital logic pins, no need to use analog acquisition.

3. Use a usb logic analyzer. Cheap. Easy to implement. There might even be one out there that comes with software which can do the analysis you need out of the box.

• The Saleae logic analyzer is great for this. It has no storage in itself, it only streams to PC. This allows for very long capture times. – markrages Jul 17 '14 at 16:13

You're describing a histogram of the pulse widths. Both the timing and the counting would be well within the capabilities of a modest micro-controller, either a ready-built experimenters board, or build it on a bread-board. Taking an interrupt at 10 Hz would barely use the capabilities of a \$5 chip. In 4 hours, a 10Hz pulse train would fire 144000 times and if it's a rock-solid 10Hz, your histo will count only one bin which would need to be able to accumulate that big a number. That's bigger than a 16-bit int (you'd need 18 bits) but easily handled by using long ints (32 bits). Figure the timing resolution (bin size) and maximum departure 1.0ms you need to quatify and decide how many bins you need. You'll need 4x that number of bytes to hold the histo. Assuming you need ~20 bins, you're still well within the resources of a modest micro-controller.

It isn't an off-the-shelf solution if that's what you need, but it will be way less money than buying a bench instrument. Lots more fun, too! (Unless you need the data yesterday...)

I'm assuming you have a computer with a USB port at your disposal for programming the chip, as well as for collecting the data.

Update:

You'd arrange for the signal to interrupt the MCU whenever it changes. You'd keep one of the timers running continuously a timer at 1KHz (for 1ms resolution). On every rising edge, your ISR would read and save the timer. On every falling edge, it would read the timer again and subtract the saved value from it to get the pulse width. Assign that value to one of your histogram counters and increment the counter.

Something like histo[width_ms]++; will histograph the actual pulse widths in msec (as opposed to the deviation from 100 ms]. Plotting a histo of deviation only requires relabeling the t-axis.

Obviously, pick the timer resolution & bin sizes that make sense for your application. I chose 1ms buckets from 0ms to [as many as you need], representing -100ms to +?? of deviation.

• I am still a little lost as to how the departure from 100ms can be calculated. Could you please explain this a little more? How do I use the interrupt to determine the deviation from 100ms? – user2578666 Jul 18 '14 at 1:36