General > General Technical Chat
Why do you think there aren't more "good" USB oscilloscopes?
TomKatt:
--- Quote from: bdunham7 on February 16, 2023, 09:32:06 pm ---The fastest USB3 links aren't even remotely close to matching the internal data transfer rates in an oscilloscope. You can remote the display and control interface, but if you offload the actual captures to the PC for processing, it won't happen as quickly. This is a limitation of PicoScopes, although not a problem in most cases. You simply can't dump data at the full capture rate to the PC memory, you have to make a capture and then wait for it to be transmitted.
--- End quote ---
I agree the triggering and processing has to be done at the hardware level. I guess what I'm thinking of is more the ability to manipulate the captured information, whether that be longer signal time analysis or improving the MSO LA capabilities by going beyond analysis of what is stored on a single screen capture.
I see now that the 'computer side' of stand alone devices (screen etc) are likely commodity items and there is likely not much of an economic advantage to eliminating those elements and using laptop gear instead.
So, it all comes down to mobility and additional analysis I guess. To that end, a tablet-like more pc oriented device would serve equally well... It wouldn't necessarily need to be USB / laptop. So it becomes more of a niche market product, explaining why I guess there aren't more 'good' ones.
Nominal Animal:
--- Quote from: PlainName on February 17, 2023, 10:13:25 am ---There is no way a display is updating at 40,000Hz.
--- End quote ---
It doesn't have to. Each display frame contains the acquisitions –– to simplify, one curve per acquisition –– since the last display update.
At 75 Hz update rate, 40k acquisitions per second would be about 533 acquisitions per frame, or 533 curves of the sampled data per frame.
At 10k acquisitions per second, it'd be 133 curves of the sampled data per frame. Is that visible? I dunno, not enough practical experience to say.
--- Quote from: peter-h on February 17, 2023, 11:05:23 am ---Those apps are very slow.
--- End quote ---
It is extremely difficult to make good products that cross niches. Here, the problem is that as a product, you need software running on arbitrary random machines efficiently, and you need hardware that interfaces nicely with random machines, and you need the combination to work well.
You essentially need a good hardware team that can provide the sampled data to a well-defined (in advance) interface (USB or Ethernet using TCP or UDP stack), and a software team that is more oriented towards games than typical commercial office programs.
To make the combination work well, you need management that can interact effectively with both teams. Do you have any idea how rare such management is?
The standard commercial solution (not talking about USB scopes only here, but more generally any similar appliance) seems to be that either one part is bought from a different company, or the software is made by the equivalent of a bunch of high-schoolers; regardless of what the appliance is.
PlainName:
--- Quote from: Nominal Animal on February 17, 2023, 11:16:26 am ---
--- Quote from: PlainName on February 17, 2023, 10:13:25 am ---There is no way a display is updating at 40,000Hz.
--- End quote ---
It doesn't have to. Each display frame contains the acquisitions –– to simplify, one curve per acquisition –– since the last display update.
At 75 Hz update rate, 40k acquisitions per second would be about 533 acquisitions per frame, or 533 curves of the sampled data per frame.
At 10k acquisitions per second, it'd be 133 curves of the sampled data per frame. Is that visible? I dunno, not enough practical experience to say.
--- End quote ---
Well, quite. The display rate shouldn't affect the acquisition rate, so having a bigger screen shouldn't mean a reduction of captures from, for instance, 40k/s to 10k/s. Which was the point.
2N3055:
--- Quote from: PlainName on February 17, 2023, 11:22:12 am ---
--- Quote from: Nominal Animal on February 17, 2023, 11:16:26 am ---
--- Quote from: PlainName on February 17, 2023, 10:13:25 am ---There is no way a display is updating at 40,000Hz.
--- End quote ---
It doesn't have to. Each display frame contains the acquisitions –– to simplify, one curve per acquisition –– since the last display update.
At 75 Hz update rate, 40k acquisitions per second would be about 533 acquisitions per frame, or 533 curves of the sampled data per frame.
At 10k acquisitions per second, it'd be 133 curves of the sampled data per frame. Is that visible? I dunno, not enough practical experience to say.
--- End quote ---
Well, quite. The display rate shouldn't affect the acquisition rate, so having a bigger screen shouldn't mean a reduction of captures from, for instance, 40k/s to 10k/s. Which was the point.
--- End quote ---
Point is that screen with 2x resolution has 4x of pixels and that display engine has to crunch 4x more data for same result.
Which means 4x more capable infrastructure for that. Not impossible but not free...
Nominal Animal:
--- Quote from: PlainName on February 17, 2023, 11:22:12 am ---The display rate shouldn't affect the acquisition rate, so having a bigger screen shouldn't mean a reduction of captures from, for instance, 40k/s to 10k/s. Which was the point.
--- End quote ---
Oops. I missed the point, as usual. Sorry :-[
I can understand the reduction of captures if each capture sequence is at most as long as is shown on the screen, but otherwise I'd expect the captured signal (and the acquisition buffer) be wider than the screen.
That leads to an interesting question: Should an USB scope always provide the sample sequences, or would it be better if it sometimes returned the combined acquisition buffer instead?
There are many forms such a buffer could take, but the simplest form I can think of has 256 8-bit bins per time unit, forming a 256-bin histogram of the acquired curves at that point in time relative to the trigger. The computer could request updates only on a specific section (a screenful), and when paused, request the entire buffer (up to whatever time depth is available), or the data from the latest acquisition. (That assumes an 8-bit ADC, by the way. For an N-bit ADC, I'd expect 2N samples per time unit.)
Typical data rate could be for example 1920 time units 25 times each second, i.e. 12,288,000 bytes per second.
More generally, given W time units, F times per second, N-bit ADC, we have W×F×2N bytes per second at 8-bit bins (up to 255×F acquisitions per second), and 2×W×F×2N bytes per second for 16-bit bins (up to 65535×F acquisitions per second).
While one might think that this contains the display information, it is actually just the histogram of the acquisitions; i.e. full information (except order of acquisitions), time-wise limited to W time units relative to trigger point. It's also quite feasible to implement on any hardware that has the memory bandwidth to store both the latest acquisition and access one entry of the 2N-byte or -word histogram for that time point. Maximum sample depth or W does not affect the work needed to be done, assuming double buffering, except for the zeroing of the memory after it has been sent (to prepare for it to be useable as the histogram buffer).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version