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:Acquisition:pretrig samples: 50postrig samples: 2000timebase: 1 ( so 125 MS/s)oversample: 1Number of Captures: 500

Channel A and B are set to 10V input scale, DC coupled.

Trigger Settings:Autotrigger time (ms): 10threshold: 10000 ( so about 1/3 of full range)direction: risingDelay : 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.

Test:In all cases: 500 captures of the signal coming in at 500 Hz, I expect about 1 sec to catch all the triggers.

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.

Questions: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.

Insights ? ThxL.

PS: to date, I observed the issue on 3x 4227. However, it does not appear to affect 4224 ( I only have one available).