Hi Jared,

You are correct. These measurements are features of Spike and are not available through a public API.

The SA44 API consists only of low level data acquisition functions. You would need to use the API to retrieve IQ data from the receiver and then make your measurements on this data. Average power would be easy to calculate but carrier offset of a digitally modulated signal is non-trivial.

At this moment, there is not a way to retrieve these measurements programatically. We have talked about making Spike programmable via SCPI but there is no definite plans of this yet.

I apologize for the inconvenience.
If you have additional questions, please let me know.

Regards,
Andrew

Hello g0s,

There are a few ways to load a custom waveform for the VSG. I know you don’t want to use the application we provide, but the easiest way is to use the UI to load the custom waveform file. There are example waveform files in the application directory at
C:\Program Files (x86)\Signal Hound\VSG25\arb_examples
You can also use the C programming interface we provide, the files for which are also provided in the application directory at
C:\Program Files (x86)\Signal Hound\VSG25\api
You will want to use the sgSetFrequencyAmplitude and sgSetCustomIQ functions to achieve this.

Waveforms can be created in excel or a number of other ways, common ways might be using a math library such as Matlab, etc.

Let us know if you have more specific questions.

Regards,
Andrew

Hello Jaguirre,

Yes, the SA44 will work just fine with the Spike software. You can download the Spike software at http://www.signalhound.com/Spike. Functionally, you should notice no differences between the SA44 and SA44B other than some RBW restrictions in certain configurations. If you have more specific questions let us know.

Regards,
Andrew

Hello Ncnteam,

You will need to find the peak manually. This can be as easy as finding the maximum value in the array. A quick search shows a simple vi is provided for this type of functionality.

https://zone.ni.com/reference/en-XX/help/371361G-01/glang/array_max_and_min/

And it looks to be available in the base version of Labview.

Let us know if you have additional questions or if this didn’t answer your question.

Regards,
Andrew

Hello Mikes,

Good question. We have several customers who have developed 2 receiver systems. The most common issue users see is high CPU usage. Each IQ stream is going to consume ~10% usage on a desktop Intel processor and customers report that it doesn’t scale linearly, i.e. 2 receivers will generally consume more CPU usage than 2 X 1 receiver. We don’t have much experience above 2 receivers. I suspect you will run into stability issues regarding USB transfer and will start experiencing disconnects/data loss. I’m guessing, that a very high end desktop system could support 4 receivers with minimal issue.

Let me know if you have more specific questions. I apologize I can’t be more concrete here, these types of solutions are going to be very dependent on the hardware used and software requirements in the final configuration.

You can also email me at aj at signalhound dot com if you would like to discuss your ideas in more detail.

Regards,
Andrew

Hi Clinton,

Both of those devices can be used on USB 2.0 hubs. We use this hub in our production line with great success
https://www.amazon.com/Manhattan-Products-Port-wPower-162463/dp/B0178R2HOY/ref=sr_1_7?ie=UTF8&qid=1486144695&sr=8-7&keywords=manhattan+usb+hub
It probably is a bit much for your needs, but there might be something similar. I would imagine most hubs with an external power supply will run the devices fine.

Let us know if you have additional questions.

Regards,
Andrew

Hi Jason,

We currently don’t have an ARM build for the BB60C. It is unlikely we will any time soon, because we would have to find replacements for the signal processing libraries we use, which target x86/x64 specifically. The processing requirements are simply too high to re-implement the functionality in naive C code and have it run on ARM.

Although, we do have a BB60 Linux build for x64 and it does not require any modifications to the kernel to run. A standard Ubuntu (or similar) install will work fine. We used the libusb library for USB 3.0 with no issues.

It should be stated that our Windows APIs are the only APIs that receive full support. We do fix issues in our other APIs but it may take awhile compared to the Windows versions.

Regards,
Andrew

Hi Jason,

The problem we have isn’t specifically with ARM, but with the FTDI USB libraries on *nix systems. The restrictions exist even with x86 Linux systems. The FTDI libraries for our chip (both the ones provided by FTDI and the open source version) are unable to meet the throughput required for our device to operate optimally (for reasons unknown).

Additionally we know that using a Linux low-latency kernel on x64 will not have any restrictions. The same cannot be said for ARM.

