kaiserParticipantkaiser February 28, 2020 at 11:21 am
So, I’m just looking for some thoughts / insight from some people who have played with a SM200A/B a bit more than I have. I’ve basically used it so far as a fast sweeping Spectrum Analyzer, and it’s worked great.
Here’s my current conundrum. I have a fast-steering RF system. Right now, I conduct some frequency-surveillance. I set it up to scan at ~50kHz RBW, in fast-sweep mode and suck up ~250MHz of spectrum at a 2kHz rate (queueing sweeps to get to that rate). I analyze the spectrum, and do some nice displays, point things out, etc. The SM200 sends out a GPIO pulse as it’s nearing the end of the sweep, which triggers the fast-steering system to move to the next surveillance location. It does that during the down-time as the SM200 repositions it’s LO, and a sweep begins anew. It does this at ~2kHz continually.
So, now when we’ve found something of interest, we want to look at it some. So, in my software when we have that flag, we set the fast-steering beam to take a small portion of it’s time (about 10-total sweeps worth at the 2kHz rate — I need 4-10 individual data points collected) to look at that signal more in-depth. To do so, the system cycles through a couple of quick settings that takes about the 10-sweeps worth. It then goes back to doing the surveillance operation for a couple dozen sweeps, then looks at the signal of interest for a second. It then does that until the flag is cleared that we want to observe that signal.
When we do that 10-sweep in-depth look, it’s still doing the full sweep at 2kHz. But I’m not getting great data from that in-depth sweep, I think because of the N=kTB problem. I should be seeing some amplitude variation on the signal of interest, but it’s getting swamped by just measurement noise (which can be >5dB at these settings, from what I can tell). I’d like to make that in-depth sweep have a bit less variability in order to clean up my measurement some.
What that in mind, here are my criteria:
1. I know my frequencies and bandwidths of interest up front, but don’t get to pick the frequency or bandwidth; I could be give na list of anything in that spectrum).
2. They are relatively narrow-band signals (generally much less than 20MHz wide)
3. They are continuous signals (not pulsing)
4. I generally won’t have more than 3-4 signals defined to look for.
4. They could be spread across the spectrum. Right now I’m monitoring all 250MHz because that’s simple and easy, but I can change that.
5. I do have processing power, so I could stream IQ or do something else more intensive
6. I do need to do this at relatively quick rates, at approximately the rate I’m currently doing things.
So, since I’m fairly inexperienced about IQ streaming with the SM200B I have, and configuring things on the fly, I’m wondering if anyone has any ideas on ways to improve my measurements here. I’m mainly worried about re-configuration times.
Would I get better sensitivity streaming I/Q for a millisecond or so and computing amplitude from there (I assume so)?
Can I use segmented I/Q or VITA-49 packets or something to continuously give me data on all my frequencies of interest?
Could I stream IQ, and change frequencies quickly to look at these different signals?
Can I switch back and forth between spectral sweeps and localized IQ-streams to get good sensitivity at khZ rates?
Do I just have something wrong, and a simple change in config will get me better amplitude sensitivity?
Thanks all for reading my page-long post! 😀
AndrewModeratorAndrew February 28, 2020 at 12:36 pm
I can give you estimate numbers for configuration switch times for I/Q streaming and segmented I/Q for the SM200B.
– I/Q streaming reconfiguration times are going to be between 15-60ms (which includes a small I/Q acquisition at each configuration) depending on decimation (longer for higher sample rates) and the I/Q queue size (see smSetIQUSBQueueSize). I achieve 15ms switch times with decimation 8 (bandwidth = 5MHz) and queue size of 5ms, and 60ms with decimation 1 (bandwidth = 40MHz) and default queue size (41ms). Smaller queue sizes are less resistant to USB data loss, but for short acquisitions, this is probably not a problem.
– Segmented I/Q reconfiguration times are ~20ms (which includes a small acquisition at each configuration). Segmented I/Q captures are limited to 160MHz bandwidth, so if you are trying to reduce noise and measure specific signals, you will need to further tune, filter, and decimate the I/Q data.
I’m not entirely sure I understand the noise issues you are having. If the SNR is low, and you need to know amplitude variation over short time intervals, consider decreasing ref level to -20 or below (if you haven’t already), performing I/Q streaming using a bandwidth that only includes your signal of interest, and performing overlapping FFTs with very high overlap rates. This can get you microsecond level resolution on your spectrums. You can play with this idea in our Spike software in zero-span mode with the waterfall plot.
If you just need to know the power of these signals over time, and SNR is low, you could measure channel power from the sweeps (which would help with noisy signals), or use I/Q and do an AM vs Time approach, and calculate power over a duration of time domain samples.
Some customers use a search/handoff approach. One receiver scanning and another measuring signals of interest reported by the search receiver. This way there is no blind time on the search receiver.
I hope you get some other feedback.
kaiserParticipantkaiser March 2, 2020 at 7:47 am
Thanks Andrew. I had thought we might have to do a handoff, and that’s like plan D. I’m still working through A-C, and seeing if there are any sub-plans to implement.
The times you gave for reconfiguration and super helpful and will help me put together some trade-space regarding how agile (I’ll toss in some margin) we’d be able to do different schemes.
You must be logged in to reply to this topic.