[Andrew]

Hi Mike,

The bulkhead connector is from Centric RF, part number C3614. It is considered a precision type-N connector. Particularly good VSWR. Data sheet link below. It is spec’d to 18GHz and in our tests fine up to 20GHz. The main reason for using the type-N was due to customer feedback, mainly revolving around robustness, rigidity, and prevalence in labs.

http://centricrf.com/content/pdf/C3614.pdf

Let us know if you have additional questions.
Regards

• This reply was modified 7 years, 1 month ago by Andrew.
• This reply was modified 7 years, 1 month ago by Andrew.
• This reply was modified 7 years, 1 month ago by Andrew.
• This reply was modified 7 years, 1 month ago by Andrew.

Hi Seth,

What I think happens, is we use older OpenGL features to try to remain as compatible as possible across many systems. It appears some combinations of PC/drivers have issues with these older features. Our use of OpenGL is very minimal and I haven’t personally had the ability to debug on a system that experiences the issue. There are certain models that see it more than others, the X1 carbon is one of those models. It almost is always resolved with drivers from Intel rather than custom ones from the PC manufacturers.

I think the Win10 upgrade is a possible solution as it might give you access to the newer drivers which might resolve the incompatibility.

Regards

You could try the the graphics driver direct from Intel for this processor. Link is below (Note the CPU model at the top of the page) The Intel one looks to be a few years newer than the version you listed. (Hard to find exact dates) On occasion I have seen incompatibilities with vendor supplied graphics drivers vs. the Intel ones.

https://downloadcenter.intel.com/download/27267/Graphics-Intel-Graphics-Driver-for-Windows-15-40-?product=85213

Hi Miran,

I’m not sure of the limitation. You can determine the COM port number of a device in the device manager.

Regards

It doesn’t look like your GSV sentence contains the SNR value, so it will stay empty.
Also I used this sentence format for the GGA string.
http://aprs.gids.nl/nmea/#gga
It looks like your message contains the data when it is emitted. Is it possible it is not emitting the GGA sentence in it’s current configuration?

Miran,

If you are seeing the “Unable to Connect GPS” then this is not an issue with the NMEA data, it is an issue with attempting to open a file handle with the GPS. We use the CreateFile() function to open the GPS with a fileName of “COM#” where # is the COM port number you provided. Can you think of a reason why the GPS would be unable to open this way? Is it being interfaced in another application?

To answer your question, we only look at the RMC, GSV, and GGA sentences, but we only require the RMC to be present, if the others aren’t present then we ignore those values, but these sentences are only going to be looked at if the GPS is successfully connected, which it doesn’t sound like it is.

Regards

Here is an RMC string from our shop GPS. If I match it successfully (as per my previous post) I only look for the first 7 comma separated values, and ignore the rest.

$GPRMC,174641.000,A,4552.763046,N,12235.011607,W,0.011,142.26,210318,,,A*47

Miran,

Are you seeing the “CommErr” message in the Spike application?

If you haven’t already, verify the baud rate is correct.

It looks like after a few seconds, only the RMC string is being transmitted? It only transmits the other NMEA sentences on the first second? I believe in my code I pattern match everything between the string “RMC” and a newline, which means if the RMC sentence was the only sentence in the message it wouldn’t parse properly. I will need to account for this case for the next release.

Regards,
Andrew

You can change the length of the IQ capture waveform by simply changing how many IQ samples you request from the GetIQ functions. Since you know the sample rate of the device for the given acquisition, you can determine the length of the capture you need with the following equations.

sampleRate = 486111.111 / decimation;
timePerSample = 1.0 / sampleRate;
desiredSamples = desiredCaptureTime / timePerSample;

I’m hoping for later this week or early next week on the Spike release. Thank you for your patience.

Regards

[Andrew]

Hi Mike,

You are correct about the tuning speed and step size.

You can find the DANL specs here,
https://signalhound.com/download/sm200a-data-sheet/
The RBW will add 10*log10(RBW) dB to the noise floor.
But, sometimes a picture can be instructive.

