Forum Replies Created
- Posts
Peter,
The entire sweep is stored in the recording file. The example you are running simply finds and prints off the peak amplitude point in each sweep. You will need to modify the program if you want to do something different with the data.
Regards,
Andrewmcline,
The biggest source of error is going to be from the RBW. With a 10kHz RBW, the frequency readout on a marker in Spike is going to be +/- several kHz, which is what you see. Lowering the RBW will improve the frequency accuracy of the marker.
Another source of error is going to be from the frequency difference between the two devices. If they do not share a reference, they may be some fraction of a ppm offset from each other. At 700M center frequency, this could be on the order of a 100Hz.
You could use a high resolution frequency measurement in the software such as the frequency difference meter utility. This will give you a much higher resolution than the marker approach.
For a given RBW, the points in the sweep might only be spaced RBW/4 Hz apart. For a 10khz RBW, that might mean 2.5kHz resolution on the points. Similar limitations apply to the E4407 as well, but the frequency of the point the peak fell on might have simply been closer to the true peak of the VSG60. There are certain configurations with the BB60C on which this might happen as well.
I hope this helps. Let me know if you have additional questions.
Regards,
AndrewThere are provisions in our protocol for detecting this kind of data loss. They didn’t make it into the final product but could be added with a software update. Some of our other products drop connection as you describe, the VSG60 will actually drop connection if any issues occur with the DMA xfers, as exposed through the USB API.
The sandy bridge processor is relevant. When we were first developing the BB60A we did development on sandy bridge processors and were never able to get the device to run fast and stable, we found out this was likely due to the Renesas USB 3.0 controllers used during this generation of CPU. The 3rd generation Intel CPUs (Ivy Bridge) started shipping with Intel USB 3.0 controllers and this fixed our stability issues. There is lots of chatter from around that time online (2012) regarding these Renesas controllers. Many companies making high speed USB 3.0 equipment stated to avoid these controllers.
Our user manuals all specify a minimum of 3rd gen Intel processor specifically for that reason, so you have the “Native” Intel USB 3.0 controllers.
You could try installing a USB 3.0 card if possible, there are several that have been tested to work with our products. The startech one has two USB 3.0 controllers on it (one controller for 2 adjacent ports), so it can support two of our devices streaming at their maximum rates.
I released an update to the VSG60 software today that reduces the sample rate on the CW output. It might be enough to be stable on this machine.
Andrew
Hi KE5FX,
This looks like USB data loss to me. If you looked at the CW output in the time domain and it looked like a pulsed waveform (non-periodic/intermittent), that would be the tell tale sign. Definitely looks like a pulsed waveform in the frequency domain.
We have seen this with the VSG60. Here are some ideas,
– A single USB 3.0 port will usually power the VSG60, except on the most ultraportable devices like the surface pro. You could rule that out with a powered hub, but it’s unlikely the issue.
– The PC is underpowered. I would recommend 2-4core or greater i5/i7 processor. We use libraries that are not optimized for AMD processors, so if you are running an AMD, that might be the culprit.
– Enable high performance power plan. See attached picture for instructions. This has helped a lot of customers in the past.
– The power saving CPU mode was one way to combat this on newer machines. Newer (8th gen or newer) Intel processors have a low power state (the C3 state) that interferes with USB transfers. It can create large enough latencies transitioning into/out of that state to cause data loss on our device. We have limited buffering on the device itself to absorb these kind of latencies in the USB3 hardware itself. The USB chip manufacturers suggestion is to spin off a busy thread to keep the CPU busy and not go into this low power state. We do that when Power Saving CPU mode is enabled. We have seen another alternative work, on some PCs you can disable C-states from the BIOS. This will definitely cause your PC to draw more power, but might resolve this issue.
Threads with more information.
https://community.cypress.com/thread/36763?start=0&tstart=0
https://community.cypress.com/message/194853#194853– The sample rate used for CW output in the GUI is 50MS/s which could be lowered to reduce USB requirements. The range of rates that the device natively uses are 25-50MHz. I can reduce the sample rate for CW signals on the next release, I think this would help you on this PC. The rate used for multi-tone is selected based on the multi-tone configuration itself, and it appears there are lower rates that work just fine on this PC. Look out for the next release, I’ll get that in there for you to try.
What OS are you using?
Regards,
AndrewKE5FX,
Yea, you have the right idea. We don’t really specify an exact number of buffers in the API, but you could think of it as about 200 buffers. We chunk the data up into ~1ms chunks maximum and pipeline them. Internally it’s handled as a couple large circular buffers with arbitrary indexes into them. The USB DMA transfers control the flow of the data through the pipeline. Whenever the API blocks on submit I/Q, it’s because the API is waiting for the next DMA xfer to complete and free up more space in the pipeline.
As long as you are submitting I/Q data at a rate faster than your specified sample rate, the API will always have ~200ms of data to absorb any delays.
We chose the 1ms chunk/buffer size because the API needs to upsample and correct the I/Q data before being transferred, which usually means one or more FIR filters need to be run over the data. The small buffer size ensures data keeps moving through pipeline in a ‘continuous’ fashion but is still few enough buffers per second to keep delays associated with thread synchronization primitives to a negligible amount.
Let me know if you have more questions!
Andrewrpettingill,
No the Spike software is not capable of measuring phase noise on a pulsed signal. There is no synchronization mechanism built in to software to synchronize to a pulse. Additionally, the measurement duration can be > 1 second depending on what phase noise offsets are selected. You wouldn’t be able to get much resolution on a 5us pulse.
If possible, I would recommend using a CW output on your transmitter, or you would need to roll your own phase noise measurement using our API or trying to capture the pulse in zero-span and post-processing the captured I/Q waveform.
Regards,
Andrewrpettingill,
We do not publish this information. The communication protocol is proprietary and rather complex as compared to a typical SDR that you might be used to.
You will have to use the DLL to communicate with the device. I apologize for the inconvenience.
Regards,
Andrewrfong,
Please email us at support@signalhound.com and we can assist you further. We can perform additional troubleshooting through email and help you determine if one of your devices is giving you invalid measurements.
Regards,
AndrewSo, you would want to set purge to false. Purge tells the API to throw away any accumulated data in the API, which would include your waveform and trigger location. Once you set purge to false, you will also need to poll the API until you see the trigger position.
Regards
Hi Jared,
Great feedback! It sounds like you are enjoying the BB60C, that’s great to hear.
I do like your suggestions for the precompliance measurements and limit lines. I have made note of them in our request log. Limit lines are due for some additional features, it has been on my list for awhile.
Can you clarify this line? I’m not confident I understand what you mean.
Highlight the row being edited, so you don’t edit the wrong field when you scroll across.
Out of curiosity, how many harmonics are you measuring?
No plans for a VNA at this point, but we have talked about it several times. Maybe someday!
Regards,
Andrewrfong,
If you want to measure the power of a pulsed signal, I recommend using an AM vs time plot such as the one we provide in Zero-span, and using the marker to measure the power during the on phase of the pulse. If you need to use the standard sweep measurement, consider increasing the RBW to improve amplitude accuracy. In general unless the pulse width is as long as the spectrum analyzers acquisition length for a given IF, the amplitude will be lowered, since the acquisition will include both on and off portions of the pulse period. For an FFT based receiver such as ours, this means the signal will not be present for the full FFT, reducing the reported amplitude.
Regards,
AndrewAre 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,
Andrew