Forums › SM Series Discussions › SM200B Frequency Trigger
- This topic has 6 replies, 3 voices, and was last updated 4 years ago by
Justin Crooks.
- AuthorPosts
jjoonathanParticipantHi!
I am trying to obtain a stable trigger in zero span mode on a signal that involves a frequency sweep. This is the same underlying task as seen in the sister post “SM200B Video Trigger.” The kludgy external trigger workaround I mentioned in that post satisfies my immediate needs, but the most natural fit for the task would be some kind of “Frequency Trigger” — a bandpass filter of some frequency and width followed by a detector and thresholding/hysteresis stage. Maybe a pair of such filters to separate upwards sweeps and downwards sweeps.
At first blush, I thought I might be able to replicate this to some degree using the Frequency Mask Trigger (which is a brilliant feature, btw). What is a Frequency Trigger but a simple special case of a Frequency Mask Trigger? Unfortunately, I had forgotten one key difference: time resolution.
According to the manual, FMT is calculated with 50% overlap FFTs, which appear to be fixed length as a function of sample rate. For example, at 250MS/s, the length is fixed at 65536, which means that the time resolution of the frequency mask trigger is 32768 samples, or 131μs. In practice, this seems to correspond to jitter of about 30μs, which was too much for my purposes.
The ability to change the FMT FFT length would let one trade off FMT frequency resolution (65535 points is excessive for picking up a sweep) for time resolution (one trigger sample every 32768 samples is anemic for picking up a sweep). Alternatively, the architecture in the first paragraph would provide single sample time resolution by simply swapping the coefficients on a filter bank rather than re-configuring a FFT.
I suspect these abilities are already on the roadmap (Shahriar mentioned frequency and phase triggers in his review) but I’d like to add my vote 🙂
Thanks!
Attachments:
You must be logged in to view attached files.
AndrewModeratorjjoonathan,
You can change the FFT size used with FMT triggering by adjusting the RBW. If you change the RBW to 1MHz for example, a 1024pt FFT will be used (round up to the next power of 2).
You might need to adjust your FMT after you increase the RBW since the noise floor will increase.
The min/max FFT sizes that are actually used on the hardware are [512/16384]. Anything below or above those values will be clamped.
Hopefully this help improve the jitter enough to be usable.
You might already be aware, the API is available, and the 250MS/s I/Q captures are can be programmatically controlled through the “Segmented I/Q captures” API. We have several examples of this in the SDK. For your chirped signal, you could setup the video trigger level as you are in Spike, collect the data, and realign the trigger post acquisition. (basically run another video trigger in software). Justin mentions the video trigger limitations in your other thread.
We appreciate your feedback and detailed posts. It’s great to see the wideband captures being pushed to their limits!
https://signalhound.com/software/signal-hound-software-development-kit-sdk/
jjoonathanParticipantThanks for the detailed answer! 512/2 sample trigger resolution is definitely better for this application than 1638/2 sample trigger resolution. I still want to toss in a vote for additional trigger capabilities that might drive that down towards 1 sample 🙂
You’re right that I’m inevitably going to need the API, but for one-off debugging and quick checks it’s nice to stay in the GUI.
Is there a way to control the FMT resolution independently of the spectrogram in Spike since it also uses Zero-Span>FFT Settings>RBW?
AndrewModerator- This reply was modified 4 years ago by
Andrew.
Would having the ability to disable the software IF filter be of interest? That would resolve the issue you mentioned in the other thread, the AM plot would line up with the trigger position. The hardware filter rolloff is a bit rough without this filter, and there is some foldover/aliasing at the band edges, I don’t know if that would affect your measurements.
There isn’t a way to control the FMT size independent of the display RBW size right now. The idea was to ensure the customer could visualize the noise floor at the given FFT size. That being said, I could see the need to uncouple them. I will make a note of this, I don’t think it would be difficult to add in a future release.
Regards
jjoonathanParticipantDisabling IF filter: If the only tradeoffs were gnarly rolloff and uncalibrated amplitude, sure, but antialiasing is a considerable foot-gun, especially for swept signals like mine. I would probably not opt to disable IF filters for my application. After all, I was able to obtain a stable trigger with the filter in place, it was just in an unexpected location. It might be useful for other purposes… but it’s definitely a foot-gun and not motivated by this particular application so I wouldn’t mind if you kept the option restricted to the API layer.
As for independently controlling FMT FFT size, I think that’s worth the effort to expose. In a perfect world, it would do its own FFTs for the purposes of the preview, but since FMT configuration already happens in a separate dialog, you could probably get away with hijacking the RBW setting while the dialog was open if that’s significantly easier. In any case, a slider akin to a multimeter “resolution / speed” tradeoff slider (but with frequency resolution / time resolution) would be an elegant way to expose this setting and intuitively communicate both the “50% overlap” architecture from the manual and the 512-16384/power-of-2 nuance that you’ve mentioned in this thread. Of course, once that tradeoff is communicated you’ll have people like me asking for time resolutions finer than 512/2 but every step forward is worthwhile even if they can’t all be made at once.
Cheers,
JAttachments:
You must be logged in to view attached files.
jjoonathanParticipantSo I was doing some customs paperwork (unrelated to my SM200B) and ran across a familiar bandwidth rating. It struck me that disabling the 160MHz IF filter might not be the most casual feature to toss in there — it looks like export controls might kick in at 170MHz and require licenses for Missile Tech and National Security if you want to export to anywhere but Canada. I’m sure you have a handle on the exact details, I just thought I’d drop a reminder in case they need to be reviewed.
https://www.law.cornell.edu/cfr/text/15/appendix-Supplement_No_1_to_part_774
3A002
c.4.a. ‘Real-time bandwidth’ exceeding 170 MHz; and
Justin CrooksModerator- This reply was modified 4 years ago by
Justin Crooks.
- This reply was modified 4 years ago by
Justin Crooks.
- This reply was modified 4 years ago by
Justin Crooks.
Yes, we can’t stream (gap free) more than 170 MHz of bandwidth without a lot more paperwork. We can’t frequency mask trigger on more than this either. But for short captures followed by gaps, it is my understanding that the same rules don’t apply. That being said, I don’t think we will allow the filter to be disabled, but future products will probably have more filtering on the FPGA to avoid this video triggering on strong signals outside the bandwidth.
- This reply was modified 4 years ago by
- AuthorPosts
You must be logged in to reply to this topic.