Forum Replies Created
- Posts
Tuong,
The .tep and .bin files are specifically for the SA44/SA124 series devices, not the BB60. The BB60C does not place the calibration files on the PC at any point, and as a result the 3rd party software should not need any calibration files. I would contact the 3rd party software developer and ask them about this.
Andrew
Thanks for the follow up. It may be worth setting up a phone call to discuss things further. I think that could accelerate troubleshooting. We can set that up through email if you are interested.
Andrew
When you stop and exit the software are you calling smCloseDevice or smAbort? If not it’s possible the device is still active. If you stop and exist the LED should have gone back to solid green. Flashing indicates data transfer.
I’m not aware of any outstanding issues that prevent the instrument from going between different modes like this. The API can only operate in one measurement mode at a time.
If you had two instances of your software running, this could certainly create this type of issue (let’s say your previous instance of your software didn’t fully close and is still running in the back ground) Our API does not stop you from interfacing the device from two different processes (which is not recommended or supported).
Are you monitoring the status’s returned from the API. When you mention getting garbage data, is it possible you are simply not getting any data and the API is throwing an error? (maybe you are just looking at uninitialized memory?)
If you continue to have issues after further investigations you can contact us directly at support@signalhound.com. You could also create a small sample application that illustrates the problem and we can try to reproduce it on our end.
Hello hhonza,
Changing the zoom level on the spectrum plot unfortunately does not change the spectrogram plot. With that being said, it is not possible to zoom in on the spectrogram plot when playing back from a recording. This is a good feature idea and we will consider in future development.
Andrew
Steve,
I can’t guarantee this would work, but I might try using something like using Wireshark to grab a packet over a WIFI network then copying the payload into our software. Just make sure you are copying the FCS field as well.
If possible, an alternative might be to disable the FCS check (or ignore it), transmit a known payload and verify the payload at the receiver manually looking for bit errors. If you transmitted all 0’s/1’s it would be easy to verify.
Andrew
Our software does not have TETRA demodulation capabilities.
You could reach out to one of the third party software developers that support our products and determine if they have the functionality you require.
https://signalhound.com/support/third-party-software/
Andrew
Thanks for the feedback Jason. Both of these suggestions sound like reasonable things we could add to our software. I have added them to our customer request logs. Thanks again.
Andrew
AKalman,
The SA series spectrum analyzers are unfortunately not supported on Linux. Only the BB and SM spectrum analyzers are supported.
I apologize for the inconvenience.
Andrew
For the SA series analyzers you cannot query the current temperature or voltage while the device is configured for a measurement. As you noticed, the temperature is not updated as long as the device is active. You can call saAbort to put the device back into an idle mode, at which point you can query the temp/voltage again.
Andrew
Specifically for the zero-span channel power measurement, no, you cannot query that measurement via SCPI.
Yes to your second question, you can load presets remotely via SCPI.
Andrew
Ed,
Unfortunately, this specific measurement would not be possible remotely via programming. While our software does accept SCPI commands (that you could send from Labview or Python) for most functionality, the measurement as configured in the picture above (zero-span channel power) is one of the few that cannot be fully automated.
There are some alternatives,
If you knew exactly what WLAN protocol you were measuring and it was not MIMO, you could use our WLAN measurements to fully capture, demodulate, and report the channel power. All of this is available via SCPI programming. You can determine if your signal would be able to be measured under this measurement mode by browsing our WLAN feature document,
https://signalhound.com/content/tech-briefs/802-11b-a-n-ac-ax-wlan-modulation-analysis-in-spike/.If you were comfortable processing I/Q data, you could use the direct device API to acquire I/Q data, and perform the triggering and channel power measurement yourself. The device APIs are provided in our SDK,
https://signalhound.com/software/signal-hound-software-development-kit-sdk/
Our API is primarily C/C++, but we have several examples on how to call our API from Python or Labview.
https://signalhound.com/software/signal-hound-instrument-drivers-for-labview/If you would like to discuss your specific measurement requirements in more depth, consider reaching out to me directly at aj@signalhound.com.
Andrew
Hi Ed,
Using the zero-span mode in Spike, it is possible to trigger on a WIFI signal, and perform a channel power measurement on that capture. See the attached picture with some relevant highlighting, showing a 20MHz WIFI capture in the 2.4GHz band.
The trigger level, capture length, and channel power bandwidth are all configurable.
Once you have the configuration setup just the way you like, you can store all settings to a preset file that can be quickly loaded the next time you run the application.
Let us know if you have further questions.
Andrew
This thread was resolved via email.
Outcome: Disabling spur reject will raise the noise floor by ~3dB. The artifact in question is likely an internally generated spur that is within the specification of the receiver.
Andrew
Thanks for the update.
I’m glad this resolved the issue.
That’s correct, the FW updater can only be run on Windows. You will need to install the Spike software on the Windows machine to ensure the USB driver is installed. The SM200C must be connected to the PC via USB for the FW update.
Andrew
I have been unsuccessful reproducing the issue with the API. Can you potentially put together a short script that reproduces the problem on your end?
I’m also now considering that you are in fact seeing networked data loss, and that could be tied to your specific hardware configuration and/or software.
While I do see the issue in Spike, I only see it ~1 out of 20 or so reconfigures, and the sweep is not corrupted, which led me to believe it was an erroneous warning.
You also have my email if you wish to communicate via email. It is easier to share pictures and code via email moving forward.
Andrew
The API picks the maximum sweep time that ensures all configuration is met. That includes RBW/VBW/sweeptime. Setting a small sweep time ensures the minimum sweep time is chosen based on RBW/VBW.
I would ignore the uncal warning flag for now if it’s being thrown on the first sweep. I suspect it’s being set erroneously. I was able to reproduce this using your settings. The uncal data flag usually indicates network data loss, I’m going to need to investigate further to determine why it’s returning this warning for this configuration.
Andrew