Precise Synchronization

I’m trying to capture spectrum from two BB60C’s at exactly the same time, and having some issues.

The two references are locked; one set to output external reference, and the other set to receive an external reference. Good there.

Then I tried just kicking them off at the same time, via something like this, hoping that it would essentially :

` while (j < 1000)
{

Thread FirstSH = new Thread(delegate () {
var status = bb_api.bbFetchTrace_32f(DeviceHandles[0], unchecked((int)traceLen), sweepsMin[j], sweepsMax[j]);
});
Thread SecondSH = new Thread(delegate () {
var status = bb_api.bbFetchTrace_32f(DeviceHandles[1], unchecked((int)traceLen), sweepsMin2[j], sweepsMax2[j]);
});
FirstSH.Start();
SecondSH.Start();

FirstSH.Join();
SecondSH.Join();
j++;
}`

They start at basically the same time, but I can tell that they aren’t. How? Well, I’m essentially trying to measure a signal’s characteristics in two polarizations. So one BB60C on one polarization, and the other on the second. The signal is a TDMA signal (think standard Wifi), and often times one BB60 will see the signal, but the other won’t or have a partial capture, or whatever. So it’s not super-synchronized, which is causing havoc for my measurements.

So, I hook up a waveform generator (btw, feature request; make the trig/sync port be an in/out like the reference for synzhronizing sweeping of units. That would eliminate my need for the waveform generator).

But, the API doesn’t allow me to trigger a sweep from an external trigger (just in zero-span and some other modes). Or at least I can’t find a way for it to let me.

It looks like I could maybe set it to stream, and that would work…but I need to cover ~100MHz on each, and the simple spectral display is all I need.

Maybe I could stream IQ, and then tyr to time-align the trigger buffers between the two? Would that work well for getting me a simple spectral plot?

Anyone have any ideas? Is allowing triggers something that could be added to a mode in an upcoming release?

Thanks!

Hi Kaiser,

You are correct to note that sweeps are not synchronized between devices. There are unknown latencies that exist such as USB timings/etc. We don’t have any mechanisms for synchronizing sweeps for our devices currently.

The traditional way to synchronize measurements for our devices is with the trigger input port in IQ acquisition mode. Aligning the spectrum measurement (FFT) on the IQ data after detecting an input trigger on each BB60C is the way to accomplish this type of task. As you correctly noted, the bandwidth would be limited to 27MHz at that point.

If you are measuring a pulsed signal and depending on your measurement, you may not even need an external trigger, you could simply look for a video trigger (specific amplitude level in the IQ data) and align on that.

While it doesn’t help your current situation, we are investigating a 160MHz IQ BW triggered acquisition for the SM200A.

We don’t have immediate plans to look into a triggered sweep measurement for the BB60C, but we do appreciate you sharing your use case. This can help us guide future development.

Regards

[kaiser]

Thanks Andrew. I understand the USB timing latencies and issues (Which is why I was hoping that I could trigger a sweep via the hardware trigger port). Given the lower bandwidth available in the I/Q mode, we can’t cover the bandwidths needed on the hopped signal to identify it. Also, we need to analyze the waveform to positively detect it for analysis (open-air RF testing, so a simple video-level detect definitely won’t work; has to be hardware). The SM200A has the bandwidth, but also doesn’t appear to natively support a standard triggered acquisition yet either.

I understand that you don’t have plans to look into a triggered sweep measurement, but is it possible to fake it / make it somehow (like fooling it into a tracking generator mode or similar?). Really trying to find a way around this, but it’s looking more and more like that’s not going to be possible. However, I won’t declare defeat until I’ve thoroughly inspected the dll and driver files to see if I can’t fake it by directly working with them 🙂

• This reply was modified 5 years, 9 months ago by kaiser.

Kaiser,

As of right now, none of our devices have firmware support for triggered sweep acquisitions.

I don’t know the specifics of your application, but the SM200A has a 1THz per second sustained sweep speed, which means you could for instance sweep a 100MHz span ‘sustained’ (IE by queuing up sweeps) in less than 1ms. This would give you a 1ms or less resolution up to a 1GHz span for sweeps. I think this would be about the best you could do with standard sweeps and our devices.

Regards,
Andrew

Thanks. Is it possible to get one (or two) to test with for just a couple of days? See if it works for or application?

I’ve been thinking about using on BB60 to find the signal, and then narrow the second onto the signal and execute some quick sweeps (switching between polarizations). On Spike I can’t get a sweep faster than 6-7ms (displayed). Do you have similar sweep rates, etc so I could compute sweep acq time vs signal on/hold time and see if I might be able to get good back to back measurements?

Thanks

Spike does additional processing per sweep that could be slowing it down a bit. You should measure the sweep times using the API for an accurate number to see if it would be adequate for your application. The BB60C doesn’t have any sweep queuing mechanism, so you incur the over head of processing and USB latencies for each sweep. 6-7 ms is probably the ball park for the fastest possible times.

We don’t have an SM200A demo/loaner program. If you are outside the US, your distributor might have a loaner program.

Regards

I’m using twin BB60Cs in something similar. And I’ve been through the same issues roughly two years ago.

(1) If you pass reference clock from one receiver to the other you need to properly set the reference clock frequency in both. When you will get proper time alignment you will see the drift. Discuss with Andrew about the special, kind of “dangerous”, API calls for properly setting the timebase information.

(2) Use IQ streaming instead of sweeping.

(3) Use an external trigger! A simple controller that can issue the sync pulses whenever you need and then align the samples in software. But be aware that there is a 4 samples pulse position imprecision at widest streaming bandwidth, as far as I recall. In my case the upper level algorithm automatically compensates it.

