Products > Test Equipment

A High-Performance Open Source Oscilloscope: development log & future ideas

<< < (8/71) > >>

Fungus:

--- Quote from: nctnico on November 16, 2020, 08:34:06 pm ---Personally I don't have a real need for high waveform update rates.

--- End quote ---

I don't recall any discussions here about waveforms/sec, waveform record/playback, etc.

I remember a lot of heated discussions about things like FFT and serial decoders.

Fungus:

--- Quote from: dougg on November 17, 2020, 12:54:57 am ---A suggestion: replace the barrel connector (for power I assume) and the USB type A receptacle with 2 USB-C female receptacles. Both USB-C connectors should support PD (power delivery) allowing up to 20 Volts @ 5 Amps to be sunk through either connector. If the power draw is <= 45 Watts then a product like the Morphie USB-C 3XL battery could be used to make the 'scope portable.

--- End quote ---

(Seen from another perspective)

You mentioned adding a battery to this but that means:
a) Extra design work
b) A lot of charging circuitry on the PCB
c) Adding a battery compartmentrr/connector
c) A lot of safety concerns
d) Higher price
e) Bigger size/extra weight

Making it work with suitably rated power banks makes a lot more sense.

james_s:
The circuitry required to manage a battery pack would be absolutely trivial compared to what has already been achieved here. This is a well developed area, every laptop for the last 15 years at least has mastered the handling of a li-ion battery pack.

For what it's worth, I have not been impressed with USB-C, my work laptop has it and I have to use dongles for everything. The cables are more fragile and more expensive than USB-3, the standard is still a mess after all this time as IMO it tries to be everything to everybody and the result is just too complex. I have never been a fan of using USB for power delivery, a dedicated DC power jack is much nicer.

2N3055:

--- Quote from: tom66 on November 16, 2020, 08:13:55 pm ---
--- Quote from: nctnico on November 16, 2020, 07:35:36 pm ---IMHO you are at a cross road where you either choose for implementing a high update rate but poor analysis features and few people being able to work on it (coding HDL) versus a lower update rate and having lots of analysis features with many people being able to work on it (using OpenCL or even Python extensions). Another advantage of a software / GPU architecture is that you can update to higher performance hardware as well by simply taking the software to a different platform. Think about the NVidia Jetson / Xavier modules for example. A Jetson TX2 module with 128Gflops of GPU performance starts at $400. More GPU power automatically translates to a higher update rate. This is also how the Lecroy software works; look at how Lecroy's Wavepro oscilloscopes work and how a better CPU and GPU drastically improve the performance.

--- End quote ---

I agree, although there's no reason you can't do both;  I had always intended for the waveform data to be read out by the main application software in a different pipeline to that of the render pipeline.  In a very early prototype, I did that by changing the Virtual Channel ID of the data set, so you could set up two simultaneous receiving engines.

What this means is though the render engine might be complex HDL you'll still be able to read linear wave data in any instance - I'd like for instance this to interface well with Numpy arrays and Python slices as well as a fast C API for reading the data. 

But it would be good to ask.  Do people really, genuinely benefit from 100kwaves/sec?  I have regarded intensity grading as a "must have" so the product absolutely will have that, but is 30kwaves/sec "good enough" for almost all uses, that potential users would not notice the difference?  I have access to a Keysight DSOX2012A right now, and I wouldn't say the intensity grading function is that much more useful that my Rigol DS1074Z despite the Keysight scope having an on-paper spec of ~8x that of the Rigol.
 
Certainly, a more useful function would (in my mind) be the rolling history function combined with >900Mpts of sample memory so you can go back up to ~90 seconds in time to see what the scope was showing at that moment and I find the Rigol's ~24Mpt memory far more useful than the ~100kpt memory of the Keysight.

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

To get discussion back to the track, let me chime in on some questions here.

For the purposes of nice intensity/colour graded waveform display, having very high display rate is diminishing returns game. Basically, if you look at, let's say, 10 MHz AM modulated with 100 Hz. You will need few thousand WFMs/s to make it smooth, so display will not have moire effect. And also, if you are watching something interactively, it will be faster than human eye and to us full real time.

I consider rettriger time important, but could live with 20-30 us rettriger time (30-50kWfms/s), if sequence mode would be much faster, on the level of 1-2 us. In that mode no data processing is performed and  that should be reachable. Picoscopes are like that. They also capture full data in a buffer, but send fast screen updates of decimated data for display, and full data delayed.

There are many scopes, even cheap ones, that do great job of interactive instrument. What would be groundbreaking is open source analytical scope.

tom66:
Why would I use USB-C?

- Power adapters are more expensive and less common
- The connector is more fragile and expensive
- I don't need the data connection back (who needs their widget to talk to their power supply?)
- I need to support a wider range of voltages e.g. 5V to 20V input which complicates the power converter design  (present supported range is 7V - 15V)

The plan for the power supply of the next generation product was to have everything sitting at VBAT (3.4V ~ 4.2V) and all DC-DC converters running off that.  It's within the range that a buck/LDO stage can work to give a 3.2V rail (good enough for 3.3V rated devices) and a boost stage can provide 5V.

Now, I was going to design it so that if you connected a 5V source it could charge the battery, so a simple USB type A to barrel jack cable can be supplied.  That would be inexpensive enough because we still have a buck input stage for single-cell Li-Ion charging (I'm keen to avoid multi-cell designs)  but at a maximum 'safe' limit of 5W from such a source, I doubt the scope could run without slowly discharging its battery.

When charging the battery this device could pull up to 45W (36W charging + 9W application) - that's roughly a 1C charge rate for a 10000mAh cell

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod