Kaiser,

I will look into this.
Which build of the SM API are you using and on which OS?

Thanks,
Andrew

Hi Kaiser,

We don’t have any documentation on the step locations, and after reviewing the code I suspect there is not an easy way to determine this information based on settings alone. I had incorrectly remembered it being easier to determine than I originally thought.

I apologize for the inconvenience.

Regards,
Andrew

Kaiser,

OK, I’m glad to hear that would be an adequate feature for you. I will look into seeing what it would take to introduce this.

For the record, attempting to call setGPIO between StartSweeps will crash the device. It currently does not check whether any active USB transfers are occurring before sending the GPIO command, potentially clobbering the sweep transfers.

You should be able to simulate it with crashing by finishing each sweep before setting the GPIO.

Regards

Kaiser,

I don’t think the GPIO sweep switching is going to be adequate for your task since you are doing the 100MHz spans. It was originally designed to antenna switch over multiple GHz sweeps. It only operates at the granularity of the LO step freq which is 160MHz in your case, or 40MHz in the slower sweeps.

The I/Q GPIO switching you saw does not work in sweep mode.

Thinking about what we could add to the API, what if the API gave you the ability to queue GPIO switches in between sweeps. For instance, insert a single GPIO switch in between StartSweeps? Do you think this would be adequate for your measurements?

I don’t think it would slow down the sweep speed at all.

Given the 100MHz span, I think you would have to give up sweep speed to accomplish what you need with our current API.

If you think the proposed solution would work, I can potentially look into adding this for a future update? You could simulate this by calling
smGetSweep() -> smSetGPIOState() -> etc..
albeit at a slower sweep speed.

Regards,
Andrew

Hi Kaiser,

It sounds like most of your assumptions about the API are correct regarding timings/etc.

FinishSweep returns when the data has returned and that data has been processed. One of the issues here is that the API will batch several operations/transfers together when we can, and in the event of queued sweeps, if you queue up several small sweeps, it might collect and process all these sweeps at the “same time” as seen by the PC (all the data is returned from the FPGA in the same transfer). So the FinishSweep might return and all the sweeps might already be done. It’s not until you get to wider span sweeps where FinishSweep could return when the next sweep has only just started.

I think the only way to guarantee some action occurs between two sweeps (at a software level) is to start/finish 1 sweep at a time.

If you can operate in a 40MHz bandwidth, using I/Q streaming with external triggers into the device to help sync would be a good way to go.

The software interrupts are an interesting idea, but I do think they would suffer from the same issue, where USB commands and data xfers would be batched together at times and it would be impossible to insert a software interrupt between two very small sweeps since they would occur back to back all on the FPGA. (FFTs for ‘fast sweep mode’ occur on the FPGA, so once the data is xferred back to the PC it doesn’t undergo any extensive processing.)

The GPIO sweeping mechanism (changing the GPIO on frequency crossings) was designed with this type of problem in mind and it sounds like you have already evaluated this feature.

Would an external trigger indicating a sweep is starting/ending be of interest? It’s not something we can do right now, but maybe we could consider it for a future update.

Regards,
Andrew

Thank you for the information Andy. I have made notes of your requests and will see about getting this functionality in a future release of Spike.

Regards

Hello Maksym,

You are correct in noting the BB60C triggering accuracy is only provided at the output sample rate. This means if you need higher trigger precision you would need to stream at a higher sample rate and then filter/downsample after retrieving the I/Q samples. I apologize for the inconvenience.

Regards,
Andrew

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

Hi Andy,

Thank you for the request. You are correct in noting that the overload condition is not stored in the sweep file. I can look into adding this in Spike.

It sounds like you are saving the files in Spike and parsing them in your own application? If so, simply storing the overload condition would be adequate for your needs? If there was a setting to not save overloaded sweeps, would that also be adequate?

I look forward to your response.

Regards

