Forum Replies Created
- Posts
You should be able to export your good trace, offset by some amount (e.g. 2 dB) in spreadsheet software, and then import it as a limit line. This might be another approach to consider.
I know Matlab has some tools for GPS signal generation. You could also just use one of our receivers, a bias tee, and a good GPS antenna + preamp to capture a GPS signal and then play it back with the VSG60A.
Thank you for bringing this to our attention. I will alert our software team to this issue, and see if they can duplicate it.
You will notice in the specifications that the DANL (noise floor) specification is 4 dB higher below 700 MHz vs. above 700 MHz. A 4-5 dB step in the noise floor is normal. This is due to a design decision to optimize for noise figure in the 700 MHz – 2700 MHz communications band, and to push for better linearity at low frequencies.
I’m not sure what signal you’re looking at there, but it is possible that level of noise is actually on your signal. You can turn the preselector on and off below 640 MHz, and change your reference level by 10 dB. If the noise level changes considerably, it may be partially from intermodulation inside the SM200C. Otherwise, it is likely part of your input signal.
One thing to watch out for is noise from the USB cable ends can mass with weak GPS signals, so it is best to have some distance between the GPS antenna and any USB 3.0 cable. A couple of meters is usually sufficient.
We ran a fresh batch of tests, with the API as it currently stands. I was a little surprised. A 2 GHz span (roughly 2 ms of actual sweep time), took from start to finish (not queued), on average:
SM200B = 4.4 ms
SM200C = 4.8 ms
There were no significant peaks in the 1000-sweep test. From this, it looks like the SM200C has a bit higher latency across the board (something like 2.8 ms vs 2.4 ms).
Obviously these numbers will vary from computer to computer and sweep to sweep, and peak numbers will vary based on CPU load, but it’s a starting point.Kaiser,
Good news and bad news. In Windows, even though the median latency for the SM200C is a bit lower than the SM200B, the peak latency can be high (I have seen 80 ms delays when opening a PDF for example).
I do not believe the same problem exists on the Linux side.Mneuman,
ThinkRF has some upconverters. Or if you’re on a budget, you could get the ADMV1013 eval board and cobble something together. Maybe even use an LO from Windfreak if you don’t have a generatorWe have a software suite for instrument calibration. See https://signalhound.com/software/signal-hound-field-calibration-software/ for more information. A typical calibration lab will have most or all of the equipment required.
GSingh,
Yes, those IMD3 products appear to be from the generator, at typical values. Typically you will see -50 dBc below -10 dBm, but it will get worse as you increase amplitude.
If you need two-tone better than -50 dBc, you would probably want 2 generators and a directional combiner. There are digital techniques as well, but they will be less stable over temperature and frequency.GSingh,
To determine whether the IMD3 products are from the generator or the analyzer, change the reference level on the analyzer by 10 dB. This will increase attenuation by 10 dB. If the levels stay the same they are from the generator. If they change significantly they are from the analyzer.Above 200 kHz span, only the 10.7 MHz IF is used, and the LO is injected first low side, then high side. The noise figure of the 10.7 MHz IF is maybe 5 dB higher, so this can affect measurements where the level of noise present is low.
As long as your VBW is much lower than your RBW, you can still make decent noise measurements, with the caveat that you’re measuring the combined noise from RF and image.We use two different IF frequencies when software image/spur reject is active and span is 200 kHz or less: 2.9 MHz and 10.7 MHz. The image frequency is [RF frequency] + 2 * [IF frequency]
Internal measurements will be made with the 2.9 MHz IF, followed by the 10.7 MHz IF. The lower reading for each frequency bin is displayed.
If you disable spur reject, only the 10.7 MHz IF will be used.The BB60 or SM200 is a better choice for noise measurements, since the image is rejected in hardware, and software spur reject is off by default.
Unless video bandwidth is much lower than resolution bandwidth, our image rejection algorithm (a minimum of 2 measurements function) will not preserve average noise energy.
My recommended settings are what I would recommend using. And if you decide to try a BB60C, you can avoid the problem entirely.Lsullivan,
At a high level, we use overlapping windowed FFTs for real-time mode. Typically, 50% overlap is used.
The SA44B is not ideal for broadband measurements. We generally only recommend it for narrow-band signal analysis (<250 kHz occupied bandwidth is ideal) due to the limitations of the SA-series software image rejection.
Because we use a software image rejection algorithm, making noise measurements can be tricky. A span of 200 kHz or less should be used. Good settings might be 1 kHz RBW, 30 Hz VBW, power, average. Then you have to factor in that the noise from the image will add to the reading, typically 3 dB.
Hope this helps. The BB60C might be a better choice for noise measurements, as it uses hardware image rejection so it can be used like a normal spectrum analyzer (the BB60C should not be used for noise measurements below about 100 kHz).
Another thing to note is that the preamplifier is off for sweeps that start below 500 kHz or so. So you will not have maximum sensitivity at low frequencies.Serpi,
The noise marker, using power, average settings, will give you a good noise measurement. The trace does not have to be in average mode, but it may help stabilize the reading a bit more.
You will find most frequencies have a noise figure quite a bit better than our specification. As a spectrum analyzer, we are required to meet the DANL specification at all operating frequencies for the life of the instrument, so padding these numbers a bit is prudent.
DDR,
You should not have big dropouts like that. This would indicate either hardware failure, bad correction data, or possibly bad sweep settings resulting in bad measurements.
To rule out the sweep settings issue, please test individual failing points with the VSG in CW mode, and the SA124B set to a 200 kHz span centered at the output frequency. You can email support at signalhound dot com and we can try to figure out if we can fix it with correction data or if we will need to repair one of the units.