I attached an image of the device configured for the 1THz sweep speed. You can see the device sweeping a 20GHz span in 17.257ms with a 30kHz RBW and a reference level of -20dBm which will configure the receiver for maximum sensitivity. If you increase the reference level the noise floor will come up in 5dB steps.

Let us know if you have additional questions.

Regards,
Andrew

• This reply was modified 7 years, 2 months ago by Andrew.

Attachments:

You must be logged in to view attached files.

Hello Bindinir,

Thank you for sharing this picture. I was able to reproduce this issue without the DC block, (which isn’t required). It looks like a bug with our software at this very specific setup. If you change your stop frequency to 90MHz or 110MHz I noticed it no longer occurs and sweeps normally. I will explore this more. In the meantime are you able to change the stop frequency to one of these other values and continue use? If you encounter other issues you can let me know here or email me directly at aj at signalhound dot com. I can try to fix these before the next release.

Regards,
Andrew

Hello vanderbasaran,

If you are interested in the option 10, contact justin at signalhound dot com. He can give you pricing information and set you up with an RMA to get the option applied to your unit. If you haven’t purchased your unit yet, you can order through sales at signalhound dot com, and be sure to mention you want the option 10.

Regards,
Andrew

I would expect this functionality within the next 6 months.

Regards,
Andrew

Hello Vanderbasaran,

At this point and time there is no way to utilize the FPGA resources for your own development. We have discussed this as a possibility but have no plans to implement this for now.

Regards,
Andrew

[Andrew]

Hi Jake,

It was nice meeting you today.

Justin will need to comment on the USB cable/power concerns/questions directly. He will be back in the shop on Friday.

We do have an option/upgrade for the BB60C that removes the need for the y-cable and adds an external power supply.

Are you running in a VM on your Mac? We don’t recommend running our products on Apple hardware or in VM’s. If possible, are you able to switch to a native Windows PC for running our device? It could help us rule out a few concerns if you are running stable on a native Windows PC.

Feel free to follow up with us directly. andrew and justin at signalhound dot com.

Regards,
Andrew

• This reply was modified 7 years, 2 months ago by Andrew.
• This reply was modified 7 years, 2 months ago by Andrew.

Hi Quadsat,

I would recommend using a small form factor Windows PC like the Intel NUC line or other brick-like models. There are also several Atom based SBC computers that would run the SA44B. Also consider the Intel compute stick.

While we do provide an x64 Linux and an ARMv7-A API build on the downloads page, they are not supported and less than ideal for the SA-series of products as we have difficulty maintaining the USB throughput on Linux operating systems, and thus difficulty in providing reliable measurements.

Let me know if you have follow up questions.

Regards,
Andrew

Hi Gary,

Good question. In the BB60C, all of the signal processing happens on the PC side. This is also the case for the SA44B. Our recently released SM200A is the first receiver to move some of this processing to the FPGA, specifically when the instantaneous bandwidth is greater than what we can push through USB 3.0. The SM200A also has an image imbalance filter on the FPGA.

Let me know if you have additional questions.

Regards,
Andrew

Hi Chris,

The issue specifically is the how the Spike software renders the plots. The issue isn’t with the hardware(SA44B) itself, which means you would not have the same issue if you were to utilize the hardware through LabVIEW. Our LabVIEW project functions as a wrapper for our C API that we provide for all of our receivers. There are examples for configuring the device for sweeping.

If you have questions while getting set up in the LabVIEW project contact roger@signalhound.com

Regards,
Andrew

Hello Chris,

I can’t say for certain that the driver will fix these issues you are seeing. I have been able to find a few forums that talk about similar incompatibilities, but nothing conclusive. (With regards to this series of cards and the functionality of OpenGL we use (Vertex Buffer Objects)) The older age of the GPU does worry me since we utilize functionality that was standardized around that time that the hardware itself would have to support.

This is generally why we recommend the newer Intel i3/i5/i7 CPUs since they have integrated graphics we have tested against. Unfortunately I don’t have access to a system like yours to test.

If you are unwilling/unable to update the driver or the driver does not fix the issue, contact me directly at aj@signalhound.com. We do have a 30-day money back guarantee. I wouldn’t want you to be stuck with a unit you cannot use.

I look forward to your response.

Regards,
Andrew

[Author]

Posts