- This topic has 7 replies, 2 voices, and was last updated 7 years, 5 months ago by
.
- Posts
Hello,
Using Labview to control an SA124B.
Changing the attn and gain inputs to the gain attn vi it appears to not control the SA124B attenuation or gain controls.
The controls are integers and the api manual shows values of -1 to 3 are valid for the attn control and -1 to 2 are valid for the gain control.
Is there any thing else that has to be done to manually control the attn and gain.
Thanks.Hello jthienel,
Ensure that both gain and atten are non-negative. Any negative number will cause the device to select the gain/atten automatically.
If you are interested, setting the gain/atten to automatic (-1) the default condition, the reference level set in saSetLevel() controls the gain/atten automatically optimizing for signals at or near the reference level. For example, if you know your input signal is -20dBm, setting the reference level to -15 will optimize the device for your measurement. You can get much more consistent results with this method. Maximum sensitivity is achieved with a reference level of -50 or less.
Let me know if you have additional questions.
Regards,
AndrewHi Jay,
Thanks for the follow up. I’m glad you got it working.
The official message you will see when the input level is too high is saCompressionWarning(2). If you have any questions about this, let me know.
Regards,
AndrewJay,
Are you by chance on Linux? I have seen what you describe on Linux, not on Windows. On Linux, the FTDI USB driver does have throughput/buffer issues for high throughput devices.
If you are on Windows, do you know which error code is being returned? The problem corrects itself on the next sweep? You could try a couple troubleshooting steps we suggest for customers who are having USB issues, such as, enabling the “High Performance” power plan in the “Power Options” control panel menu, and disabling any anti-virus you might be running.
Regards,
AndrewHi Jay,
We have seen improvements when using a low latency or real-time kernel. Unfortunately there is no way to determine when this loss occurs. At one point we narrowed it down to a small circular buffer within the FTDI driver, (based on other similar complaints). Several years ago we tested an open source version of the FTDI driver and saw worse results.
Internally using a low latency kernel with a desktop PC (Intel i-series processor), we saw no loss occur over long periods of acquisition (using IQ data to detect data loss). Although, I have had customers report data loss even on low latency kernels with lower power processors.
It would require a moderate/large firmware/software redesign to fully resolve this issue for the Linux platform. We don’t have any plans for this at this time.
Regards,
Andrew
You must be logged in to reply to this topic.