Forum Replies Created
- Posts
Hello Maurool,
The IF bandwidth of the SA44B is only 250kHz (internal sample rate of 486kS/s). This is the maximum bandwidth on which you can make instantaneous measurements. A 2 or 4 MS/s sample rate would produce a signal with roughly 2-8MHz of bandwidth, exceeding the BW of the SA44B.
The BB60C is our most affordable analyzer that could measure signals with these sample rates with a IF BW of 27MHz.
Let me know if you have further questions.
Regards,
AndrewHi Kaiser,
I updated the SDK with a rebuilt SM API 1.1.7. I tested it on Ubuntu 18.04 before uploading. I’m not sure where it got corrupted before. Thanks for your patience.
Regards,
AndrewHello Udeerna,
Can you please email support@signalhound.com and we will help you troubleshoot this issue.
Can you provide the following information in your email to get us started.
– The serial number of your unit
– The type of waveform you are generating? (e.g. CW, modulated signal) What are you using to generate this waveform?
– Any screen shots of the measurements? Or any other information that you think might help.
– Make and model of your PC.We look forward to your email.
Regards,
AndrewHi Kaiser,
Thanks for your patience.
I just returned from a 4 day weekend. I should be able to look into this in the next day or two.
Regards,
Andrewmarvistamike,
Can you please email this information to
justin at signalhound dot com
and CC
service at signalhound dot comThey will be able to assist you. Please send them the serial number of your device.
We look forward to your email.
Regards,
AndrewKaiser,
I will look into this.
Which build of the SM API are you using and on which OS?Thanks,
AndrewHi 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,
AndrewKaiser,
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,
AndrewHi 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,
AndrewThank 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,
AndrewKaiser,
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
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
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,
AndrewSpike 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,
AndrewHi 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