Forum Replies Created
- Posts
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.
I want to make sure that the trace “Type” is set to “Clear & Write” and not averaging when you make the noise marker measurement. Trace averaging will interfere with the noise marker measurement. The trace average control is located in the Trace control panel in the upper left of the Spike application.
With Clear & Write you should no longer be seeing a different between a 100/100 or 100/10 measurement. Can you verify this?
Can you also provide which version of Spike you are using?
Hi,
You are seeing this because of the trace averaging you are performing. The trace averaging is being performed as dB, not in linear units, and thus will skew the results. You will want the “clear and write” trace type for noise floor measurement. To compensate for the noisier measurement without the additional averaging, you can increase the RBW/VBW ratio. Something like 100/1Hz would perform significant averaging. Increasing RBW would also have an averaging like effect (1000/1).
You will also want to leave the VideoUnits/Detector settings to Power/Average (as you already have them set).
Let me know if you have follow up questions,
ThanksHi mlund,
Unfortunately no. If you are trying to configure either sweeps or an I/Q stream in the API, most of the settings in the Spike software control panels directly correspond to settings available in the API, but you have to write code to properly configure those desired settings. There is no notion of presets in the API.
It should also be known that the device itself stores very little of the configuration (most memory on device is volatile), almost all of the configuration is PC side.
Andy,
Unfortunately this is the only sample rate available from our API.
That being said, in MATLAB, you could use the resample(x,p,q) function like this,
> y = resample(x,9,10)
and y will be resampled to 437500, which would be a nice integer. Is this what you’re trying to do?
Jeremy,
To convert to mV (voltage) you have to use the V = sqrt(P*R) Ohms law relationship. The system is 50 Ohm. This simplifies to
mV = 10^((dBm+46.9897)/20)
You can also derive an equation to go directly from I/Q to mV without needing to log/power the data too.
Use the 32-bit floating point values to avoid the need for an additional scalar.
Is the I/Q data 16-bit integer or are you using the 32-bit floating point data from the API? If you are using the 16-bit integer data, there is an additional scale factor you must account for.
Also, what value are you comparing it to in Spike? If you are looking at a modulated signal, you’re going to need to do a channel power measurement. If looking at a CW, then the instantaneous I/Q power will have more relevance.
dBm = 10*log10(i^2 + q^2) is the correct equation. Make sure it’s log10 not log2.
Look forward to your response.
Hi Devin,
The VSG60 does not provide indication or feedback that an ext reference is present, other than simply exhibiting a large frequency error (in my bench VSG60, the freq error is 38ppm without an ext ref to lock to). Maybe this freq error is enough to detect?
I apologize for the inconvenience.
Hi Tim,
Looks like we clamp at 0dB SNR in the software, so this is going to be a hard limitation right now.
The only workaround would be to generate your own waveform and transmit it using the Arb mode.
I have made a note to look into negative SNR’s and see if this is an easy add for a future release of the VSG software.
Thanks for the feedback.
Ed,
We have lots of customers using PyVISA to do this. We should have a PyVISA example in our SDK. It should help you jump start your project. Hopefully others chime in!
If you are willing to start a direct correspondence with us, please email me at aj@signalhound.com.
We’re going to do a little bit of research on our end to see if we can learn more about how our device performs in a VM.
If it’s possible on your end, I would be curious if running on bare metal makes these issues go away. Running bare metal may not be an option for you, but I think there is value in knowing if the VM configuration is the problem, or if there is still something else limiting the data rates.
Both -6 and -11 are related to network data loss. -11 is simply an indication of UDP packet loss, and assuming packet loss continues or is bad enough you will eventually see a -6 (device connection loss). -11 is generally bad enough that you can’t trust the I/Q data fully anymore.
Here are some troubleshooting ideas and suggestions,
– Ensure you have configured all the network settings we recommend in our network config manual. Ring buffer sizes, socket buffer sizes, jumbo packets, etc.
– Simplify your network to just SM200C directly connected to the PC. If stable, start adding additional equipment like your switch and determine when the issue starts.
– We recommend SFP+ for the full run. if you convert to RJ45 or SFP at any point, this is likely the source of your issue.
– Reduce the sample rate. You didn’t mention what sample rate you were using, but if it’s 200MS/s, try going down to 100/50/25. Any lower than 25 and the network rate doesn’t reduce, but it will perform on device decimation down to 25. This should put significantly less pressure on your network and hopefully contribute to a more stable system.
– If none of the above work, try swapping out fiber/transceivers to determine if there are any flaky ones. Definitely something we have seen in the past.I look forward to your results.