Forum Replies Created
- Posts
mneuman,
Unfortunately the device does not have an idle mode. Once plugged in it will draw ~6W regardless of whether is it making a measurement or not. The only way to reduce power consumption is to unplug the unit. The 50C idle temps will not hurt the unit, but I understand it may be undesirable for other reasons. If you want it to be unpowered while not in use, consider a powered hub you could also keep on your desktop. Some hubs have buttons that allow you to turn off that port.
Regards,
AndrewThanks for the update Gary.
There are limitations on how quickly people can reply to a thread to try and help cut back on spam. If it becomes a problem for our customers we can relax those limits.
December 4, 2020 at 8:21 am in reply to: Feature Request – Clear MAX HOLD when changing frequency parameters Thank you Gary, I was able to immediately reproduce the issue. This is not intended behavior. I can get a fix for this. Until the next release, you can press the “Clear” button on the trace controls when trace 2 is selected to clear the max hold trace. Since we just released Spike I’m not sure when the next release will be.
Thanks again for the feedback!
Regards
December 3, 2020 at 2:29 pm in reply to: Feature Request – Clear MAX HOLD when changing frequency parameters Gary,
That is the intended behavior (for sweep mode). I was not able to reproduce the behavior you are seeing (max hold NOT clearing when changing frequencies). I’m testing this in sweep mode on Windows 10. Can you please provide more information about your setup? Maybe a picture of the software before you make a change and I can try to reproduce it?
Gary,
Try re-downloading it now. We re-included this file in the installation directory. It is not present for some OS’s outside the recommended Ubuntu 18.04, so we have to ship it with our application. It should work for you now.
Thanks
Try setting the sweep time in the API to 1ms instead of 6 seconds. With 1ms the sweep time parameter will be effectively ignored and it will use the minimum sweep time needed to achieve the 1Hz RBW which will be 2-4 seconds depending on window function. If you set the sweep time to 1ms, this will mirror the settings used in Spike more accurately which it sounds like is working for you. Spike also uses the API, so if you are able to find settings that work in Spike you simply need to mirror them in the API to get similar results.
Regards
Thanks Volker,
I was able to track it down. It looks like another display related issue affecting just the limit lines. As before, the limits lines are still being tested the same as they have been for awhile.
I was able to fix this display issue, and can get it in the next release.
I apologize for the inconvenience. I will likely get a release out in the next 1-2 weeks.
Regards,
[See image for your line with fix implemented. Peaks align on the graticule lines and don’t shift left at higher RBWs. Although increasing RBW too much is not recommended with your narrow limit line spikes.]
hquezada,
Consider increasing RBW or using the Nuttall window (rbwShape parameter on bbConfigureSweepCoupling) if the device is unstable at low RBWs like 1Hz. It looks like your PC is unable to keep up with the processing required for the 1Hz RBW on the BB60C. Unfortunately RBWs that low on the RBW require significantly more processing than other measurements.
Regards
hquezada,
You did not mention which RBW shape/window function you are using. I would recommend the Nutall window for this measurement. It will speed up the measurement by about 2x which will help with stability.
Based on the sweep time and warning you are receiving, it sounds like the PC is unable to keep up with the measurement. The measurement as configured will require high sustained USB throughput and high CPU usage to perform, more so than sweeps with larger RBWs, which is why you are seeing issues at this RBW and maybe not others.
The 250s sweep time tells me the API is likely falling behind and getting in an undesirable state. I have configured this sweep in Spike and get consistent ~6 second sweep times. Are you able to reproduce this in Spike?
What is the make/model/CPU of the PC you are using?
Regards
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,
Andrew
