Forum Replies Created
- Posts
Hi Andrew4010,
Thank you for expressing interest in a multi-channel receiver. If you have specific measurement requirements please email me at
aj at signalhound dot com
with a description of your requirements. We can use this information for future product development considerations.Regards
We do not have Linux libraries for the VSG25.
Regards,
AndrewHi Jeffro,
Spike can save I/Q recordings in Zero span for 60 seconds. It saves the I/Q data in a basic 16-bit complex short binary format with descriptor file.
If you want to re-transmit a waveform, then you will need another piece of equipment. In the test equipment industry, this would be a vector signal generator. We make one that goes up to 2.5GHz but can only playback patterns that are 2048 I/Q samples long (very short). Something like an SDR would be capable of transmitting a waveform, although you would likely need to do some minor programming to set this up. We are working on a 6GHz VSG which would have the playback capability you are looking for, but won’t be released until later this year.
60 seconds worth of waveform at 20MHz BW is a lot of data and for instruments that have a fixed sized pattern memory buffer, you may struggle to find one for cheap with this amount of memory. 60 seconds at 20MS/s I/Q is 4.8GB stored as 16-bit complex values.
Regards,
AndrewHello Dbreton,
1) It sounds like your understanding is correct. When you select an IF bandwidth of 1MHz, we use a filter with cutoff points (6dB down) that have 1MHz banwdidth. This filter is also applied for the I/Q recordings.
2) (edit) See Justins response below. Also see this paper that lists various window functions and their ENBW/3/6dB bandwidths. See Eq. 11 for calculating ENBW.
https://www.utdallas.edu/~cpb021000/EE%204361/Great%20DSP%20Papers/Harris%20on%20Windows.pdf
We use the “blackman” window from this paper with the 1.73 bin ENBW.Let me know if you have follow up questions.
RegardsThanks for the suggestions. We are hoping the near future to adapt the improvements we have made to zero-span, analog/digital demod to sweep mode. The core of this giving us and the user the ability to scale/drag the plot data independent of the measurement config. I think this starts to open up the door for multiple plot arrangements you have suggested. No time frame on this.
Thanks again.
Regards,
AndrewKaiser,
For normal sweep speed, (via the smSetSweepSpeed function) the resolution on which we can change the GPIO output is multiples of 39.0625 MHz. (N * 39.0625 MHz) If you are using the fast sweep speed, that number is 156.25 MHz but can be offset by a multiple of 39.0625 MHz. (N * 156.25M + 39.0625M * [0,1,2,3 depending on factors]) If you use the same sweep settings, the API will be consistent about what LO steps it changes the GPIO on.
I believe the logic is, that if your GPIO freq exceeds the freq calculated from the equations above, then we perform the switch. If you use these multiples directly, pick a number slightly higher to force the switch.
It sounds like you just need to nail this down for just a couple sweep configurations? This should be enough information for you to start adjusting the frequency on the GPIO steps and choosing the best values for your sweeps?
Regards,
AndrewHello 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