So, the options as we have seen,
Windows: x86/x64 – full capability.
*nix: Standard kernel – x64 – limited functionality.
*nix: low-latency/real-time kernel – x64 – full capability.
*nix: ARM – (all systems we have tested) – limited functionality.

Let me know if you have additional questions.
Regards,
Andrew

Hello Mehran,

I apologize that you are having issues.
Lets wait another week or two and we will release some .vi’s and examples that should help you get going. This will be part of our API download SDK once released. Check back in a couple weeks.

In the meantime, someone on the forums may be willing to help you out with your Labview issues. The only tips I can provide is to look at our existing SA API example for Labview. Also check out the BB60 API C examples which show how to use the API.

Regards,
Andrew

Hey Scott,

Email me at aj at signalhound dot com.
Send me the serial number for your device.
We will want to try manually updating the cal file on your system in case it got corrupted.

Look forward to your email.

Regards,
Andrew

Hello ykhaled,

We do not offer this type of plot in our software (CCDF plot). This is something we may offer in the future, but for now we don’t currently have plans for this.

The only work-around I see available is to utilize our programming API to make the measurement in your own application. This would require programming experience as well as the ability to make this calculation with the waveform data from the BB60C.

Let me know if you have additional questions.

Regards,
Andrew

Hello mehran,

We are working on Labview vi’s right now for our products. These files should be available in the next couple of weeks. If you cannot wait for us to deliver this, then consider using the example vi project we distribute in the API download folder. The vi project can be found in the sa_series examples. The API for the SA44/SA124 is very similar to the BB60C API and you should be able to convert this project to the BB60C API in short time.

Regards,
Andrew

Sure, it probably doesn’t recognize the __declspec(deprecated()) specifier. I use it to warn people when they are using functionality that is deemed deprecated. You could probably remove the specifier and find out if it compiles.

Regards,
Andrew

Hi Simon,

Wow, this is excellent feedback. Thank you so much for taking the time to write this up. I think you propose a number of reasonable modifications. I will be making notes of all of your suggestions and determining where we can fit these into our development.

You did ask about the sweep time. There is an upper limit currently on the sweep time of 1 second overall. This limitation exists due to our architecture and how we process sweeps. This is unlikely to change at this point, without some substantial rework.

Regards,
Andrew

Hi Amy,

Our phone number is 1-800-260-TEST. Justin’s extension is 3.
Justin’s email is justin at signalhound dot com.
We are usually available by phone between 9-4 PST.

We look forward to hearing from you.

Regards,
Andrew Montgomery

Hello Joe,

Thank you for the update. The USB card sounds promising!

Regards,
Andrew

Hi Jason,

Sounds like you have a cool setup.
Out of curiosity, are you aware of the fast preset loading with the Ctrl+# keys? If you save a preset (Through the ‘Preset’ file menu), you can quick load it with this shortcut. If you are opening Spike remotely, you can load the preset right after the application launches.

Currently we do not have any command line functionality or the ability to programmatically control Spike, nor is there a way to start Spike with a start up preset. It has to be done through the file menu or the keyboard shortcut.

Let me know if you have additional questions.

Regards,
Andrew Montgomery

Hello bayderkhani,

The Spike software can be used with all of our devices. Some quick questions.

In the lower right hand corner of the software, in the status bar, it should list the device type/serial number/firmware version. Can you let me know what is listed there?

What is the version of the Spike software you have installed? You should be able to view this in the Help->About menu.

I won’t in the office until Tuesday the 3rd to be able to address this fully.

I look forward to your reply and thank you for your patience.

Regards,
Andrew Montgomery

Alexey,

Please email support at signalhound dot com as well as beau at signalhound dot com and ask for the .bin and .tep files for your serial number. You will need to place both of these files into the folder you mentioned. I believe this will solve your problem.

Regards,
A.J.

Hello magintd,

The IQ samples are stored in the binary file as 16 bit signed integers, interleaved (I1, Q1, I2, Q2 … etc). The 16 bit integers are scaled to +/- 32767 with an additional scaleFactor to bring them into the 0-1 range.

The proper way to recover the IQ values are
float floatReal = ((float)int16Real / 32767.0) * (1.0 / scalefactor);
float floatImag = ((float)int16Imag / 32767.0) * (1.0 / scalefactor);

Where the scaleFactor is found in the XML file.

Let me know if you have additional questions.

Regards,
A.J.

[Author]

Posts