The best workaround is to show multiple captures. You could do several 200 kHz steps with low RBW. If you wanted you could export them as CSV, paste them together, and then plot using spreadsheet software or your favorite plotting tool.

I realize the RBW/span limitation at low frequencies seems odd, but the combination of hardware limitations at those frequencies, and the sweep performance we wanted for Spike, made it necessary.

With a shared external frequency reference, in streaming mode only, there should be zero phase drift. However, every time you change center frequency, there will be a new phase offset.

If there is phase drift from floating point frequency correction rounding errors at some frequencies, I would think it would be very small and identical across devices and therefore cancel, but I have not tested this (maybe 1 degree per minute?).

At even multiples of 20 MHz (e.g. 200.00 MHz), this correction should be zero, so you should get a true zero phase drift. If you test this, let me know. If there is phase drift, there should be a way to easily get rid of it, possibly by using streaming IF instead of I/Q…

The standard RBW works well for the BB60C, but not for the USB-SA44B. Because of the software-based image rejection, the default noise bandwidth is 2 x RBW, but then there is the software image reject algorithm. To get NBW close to 2 x RBW, you would need to either disable “spur reject” / image reject, or set video processing to power average and turn VBW down to 1/10 RBW.
To get noise BW close to RBW, you would need to filter out the image frequency. For wide sweeps, this is 21.4 MHz above or below the image frequency. For 200 kHz spans or less, this is 5.8 MHz above or 21.4 MHz above the measured signal. With image/spur reject on, filtering out either image will result in a good measurement.

Another thing to note: For accurate power measurements, you need to keep the total power into the BB60C below +10 dBm. Your picture showed over +16 dBm. You will want to use a 10 or 20 dB pad for accurate measurements.

For 6 dB bandwidth test, I believe the test is marker peak, then marker to the first point (left-to-right) less than 6 dB below peak, then delta, then last point (right-to-left) less than 6 dB below peak. You may wish to verify this, but I believe this is the 6 dB test.

Bbowar, to simplify the thought process, we use wide flat top windows, so the noise bandwidth is very close to the resolution bandwidth.

12V is not too bad, it’s people connecting to AC mains that can be really scary. An attenuator (or a limiter if sensitivity is important) is always a good idea though.

Bbowar, you can also look at the simple, less functional Labview example in your C:\Program Files\Signal Hound\Spike\api\sa_series\labview folder. It doesn’t have all of the functionality of Lior’s program, but it might be easier to get running if you are experiencing difficulties.

Jared,
AJ pretty much summed up what you see. The center frequency gets set, then the frequency modulator (which offsets the center frequency) gets activated, then the modulation pattern begins looping.
I am looking at adding packet-based digital modulation with a 2-508 symbol packet followed by an “off” period of up to 65,000 symbols. This could easily give you a 1% duty cycle. Let me know if you are interested. The only (minor) challenge is I would have to convert FSK math from frequency modulation to its quadrature amplitude equivalent to enable this.

We could create a “packet” mode: send 2 – 508 symbols, then “off” for up to 65,000 symbols. Would this satisfy your requirement?

Andy,
In Spike, you must explicitly set preamp AND gain before it will accept manual settings. With gain set to 1 or 2, you should notice a big change when you turn on the preamp.

KBONE, you can also download an evaluation copy of the latest LabView, save as a previous version (e.g. LV 2012), and then fix whatever errors creep in.

After unzipping, I had to create a sub-folder, “data”, and move shlv.ini into the folder. After that, it looked pretty good. Nice work!

Excellent!!! I will try it out later today. Thank you for sharing this.

Depending on settings, it can sometimes draw up to an amp, so we went with the Y cable. However, many customers have used a single 1 meter USB3 cable with the BB60A.
The BB60C draws 1.25 to 1.3 amps, so it requires the Y cable.

Julian,
The BB60A draws about 900 mA. Sorry I didn’t get back to you yesterday.

If you are using it with the USB-SA44B, you can use the API found in the Spike folder.
If you are using it by itself, without the USB-SA44B, email support@signalhound.com for a standalone TG API. Keep in mind that the TG output power is only from -30 to -10 dBm.

I think I answered this on Facebook last week. In essence, for the legacy API, yes. I recommend keeping FFTSize * AvgCount <= 65536, although up to 512*255 will work. The new Spike API has no such limitations.

Dan,
You will probably want to use the most powerful Beagleboard you can get your hands on. The ARM processor has to be powerful enough to perform thousands of FFTs per sweep, and keep up with 2 megabytes per second of data from the device, where very little latency is tolerated.

It looks like you’re using the 454 MHz ARM Freescale i.MX286? Unfortunately, we have no experience with this part. If our 32-bit x86 library and our ARM library both fail to compile, we most likely don’t support the architecture. We tried to satisfy the Linux embedded market with our Beagleboard ARM-based API, which works on a subset of ARM processors. I realize this is not an ideal platform for all customers. Most of our users connect the Signal Hound to a laptop or PC, so we have not had a high demand for embedded support, especially once users see how much slower it performs on a low power embedded platform.

[Author]

Posts