Hi Andy,

We custom make the locking y-cable. Reach out to lori@signalhound.com if you need another. If you purchased through a distributor, reach out to them and they will be able to help you get another.

Andrew

Hi Andy,

Yes, the timestamps still come from the system clock.

I will look into a GPS indicator for a future release. This is a good idea.

I’m glad you like the recent changes to the recording/GPS. Both the sweep decimation and GPS coord. tagging were highly requested features.

Thanks for the feedback.
Regards,
Andrew

Hi Andy,

I am attaching a folder with the example project we will be shipping for SHR parsing. The format is very similar to the BBR file except it changed the header format (still a single struct) to include all the new settings that were introduced with the SHR file format. Also, the sweeps are prefixed with a bit more information than just the timestamp. The general parsing process should be very familiar and similar.

In the future, this will be available in the standard API/SDK download, sorry I hadn’t got around to uploading it yet.

Regards,
Andrew

Attachments:

You must be logged in to view attached files.

[Andrew]

Eric,

(Edit: after looking at the equation you linked, it looks like it accounts for the spectral window and the discrepancy is probably just the spur reject setting, leaving the full reply)

A couple things that come to mind regarding your measurement discrepancy. The SA44B has spur reject processing enabled by default. Unless you either disable this in the settings file menu or lower your VBW substantially, this will contribute to a lot of your error. Additionally you will want to account for the window bandwidth. All spectrum analyzers will utilize a spectral window. In our software this is the RBW shape control. By default, we use the flat top window. The spectral windows will also contribute to the calculation. Below I linked another thread which goes into detail regarding this and also you will find a code snippet in one of my replies which has the channel power code calculation from Spike. You can compare your code to it.

The spectral window is also why you are seeing a different sweep size than you expect. When using a spectral window, larger FFT sizes are required to achieve the same RBW, thus the larger sweep size. If you are unfamiliar with these window functions, see the other link below.

If you have follow up questions, please let me know.

https://signalhound.com/support/forums/topic/noise-bandwidth-of-resolution-bandwidth-filter/

https://en.wikipedia.org/wiki/Window_function

Regards,
Andrew

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

Hello Miran,

I was able to reproduce the export issue. I will look into this and get a fix for the next release.

Currently there is no way to export the reference trace. The export button will export the current average trace.

Thanks for the bug report. It is always appreciated.

Regards,

Maksym,

The bandwidth parameter controls the FIR filter cutoff frequency on the IQ data stream. The lower limit for IQ bandwidths are below. Additionally, the final IQ bandwidth is reported back to you in the bbQueryStreamInfo function after you initiate an IQ data stream. Ideally, you should target a bandwidth between 20-80% of the sample rate, because with fixed lengths FIR filters, the filter rolloff duration will be constant. If you need a narrower bandwidth, I would suggest either lowering the sample rate, or running an additional larger filter on the IQ data after you acquire it.

case 1,2: return 50.0e3;
case 4: return 50.0e3;
case 8: return 50.0e3;
case 16: return 50.0e3;
case 32: return 50.0e3;
case 64: return 50.0e3;
case 128: return 50.0e3;
case 256: return 20.0e3;
case 512: return 10.0e3;
case 1024: return 5.0e3;
case 2048: return 2.0e3;
case 4096: return 1.0e3;
case 8192: return 0.1e3;

[Andrew]

Hello Mehran,

Thank you for the feedback. Can you clarify, is the monitoring section you are referring to the waterfall/spectrogram plot, or the interference hunting measurement mode? Can you provide any other sort of information regarding these features (pictures/manuals/etc). I want to ensure I understand the functionality you are looking for.

Regards,
Andrew

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

It looks like the channelizer only saves 8 channels instead of the expected 9. (Look at the sweep size to verify). Might be a rounding issue. I can look into getting a fix for this next release. Otherwise it does look like it is properly calculating your channel powers. It is still usable but will contain 1 less channel. You might have to increase your span to include all the channels for now. Also, note, the start/stop/center frequencies displayed during playback are the settings at the time of capture. You will want to use the marker readout to confirm the channel frequency.

Thanks for the feedback Miran,
Andrew

This is a nice feature Miran. We will definitely consider this for future software updates. I think this would be very helpful. Thank you for providing your feedback and suggestions, it is very appreciated.

Regards,
Andrew

Hello Miran,

You are talking about a relative frequency limit line? This is a good idea, but unfortunately we don’t have any implementation of this yet. I appreciate the feedback.

Regards

Hello Volker,

Did you try making the limit more like a box rather than a Spike like I suggested in my earlier response? Since your spike is smaller than 1 RBW the limit test point is being interpolated between the high point and adjacent low points. Unless the frequency bin happens to fall exactly on your high limit line point, it will interpolate somewhere along the steep limit line. This latest version is now drawing what is being tested against so there is no confusion, (the last version improperly drew the limit line as entered rather than the actual interpolated test points)

Ultimately I think this spike in the limit line approach to check for a CW is not ideal with how we implements limit lines and it looks like you had a perfect setup back in 3.1.11 because I can’t even reproduce your original image using the original limit line you provided. I think going towards a box/square shape and being mindful of your RBW will solve this problem long term.

Regards,
Andrew

[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, 5 months ago by Andrew.
• This reply was modified 7 years, 5 months ago by Andrew.
• This reply was modified 7 years, 5 months ago by Andrew.
• This reply was modified 7 years, 5 months 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;

[Author]

Posts