Yes, our SM API will support interfacing 2 SM200Cs simultaneously. I would recommend using the API and C++ for initial testing and proof of concept work. MATLAB adds significant overhead for streaming I/Q especially at high data rates. Our MATLAB examples only interface 1 device so it will need to be extended to support multiple devices. Starting with C++ will also help you understand how you will need to extend the MATLAB examples.

We would also generally recommend Linux over Windows if you are going to run multiple devices at the highest sample rate (200MS/s).

Are you using GNURadio v3.10? If yes, our OOT modules were developed on v3.9 and will require porting to 3.10. We currently have this as a TODO, so it is left as a customer exercise until we can make time for this. There are some resources that might help, for instance, https://wiki.gnuradio.org/index.php/GNU_Radio_3.10_OOT_Module_Porting_Guide

A reference level of -20dBm on the SP145 achieves the minimum noise floor, but will limit input signals to ~-20dBm before IF overload occurs. On the BB60D, the minimum noise floor is achieved at -30dBm reference level.

Mehdi,

You specify an attenuation of 0dB, which for the SP145 I believe is overriding your reference level control. If you want reference level to control the sensitivity of the receiver we recommend leaving all gain/atten/preamp values to their defaults. The reference level control alone will properly set these controls behind the scenes for the best dynamic range. If you change attenuation back to Auto, with a ref level of 0dBm, your measurement should work again on the SP145.

The reason you probably don’t see the same issue on the BB60D is because you have to set both gain and atten before it override the Ref level. Again, we still recommend leaving everything auto and just using ref level, unless you have a specific reason not to.

If Spike is set to hidden mode, that dialog will not appear, but I also believe it will not automatically enter demo mode. There is not a way to automatically enter demo mode. The only way to bypass that dialog into an active state is with 1 Signal Hound device connected.

Galc,

Spike has a “hidden” mode in which you can launch the software and it only appears in the task list. You can read more about this in the manual. If the issue is that the software is visible and you want just your application showing, that might be interesting.

Hi Volgy,

Nice work for being new at this! You have largely properly characterized the functionality of the fast sweep mode. There is only one more thing to know about. To accomplish “arbitrary” RBWs, you can perform FFT zero-padding. This basically gets us the ability to configure for RBWs as if we have FFT sizes between 16 (or whatever we use as the smallest) and 16384, in increments of 1, and not just 512,1024,…,16384.

And to address your other question, you are correct, the detector is not relevant for the reason you listed.

If you need more flexibility than what fast sweep mode offers, take a look at the I/Q sweep list. This mode lets you preconfigure a list of freq steps and I/Q capture sizes, and executes them at the same speed as fast sweep mode. This gets you the time domain I/Q samples as opposed to the processed spectrum data. On the SM435C, the I/Q bandwidth for each “step” is 160MHz, so you can achieve > 1THz sweeps with the right settings. For the SM435B models, the I/Q bandwidth is only 40MHz, so it falls short of 1THz per second, and in that case the fast sweep mode is providing functionality that I/Q sweep lists cannot. The downside of I/Q sweep lists is that now you have to do your own processing, but it will let you reproduce most of the sweep capabilities offered through the sweep modes.

The concept of a preset does not exist in the API, that is only in the Spike software.

Also, you are correct, the API provides just the sweep and I/Q data from the instrument. Any measurements on the data need to be performed in your application.

As Roger noted, the SCPI commands support both loading presets and exporting trace data.

Let us know if you have follow up questions.

I have replied to the email that you also sent asking this question.

Nice find and fix!

Email me at aj@signalhound.com and lets see what we can do.

Thanks for the feedback. These are 2 highly requested items. Maybe someday! 🙂

[Andrew]

Hi Torbin,

Zero-span mode has only partial support for SCPI. There is only commands for configuring the capture and then requesting the I/Q data. To achieve the functionality of a frequency marker, you would need to pull the I/Q data, FM demodulate it, then index your FM array accordingly.

This may be expanded in a future update, I cannot provide a timeline on when this would be available.

