Forum Replies Created
- AuthorPosts
AndrewModeratorHello Ajaykumar,
Look in our Spike software manual (linked below). In section 4.14.5, we provide a measurement walkthrough for our WLAN measurements. This should provide you with several steps for setting up the measurement for the first time. To get a nice looking constellation you will have to use our WLAN measurement mode. No other measurement mode in the software will show you a constellation of a Wifi signal.
https://signalhound.com/sigdownloads/Spike/Spike-User-Manual.pdf
Andrew
AndrewModerator- This reply was modified 1 year, 9 months ago by Andrew.
Awesome! We’ll definitely take a look at this. I think we tried to do something similar in the past.
Thanks!
AndrewModeratorThe FFT processing is done in software. There is processing time associated with each sweep and there is blind time between sweeps where events can be missed. This is a general shortcoming of swept based spectrum analysis, and if your goal to capture 100% of short duration events, measurements like real-time and I/Q streaming are required.
Andrew
AndrewModeratorHi Jing,
The interference hunting mode is not a real-time measurement, it operates using standard sweeps. This means for short duration events like the ones you are measuring, you can miss them. Increasing the RBW can help improve sweep time.
If all of your events are within a 27MHz span, you can use our real-time measurement mode to be able to visualize all events in the frequency domain, and use our sweep recorder to capture these events. The data format for the sweep recording is different than the recorded data in interference hunting mode, but all events that have 2ms duration will be visible.
You can also record events in zero-span using the I/Q recorder in zero-span mode. You can set up a video trigger and capture a sequence of I/Q time domain files that should contain a significantly higher percentage of the events than you capture in interference hunting mode. Depending on how the pulses arrive, it may not capture 100% of them.
Another option is to use the API in I/Q streaming or real-time mode to capture data and programmatically store the events of interest.
Andrew
AndrewModeratorThanks for the additional feedback!
Andrew
AndrewModeratorThere is not currently a way to extract that value. It is something I could add relatively easy (I believe) for the next release of Spike.
In the meantime, if you are retrieving the I/Q data, you can make this measurement with the equation
10*log10(mean(I^2 + Q^2));
In spoken word, calculate the linear power of each I/Q sample, I^2 + Q^2, calculate the mean of the linear powers, then take the 10*log10 of that mean.
This would give you the average power in dBm over the sample interval of your choice.
Given this, would you still be interested in a SCPI command to retrieve this value?
I look forward to your response.
AndrewModeratorJing,
We do not sell or provide antennas with our products. You will need to reach out to whom you purchased our products to find out what antenna they provided you.
Andrew
AndrewModeratorTuong,
The I/Q recorder in Spike is not open source. That being said, we could look into extracting some useful code from the recorder as an example for customers to use. I will consider what this would look like.
We have a much older open source recording utility that was written for the BB60A/C many years ago. It illustrates multi-threaded recording of full IF/IQ data. It will likely not compile against our current APIs, but it might be helpful for you.
https://signalhound.com/sigdownloads/BB60C/BB60_Demos.zip
Andrew
AndrewModeratorThanks for the feedback. We are continually evaluating ARM as a target. It is unfortunately more involved than a recompile (otherwise we would definitely have done it!), there are large amounts of x86 specific code that need to be rewritten/refactored for ARM.
Andrew
AndrewModeratorWe currently do not support ARM based CPUs for any of our products. Our devices are recommended for use with Intel x86/x64 CPUs.
Andrew
AndrewModeratorTuong,
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
AndrewModeratorThanks 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
AndrewModeratorWhen 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.
AndrewModeratorHello 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
AndrewModerator- This reply was modified 1 year, 12 months ago by 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
AndrewModeratorOur 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
AndrewModeratorThanks 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
AndrewModeratorAKalman,
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
AndrewModeratorAndrew April 13, 2022 at 3:31 pm in reply to: diagnostics don’t work after the device has been initializedFor 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
AndrewModeratorSpecifically 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
- AuthorPosts