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.

Hello sajdenman,

The audio demod mode does have a limiting bandwidth of about 300kHz.

You could manually measure your frequency deviation in zero-span mode using the FM plot and markers to measure the peaks and troughs. I don’t know if this would be sufficient for you.

Let me know if you have additional questions.

Regards,
A.J.

Hello Claudio,

Thank you for posting your findings here. I have also received your email with this document.

Have you tried a resolution of 1080p yet? I have yet to be able to reproduce these issues at 1080p. I’m wondering if this is another graphical issue at the 4K display resolution.

Regards,
A.J.

Hello magintd,

I can clarify. The bbr file is a flat recording of sweeps only (frequency domain ‘bins’). The IQ data is not recorded in this file. The sweeps are stored as min/max arrays. If the avg detector is enabled, min/max should equal the same values. I will attach a basic bbr parser so you can see the layout and how we parse the files in our software.

If you are looking to get IQ data, then we do have another recording feature in zero-span that records IQ data. If you are looking for the ultimate flexibility, you could grab IQ data directly from the device with our APIs.

Let me know if you have additional questions.

Regards,
A.J.

Attachments:

You must be logged in to view attached files.

Hi Fabrice,

Thank you very much for the feedback. I like all of your ideas! We will definitely take these ideas into consideration as we further develop our software. Thank you again.

Regards,
A.J.

[Author]

Posts