Oscilloscope time base

Question

I am working on a personal project to make an remote oscilloscope using a PIC32 with wifi module for Android phones.

So far I have did a lot of things, like connecting the wifi module of the PIC32 to android also developing the base software for android.

I am now at a step to get ADC values from PIC32 and display them on the android. I am not sure how can I make this to work like a real scope.

For example, in the software I have set up a timer that depnding on user choice, can read the ADC value from the pic in time intervals of say 1 , 0.5, 0.1 and 0.01 seconds. So lets say the user has selected a TimeBase of 1 second, then the program will request the ADC value on 1 second intervals and connects this data points on the graph to form a wave signal. Is this same as what happening in real scopes?

I don't have a function generator or a real scope in my hands to check this out!

This is the user interface of the software I wrote for android:

So basically my question is, how should I treat the reading process of values out of the PIC32? Should I just stick to the timer in Java, or I should read as much as values possible and draw them on the screen? How should I handle this?!

Answer 1

A oscilloscope plots voltage as a function of time, so your display is reasonable as you show it. However, the term "time base" is meaningless to indicate the X axis scale. What you want is "s/div" (or ms/div or µs/div). This is independent of the sample rate, although there is little point using more than a few pixels per sample.

The sample times you mention are very slow for ordinary oscilloscopes. Some signals will be reasonably visible at those rates, but most things you encounter will not be.

I would probably figure out what the fastest sample rate is that you can support, then always sample at that rate. If the application indicates it does not need samples that fast, then you can merge multiple samples into one before sending over the network. In that case you don't want to do traditional decimation, which seeks to eliminate frequencies that alias. Instead, for each data point send the min and max A/D samples covered by that data point. Each data point should then be shown to vertically cover that min/max range. If the user selects a slow sample rate and a faster signal is being sampled but it is still within the capability of the A/D and the underlying fast sample rate, then the display will be a horizontal bar with vertical width showing the signal peaks. That is a much better display than something that aliases.

Answer 2

Controlling The ADC

As a general approach, I would have the controlling app tell the PIC32 what the sample rate to use. So, for example, you select a time interval of 0.1 seconds, and the PIC32 now samples 10 times a second. The PIC32 could stream samples instantly or bucket them in smaller time increments, like every 3 seconds, etc. Having the application request every single sample will be fraught with unnecessary latency, IMO.

I'd probably do something like: send sample values over UDP with a timestamp of when they were taken. Asynchronous transmission so my controlling app doesn't freak out if the link is crappy and it gives me enough info to bucket my data on the controlling app for drawing.

Drawing The Signal

This mainly depends on your time division. You need to keep enough samples in memory to draw the whole time span of the graph. However, the refresh rate is up to you. You could simply store the latest values in a buffer, then when its time to refresh the graph, append them to the buffer of values to be shown, remove all values that are now older than the newest sample minus the time span of the graph.

So, simply: if your graph has ten 1 second divisions, and your latest sample has a timestamp of 37 seconds, you only want to show samples where the timestamp is greater than (37 - 10) = 27 seconds.

There's also optimizations that can be done like capping the number of values you keep per time division to limit memory usage and drawing samples that will get anti-aliased anyways.

Answer 3

It is triggering problem

Answer: For start choose manual trigger (button) and you will complete project easy.

Longer explanation for next phase, when you decide to have a real trigger: It is non trivial part of any oscilloscope, both for digital and analog scopes. It is especially more difficult for digital scopes because sampling clock can not be trained to phase of input signal. Consider most common use cases: user wants to couple trigger with AC, DC, trigger by front or fall, pulse or dip, with some set level, or manually, or on digital signature, or in sync with mains AC or in sync with TV broadcast, etc. It is not small feat.

So to cope with it, each use case must be considered and should have a separate solution. You basically asking to describe decades of patented knowledge (pehaps legally outdated).

What is good about contemporary parts, is that you can choose a 1st class solutions using FGPA, fixed point numerics, level/time interpolation, splines, subsample geometry, fast dual port memory on FPGA itself and implement statistical sample baskets, window comparators, sub clock timestamps and digital phosphor kind of solution. It sounds a bit monstrous, but that what many could consider an unltimate trigger. Anything less than FPGA, like pure software solution, will be very limited either in speed or have high phase noise.