Let me know if you have follow up questions.

• This reply was modified 3 weeks ago by Andrew.

Roman,

The API is setup to only return UBX messages when GPS is locked and outputting NMEA sentences. This is a result of how we package and return this data. For this reason, yes, you would need to see GPS lock before expecting messages.

Is there an event that consistently leads to lost GPS lock? Is it after sending a message? Does your GPS antenna have access to clear sky? I can’t say that I have seen a scenario or heard from a customer that a reboot of the device was required to attain GPS lock. Is it possible one of the messages is configuring the device in an undesirable state?

We only have experience sending the NAV5 message for changing the platform model. That code example is in our SDK (you probably already found it). I have not used the cold boot command. If it forces the GPS to do a cold boot, this will take many minutes or longer to get GPS lock again, I’m assuming you are waiting an appropriate amount of time?

Thank you for the feature request Victor. I will update this thread if we add something to address this.

Andrew

Did you enable the use of the GPSDO? You have to go to the Settings -> Reference menu and tell the instrument to use the reference.

Also, is your DUT being disciplined by the GPSDO?

We calibrate our devices to a GPSDO. If you just put our instrument on it, there might be minimal change (basically whatever drift there has been since we adjusted it in our facility). Once our instrument and the DUT is using the GPSDO, then I expect nominally ~0Hz offset.

CMarkovic,

Thank you for the question.

Unfortunately, there is no feature in Spike to export markers to a CSV.

The only solutions I can imagine for this,

– If you were able to use the peak table for your marker needs, you can copy and paste all markers in the peak table as a CSV.
– It would be possible to write a small SCPI script that you could run at any point and read all active marker values and save them to a file. This would require some programming which I realize not everyone is comfortable with.

Thanks for the follow up.

You are correct that when you are in sweep playback mode, only the swept analysis is available. Unfortunately the other modes I mentioned only work with I/Q and not sweep data, so they are not compatible. Other than the sweep mode recording, I am aware of any other recording or logging features in Spike that would be useful for your specific task (long term logging/recording). I apologize for the inconvenience.

I’m assuming you are using the sweep mode + markers to perform these frequency measurements? This will have limitations, notably the frequency resolution will be limited to your RBW. If you wanted 1Hz resolution on your measurement you would need ~1Hz RBW. At higher RBWs, the freq bins will land on discrete steps that might give you the illusion that one device is more “accurate” than another, in this case it sounds like the BB60D has a frequency bin that lands exactly on 10MHz, and the CW energy happens to be closer to that bin than the adjacent.

We have other methods for measuring the frequency of a CW signal that are preferable. You can use either the frequency difference meter utility, or the analog demod analysis mode, which will provide you a high accuracy frequency measurements of a CW input with faster update rates than a low RBW sweep.

For logging, sweep mode + low RBW might be ideal. There is a sweep recorder which can log sweeps over long periods. Depending on how much time resolution you need, you can add artificial delays in the in the sweep recording toolbar so that you have adequate time and frequency resolution over your 12 hour period without a prohibitively large recording file.

The SDK will allow you to retrieve sweeps and I/Q data. All post processing such as frequency estimation must be performed by your application, but this gives you the most flexibility in how you log your measurements.

Keep in mind, the OCXO you are measuring will have a frequency error. In addition, as you mention, without a known reference, you don’t know what offset either of your SA’s have. A common approach to this is to use an external 10MHz reference, commonly a GPS disciplined one, which has a known frequency accuracy and is generally quite good, and provide this as a reference into the SA’s 10MHz input port. When an external 10MHz reference is connected to the SA’s, you can instruct the device to use it in the “Settings -> Reference” menu.

For any future customers that find this issue,

There is an issue when loading presets between different version of Spike while running Windows 7. To resolve this, we recommend updating to Windows 10 or 11, and if you still have an issue related to this, reach out to support@signalhound.com.

Thanks

Volker,

Can you send this to my email at aj@signalhound.com? The forums blocked the file upload.

Thanks

[Author]

Posts