| Products > Test Equipment |
| PicoScope 2000 |
| << < (9/12) > >> |
| MrW0lf:
Ok, after fighting with some tech nuances more-less optimal procedure has emerged: For whole concept to work need signal gen with two channels that can do phase synced sweep over freq range of interest. My SDG2000X can do 0...120MHz so covers 100MHz Pico 2408B range well. Choice of cabling (probes, 50 ohm system, etc) depends on DUT. In this example investigate FM notch filter 88-108MHz, so 50 ohm system. Disclaimer: AFAIK not all best practices of RF testing followed :P 1) Need to calibrate channels so ChA & ChB would absolutely match. Levels could be different due to signal gen, scope, cabling etc. ChA would serve as reference later, DUT on ChB. So need calibrate ChB. - set up sweep: 10ms, 80...120MHz, -11dBm, load 50ohm, Trig Out=ON, lock Ch1-Ch2 - connect Gen-Ch1=>Scope-ChA, Gen-Ch2=>Scope-ChB, Gen-Trig=>Scope-ChD - create math function eval(B)=max(B)/max(A), range 0...2 - set timebase to 1 ms/, memory to 2kS, trigger on ChD. Do not pay attention to aliasing, soon there will be ok line for eval(B). - if intrested may add Min, Max auto-measurements, in my case it can be seen that correction ranges from 1.031 to 1.076. - save eval(B) math trace as reference channel - turn off math trace eval(B) - create math trace cal(B)=B/{eval(B) (2)} (ref channel name may vary) - disable visual of ChB, can now observe that sweep level completely identical on ChA vs cal(B), if interested can confirm with auto-measurements 2) Plot magnitude trace. - create math channel dBm(B-A)=LowPass((10+20*log(max(abs(B/{eval(B) (2)})))) - (10+20*log(max(abs(A))));32000) - may add auto-measurements to confirm Min/Max which should be very near 0dBm - if magnitude trace gets jerky time to time tweak trigger level on ChD, because there needs to be some jitter for max() traces to converge as continuous line - connect DUT between Gen-Ch2 and Scope-ChB - plot is instantly generated, tweak smooth/coarse with math channel LowPass setting to match personal taste - auto measurements show Min/Max etc, may investigate with cursors and so on - if all ok set dBm(B-A) as ref trace and disable actual math channel 3) Plot unsigned phase trace. - create math channel graph(phase(A;B))=LowPass(average(duty(((((atan(1/tan(pi*(A/10000)))/pi)+(A/10000))*-((atan(1/tan(pi*(B/10000)))/pi)+(B/10000))) + 0.25))/0.555555555);10000) - phase trace may look as expected because formula is quite tolerant of subsampling, however if "strange phenomenon" present go conventional and increase memory depth to level when there is no subsampling. In this case 3MS does the trick. - now have quite clear unsigned phase plot 4) Plot frequency sweep trace. - with subsampling etc freq() math function does not work so better stick to linear sweeps and plot graph with simple math function _freq=norm(T)*40000000+80000000. Almost all set. Now tweak wfm scaling a bit for best fit in viewport and observe good approximation to real spectrum analyzer plot in magnitudes. Only bottom end suffers because switching ranges would be quite a hassle. If phase trace should, but does not reach 0-180º extremums may want to raise LowPass frequency on phase trace (slight problem on my screenshot). 5) If interested confirm phase manually for single freq: - set all active traces as refs, disable math channels - disable sweep, set freq to 110MHz - disable ChD (no need for sweep trigger anymore) - create math channel phase(A;B)=((((atan(1/tan(pi*(A/10000)))/pi)+(A/10000))*-((atan(1/tan(pi*(B/10000)))/pi)+(B/10000)))+ 0.25)/0.00277 (will convert phase to PWM, so can apply DC average measurement on it). - reading is ~117º, close enough 6) If still in doubt visual check on different timebase with 20 GSa/s ETS & cursors. Described above of course lack convenience of real bode plotter software but with simple filters etc where can "decipher" phase data can go far above scope nominal bw. Would have gone further but SDG2000X limited to 120MHz. Alternate for this crude magnitude plotting is of course FFT but on Picos it is limited at scope nominal bw, which in my scope case is 100MHz, so fully characterizing of specific filter with FFT is impossible. |
| MrW0lf:
To demonstrate most severe conditions that MCFRA can handle and still give some meaningful output did run 0-100MHz sweep on coax stub filter from previous tests using my old PicoScope 2205 (25MHz analog): Despite setting eval(B)=average(max(B)/max(A)) cal trace is still mess near 100MHz, but since it substantially improves things <50MHz will use it: Since scope has only 16k of memory all it can do is severely undersample at this timebase, but overall picture readable: Did leave visual of cal(B) enabled to demonstrate on what this poor puppy has to chew on... |
| MrW0lf:
Reflections on some experiments related to bode plotting and TDR. Got nice little 50ps pulse gen from Leo Bodnar: http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=124&products_id=295 First experiments sparked some discussion here: https://www.eevblog.com/forum/projects/yet-another-fast-edge-pulse-generator/msg1322739/#msg1322739 Since it turned into yet another PicoScope 6 software hacking session better continue here... First good, as usual it is hardware: According to this analog bw is 144MHz (0.35/2.427ns) Next bad: Wanted to try fft(derivative(signal)) for bw estimation TDR style, since after all 2408B can do 20GSa/s ETS. This failed because software bugs handicap most functionality related to math channels gone thru time related processing (integrals, derivatives, time shift, filters, ...). Also FFT does not work in ETS mode at all, which is by design :-// At least it can export to MatLab format so had some go at it there, see original discussion. Since it is painfully obvious what kind of bug breaks fft(derivative(signal)) functionality I hacked around it with DIY derivative function: green - A: raw trace cyan - derivative(A): built in diff on A brown - average(A[0.000000001]): A time advanced by 1 sample point, averaged yellow - average(A[0.000000001]-A)/0.000000001: DIY diff on A, averaged This kind of DIY derivative is only one that seems to allow for FFT under specific condition: RTS trace gone thru Sinc interpolation. With that in mind can do some limited experiments. For these ideally need averaging of some kind on FFT to obtain reference trace. Averaging is there but another bug will set as ref not averaged trace, but current raw, which is useless. To work around that I use following setup: Signal generator (SDG2000X) set to generate 1.1MHz 0dBm square. Arb/DDS mode for sharp rise. Same signal on both channels. Ch1=>coax=>T_with_2m_coax_stub_filter=>50ohm_passthru=>ChA Ch2=>coax=>50ohm_passthru=>ChC Interpolation switching off at >2000 samples limits effort only to 512 FFT bins but it's real deal! Only when zooming in can see that detail is very limited: Now for cross check tried another method, set signal gen to output noise and cranked FFT up to 128k bins. Big picture exactly same. Only detail much better. So what can conclude? Failure at basic Q&A has handicapped software with quite powerful architecture. If you would like to unlock full power of your PicoScope suggest to demand following: - fix math on time-manipulated channels, all need to do is handle boundary conditions properly when sample count <> nominal, scope should be able to pass integral(derivative(signal)) test. - allow FFT on ETS - unlock FFT from scope official bandwith. On 2408B it is limited to 100MHz, while actual analog bw is ~140MHz, and usable bw way higher - fix creating ref traces from processed channels (averaged etc) - allow Sinc on recordsets >2kPts |
| MrW0lf:
Founds these helper tools for bode plotting type activity, maybe useful to someone: PicoMeasure http://pmz.gtkc.net/ It will chew thru CLI ouput of PS6 software: --- Code: ---picoscope.com /a Measurements.CSV? --- End code --- and feed into Graphtool http://graphtool.gtkc.net/ |
| MrW0lf:
In PS6 max number of stats you can have is 1000. Clearly not enough for long time observation of measurements. Did write "infinite measurements" Python script that more-less fixes this. It uses this CLI command: --- Code: ---PicoScope.com /a Measurements.CSV? --- End code --- It returns human-readable garbage which must be parsed. Since the command will run at around 2Hz max on my PC it does not make sense to use Value of measurement, instead I use Average and tune PS6 count to get more-less reasonable chain reaction. CLI command is wrapped in bat because it did not work directly for some reason. Just unpack script and bat. Run script. Resize CLI window to nice size. In beginning of script there is self-explanatory config block: --- Code: ---# CONTROL # [Esc] - exit # [Space] - reset # CONFIG rate = 1 # x=Loop_time_in_s; 0=Loop_rate_disabled avg_source = 5 # 2=Value; 5=Average round_input = 15 # decimal places round_output = 6 # decimal places round_hz = 1 # decimal places show_header = True pad_lines = 4 # pad display to X lines to avoid resizing window --- End code --- It should be trivial to expand this for writing long term measurements data to CSV, perhaps better type of post-averaging etc. Should it turn out nice please post your version here also. |
| Navigation |
| Message Index |
| Next page |
| Previous page |