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.

Andy,
250 kHz is the magic number. Sweeps that start below this cannot use the preamplifier, which raises the noise floor.

The TG sweeps now use two sweeps to build the final result. One covers the low loss region (approx. 0 to -40 dB for a passive device, or -20 to 20 for an active device). The other covers the high loss region (approx. -40 to -80 dB or -20 to -60 dB for an active device).

When the start frequency is below 250 kHz, the software selects the active device range since it cannot use the preamplifier.

Andy,
These might be from steps in input / output impedance at those frequencies. You can remedy this by adding a 3 dB pad to the output of the TG and input of SA before “store thru” and keep them on for all measurements. This improves return loss by 6 dB and cleans up impedance mismatch-related measurement error.
Another thing you can do is “store thru” with a similar length cable to the circuit you will be testing.
If these steps occur with 30-50 dB insertion loss, you may need to “store 20 dB pad” to get rid of them.

KBONE, thank you for the bug report. I’ll see if we can duplicate it. Do you mind sharing details about your CPU and GPU so we can try to duplicate it?

Roger,
What application do you use the trace math for? We’ve been discussing how to implement it in a robust, maintainable way. Would something like (Trace 1 – Trace 2 – offset), shown on the same graticule work for you?

Ockhams, Thanks! That’s what we love to hear.
Andy, we duplicated your problem. We’ll work on it and see if we can find a fix.

FYI: This discussion continues post-release here: https://signalhound.com/support/forums/topic/spike/

Andy,
The zip file you download contains the drivers, if you don’t already have them from a previous install. You still have to install them separately as a second step. We will continue trying to simplify the process, but for now it is a two step install if you don’t have the drivers already installed.

Cliffy,
This poorly worded error code means the temperature correction data file, typically downloaded from our web server, was inaccessible.
This can be because:
1) The computer does not have an internet connection
2) The application cannot use the connection (e.g. company firewall), or
3) The file does not exist on our server.
If you email support@signalhound.com with your serial number, we can email the file to you, or you can manually copy it from the working installation folder. Copy two files from the working installation (both have your serial number in the file name), to the non-working installation.

With our new software release tomorrow, this error description will be a thing of the past.

Nice! Yeah, type N connectors definitely have some advantages…

[Author]

Posts