| Products > Test Equipment |
| A High-Performance Open Source Oscilloscope: development log & future ideas |
| << < (13/71) > >> |
| JohnG:
This is a fantastic bit of work, so I hope it takes off. I can only contribute a couple requests, since this sort of work is way out of my realm. One request would be that if the front end is modular, it would be nice if it were flexible enough to accomodate some more unusual front ends, like a multi-GHz sampling scope or a VNA front end. The latter may not even make sense within the context of the project. Again, really nice work! John |
| Zucca:
Nice feature would be to talk with the scope. It is based again on a Raspi. |
| ogden:
--- Quote from: nctnico on November 17, 2020, 03:31:46 pm ---Still isn't adding USB-C adding on more complexity to an already complex project? --- End quote --- Right. Also USB-C will take time and resources off actual scope work! Those who suggest USB-C could start adapter development right now and share with author so he can copy-paste if he finds it useful. To the *scope* wishlist I would add DDC (digital down converter) with configurable digital IF filter to implement (possibly but not necessarily) realtime spectrum analyzer. For those who wonder why plain FFT is not good enough, answer is: using just FFT you either get frequency resolution or performance, but not both. Calculating gazillion-tap FFT is slow - every user of FFT option of common scopes know. With DDC we downconvert frequency band of interest down to DC (0Hz) to use low order FFT, like 128-1024 taps. Further reading: Tektronix MDO scope info. |
| rhb:
--- Quote from: Someone on November 17, 2020, 09:55:24 pm --- --- Quote from: tom66 on November 17, 2020, 12:12:48 pm --- --- Quote from: Someone on November 16, 2020, 10:16:31 pm --- --- Quote from: tom66 on November 16, 2020, 08:13:55 pm ---Shifting the dots is computationally simple even with sinx/x (which is not yet implemented). It's just offsetting a read pointer and a ROT-64 with an 8-bit multiple, practically perfect FPGA territory. In the present implementation I simply read 0..3 dummy words from the FIFO, then rotate two words to get the last byte offset. --- End quote --- Noting that triggers in modern scopes are aligned more finely than the sample rate (interpolation), with the reconstruction and interpolation methods also dependent on the front end characteristics. Expect the rendering speeds to collapse in a software/GPU approach once you put in that phase alignment and sinc interpolation. --- End quote --- As I understand it, and please DSP gurus do correct me if I am wrong, if the front-end has a fixed response to an impulse (which it should do if designed correctly), and you get a trigger at value X but intend the trigger to be at value Y, then you can calculate the real time offset based on the difference between these samples which can be looked up in a trivial 8-bit LUT (for an 8-bit ADC). It's reasonably likely the LUT would be device-dependent for the best accuracy (as filters would vary slightly in bandwidth) but this could be part of the calibration process and the data burned into the 1-Wire EEPROM or MCU. In any case there is a nice trade-off that happens as the timebase drops: you are processing less and less samples. So, while you might have to do sinx/x interpolation on that data and more complex reconstructions on trigger points to reduce jitter, a sinx/x interpolator will have most of its input data zeroed when doing 8x extrapolation, so the read memory bandwidth falls. I've still yet to decide whether the sinx/x is best done on the FPGA side or on the RasPi - if it's done on the FPGA then you're piping extra samples over the CSI bus which is bandwidth constrained, although not particularly much at the faster timebases, so, it may not be an issue. The FPGA has a really nice DSP fabric we might use for this purpose. I don't think it will be computationally practical to do filtering or phase correction in the digital side on the actual samples. While there are DSP blocks in the Zynq they are limited to an Fmax of around 300MHz which would require a considerably complex multiplexing system to run a filter at the full 1GSa/s. And that would only give you ~60 taps which isn't hugely useful except for a very gentle rolloff. --- End quote --- Not sure the trigger interpolation calculation is a single 8bit lookup when the sample point before and after the trigger could each be any value (restricted by the bandwidth of the front end, so perhaps 1/5 of the full range). Sounds like an area you need to look at much more deeply, as the entire capture needs to be phase shifted somewhere or the trigger will be jittering 1 sample forward/backward when the trigger point lands close to the trigger threshold. Exactly where and how to apply the phase shift is dependent on the scopes architecture. This may not be a significant problem if the acquisition sample rate is always >>> the bandwidth. Similarly if you think a 60 tap filter isn't very useful recall that Lecroy ERES uses 25 taps to obtain its 2 bits of enhancement. P.S. don't restrict the thinking to DSP blocks as 18x18 multipliers, or that they are the only way to implement FIR filters. Similarly while running decimation/filtering at the full ADC rate before storing to acquisition memory makes for a nice architecture concept suited to realtime/fast update rates, its not the only way and keeping all "raw" ADC samples in acquisition memory (Lecroy style) to be plotted later has its own set of benefits and more closely matches your current memory architecture (from what you explained). If memory is your cheap resource then some of the conventional assumptions are thrown out. --- End quote --- Interpolation for sample alignment and display infill are fundamentally different even if the operation is identical. High order analog filters have serious problems with tolerance spreads. So sensibly, the interpolation to align the samples and the correction operator should be combined using data measured in production. The alignment interpolation operators are precomputed, so the lookup is into a table of 8 point operators. Work required is 8 multiply-adds per output sample which is tractable with an FPGA. Concern about running out of fabric led to a unilateral decision by me to include a 7020 version as the footprints are the same but lots more resources. I am still nervous about the 7014 not having sufficient DSP blocks. Interpolation for display can be done in the GPU where the screen update rate limitation provides lots of time and the output series are short. So an FFT interpolator for the display becomes practical. As for all the other features such as spectrum and vector analysis we have discussed that at great length. The To Do list is daunting. Reg |
| tom66:
If anyone hasn't figured it yet, rhb (Reg) is the American contributor to this project - he's been a good advisor/counsel through this whole project |
| Navigation |
| Message Index |
| Next page |
| Previous page |