It would in the grand scheme of things be rather easy to "just add ram" but that's not how the product lines work for oscilloscopes. It's a bit like asking "Why does Intel price their high-end chips so high? It's not like the silicon is that much more expensive or yields that differ so much that they're 500% more expensive? And the consumer chips don't even support all the features that their Xeon's do!"
And you're right, it's a digital signal, and in the normal world you would just use a logical analyzer and do it like you said. But this is for educational purposes and seeing the same tool and the actual edges is a great and clear example. That's not to say that oscilloscopes aren't useful for debugging digital signals. After all, seeing the exact glitch might help in some cases.
So yeah, basically it's a combination of product differentiation and not the entirely right tool for the job.
There is absolutely no reason you can't just add more RAM (and a memory controller), or even add user upgradeable memory. If the big players don't do it, a newcomer will and they'll fall further behind the curve.
There is no technical barrier that prevents an oscilloscope manufacturer from adding a DRAM controller to their designs, either via an IC or as an IP core in their main FPGA.
The cost would be relatively low, too, and long traces are extremely useful especially for beginners.
Market forces will work to make this a reality.
Doesn't have an on-board DRAM controller, but I did look into the feasibility of it early on. In the end, I decided it was easier to just use the memory of the attached PC. Can record 10s of continuous data without dropping a single sample.
It's probably more of a bandwidth issue than a memory issue. USB 2.0 runs at 480 Mbit/s, so if the oscilloscope can decode that, it would have to be able to output/store at least that much in terms of bandwidth. A USB keyboard would never hit that type of bandwidth, but presumably a buyer of such expensive oscilloscope would expect the feature to work every time, rather than only in best case scenarios.
>And note that (since it's a digital signal) you don't have to sample evenly; you can also record the timepoints of the edges.
Depending on the signal characteristics this can actually be worse. eg. if it switches very rapidly you'd probably be better off storing the reading as PCM or something, because the timestamps (which are presumably nanosecond level) would take more space to record than the raw sample reading (a few bits at most).
Yeah, but you can use multiple banks and write in a round-robin fashion.
> Depending on the signal characteristics this can actually be worse.
Of course, that was only an example. You should probably do something like runlength encoding.
In any case, the USB protocol is much slower than modern hardware can handle, so certainly doable.
A cheap logic analyzer, like DSLogic, would probably work much better for the specific use case.
And note that (since it's a digital signal) you don't have to sample evenly; you can also record the timepoints of the edges.