I need to be able to detect, though Visual Basic software, when a trigger has been received by the DSO (PCSU1000). Response to a similar request, posted Dec 2006, stated that such a feature would be included in the next DLL update. Has this been implemented? If so, how can I get the software?
Sorry, I didn’t find the post Dec 2006 you referred to.
Anyhow, now there is added DataReady function to the latest version of the DSOLink.DLL. This function can be used to check if there is fresh data available from the oscilloscope. It indicates also when the triggering occurred.
You may download the full DLL package for the PCSU1000 pcsu1000_dll_package.zip with user manuals and examples from the Velleman downloads site.
For more details see also the thread:
forum.velleman.be/viewtopic.php? … 7880e3ab95
Hi,
I’m trying to use the PCSU1000 in an application to record the sound transit time through various materials.
For this I must know the time of arrival of a wavetrain at Ch1 or Ch2 but also the trigger onset time.
There is no problem if I use one ‘Ch#’ as trigger source and the other as receiver; I can then calculate the time difference of the two arrivals.
But, when using ‘Ext’ as trigger, I cannot find out when the triggering occurs in either Ch1 or 2.
In looking at relevant posts, I saw that with 25MS/s sampling rate the triggering should be detected at about sample 1020-1030. How could I estimate this for other rates, for example at 2.5-12.5kS/s, which is the s.rate I am interested in?
Moreover, in experimenting with the 25kS/s rate, I see the trigger reference index on the X-axis to be at sample 1025 (by default), while the relevant wavetrain first arrivals at Ch1/2 where at about sample 750-760 and the trigger should be at about 730-740 (that is, the time difference should be about 0.4ms, or 10-15 samples, since the distance between the impact source and the receivers was only about 1.0m and the speed of sound through the material is about 2500m/s).
On the other hand, I notice an ‘anomalous peak’ in the data right before the first arrival on Ch1, but since similar peaks appear elsewhere in the data, I cannot judge this as a safe indication of the trigger event.
I would be grateful to receive your advise with the trigger detection issue.
Happy New Year!
lazzy
Further to my last post, please note that I use a vibration sensor (accelerometer) as the triggering switch, attached to a small hammer; hence when the impact occurs, the sensor sends an electrical ‘signal’ to the scope.
Could the voltage of this signal be important for the recording and detection of the triggering event?
Thanks in advance!
Assuming a buffer (dataBuf[]) defined as a 0-based array of 32-bit integers loaded by ReadCHx() function, the triggering point is always at dataBuf[1027], in either channel, regardless of timebase settings, or use of an external trigger.
This is index 1024 of the 0-4095 samples, or the 1025th sample.
If your “arrival” event is being recorded before the 1025th sample (I.e. pre what the PCSU1000 thinks was the trigger), then the trigger event would appear to be either significantly delayed, either mechanically or electrically, or is being mishandled by the scope.
I have not used the PCSU1000 for any single trace triggered events, however I can set something up with a pulse generator and see what I can see…
I just ran some quick tests of the PCSU1000 using a single double pulse from a Systron-Donner 100-C pulse generator, with pulse widths of 20us to 100us, and delays between pulses of 20us to 400us, and had no problem consistently triggering on the first pulse (the waveform displaying the 2nd pulse trailing the trigger of course).
I did find some triggering issues when the pulse width became a fraction the inter-sample period, this is to expected of course–for example the 'scope could not trigger consistently when the sample rate was 25MHz (40us between samples) and the pulse width was 200us or less.
What is the nature of the trigger signal from the vibration sensor, have you examined just that with the 'scope, particularly its amplitude relative to the “arrival” signal.
The PCSU1000’s channels are sampled simultaneously, so you could feed the trigger signal, properly scaled to CH2 and record the “arrival” sensor’s signal, also properly scaled, on CH1. The trigger point will always be at dataBuf[1027] in both channels’ data.
cliffyk,
thanks for your interest and sorry for the delayed reply!
as you correctly point out, one way is to feed the trigger via ch1 and receiver(data) via ch2; in this manner, one can compare the two signals and find out the ch2 signal ‘arrival’
regarding the ‘ext’ trigger:
the scope is triggering at the first pulse of the received signal, which is correct as a principle for the scope’s function, but is not what I would be interested in.
trying to rephrase my intention:
i need to be able to know the time-difference between the -ext- triggering first pulse and the first pulse from a sensor in either ch1 or ch2, which is physically located at a specified distance from the 'trigger ’ device (which is a small hammer with a vibration sensor attached to it).
is this possible, in taking into account the scope’s abilities?
regarding the nature of the trigger signal:
single-pulse, attenuating quickly within 1-2 periods, max amplitude about 2/3 of the respective receiver’s max signal.
I could send a ‘txt’ DSO file if you would be interested in looking at the relevant waveforms.
looking fwd to your reply
regards
lazzy
lazzy,
I would indeed be interested in looking at the waveform, I am always interested in seeing something new.
As to your project, as I understand you wish to “ping” one end of your sample via a hammer fall (and use that event as the trigger), and then capture and display the arrival of that mechanically transmitted ping at the other end of the sample material using a second sensor.
Can you not feed the hammer fall event into the EXT trigger, and capture the arrival sensor’s output on channel 1 or 2? Here are some simulations of doing this that I generated using a Ballantine 6130A time mark generator, in these traces CH1 is the time mark and CH2 is a 1.0ms trigger pulse that precedes the time mark by 0.5ms.
This is using CH2 as the trigger source:
This is using EXT as the trigger source:
As you can see the trigger point remains the same
As the trigger point will always be at sample 1024 in the data file, calculating the time from the trigger to the arrival of the “ping” at the other end of the test material is easy. First, find the point in the CH1 (ping arrival sensor) data where the amplitude rises, then subtract 1024 from that sample’s index to get the number of samples between the trigger and arrival events, then multiply the number of samples by the time period between samples.
Using the data collected in my simulated environment the process looks like this:
Depending on the actual waveform of the ping arrival you may want/need to develop a suitable algorithm to decide when, how many samples, after the arrival ping is first sensed you will tag as the actual event sample.
cliffyk
thanks for the reply and example;
indeed, if this is the case like in your simulation, it is straightforward to calculate the time ‘delay’ at the receiver.
but in my recordings things are slightly different; thus I would like to send/upload the dso file with the data for you to examine and comment.
please let me know how to send/upload the dso file along with a separate text file with comments on the data.
regards
lazzy
I’m also interested to see your results.
You can use this e-mail to send the files: (email address removed)
[quote=“lazzy”]cliffyk
thanks for the reply and example;
indeed, if this is the case like in your simulation, it is straightforward to calculate the time ‘delay’ at the receiver.
but in my recordings things are slightly different; thus I would like to send/upload the dso file with the data for you to examine and comment.
please let me know how to send/upload the dso file along with a separate text file with comments on the data.
regards
lazzy[/quote]
lazzy,
I can be reached at cliffyk@paladinmicro.com
-cliff-
cliffyk
Sorry to see just today the contents of the topic and discover that I had proposed to send some data for inspection, regarding the triggering of pcsu1000!..
Could I send the data to your email-address?
tx, lazzy
[quote=“lazzy”]cliffyk
Sorry to see just today the contents of the topic and discover that I had proposed to send some data for inspection, regarding the triggering of pcsu1000!..
Could I send the data to your email-address?
tx, lazzy[/quote]
Sure…
-cliff-
cliffyk
I have sent some DSO files to your email address above for your comments on using the trigger on the Ext channel of PCSU1000.
tx
lazzy
When the trigger is connected to the ‘Ext’ channel, does the trigger point shown in the time-voltage diagram reflect the trigger time of the external trigger? Or not?
I ask this, because when trying to use a trigger fed to the Ext channel, with the ‘Single’ recording mode, the recorded signal on Ch1 (or Ch2) does not appear at the same time at every trigger source activation -despite triggering and recording parameters are the same for every try-, but at different times (earlier or later), with respect to the trigger point shown on the diagram. It seems that the scope, despite being in ‘Ext trig’ mode, is still triggered by the signal recorded in Ch1 (or Ch2). Could this be a software bug? Or am I missing something?
Please advise.
lazzy
Regarding my last post, I understand that whether the signal source is connected to Ch1/Ch2 or Ext channels, the trigger point always corresponds to the instant the incoming signal in either Ch1 or Ch2 crosses a certain threshold level.
My question is: in case an Ext trigger is used, could the tigger point correspond to the instant the trigger source is activated, allowing for the recording in either channels 1 or 2 to begin at this point and not at the point the signal crosses the threshold level at those channels?
If this is already the case with the scope hardware and software, could there be a bug in the software or a defect in my scope, that results in a trigger point incompatible with the recording signal when using the Ext trigger?
Please advise.
Lazzy,
I must first report that I suffered a stroke in May that has left me not quite as sharp as I was; in fact most of my test equipment has been sold off as I am no longer able to make use of it. That said however I did look at your data and offer the follwing comments:
The tests I did way back when use fast rising pulses to simulate both the hammer blow and “ping”, I believe that the more complex real world waveforms, the somewhat crude nature of the PCSU1000 external trigger input circuitry and the basic nature of the instrument.
It is a wonderful device however we must keep in mind that at its core is just a single–very well programmed but also very busy–FPGA. Without knowning more about its internal workings I can only speculate; my suspicion is that we are asking too much of the instrument to expect its polling of the external trigger input to be especially precise.
cliffyk
Sorry to hear that!
I, too, feel that the scope is quite fine and one of the best in the market for its price.
As I figured it out, the problem with using an external trigger seems to be as such:
despite the signal source is connected to the Ext channel, any resulting signal is recorded only when a threshold is crossed in either Ch1 or Ch2, whereas the trigger point shown in the diagram is not related to the Ext channel (please correct me if I am wrong with this)
My proposal to Velleman would then be the following, regarding the scope’s software:
in the ‘Single’ mode, to handle the Ext channel as an extra recording channel (such as Ch1/Ch2) so that when a signal source is connected to it and the ‘Ext’ trigger is selected, recording to all channels would be controlled to the time the threshold is crossed on Ext channel (as is the case when Ch1/Ch2 are selected as trigger); optionally, the Ext channel could be plotted in the same way as the other 2 channels, allowing for the trigger point shown in the Ext channel plot to correctly reflect the activation of the signal source; in any case, all three channels should be saved as DSO text data (in the same way the other 2 ch’s are already saved) for further processing.
If I am correct with the above thought for the Ext channel, I would kindly ask Velleman to have a look at the above proposal and possibly embed it in a future version of the scope’s software
tx
lazzy
Cliffyk,
Sorry to hear that.
You are an asset to this forums board.
Glad to see you are back.
Sorry to hear that CliffyK, hope that everything turns out allright.
Having to give up a hobby must be hard…
Anyway, welcome back!