I am experiencing some bizarre behavior with a 4227 that I would like to share and see if you can reproduce on your bench:
HW: 4227 ; SDK r_10_5_11; IDE : Labview 2011, using the ExampleRapidBlock as the base program for testing.
Signal: I feed the same 500Hz square pulse (0-5V) on both ChA and ChB with a splitter BNC, with a duty cycle such that the the pulse is at +5V for 3-5 microsec, and 0V the rest of the time within a cycle (2ms minus 3- microsec), (a 50% duty cycle can be used for testing also).
The ExampleRapidBlock vi is set up to with:
pretrig samples: 50
postrig samples: 2000
timebase: 1 ( so 125 MS/s)
Number of Captures: 500
Channel A and B are set to 10V input scale, DC coupled.
Autotrigger time (ms): 10
threshold: 10000 ( so about 1/3 of full range)
Delay : 0
In the PicoScope4000GetRapidBlock.vi I add a tick count vi before the ps4000IsReady loop and another one after the loop to time how long the driver is checking for all the samples to be ready before transfer to the PC.
In all cases: 500 captures of the signal coming in at 500 Hz, I expect about 1 sec to catch all the triggers.
Timebase kept at 1 (125 MS/s):
A ON, B OFF, triggering on A,
--> time A shows ~ 1090ms, so it makes sense.
A OFF, B ON, triggering on B, .
--> time B shows ~ 1900- 2100ms, it does not make sense.
A ON, B ON. triggering on A:
--> time shows ~ 1070ms, as expected.
A ON, B ON. triggering on B:
time shows ~ 1900- 2100ms, it does not make sense either.
Timebase back to 0 (250MS/s):
A ON, B OFF, triggering on A and A OFF, B ON, triggering on B, .
--> time shows ~ 1090ms : good.
Why does the digitizer take longer to acquire my captures on B ?
If the time base is increased (slower sampling), time B get closer to time A (remains consistent)
I tried with a second digitizer, same issue.
PS: to date, I observed the issue on 3x 4227. However, it does not appear to affect 4224 ( I only have one available).