Forum Replies Created
- Posts
Occasionally we get sticky USB problems when something goes wrong during a device’s initial configuration. To remedy this, you sometimes have to remove the instance of the USB device. This tool: http://www.ftdichip.com/Support/Utilities/CDMUninstaller_v1.4.zip
can be used to remove all memory of previously connected Signal Hounds.
Launch the GUI version, leave teh VID at 0403, change the PID to 6010, click “Add”, and then click “remove devices”. Then re-install the USB driver, connect your device, wait for the “searching for updated driver” to finish (1-2 minutes sometimes), and then launch Spike.Interesting. It is probably safe to ignore the first overflow flag after a settings change from an overflow condition. Subsequent overflow flags should be treated as valid.
JoeQSmith,
We do not have any provisions for locking the time base to an external source. There is a 24 MHz time base that could have been locked with an additional timebase PLL, but that would only get you within a few Hz, not a true lock, due to the resolution of the RF PLL.
Any future vector signal generators we produce will have the ability to lock, but they will be significantly more expensive.Andrew,
The ADC overflow flag is only cleared immediately after reporting it. When you are doing single sweep, with an overflow condition (e.g. gain 2 atten 0), it reports the overflow, clears the flag, and then immediately sets the flag again (overflow condition still present). You set the attenuator to 10 dB (no more overflow), sweep, and it reports there was an overflow condition since the last time it was reported. But the next sweep reports no overflow.
This is the expected behavior. If this is not what you are seeing, let me know.Because of the architecture limitations of the SA44B, it really is not a good fit for EMI precompliance. The SA44B is not capable of picking up some types of transient signals without disabling image rejection, and for EMC precompliance, you want a high degree of confidence for all types of signals that the SA-series really can’t provide.
Ivan,
High Q devices require a long settling time, often tens of milliseconds, before an accurate measurement can be taken. This is one reason we limit the step to 1 kHz–any finer resolution would take exponentially longer to measure.
In Spike, you can accomplish a high Q insertion loss measurement using a MAX HOLD trace and the TG CW utility, manually stepping across the frequencies of interest. Your “external” sweep with max hold is a good approach to this, and essentially automates this process.
For this type of measurement, “zero span” would be the best place. Just set your IF bandwidth to your channel bandwidth, with the signal centered.
If it is a constant amplitude envelope (e.g. FSK, GMSK), a marker anywhere gives you channel power. If not, you could export the zero span data into a CSV, and then (in mW units, not dBm) average the power of each sample within your packet.
I’ll talk to AJ and see if this is something we could add to the next release.
Users never used to have to uncheck the VCP in the advanced driver settings, but we are seeing that more and more now. I’m glad you got it fixed.
For others who have this problem, in the device manager, locate “serial converter A”. On the Advanced tab, uncheck “load VCP driver”. Then do the same for Serial Converter B.
For the TG44A, repeat this for “serial converter” (no A or B)
It is an AD9864. We run it at 10.7 MHz, or bypass the mixer and run it at 2.9 MHz in “hung mixer” mode.
http://www.analog.com/media/en/technical-documentation/data-sheets/AD9864.pdfIf you are referring to frequency vs. time plot or data, you can use our zero span mode for short captures, or our API for continuous I/Q data, which you can FM demodulate using the atan2 function.
It’s actually a sigma delta 24 bit ADC, digitally converted to 16-bit I&Q.
It’d be kind of cool to see a vertical bar representing channel power on the spectrum plot, and then you could show the video trigger threshold on that. Just throwin’ out ideas…
June 8, 2016 at 8:58 am in reply to: SA44B Linux 32-bit Linux API files have wrong architecture (64bit) Good deal. I’m glad they worked!
We spoke on the phone this morning. To summarize for people troubleshooting from forum posts, it was a combination of two common problems:
1) Since you could not see the 10×10 grid when you launched Spike, we upgraded your video driver.
2) The Device Manager–>USB serial converter A & B–>Advanced “load VCP” check box was checked (both converter A and converter B are part of the SA44B). You had un-checked these so your SA44B was working.
3) The “load VCP” was checked for “USB Serial Converter” (the TG44A). Once we un-checked this and power cycled the devices, everything was working. June 1, 2016 at 1:34 pm in reply to: SA44B Linux 32-bit Linux API files have wrong architecture (64bit) I found this in the archives. A customer reported it worked for his 32 bit application. Let me know if it helps.
June 1, 2016 at 1:26 pm in reply to: SA44B Linux 32-bit Linux API files have wrong architecture (64bit) Giorgio,
Is this a one-off project, or something you will use for many customers? Are you aware of the low latency kernel requirements?Another issue is the driver. Is this a true x86 platform with full USB 2.0 support?
June 1, 2016 at 9:16 am in reply to: SA44B Linux 32-bit Linux API files have wrong architecture (64bit) Dear G. Grasso,
These legacy APIs are no longer supported. I have had reports that the 64-bit API, when paired with a low latency kernel, works reasonably well.
Your best bet is Windows (x86/x64) which is our tried and true OS. If you must use Linux, try either the x64, or 32-bit ARM (Raspberry Pi 2-like processors).
We’ll remove the 32-bit link from our website to avoid this problem in the future.Bbowar,
Yes, good catch. For channel power, you definitely want average+power for your video processing.
bbowar,
The algorithm is basically the same, but with the SA44B, software image and spur rejection is on by default, and this can cause inaccuracies if the signal changes rapidly. The BB60C defaults to using only hardware image and spur rejection, so it is immune from this added measurement error, and will be more accurate for dynamic, real-world signals.