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

Matan,

Using SCPI, you can retrieve the demodulated bit string. This would return a string of ‘0’s and ‘1’s from the Spike software measurement. This is using the :FETCh:DDEMod? command. You can learn about our SCPI commands and see SCPI examples by downloading our SDK here, https://signalhound.com/software/signal-hound-software-development-kit-sdk/

Hello rlisboa,

There is no current timeline on availability for this. You can follow updates here, https://signalhound.com/support/forums/topic/bb60c-api-for-arm/

I will be sure to update the linked thread when we do have something to share.

Currently the only ARM support we have is for the SP145 API, compiled on the NVidia Jetson (Orin AGX) platform.

Regards

Hello Sagar,

We have received your support emails asking similar questions and have responded via email.

Regards

Hi Cyprien,

Unfortunately our software does not have this capability right now, but this is a highly requested feature and is likely something we will be implementing in the future. We appreciate your suggestion and feedback.

Thanks!

For a 20 foot range, I would recommend a USB 3.0 “active” cable. A passive cable should not exceed 6ft. We have not personally tested these, but they have all come from customers who have had success with them, and I have recommended them to many other customers (who have not reported issues).

– FIRENEX-ULS-05
– SIIG USB 3.0 active cable 20 meters
– Cable Matters 10m active cables
– Corning 20m USB to optical cables.

For other customers who might see this post, these active cables should work for any of our USB 3.0 devices. For much longer distances, the Icron USB-Fiber extender is a popular choice with our customers.

Thank you for the bug report Miran. I believe this should be an easy fix.

There is still only Windows support for the VSG25, with no current plans to support other operating systems or CPU architectures.

Andrew

I’m not aware of any workarounds, but maybe someone else will chime in.

We have no plans to support the SA44B on Linux operating systems at this time.

Thanks

Thanks for the feedback Andrew! Glad to hear.

Hi Jeremy,

I responded to your email asking the same question. For others who might be reading, the SA44B is not supported on Linux, only Windows. For Linux support look to our BB60, SP145, or SM200/435 spectrum analyzers.

We have made one small step in this direction yesterday with the release of the SP145 API for the Nvidia Jetson AGX Orin platform. This is a highly requested pairing. It supports sweeps and I/Q streaming with some minor limitations. Hopefully some of you here or future visitors looking for ARM platform support can benefit from these efforts.

If you have any follow up questions or issues with the API, please reach out to me at aj@signalhound.com.

All of these files are now located in our SDK.

Thanks

Hello,

This scenario is also unfortunately not something you are going to be able to make work with the capabilities of the BB60s. The video trigger is a function of software running on the PC, so it’s fully post acquisition and USB transfer. Any sort of trigger mechanism using the video trigger detection would have very poor resolution.

Additionally the BB60s are not really a good choice for generating a pulse. One of the ports can be configured as a logic high or low, but the resolution on this is very poor.

There might be an alternative way to accomplish this. If you have an external trigger source, such as a GPS PPS signal, that you could route that to both BB60s, the API will mark the position in I/Q stream where the external triggers occur and you could measure them relative to the video triggers you detect. A rather elaborate setup and some code to tie it together, but that should give you something like 40ns of resolution on the timing differences between 2 BB60s.

Our other devices, the SM and SP analyzers, have an internal GPS, which with a GPS antenna could be used to timestamp the data, which would also give you a relative timing between the 2 analyzers of ~40ns, essentially trading the need for an external trigger source with an external GPS antenna for each receiver. The timestamping is all done automatically, so the final code might be slightly simpler.

Let us know if you have follow up questions.

Hi Steve,

If you want to use SCPI, then yes Spike has to be running. Spike has a hidden mode, which can be activated by launching it from the command line with a special flag. The Spike user manual details this.

If you want a true headless interface, you could use the API’s which are located in our SDK. The headless APIs support only basic data acquisition such as sweeps and I/Q data. Any additional processing or operations such as markers or channel power, or etc, would need to be performed in your application.

Let me know if you have follow up questions.

Hi Wilson,

Yes, empirical tests have been done. A recent test showed a typical switch time at ~43ms.

It’s important to realize that it can depend on a few things. The 43ms above was done by repeatedly switching frequencies with no I/Q data acquisition at each frequency, probably the optimal scenario.

The switch time includes things like sending the stop streaming command to the device, flushing all USB transfers, cleaning up the large arrays allocated in the API, reconfiguring the instrument, and starting up the stream at the new frequency. Some of these are more deterministic than others.

The BB60 is rather slow in this regard. Both the SM200/435 and SP145 devices have something called the I/Q sweep list in the API. This allows you to preconfigure up front a list of frequencies and I/Q sample counts to collect, and execute this all at once. This brings switching time to sub-1ms at the cost of having to know in advance the frequencies you want to switch to.

The VSG60 is similar in that to get the full speed of 200us, you need to feed the switch frequencies far in advance to keep the queue saturated. If you don’t, the full switch time is more like 100ms.

You may contact me directly at aj@signalhound.com if you want to discuss any of these options in more depth.

There is a company called Jackson Labs that makes suitable GPS modules, I have heard of customers using those products. We have used a ublox EVK-F9T eval kit and Connor Winfield module in the past. The CW module suffered from the 19.6 year rollover issue, so if you bought one used it might suffer from this.

If you aren’t aware, our SP145 and SM200/435 receivers have a built in GPS for timestamping and disciplining. We have certainly heard about the lack of suitable external GPS modules and the SP145 is becoming popular for this reason.

[Author]

Posts