I'm having a hard time increasing the effective time sampling and performing oversampling.
No matter what value I send to the Oversample register in get_timebase, the noise seems to be at the same level.
Also, if I change the ETS mode in set_ets to anything other than none, Labview freezes. Thanks for your time. The code (slightly modified from an example I received from you) is attached.
Please find below response from the driver suppport group.
ETS mode will freeze if a trigger isn’t met; it waits indefinitely for a trigger. Since they’re using Ultrasound signals, I presume it’s not a repetitive signal and won’t trigger properly in ETS mode.
Oversampling increases the effective resolution as …
Increase in resolution (bits) = log (oversample) / log (4)
The oversample needs to be passed into the Get_Timebase AND the RunBlock calls (the same value to each). Since they only passed it to the Get_Timebase, it wasn’t enabled. Further, the 2 they pass to Get_Timebase will only increase the resolution by 0.5 bits.
The revised version we've included takes into account the maxSamples available for the given Timebase setup. This should have been an out variable . Also, unfortunately, we had to delete a stack of the post-acquisition processing as we don’t have the module you are using.
Please find attached revised file.
I hope this is of some use.
Thanks for the response. I increased the sampling rate to the maximum, so I'm no longer interested in oversampling...just ETS.
The ultrasound signal is being used to measure time of travel in water, so it actually is repetitive. Right now we are using an external trigger from the signal generator, so I'm not sure there's any reason for it to miss a trigger. Attached is a program which works correctly until I enable ETS mode. Then it returns the handle and freezes. Since the trigger mode is set the same whether ETS is enable or disabled, I'd be surprised if the reason it was freezing was due to triggering. Thanks for your time.
Thanks for the response. I increased the sampling rate to the maximum, so I'm no longer interested in oversampling...just ETS.
The ultrasound signal is being used to measure time of travel in water, so it actually is repetitive. Right now we are using an external trigger from the signal generator, so I'm not sure there's any reason for it to miss a trigger. Attached is a program which works correctly until I enable ETS mode. Then it returns the handle and freezes. Since the trigger mode is set the same whether ETS is enable or disabled, I'd be surprised if the reason it was freezing was due to triggering. Thanks for your time.
Thanks for the response. I increased the sampling rate to the maximum, so I'm no longer interested in oversampling...just ETS.
The ultrasound signal is being used to measure time of travel in water, so it actually is repetitive. Right now we are using an external trigger from the signal generator, so I'm not sure there's any reason for it to miss a trigger. I have a program which works correctly until I enable ETS mode. Then it returns the handle and freezes. Since the trigger mode is set the same whether ETS is enable or disabled, I'd be surprised if the reason it was freezing was due to triggering. I had trouble attaching it. I will try again tomorrow. Thanks for your time.
1)Try out your setup in PicoScope – with ETS on. (That will use 60 cycles and 20 interleaves, but should tell us if its labview or our drivers).
2)The wiring in your VI is slightly off – the handle ‘wire’ is coming out of ‘SetETS’ and going to BOTH GetTimebase and RunBlock – it should go into GetTimebase first, and then into RunBlock – as it is, theres no guarantee which order they will execute.
3)Can you step through your diagram, with ETS on and find out which DLL call it hangs on ?
I changed my wiring so that the handle goes through GetTimebase first, and then into RunBlock, and I'm still seeing the same trouble. Also, it doesn't appear that the vi is hanging, because I can run through a few iterations of it. Instead, it seems that GetTimes&Values is returning all zeros, since that is what is plotted on the graphs. Thanks for your time.
One of our software developers has identified an issue. If you could you answer the first question I asked earlier it would be help him further in resolving your query:
1)Try out your setup in PicoScope – with ETS on. (That will use 60 cycles and 20 interleaves, but should tell us if its labview or our drivers).
Earlier I didn't quite understand what you were asking me to do, and I'm still not entirely sure I do so let me know if I missed it. I had cycles set to 6, and interleave set to 2 in my program, so I used the pico scope software to set it to ETS mode and the cycle time to 5 ns/div, with the ETS oversample set to 3. With 13600 samples this didn't give me a problem. Also, the trigger was set to rising and the total vertical range was set to 20V. Let me know if there's another setting I should look at or if something doesn't seem right. Thanks for your time.