Re: Low spec 'scope.

On 8/29/2024 11:36 PM, Jasen Betts wrote:

On 2024-08-29, Don Y <blockedofcourse@foo.invalid> wrote:

On 8/29/2024 1:57 AM, Jasen Betts wrote:

On 2024-08-28, Don Y <blockedofcourse@foo.invalid> wrote:

On 8/28/2024 7:47 AM, Martin Brown wrote:

On 28/08/2024 08:39, Liz Tuddenham wrote:

The recent thread on high-end oscilloscopes has reminded me of a project
that I shelved some years ago and might be due for resurrection:  I am
looking for a real-time display about 3" x 4" that can behave as an X-Y
oscilloscope with a bandwidth of about 100 Kc/s; a flat panel would be
ideal.
>
Currently I am using an actual X-Y oscillocsope to monitor the output
from a stereo gramophone cartridge, which allows me to check historic
discs for damage or faulty recording geometry.  The tube is about 14"
long, which means it has to be a standalone shelf unit and I can't build
anything like it into portable equipment.

>
I think that Daqarta software can probably do about what you want using the PC
stereo soundcard to digitise X & Y. 100kHz bandwidth might be pushing it but it
should be fine for audio up to 20kHz.

>
or any other sound card scope software,

>
I think the OP wants a "real-time" X-Y display.  If it is acceptable to
treat this as a two-step process -- acquire data, display -- then
it becomes a lot easier to implement.

 I think few millisecods latency will go unnoticed,

So, you think you can chop the signal at 500Hz and the results won't
matter?

Does it *simultaneously* sample each channel?  Or, toggle between them?

>
It makes an audio recording using commodity PC sound hardware.
https://www.ti.com/product/PCM2900C has 2 ADC channels

>
But, is that true of ALL "sound cards".

 That is not important, avoid unsuitable devices.

The interface to the sound system dictates how the software *can* use
it.  If there is never an expectation that the sampling can occur in lock
step, then the interface won't have provisions for that.
Or, do you expect a specific driver for a specific piece of hardawre
(presumably, the software that Martin mentioned, upthread, doesn't make
those assumptions)

The advantage would be that you could locate the data acquisition
hardware separately from the (COTS) display.

>
It's starting to feel like raspberry pi + LCD display + usb sound card.

>
The OP seems to want to avoid writing any code.  And, to be fair, capturing
two 100KHz signals and pushing them onto a display while ERASING any previous
display content is a bit of a job, especially if you want to truly mimic
a 'scope in X-Y mode (where the display's persistence allows some portion
of "old" traces to remain visible before fading away (with the LCD, the
software would have to perform that function)

 

(think about how you would decide *what* to erase, given that a particular
pixel may have been painted as part of N consecutive cycles -- even if it
is the "oldest" pixel in a time-sorted list)

 store a ring buffer of pixel coordinates and a raster size buffer of
pixel birthdays and then the update process becomes O(1)

The intensity of a particular pixel would have to reflect its age-related
contribution.  E.g., if pixel (X,Y) has been "hit" on the last two cycles,
it should be brighter than if it had been hit on the 500th and 501st cycles
previous.  Removing the 501st (oldest) should have less impact on the
overall brightness.
The overall brightness going forward has to reflect the sum of the aged
"hits" over the past N cycles.

look up the age(th) pixel in the buffer, if the age in the birthday map
is wrong then it has since been overwrittenm, so do nothing, else dim it a little.
 this won't get you anti-aliasing, which is possibly more valuable,
 Maybe there's a way to get both subpixel resolution and a fading effect.
perhaps some sort of palette rotation? does it actually need a
microcontroller? perhaps do the whole thing in an FPGA.

Presumably, you want to refresh the displayed *data* at something close to
the signal frequency (else there is the risk of missing artifacts).
So, you need to store the mapped locations of each of the previous N
10us samples and dynamically weight their ages into the intensity of
the pixel that will *actually* be displayed in that location.
Well suited to a parallel hardware solution -- save for the number of
samples you want to keep in the queue.
The OP likely has a better understanding of the number of samples required
for the artifacts of interest to manifest, given that there are audio (?)
frequency signals being encoded -- does the "problem" manfest more noticeably
at higher signal frequencies?  Or, when the channel difference is greatest?
Or...