I find things still a bit unclear.
In rapid block mode the software does one data record, then it needs some time to recover (dead time) and then it listens again and waits for the next trigger.
I understand that the function doesn't include the dead time. But what is with the time the device is listening? Is this included?
I noticed that with a constant pretrigger value set, I don't get a constant from that function but different values. Thus, the time offset it gives has to include more than only the pretrigger which is set.
I'm working with a 6404B and I am highly relying on getting the absolute or relative trigger times somehow.
Hello!
Sorry to resurrect this but it is the right topic.
I also want to add how much of an improvement would be if at least 3000 and 6000 series would have support in Picoscope software to show relative timing between captured segments (normal and rapid mode).
For multiple segment protocol captures, to know relative timing between trigger events is very important.
Also, this would be gold to add to DeepMeasure, so you would have right timing for all data across multiple segments (trigger events)..
Please, I vote for this to be added if at all possible...
Best regards,
Sinisa
P.S. Is it common practice for all posts to have to be approved before displaying ?
Also a little bumped here
We just got two 2208Bs as I thought the Offset would provide what I now know it doesn't, after reading through threads for quite a while
The dilemma is, that all I had before was a call to get system ticks (which isn't accurate at all but at least something) and now (with rapid block mode), I don't even have that
Please pardon my frustration and maybe I am just missing something else here. The product is great and the features are all in all really amazing. I am not sure why the .Net examples are in such a state, but as a developer, I'm aware that's very subjective