[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 6 years, 4 months ago by Andrew.

Attachments:

You must be logged in to view attached files.

Hello DJSbriscoe,

It sounds like you are prepared.

The big things to look out for are,

DC – which sounds like you have handled.
+20dBm max into the unit – Which the attenuators will help with, or an RF limiter can help.
Connecting an antenna – Having yourself grounded or having an RF limiter on the front end will help with connecting an antenna on the front end. High risk being static on the center pin into the unit.

Regards,
Andrew

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

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

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

The scaling was changed to be more representative of the actual contribution to that bin. We had arbitrary scaling which was not consistent across all of our devices, so we changed it so that the scaling factor is ‘correct’, IE divide the number of hits in that bin by the total number of possible hits for that bin.

In general this resulted in a decrease of absolute values but will still plot the same if you increase the sensitivity of your coloring algorithm. That is what the slider does in Spike, it changes what is considered ‘full scale’.

I hope this helps,
Regards,
Andrew

1) The sampling rate is 80MS/s IF which we convert to 40MS/s IQ.
2) Yes, we do overlapped FFTs. I apologize, 1.25 is not necessarily the exact number, it’s going to depend on the overlap amount. The idea being the same though, the energy needs to be present in a significant portion of the FFT to show up at the correct amplitude on the spectrum.
3) It depends on what you need from the measurement. This will also mean that the waterfall only has 30ms resolution, which some people might want a smaller resolution, in your case see activity in the waterfall between the pulses.

Regards,

Hello Andrew,

You are correct in noting that the ADC overflow is not tied to the IQ samples. We would need to do a bit of work to make that happen.

Right now, the ADC overflow flag is a boolean that is cleared once per call to GetIQ. Setting purge to true will not clear it right now.

Until we change the behavior of the API, it might be appropriate to ignore the ADC overflow flag when you want to purge IQ?

I apologize for the inconvenience. I will make a note of this issue and in the future maybe we can improve the reporting of the ADC overflow flag.

Regards,
Andrew

Hello Bittware,

The maximum sample rate of the SA44B at the IF is ~486kS/s, which means a 5us pulse would only appear in ~3 samples. Generally in real-time modes, the energy of a signal needs to be present in 1.25 FFTs worth of data. In fact the Spike software even tells you the signal duration required for 100% probability of intercept (for the signal to be represented on display within 3dB). At the highest RBW, the 100% POI requirement of a signal is 592us. Once signals start becoming shorter than this, the energy level displayed will decrease.

In short, the SA44B is not the best tool to measure this type of signal using real-time mode.

What you can try, is using zero-span mode to capture the pulse in the time domain. A 5us signal can be captured in this mode. I have included a picture of this configuration with my SA44B. I used a 5us pulse with 80us period to demonstrate. The spectrum plot in the zero-span mode will still not be accurate, but you can get a good idea what the pulse looks like in the time domain.

The BB60C or SM200A would be better analyzers to measure this type of signal in real-time, the BB60C has a minimum 100% POI of 4.8us. As you have noticed though, the sweep time of our real-time mode is ~30ms and will also be that for the BB and SM. We accumulate ~30ms worth of spectrum before displaying the results in real-time which means you will see the accumulation of several pulses in your config in one sweep. At this point we are unable to have a finer resolution than this.

Regards,
Andrew

Attachments:

You must be logged in to view attached files.

Mike,

Yes I think I know what’s happening.

The MATLAB example folder includes the bb_api.dll which is outdated. If you have a newer BB60C only the latest versions of the API will be able to be used. (The older API version can’t recognize your newer BB60C) In that same SDK, go to the core API folder and copy over the newest API.

I’m assuming you are running 64 bit MATLAB so I think you just need to copy over the 64-bit API and header, overwriting what is already in the MATLAB folder. Copy the contents from
signal_hound_sdk\device_apis\bb_series\win\lib\x64
into the MATLAB folder with these existing files.

I look forward to your results.

Regards,
Andrew

Hi Charles,

Thanks for the feedback. I’ll look into this, or at least see if there is a quick way to add something to solve this. It may involve adding dummy or duplicate points. Unfortunately I can’t provide a timeline for this right now.

I appreciate the requests and feedback you have been giving us. I hope some of the added functionality has been of use to you.

Regards,
Andrew

[Author]

Posts