Path: ...!feeds.phibee-telecom.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Don Y <blockedofcourse@foo.invalid>
Newsgroups: sci.electronics.design
Subject: Re: Low spec 'scope.
Date: Fri, 30 Aug 2024 00:32:32 -0700
Organization: A noiseless patient Spider
Lines: 103
Message-ID: <varsip$dbfe$1@dont-email.me>
References: <1qyzrl3.ocj6lm4e4yaN%liz@poppyrecords.invalid.invalid>
 <vandb0$3gr7i$1@dont-email.me> <vanfv4$3hajc$1@dont-email.me>
 <vapd5n$19tlv$1@gonzo.revmaps.no-ip.org> <vaqebj$2lnn$1@dont-email.me>
 <varp8n$1bcop$1@gonzo.revmaps.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Aug 2024 09:32:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="abd3e25f7ccb4ae2d2d1b094a7f46280";
	logging-data="437742"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX193whGbryrlNelcDHNBBR26"
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Cancel-Lock: sha1:w7FAXC8QqeYNQzucrGY5zsDyeYI=
In-Reply-To: <varp8n$1bcop$1@gonzo.revmaps.no-ip.org>
Content-Language: en-US
Bytes: 6279

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...