Forum Replies Created
- Posts
Jan,
The automated meter measurements are being actively worked on. Look for this in the next release of Spike.
I’ve added your copy screen request to our request log.
Regards
Volker,
Thanks for bringing this to our attention. This appears to be a bug. We can get this fixed and in the next release of Spike which should be in the next couple weeks.
Thanks again!
AndrewGlad to hear that you love your new SM200B. That’s great!
Regarding preselectors, check out section 3.3 of the product manual linked below for the full description.
https://signalhound.com/sigdownloads/SM200A/SM200-User-Manual.pdf
Above 645MHz, the preselector filters are always on, since we have enough filter overlap to measure at any of those frequencies with any IF bandwidth. The narrower filters below 645MHz are the ones that are controlled with the preselector control. For sweeps, enabling the preselector will slow down the sweep for the benefit of the extra filtering. For I/Q streaming and real-time measurement applications, enabling the preselector means we can only enable a single filter. In these situations, you can refer to the filter list in the above manual to see which filter is used at specific frequencies.
I hope this helps. Let us know if you have further questions.
Andrew
jpetrik,
Thank you for the feedback. I agree this would be a useful feature. Would a button that automatically performs the QP measurement on all current peaks in the peak table satisfy your workflow requirements?
Regards
Hi fgroger,
Unfortunately the VSG25 and VSG60 do not share drivers or codebases. This request is something I could add to our customer request log, but I don’t have any sort of timeline on when I could try to port the VSG25 to Linux. We have not done any work to ensure all drivers are available or that code could be easily ported to Linux. It was designed as a Windows only device.
As far as the SA44B on Linux, we are glad the Linux APIs are satisfactory for you. Just note, we have obsoleted our Linux APIs for the SA44B due to limitations between the drivers and how we handle USB transfers. We noted periodic data loss that cannot be avoided, detected in software, or recovered from in our current design. Something to keep a look out for moving forward.
Regards
Hi Gary,
The sweep time under the spectrum is a measured sweep time. The resolution on the timer is coarse and provides a rough estimate. This sweep time includes acquisition and processing time. The sweep time control is used to specify a minimum acquisition time. We attempt to acquire data for at least as long as the value provided here. There are situations where we may not be able to accommodate this, and there are other situations where we may have to overshoot this value by a bit. Either way, we try to get as close as the hardware will allow.
Regarding acquisition lengths… The BB60C measures spectrum 20MHz at a time and stitches the results together to form the final sweep. At each 20MHz step we might acquire more data than is truly necessary, either due to minimum acquisition lengths of the hardware, increased sweep times set by the user, or even the default 1ms sweep time combined with a narrow span and large RBW, which results in acquiring more time data than is necessary to achieve the selected RBW. We process this time data with overlapping FFTs and use the detection algorithm selected (minmax/avg) to produce the final result. The BB60C always performs as many overlapping FFTs as possible with its acquired data, unless the “sample” video units are selected, at which point, a single FFT is performed, and no minmax/averaging is performed.
I hope this helps.
Regards
Terry,
Thanks for the information.
If you still wanted to try to use the SYST:IMAG:SAV function, there is a common issue that might be tripping you up. For file names over SCPI, standard convention is to include quotes around the file name. So in manuals the command looks like this
SYST:IMAG:SAV “C:\Users\AJ\Documents\SignalHound\images\scpi.png”
In your code though, you will need to be sure to put escape characters before the quotes so they are actually part of the string. So it might look something like this. In C++,
std::string msg = “SYST:IMAG:SAV \”C:\Users\AJ\Documents\SignalHound\images\scpi.png\””;
I find this annoying as it has tripped up many of our customers now, but it makes it really easy to parse filename that include spaces, so I imagine that is why people standardized on this.
I can definitely look into retrieving the temp/voltage through SCPI. This would be a very quick and easy add for us. Look for this in the next release.
Regards
mcline,
In general we have found that most USB 3.0 ports will provide enough current to run the BB60C and VSG60 off of a single USB 3.0 connection. Where the second cable/connection is usually needed is on ultraportable laptops, ones that are optimized for low power consumption like the MS Surface Pro. I have not seen a port become damaged, but on those low power laptops, sometimes what you will see is Windows will shut off that port if it detects high current draw. It’s restored on a PC restart. If you have a machine that exhibits that, usually a powered hub is the best workaround.
When both connections of the y-cable are used, we don’t generally see any issues.
I would recommend the following 3 USB hubs, we know they work with our receivers and have been used to connect multiple devices simultaneously.
https://www.amazon.com/dp/B014ZQ07NE/ref=emc_b_5_i
Let me know if you have follow up questions.
Hi twood,
Thank you for the feedback.
We are looking into the font size issue. It looks like the font size is scaling in ways we didn’t intend. In general, yes we are going for a font size that matches the other text. Looking into that now, once we have a fix, we can get that into the next release of Spike.
The other meta data is something that has been requested often. Hopefully if we can address the font size, the presence of the meta data will have less of an impact on your usable screen real-estate.
I have entered feature requests for your resolution selection and the ability to enable/disable the new on image text. How are you taking images right now? Via SCPI? Or are you logging into the system remotely?
You can download older versions of Spike using this direct link.
signalhound.com/sigdownloads/Spike/Spike(x64)_3_5_12.zip
You can modify the version number. 3.5.12 was the previous version if you wish to go back to this in the meantime. I have mentioned this to our IT dept and potentially we can get an version archive available to users.Thanks again for your feedback.
Regards
gkang,
If I’m understanding your problem correctly, something like the external trigger could help with your problem. If your generator can emit a trigger at the same time as the RF, you can stream I/Q data on one of our receivers and measure the time from the external trigger position to when the RF energy arrives. You can do this with both the BB60C and SM200 using the SDK. We also have external triggering in the Spike application for these two devices, so depending on how complex your setup it, you might be able to do it with Spike.
Let me know if you have follow up comments.
Regards
tyang,
1) This will be difficult to measure. This number will include USB transfers, hardware acquisition speed, as well as buffering and processing latencies in the API. For certain modes like real-time, we only provide sweeps at specific intervals which means the latency for a specific event can be anything up to that interval. That being said, latencies are likely in the 16-100ms range depending on the measurement.
2) In your code I do not see a channel power measurement. Each call to saGetRealTimeFrame returns one sweep and one persistence frame (to create the persistence display). For your purposes you can ignore the frame and just focus on the sweep. You are indexing just a single value in the sweep. The channel power measurement in Spike is an integration over a portion of the sweep based on your settings. There will be additional math to calculate a channel power value on a sweep returned from the API.
We have a couple of resources that can help you get started. The equations for calculating it are in the blog post. I have also attached a file that contains some code snippets from Spike that calculate channel power. You will not be able to compile this code, but it will illustrate the operations involved and you should be able to write your own implementation using it.
https://signalhound.com/news/what-is-channel-power-and-occupied-bandwidth/
Regards,
AndrewHi ghuxtable,
Yes, changes in the reference level affect sensitivity, which change gain and attenuation of the instrument. A lower reference level implies you will be making measurements on smaller signals, in which we increase the sensitivity.
In standard sweep mode, linear scale frequency is the only scale possible. There is no way to plot on a logarithmic scale outside of the precompliance mode. I apologize for the inconvenience.
Regards
ghuxtable,
You can convert to dBm from dBuV by simply subtracting 107dB.
Try decreasing your reference level. The devices maximum sensitivity is ~50dBm or 57dBuV. Your noise floor will drop ~30dB from its current position. This will get you very close to the pictures in the other software you provided. Decrease ref level to 60dBuV or 55dBuV. Any lower than -50dBm and you won’t see any improvement in the noise floor.
Your path loss table values appear correct. Our software will linearly interpolate between your points. If you need more resolution you can also add more points later.
Regards
Thanks for the follow up information Volker.
Did you see the Spike manual section on Noise Figure? We have the equations we use for the measurement. We will be writing a white paper for this soon.
I agree that measuring the noise source once is the best first step for automation.
NF of the BB60C will vary slightly per device, but is roughly the DANL of the instrument + 174. You can find the DANL specs in the product manual.
Hello ghuxtable,
The precompliance measurements mode in Spike would allow you to setup a measurement like the one in the picture you provided, with one limitation, in that we only perform QP measurements at a single frequency. Ideally you would sweep with a peak detector, and check troublesome frequencies with the single frequency QP detector we provide. The single frequency QP detector is only available in precompliance mode.
The SA44 and SA124 are excluded from the precompliance measurements due to their lack of hardware image rejection. Using the SA124 for precompliance measurements will introduce false positive spurious image responses for every real signal input. Without a good understanding of the SA124 architecture it will be difficult to interpret the results.
At this point we do not have plans to enable precompliance measurements for the SA124. The BB60C is the most affordable analyzer we sell with precompliance mode enabled.
You can use the path loss table functionality to enter the antenna factor table. This will be applied for both sweep and precompliance measurement mode. Units would then be in dBuV/m. In precompliance mode, dBuV units are default, in sweep mode, you can select dBuV from the reference level control.
Let me know if you have follow up questions.
Regards
Miran,
Do you have any documentation for the mask you are trying to create? Any standard documents we can review? As it stands, given your current settings, reducing the minimum frequency of the offset to 0Hz instead of 1kHz would have no effect on the measurement. It would never fail in this region. If we extend this lower frequency, I would like to do it in a way that meets your requirements.
Regards
Hi Miran,
Thank you for the suggestion. I have implemented this and it will be in the next release of Spike.
Regards,
AndrewHi Volker,
Thanks for the feedback.
We have disabled the measurement for the SA44/124 devices due to their lack of hardware image rejection. The wideband noise source aliases in at all points in the measurement affecting the results. We have not determined if we will address this.
We intend to revisit this measurement in the future. Reusing the noise source measurements (step 1/2) is something we plan on adding. We agree that it would be beneficial to not need to perform this step for each measurement.
We have also considered how we would perform more automation with the noise source. The trigger idea is good.
We can review the noisy values you are seeing. With some more testing we might be able to reproduce and deal with these. Can you provide any configuration information for the measurements on which you saw this issue? I will include this in my notes.
Can you clarify your last question?
Thanks again for the feedback. This will be very useful for future development. We are happy this measurement has been useful for you. Hopefully we can make it better in future revisions.
Regards,
AndrewHello Miran,
It appears that the 1kHz minimum is an artificial limitation in the software. We could look into removing this limitation in a future release of the software.
The best you could do right now create an offset between 1kHz to 100kHz.
Additionally, given your current settings, if you create an offset that is higher than the measured channel power, it would never fail. Is this close in offset for visual indication only?
Also, the channel power bandwidth used when “Auto” is selected is based on your current offsets. If you created an offset that comes all the way in to 1kHz or below (given a software update), you will want to manually set the channel power bandwidth.
With your current RBW of 300Hz, being able to specify a start frequency of < 1kHz would only test a few additional points. Are you testing against a standard mask? I look forward to your response. Regards
Hi Kaiser,
Would you please email the request to sales@signalhound.com. They can determine if this procedure is possible and provide a quote. Please provide your unit serial number when you message the sales department.
Thanks