Forum Replies Created
- Posts
Are you setting purge to true in that example? Effectively flushing any data and triggers that have accumulated?
I see only one GetIQData function call. The BB60C is a streaming device, so how much data do you have accumulated before the actual trigger occurs? Are you sure the trigger isn’t buffered in the API and you just haven’t polled it yet through the getIQ function?
The BB60C API only stores about 1/2 second of I/Q data. If this buffer fills, it will be forced to wrap it’s internal circular buffer. If it takes you 1/2 second to call getIQ after configuring you might have discarded that I/Q data.
Ideally, you would be polling the BB60C in another thread and waiting for the trigger to occur or transmitting the VSG60 waveform and trigger in another thread while you poll the BB60C in your main thread. That way there is no worries about any I/Q accumulation buffers overflowing. If your VSG60 waveform is short, that is probably not the case here, but worth noting.
Dhivagar,
Please check your email, as I have responded to these questions through email.
I am copying my email response below.
The “export as CSV” feature in Spike will only export the data that is visible on the Spike display. Spike can only display up to 4 million points at a time. The recording feature can record much longer durations of I/Q than the “export as CSV” feature. If you need recording longer than 4 million points, you will need to use the recording feature in zero-span mode or use the API and program a custom recording solution. You cannot record longer than this using the CSV feature in Spike.
The data that is stored in the CSV files when using the “export as CSV” feature, is I/Q values. Each line of the file is one I/Q value separated by a comma. Each I/Q pair is separated by a newline. Each I/Q value is scaled to mW. To convert to power (dBm) use the equation 10*log10(i^2*q^2).
You can learn about the I/Q file format when using the Record I/Q feature in zero-span by looking at the Spike user manual on page 77. https://signalhound.com/sigdownloads/Spike/Spike-User-Manual.pdf
The I/Q data store in the recording file is stored as full scale 16-bit complex integers.If you want to convert the I/Q recording to a CSV file, you will need to write a program to parse the binary file. You can do this in any programming language or environment such as MATLAB if you have access to such. We do not provide any such conversion utilities.
Regards
Can you describe what issues you are having with peak tracking? If you have a simple SCPI example that illustrates the application closing by setting a 2GHz span we can look into it and verify it is not a bug with the Spike software.
Otherwise, there is no issue setting a 2GHz span through SCPI. Any actions you take through SCPI commands should work identical as if you performed them with mouse/keyboard.
Jon,
vsgSubmitTrigger and vsgSubmitIQ are part of the VSG60s streaming interface. If you call those functions it will push those actions into the queue to transmit ASAP. For example, if you wanted to transmit a single short waveform synchronized with a trigger, you would call in sequence
vsgSubmitTrigger
vsgSubmitIQ(yourWaveform)
vsgFlush/vsgFlushAndWaitThe vsgOutputWaveform/vsgRepeatWaveform functions are just convenience functions that cannot be combined with others. vsgOutputWaveform transmits your waveform exactly once. It simply calls vsgSubmitIQ and vsgFlushAndWait for you. No triggering is possible with this function. vsgRepeatWaveform is simply a convenience over calling vsgSubmitIQ in a loop. It spins off a thread to do this for you and returns control to your application. If you perform any other action, the waveform being transmitted by vsgRepeatWaveform is interrupted.
If you want to re-transmit a waveform with thg trigger, you will need to recall the submitTrigger/IQ/flush sequence again.
I hope this helps.
Regardsjgauthier,
80% is a good number to use across the board. I will say, there is a trick you can use to ensure you are always getting the maximum available bandwidth. If you simply set the bandwidth equal to the sample rate (100%), then after you configure the receiver you can call the bbQueryStreamInfo function, and it will report the bandwidth that was actually used by the API. It will internally clamp to the upper bound for each given decimation.
The maximum bandwidth for any given decimation was calculated by looking at the decimation filters available at each decimation stage and making a decision about what cutoff frequency is going to give us the performance we need at that given rate.
Regards,
AndrewHi jraymond,
I have heard reports of this as well. We haven’t used or compiled the HDSDR project in a few years. I believe some customers have got this working by recompiling the project against the latest BB60C API. There have been hardware changes since our last HDSDR release such that the newer APIs are needed to interface BB60Cs. You could try dropping in the latest BB60C API to see if that works.
I’m not sure when we will swing back to this project. Maybe some other customers here could make some recommendations.
Regards,
AndrewHi Volker,
Thanks for the bug report and feedback. We are aware of this issue and have implemented a fix for this to be released in the next version of Spike. I apologize for the inconvenience. This issue was created when we introduced the new sweep plot scaling/zoom features. As you noted, this is limited to the display only, the testing on the limit lines remains unchanged. I can get you a link to a previous version of Spike if desired, or you could wait 2-4 weeks for the next release?
I look forward to your response.
Regards,
AndrewJon,
Here is some code to get this going.
First, you will want to ensure you configure the external port to accept a rising edge (or falling) external trigger.
calllib('bb_api', 'bbConfigureIO', handle, int32(0), int32(64));The best time to call this would be right after opening the device and only once. The 64 is taken from the header, it is the value for BB_PORT2_IN_TRIGGER_RISING_EDGE (0x40).
Then you will want to create a trigger array and count just like the iq data.
% Trigger parameters triggerptr = libpointer('int32Ptr', zeros(4, 1)); triggercount = int32(4);In this instance I am creating an array of 4 integers to store trigger positions. If I am only expecting 1 trigger, then an array of one will work fine.
Now I need to call bbGetIQ with these new parameters.
status = calllib('bb_api', 'bbGetIQUnpacked', handle, ... iqarrayptr, iqcountint, triggerptr, triggercount, purgearg, ... nullptr, nullptr, nullptr, nullptr);And pull out the array when it returns
triggers = triggerptr.Value;If a trigger occurred during this capture of I/Q, you will see it in the trigger array.
disp(triggers);Might show
230722 0 0 0Meaning an external trigger event occurred at sample index 230722 (zero-based).
Regards,
AndrewThanks for the clarification.
Yes, you would need to call the vsgSubmitTrigger function from Matlab which you should find easy if you glance at the other wrapper code in VSG60 matlab class.
You could create a loop like this
while(forever) {
vsgSetFreq
vsgSubmitTrigger
vsgSubmitIQ(your_iq_cw_array)
}The trigger is submitted inline with any other function calls to the API.
Hope this helps.
Regards,
AndrewJGauthier,
You will need to write a dedicated function for that. A wrapper function around the GetIQ functionality should be adequate for performing any triggering on the I/Q data. You could perform video or external triggering with this function. (you didn’t specify trigger type in your message) If external triggering, there is a C++ example showing you how to detect an external trigger event, you would need to then align your capture on the trigger position and collect any additional samples required (with purge disabled to ensure continuity)
The API does not perform any triggering for the user, only provides the facilities for triggering to be performed.
Let me know if you have specific questions as you work through this.
Regards,
AndrewHi Jgauthier,
This is a good question. The reason this is called twice has less to do with the purge parameter, and more to do with wanting to discard the first chunk of I/Q samples in the stream. Your assumptions about the purge parameter are correct. There are potentially several FIR filters (depending on settings) that are in the signal processing chain when I/Q streaming. These filters take hundreds/thousands of samples to ‘charge’ and until they do, the I/Q samples will not be amplitude accurate. By calling the function once with the purge parameter, this ensures that the first large segment of I/Q samples subject to this charge time are discarded. This is not necessary, but if you do this, doing this only once after each configure is adequate.
Another interesting component of this, the first call to GetIQ might not purge any samples, as there may not be any samples collected yet on the PC. So the worst case scenario is that the first call is just waiting until some samples arrive on the PC, and the second call is the one that actually purges that first chunk of I/Q to arrive.
Feel free to try just 1 call and see if that affects your application.
Also, waiting some small amount of time (100ms) before calling getIQ after configuring the receiver would ensure that the first call to GetIQ purges the first samples.
We chose to give these samples to the user instead of discard them in the API as they could still contain information just at a reduced amplitude.
If you are using any sort of triggering to acquire your waveform, calling the function twice is probably not necessary.
Regards,
AndrewHello Ewald,
I believe the VSG60 would be able to meet the AWGN requirement, but not the 2FSK requirement (at least with the included software). The minimum symbol rate for 2FSK will be 4kS/s on the VSG60. If you need to go lower, you would need to create your FSK waveform as an oversampled arb file and load it as an arb waveform.
You could use the VSG25, but you would need to use a multi-tone signal to simulate AWGN or create your own arb waveform for AWGN. The VSG25 also has no reconstruction filter on the DAC which will create images that might interfere in adjacent bands. Similar restrictions on the FSK signal for the VSG25 as well, except the VSG25 has only a 2k waveform size limitation, whereas the VSG60 does not. Since you will need to oversample the waveform the full waveform won’t fit in the VSG25 arb memory buffer.
The VSG60 software generates AWGN. In some configurations you might see a spurious signal. The picture below at 1524M shows an example spur as well as the adjacent channel performance of 1MHz AWGN channel. I also include a screenshot of the VSG60 software for this configuration.
Let me know if you have additional questions.
Regards,
AndrewHi Dhivagar,
Yes, the BB60C is capable of a 27MHz real-time bandwidth in all of the frequency bands you listed. The BB60C has a 27MHz bandwidth at all center frequencies >= 20MHz.
Regards,
AndrewQuadsat,
You can enable a channelizer in Spike to basically perform channel powers through the entire sweep before recording. You can select your channel bandwidth. Is this the functionality you need?
Dhivagar,
We recommend the use of the BB60C over the SA44B for pre-compliance measurements.
Regards
Hi Volker,
Thank you for the feedback. I think you might be interested in the peak table functionality. You can find it in the control panel along the bottom of the application in sweep mode. You can activate up to 16 peaks on the screen and measure freq/ampl deltas between those peaks. It sounds like this would satisfy your measurement requirements.
We are also looking into a dedicated intermod measurement in the future. Keep a look out in coming releases.
Regards,
AndrewHi Karlist,
I mirrored your settings in the latest version of Spike and saw a similar sweep time. Neither EMC precompliance or BB60C functionality has changed recently in a way that would affect the sweep times as you are seeing.
The biggest factor in sweep time for the given settings is the dwell time. You will notice that decreasing dwell time has a drastic effect on sweep speed. If somehow the dwell time has changed since you last performed this measurement, that could be the cause.
If you remember updating Spike from a much older version recently, that would be interesting to know. If it is possible to determine that older version of Spike, I could investigate that further.
Regards,
AndrewHi Flo,
It looks like we use the default print resolution which is 6 digits after the decimal. I can look to change this in a future release to print more digits after the decimal, or change the units to Hz.
I apologize for the inconvenience.
Regards
Mikeh,
Which one of our spectrum analyzers are you using? I will try to reproduce this with your model specifically.
Mike,
If you are not currently using the latest version of Spike, is it possible you could update to determine if that is why this is not working for you? I am seeing success with this in Spike 3.5.5.
Regards