Hi tma,

It will, good point. It would be best to set the reference level to the maximum value (+40) before switching over to the VSWR plot, this way you don’t have to worry about needing another store-thru.

Regards,
Andrew

Hi tma,

Thanks for letting us know about this. I was able to reproduce the issue immediately. This is something I can address on the next release of Spike. There is currently a trick to get rid of the message. If you set the “Ref Level” above the peak of your signal, for instance, in your picture, the peak is ~5.5. Set the Ref Level to +6dBm or higher and the error will go away. In short, the software is comparing the VSWR sweep to the dBm reference level and not the VSWR reference level.

Let me know if you have additional questions or need further clarifications.

Regards,
Andrew

Hello Ivan,

OFDM decoding is not currently possible with our software. Adding this to our software is something we have discussed many times, but we don’t have any definite plans at this point.

If you have access to something like Matlab with the communications toolbox, this might be an alternative.

Regards,
Andrew

Andy is correct, if software image rejection is enabled, the Bluetooth packet would be identified as a spur. You can disable it in the File->Settings menu.

Also, increasing your RBW and selecting the min/max detector will increase your chances of capturing a transmission.

The bandwidth of a Bluetooth transmission is greater than the instantaneous bandwidth of the SA44B, so it will be difficult to make accurate measurements on this type of signal.

Let me know if these suggestions help.
Regards,
Andrew

Hey Mike,

Below is what another customer on this forum is doing to use the Spike software on remote desktop.

I created a batch file in the spike program folder and named it RunFromRDP.bat.

Inside that batch file I placed the following commands:

tscon 1 /dest:console
spike.exe

The first command disconnects the remote desktop session and forces Windows to run in the local console. Then the Spike starts and OpenGL initializes correctly. After a few seconds I reconnect and everything works fine.

Essentially, as long as Spike is started not through remote desktop, you can log into the machine while it is running with no issues. To date, this is the primary workaround. If you search for remote desktop and OpenGL you will find several discussions online that might have other suggestions.

We have used TightVNC in the past with success, maybe TeamViewer is a possible solution here? If your CPU has vPro capabilities, there are tools available for connecting to the PC through this as well, which we have tested at one point with success.

Let me know if you have additional questions.

Regards,
Andrew

Hello Gabi,

The TG44 programming interface is available on x86/x64bit Windows and x64bit Linux. We do not support the TG on ARM architectures.

You can download the programming files at
https://signalhound.com/support/product-downloads/tg44a-tg124a-downloads/

Let me know if you have further questions.

Regards,
Andrew

Hi Dave,

Sorry you are having issues.

Can you email me at aj@signalhound.com? In your email, let me know the serial number of your device.

I haven’t seen the software crash in this way before. I can email you several troubleshooting ideas.

Regards,
Andrew

Hello all,

We recently released instrument drivers for LabVIEW. The install includes several examples for both the SA and BB series devices, with an incredible easy installation process.

You can download the drivers at
https://signalhound.com/software/signal-hound-instrument-drivers-for-labview/

Regards,
Andrew

Hello Jean Pierre,

After you save the file, I think the edit path loss dialog is still active and probably behind the spike window. This is preventing you from interfacing the Spike dialog.

You can bring those to the front by finding them in the Windows toolbar along the bottom of the screen. The windows should be grouped with the Spike application.

I apologize for the inconvenience. I will see if we can keep these on the top automatically in the next release.

Regards,
Andrew

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

[Author]

Posts