PicoScope 7 Software
Available on Windows, Mac and Linux
I agree. That does seem to be a contradiction to my theory.
That is odd. I can tell you that 6.14.54 does work for PS2204A on my Windows 10 machine. I still have a Windows 7 laptop, where I could try that out to see if I can replicate it too.
The release notes for 0.7.3b say that the correct SDK is 10.7.20.192, but if you can't find that one later ones will probably work fine. Let me know what you see and we can go from there.kaimex wrote: ↑Wed Jan 05, 2022 11:11 am4. Does your FRA4... version 0.7.3b require the PicoSDK_32_10.6.13.97 (~75 MB) or the present PicoSDK_32_10.7.21.227 (~115 MB) ?
Presently I have the ...97 installed (expanded to ~164 MB !). This was not yet the case when I tried the 0.7.3b version. Should I test, whether it still crashes with this SDK present ?
At 0.1 Hz, 16 cycles will take about 160 seconds to capture the data. If you want to see a status that communicates that to you, turn on “Sample Processing Diagnostics”
The main reason for this is that this use case begins to stretch the dynamic range of the scope. I don’t know what you have the stimulus amplitude set to, but if it were for example 2 Vpp (the default), a 70 dB attenuation will put you at 0.632 mVpp. With 8-bit sampling for a 100 mV range (+/- 50 mV), that’s only 1.62 ADC counts peak to peak. And that’s not even considering the ENOB due to noise. So, there are a couple things you can do to combat this:kaimex wrote: ↑Wed Jan 05, 2022 3:27 pmLooks mostly ok, only the attenuation beyond 1 kHz i.e. below -70 dB shows more irregularity than one would like to see. May be that for such reasons I had increased "Minimum cycles captured" from 16 to 28 many months ago (but not yet after this new installation).
If you want a fixed smaller capture duration, you should use Noise Reject mode. It will keep bandwidth (which is the exact inverse of capture/record length) fixed. To take your example above: 4 cycles at 0.1 Hz = 40 seconds, so set bandwidth to 1/40 = 0.025 Hz. To stay within the memory of the scope, you’ll also want to set the timebase to 21 (47.7 Hz). Just to be safe, set the minimum cycles captured to 4. The limitation here is that you’ll want to stay below the Nyquist frequency of 23.8 Hz for the stimulus.kaimex wrote: ↑Wed Jan 05, 2022 3:27 pmAt least it leads to the new question, whether it could be possible to make "Minimum cycles captured" dependent on the frequency, or, in other words, limit the time spent for that such that e.g. for 0.1 Hz it does not do more than 4 cycles. This would speed up the measurement for the "first" steps considerably.
As you can tell from the discussion above, minimum start frequency does still depend on minimum cycles captured. You don’t see the effects in your example because you’re still above the minimum start frequency. For 16 cycles it’s 0.0536562 Hz and for 28 cycles, it’s 0.0897074 Hz.
Sorry if it seems I sent you on a wild goose chase here. Now that I’m more aware you’re interested in overall speed, we can discuss tradeoffs. Here are the basics:kaimex wrote: ↑Thu Jan 06, 2022 12:48 pm2. "noise reject mode" with the parameters you proposed. In contrast to my expectation, this was not faster. It took 36:50 min. It proceeded faster than measurement (1) for the frequencies below 1 Hz, but took much more time for each measurement above (presumably) 1Hz.
The main issue here is that the sampling rate required to achieve narrow bandwidth with the scope’s limited memory also limits the upper stimulus frequency. As I noted above: “The limitation here is that you’ll want to stay below the Nyquist frequency of 23.8 Hz for the stimulus.”kaimex wrote: ↑Thu Jan 06, 2022 12:48 pmThe result looks similar to the first only up to ~600 Hz, apart from higher errors at 50 Hz, 100Hz (150?), i.e. multiples of the mains frequency. Above 600 Hz the results are too wrong to be useful.
So, with this parameter set, measurement 2 provides no advantage, its result is actually worse.
Unfortunately that won’t work until the next release of the application. It’s because the code still must see all the DLLs (*.lib and *.h don’t matter)kaimex wrote: ↑Thu Jan 06, 2022 12:48 pmI was thinking, whether it could possibly suffice to put all ps2000a*.lib & ps2000a*.dll from C:\Programs(x86)\Pico Technology\SDK\lib into the C:\Programs(x86)\FRA$PicoScope\Lib to get your program working without the SDK.
Would it also require the ps2000a*.h files ?
I was wondering the same
As noted above, I filed an issue against this and have since found the root cause. It’s pretty straightforward, so it should be fixed in next release.
That's correct.
That seems like a good idea. To be honest, the main reason auto-ranging is so slow is that it’s not very sophisticated (e.g. only steps one range at a time). I have an issue logged to improve it. While I’m doing that I can explore your idea to cut stimulus cycles to 1 during auto-ranging.
Applying a window isn't so critical in the FRA App because the Goertzel algorithm allows me to capture a whole number of stimulus cycles. The same doesn't apply to random noise, but this can often be combated with processing gain by increasing samples.
If I understand you correctly, you are correct. As described above, you can get away with slower sampling here which (assuming a fixed memory size) narrows the bandwidth.
Hello,