There would be a relatively simple method of doubling the real-time(!) sampling rate, WITHOUT ANY CHANGE TO THE SCOPE HARDWARE: Use a T-connector plus a cable with 10ns propagation delay to connect the two channels (CH1 and CH2) together, then attach the probe to the third end of the T connector. I.e.
At 50 MSamples/sec the sample interval is 20ns. The 10ns cable delay means the two channels are effectively interleaved (with 10ns skew between them), so you have one sample every 10ns instead of every 20ns. Now all that is needed is a software change to merge the data from CH1 with the data from CH2 and you have a scope with one channel but at a sample rate of 100 MSamples/sec. Sure, you lost one channel, but the higher sample rate will be beneficial for faster signals, as well as for the spectrum analyzer mode (suddenly that mode can go up to 50 MHz instead of 25 MHz). All that at virtually no cost to the user, and a rather simple software update.
It may be necessary to add 50 Ohm terminations in front of CH1 and CH2 to preserve the analog bandwidth (otherwise the 10ns cable may degrade it too much), but again this could be added externally, without any change to the scope.
A future version of the PCSU1000 could even add this 10ns delay line internally (switched in and out through relays), or offer an interleave mode where the ADCs get strobed 10ns apart (that’s likely a change to the FPGA configuration?) so a user could choose between 2 channels with 50 MSamples/sec max and 1 channel with 100 MSamples/sec max.
Please let me know what you think. I am owning a PCSU1000 (which works great!) and I’d be willing to beta-test the software update (I have the cables and T-connector available), or beta-test a new PCSU1000 version. To me this looks like a very easy way to push the PCSU1000 performance at very low cost.
Thank you for this idea how to double the real time sample rate of the PCSU1000 to 100MS/s. Your idea was to connecting the signal to the both channels of the PCSU1000 and to add a 10ns delay to other channel. This can be done as you suggested by adding a cable with 10ns propagation delay.
Other way, as you suggested is to modify the FPGA.
I made it by inverting the sampling clock of the other channel.
I modified the FPGA file and the main software slightly. I had to remove the slower time/div ranges from this version. There is only 100MS/s sample rate ranges left and the spectrum analyzer of 50MHz.
Adjust the y-position sliders so that there is no difference between the samples from different channels. Use the fastest 0.05us time scale and linear interpolation when doing this adjustment.
Set same Volt/Div setting to both channels.
Maybe a little difficult to use but anyhow this version may be useful in some cases when the 1GS/s sample rate can not be used. (Single shot etc.)
Wow, that was very responsive - thanks a lot! I already downloaded the patched software and tried it out (didn’t have access to my scope before Monday).
The fact that you can just do it by modifying the PC based program means that the FPGA configuration is not stored in an in-system Flash PROM (as I initially assumed), but gets downloaded each time I launch PCLab, correct? That’s good news as it allows for easy changes to the scope firmware. Too bad such things aren’t possible for the scope hardware as well
Here are the results so far:
tried with a fast rising step (true rise time about 2ns as measured by a high-end 20 GHz scope). I can see the step and perform the sequence operations you outline. (I attached both probes to the signal, set to 1:10 to minimize capacitive loading). Signal step size is about 5V (0V to +5V). Scope is set to 1V/div (also tried with 2V/div).
however, the amplifier linearity seems to be a limiting factor. By adjusting the vertical position I can either make the low side (0V, before the step or the high side of the signal (5V, after the step) be flat (which indicates the two channels measure the same voltage), but not both. The repsective other part shows some sample-to-sample ripple (approx. 1/2 division at 1V/div). Maybe that could be remedied (or at least mitigated) with a modified calibration routine?
I tried to calibrate the scope in the modified software, calibration runs but it says it fails. I went back to the original PCLab software and calibrated it there - passes without problems. So probably the FPGA configuration changes mess up the cal routine?
When using the trigger, the waveform on the screen jumps left and right by approx. 1 sample, which maybe indicates the trigger is stressed beyond its limit? I can enable averaging mode (8 or 16 acquisitions) which helps somewhat. But maybe the trigger algorithm could be improved?
With such improvement maybe this could become a special “interleave” mode in the standard PCLab software?
Thank you for your comments about this special 100MHz scope.
As I assumed there may be some difficulties to run it.
It is OK to run the calibration in normal mode. The WinDso.ini holds the calibration parameters for this special scope if in same folder.
You noted also that the gain of both channels must be exactly same. Also probes must be identically adjusted.
The horizontal jumping of the trace is because the triggering is sampled at 50MHz (only one channel used). This causes the +/-10 or 20ns variations in the triggering position. Those are more visible in the 100MS/s mode than in 50MS/s mode.
This was interesting experiment anyhow…
I think there are too many problems to make it as a product.
At least some sort of automatic calibration should be added…
Anyhow this software will be available still about 50 days in the web.
Well, I believe there is still room for software based improvement. I wouldn’t give up on the approach yet. Here are two suggestions to address the issues I’ve found:
As for the triggering, both channels are assumed (make that: required) to see the same signal anyway. So the scope could look at both channels (instead of only channel 1 or only channel 2) and the channel that crosses the threshold first causes the trigger to fire. That way the trigger jitter should get reduced by half. Or - depending on how the trigger is implemented - duplicate the trigger circuitry in the FPGA and trigger the copy from an inverted clock like you did for the samplers.
As for the PCLab GUI, you could then simply remove the option to trigger on CH1 or CH2 and only display “Channel” vs. “External” for the trigger source. (as another smaller improvement to the GUI I’d also remove the Volts/div settings for the second channel or at least force them to be the same as for the first channel). Of course this will not help when triggering on the EXT TRIG input, but it does when triggering on the signal itself. Any possibility to implement this on the experimental version of PCLab? I’d try it out for you the moment it becomes available.
Second, for voltage calibration: I also own your PCGU1000 signal generator. This could be used as an external source for calibration. The user would attach both probes to a single output on the PCGU, which then sweeps the voltage over the full range. The PCLab software could then store either a lookup table or at least a simple gain/offset correction (faster to implement for a quick experiment) for each channel and for each V/div setting. That way the full setup (probes + scope) would get calibrated. Again, I’m offering to test this for you.
By the way, doubling the sample rate on the trigger to 100 Ms/s (by duplicating the trigger circuitry in the FPGA) may be beneficial even for the “normal” PCLab application - at the highest sampling rate, and especially in the equivalent time sampling modes - the trigger jitter is already quite noticable and makes for an unstable waveform on the screen.
Thank you for your comments.
It is good idea indeed to look at both channels for the triggering event! This should reduce the triggering time jitter to half.
I’m sure to implement at least some of these ideas to the next test version of the software after a while…
Indeed should be nice if all the PCSU1000 owners had PCGU1000 generator too. This combination is very nice to control from the software.
Hello would it be possible to add a similar solution for double the memory? I had problem when examine a signal. When I had the complete signal length in the scope the resolution was to bad, and when I had enough resolution I could not fit the whole signal. If you use this kind of method you will double the memory. Or when better is it possible to do like this? When memory on ch1 is full the measure start on ch2 while measure on ch2 it transfer ch1 data to pc and when ch2 memory is full it can start with ch1 again.
Thank you for these nice ideas.
Doubling the memory in single channel use has been considered but due to the big amount of software modifications it has not implemented (yet).
Your other idea of unbroken data acquisition by multiplexing the channels is very interesting too.
I think that some of these ideas may be implemented in the future releases of the software.
I think that you’ll get a single channel version of the software with double RAM (8kB) in a couple of days for testing.
When ready I’ll inform you the download link.
I’d be interested in that update (single channel with twice the record length) as well. Please keep me on the distribution list as well (or post the download link on the forum as you did for the double-sample-rate version).
[quote=“VEL255”]I think that you’ll get a single channel version of the software with double RAM (8kB) in a couple of days for testing.
When ready I’ll inform you the download link.[/quote]
There is 8kB of RAM available in the FPGA of the PCSU1000. Either divided for two channels (4kB/channel) or used for one channel. I’ll inform here when the 8kB single channel version is ready for testing…
Now the single channel version with 8kB of data RAM is ready.
Please download and extract the files to the \Program Files\Velleman\PC-Lab2000SE folder.
Run PCSU1000GU1CH.exe
I noticed the folder has some more files, among them V3.06 interim. What new features does this version include? (100 Msamples/sec? 8kB record on one channel? others?).
The function generator section of the software is modified in the 3.06_interim version.
For more details see the thread: [forum.vellemanprojects.eu/t/wave-sequence/1065/6)
