Reply To: Queued Sweep Synchronizations

Forums SM Series Discussions Queued Sweep Synchronizations Reply To: Queued Sweep Synchronizations

#164288
kaiser
Participant

Thanks for the detailed reply Andrew. Like I said, interrupts would be the best case. I’ve extensively used to National Instruments samplers, and my understanding form talking to their engineers is that they open multiple pipes on the USB connection; one for high bandwidth streaming, and one for low latency notification. So, for example if I’m sampling 32 inputs at 16-bits, 30kHz I get a stream very similar to what I get from the SM200A, but also can have extremely low latency notifications (non-deterministic of course, but low latency) of events like sample start / sample end or change detection on some pins. I imagine that it would complicate your drivers somewhat and might not be worth it. Like I said, in a perfect world 🙂

What I’ve done is grabbed one of our microcontrollers (a SAME54 board) from the back, and am working to integrate that. The thought is that I can use the GPIO of the SM200A to notify the microcontroller of when a sweep end. The microcontroller gets an interrupt, and then communicates with the attached equipment to prepare it for the next sweep while the SM200A is running.

Basically, I need to keep the SM200A sweeping my 100MHz band of interest at the 0.3ms sweep time that I am getting now, but also in between sweeps configure my support hardware for the next sweep. I can’t afford to let the sweep time increase any, and I have to sweep the entire 100MHz, can’t get it down to 40MHz.

The microcontroller in debug mode yesterday could update the support hardware at >100kHz, so I should be able to keep the SM200A in fast sweeping mode, and just upon notification of the sweep end (or that the sweep has hit a certain frequency to account for any latency), update the equipment while the SM200A prepares for the next sweep.

I’m running through a couple hundred test states of the support equipment while this happens. So, the best way would be for the GPIO to essentially increment/change every scan. But I don’t see exactly how I could do that with the GPIO; it seems to be more inter-scan focused than intra-scan focused or time-based (which might work).

So let’s talk GPIO:

If I use GPIO sweeping, does it reset every sweep, or run independently? Say I.m sweeping up to 2.9-3GHz. If I set the GPIO sweeping to increment every time I pass 2.99GHz, would it continue to increment every sweep, or reset? If it just continually incremented down the list, that would be awesome. If it resets, then I can probably make it work, but then move a ton of functionality to the microcontroller and end up with potential for them to get out of sync (microcontroller counting pulses, and running the show rather than the main computer telling it which state to go into). Guess that I can probably test this.

With GPIO switching — the examples I saw show it going alongside IQ streaming, and the API indicates that it’s “output while the device is streaming IQ data”. So I assume that it doesn’t work with regular sweeping? If it did, is the timing good enough between it and the sweep, that I could get/keep them synchronized? I didn’t see a great mechanism for that, and am unsure how I would synchronize, but could be missing something.

Still just trying to find the right way to skin the cat here 🙂