I’ve done all of those things (shared clock, external triggers) and it got a lot better, but still wasn’t giving me the synchronization I wanted.

I did put it in IQ streaming, and and set it all up with Spike, but again it just didn’t quite get me where I wanted to go.

I bought an SM200 to give a try and see if it’s super-fast sweep time will allow me to make back-to-back spectrum measurements over 100MHz using a switch versus trying to synchronize the two BB60’s.

If “shared clock” implies getting the clock from one BB60C to the other BB60C, some special API functions must be called in order for the API to use the same reference clock frequency. The 10MHz built into the BB60C is not quite 10MHz, but slightly off. When set to external reference, the API considers exactly 10MHz.

The end result of this issue is a tuned frequency mismatch and slight sampling rate difference.

I don’t see the post I made yesterday up here, so here I go again.

As I said before, I decided to get an SM200A and see how that works. The queuing up of sweeps is huge and really this device is much faster.

Right now I’m scanning 100MHz at ~0.3ms, which is great. Theoretically it could go as fast as 0.1ms (1THz/s sweep rate). I expect that a lot of the increase in time is sweeping the LO back to the beginning of the spectrum? I’m not sure.

Either way, I’m pretty happy with the SM200A and it’s performance.
The capture is a bit noisier, which will require me to add some smoothing or similar to my algorithms, but it’s not a huge deal.
Overall, if I could eek out a bit more performance (faster scans), that would be great. Here’s some prototype code I was using to test it below; any thoughts?

Again, great device!

// Configure the receiver sweep functionality
// Things to note for THz sweep speeds
// smSweepSpeedFast must be set
// RBW must equal VBW and be above 30kHz for Nuttall window
sm_api.smSetSweepSpeed(handle, SmSweepSpeed.smSweepSpeedFast);
sm_api.smSetRefLevel(handle, -20.0); // -20dBm reference level
sm_api.smSetSweepCenterSpan(handle, 2.45e9, 1.0e8);

sm_api.smSetSweepCoupling(handle, 100.0e3, 100.0e3, 0.001); // 100kHz rbw/vbw
sm_api.smSetSweepDetector(handle, SmDetector.smDetectorAverage, SmVideoUnits.smVideoPower); // min/max power detector
sm_api.smSetSweepScale(handle,SmScale.smScaleLog); // return sweep in dBm
sm_api.smSetSweepWindow(handle,SmWindowType.smWindowNutall);
sm_api.smSetSweepSpurReject(handle,SmBool.smFalse); // No software spur reject in fast sweep
sm_api.smSetPreselector(handle, SmBool.smFalse); // No preselector in fast sweep

// Initialize the device for sweep measurement mode
SmStatus status = sm_api.smConfigure(handle,SmMode.smModeSweeping);
double actualRBW = 0, actualVBW = 0, actualStartFreq = 0, binSize = 0;
int sweepLength = 0;
sm_api.smGetSweepParameters(handle, ref actualRBW, ref actualVBW, ref actualStartFreq, ref binSize, ref sweepLength);

float[] sweepMax, sweepMin;
sweepMax = new float[sweepLength];
float[][] sweepsMax = new float[1000][];
float[][] sweepsMin = new float[1000][];
for (int i = 0; i < 1000; i++)
{
sweepsMax[i] = new float[sweepLength];
sweepsMin[i] = new float[sweepLength];
}
sweepMin = new float[sweepLength];

long[] sweeptimeEpoch = new long[1000];

//the API allows us to queue up to 16 sweeps. They recommend queueing ~4 sweeps
//but we’re pretty narrow sweeps, so let’s try 12 to start…
// Start all sweeps in queue
int sweepsToQueue = 16;
for (int i = 0; i < sweepsToQueue; i++)
{
sm_api.smStartSweep(handle, i);
}
int j = 0;
int queuePos = 0;
while (j < 1000)
{
SmStatus status = sm_api.smFinishSweep(handle, queuePos, null,sweepsMax[j], ref sweeptimeEpoch[j]);

// Process/store sweep here
// Sweep in contained in the ‘sweep’ array

// Start it back up
sm_api.smStartSweep(handle, queuePos);

// Increase and wrap our queue pos
queuePos++;
if (queuePos >= sweepsToQueue)
{
queuePos = 0;
}

j++;
}

My own experience is limited for now to BB60C, and we have used quite a few. So far I have not touched the SM200A.

[Andrew]

Hello Kaiser,

I’m glad to hear the SM200A is a better fit for your application.

There is overhead when using the queued sweeps for smaller spans (<1GHz). It sounds like you are getting around the best performance at that span. If you were willing to go to 300kHz RBW, you could get a bit faster sweep speed. See the attached image from the SM200A product manual that relates span and RBW to sweep speed. It should give you a good idea what kind of sweep speed you can achieve at various settings.

Based on the provided code, I think all the settings are being set to the optimal values for speed, except for maybe increasing RBW if you want to try that.

Let me know if you have follow up questions or comments.

Regards

• This reply was modified 5 years, 8 months ago by Andrew.

Attachments:

You must be logged in to view attached files.

Thanks Andrew for the review. I had tried larger RBW’s, and smaller ones. This was the break-over point where any lower and the sweep time increased, but any higher and there was no change.

Again, thanks.

Kaiser,

One more bit of info that might help. The SM200A in fast sweep mode steps in 160MHz steps. If the span you select happens to be in two 160MHz steps, it will have to step the LO twice for your one sweep. If you shifted your 100MHz span higher or lower you will find a spot where we only have to step the LO once for your sweep, you could get a theoretical 2x speedup (minus some overhead). If you have the flexibility to move the span for certain measurements, you could utilize this.

Regards

Excellent info Andrew. Thanks.

[Author]

Posts