VSG60A stability in CW mode versus multitone

[KE5FX]

Have you guys ever seen behavior like this on the VSG60A?

https://youtu.be/lIyLuB0UDDc

Basically it’s unstable in CW mode (i.e., no modulation turned on), but if I use multitone modulation to generate one or more tones — such as a single tone equivalent to the CW output — it works fine.

This isn’t likely to be an actual defect, because the unit is working great in both modes on a different PC. I’m guessing it’s just not getting enough power from the USB ports, since the PC where it acts up has only one USB 3.0 port available. There are no errors in Utilities->Show Error Log, though, so I thought I’d see if there is a known solution, or if there are any other diagnostic steps I should try. It would be convenient to be able to use the VSG60A with this PC, but I’ve had trouble with other USB 3.0 peripherals on it as well, so it may not be in the cards.

(I did verify that the ‘low spur mode’ and ‘power saving CPU mode’ toggles don’t have any effect on the behavior. Same with using internal versus external 10 MHz references.)

• This topic was modified 3 years, 10 months ago by KE5FX.
• This topic was modified 3 years, 10 months ago by KE5FX.

[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,
Andrew

• This reply was modified 3 years, 10 months ago by Andrew.
• This reply was modified 3 years, 10 months ago by Andrew.

Attachments:

You must be logged in to view attached files.

Thanks, Andrew — it really does look like you’re right about it being a data loss problem. This is a reasonably fast quad-core system (i7 Sandy Bridge at 3 GHz running Windows 7 x64) but its USB 3 SS support has always been flaky. Yesterday I discovered that I can’t even use a GPIB-USB-HS adapter on the same root hub without corrupting the data going out to the VSG60A. 🙁 Not much you can do about that.

I’m unfortunately more than familiar with supporting customers with USB streaming problems, myself. As a matter of policy, though, I drop the connection entirely if anything goes wrong. IMO, you don’t need to go to the trouble of checksumming your packets independently of what the USB subsystem already does, but sequence numbers are a good sanity check against dropouts during bulk transfers. Many users will prefer to drop the connection and report an error than to risk breaking phase continuity or other corruption that might go unnoticed until it causes trouble later on. Maybe a warning could be implemented?

[Andrew]

There 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.

https://www.amazon.com/Inateck-Express-Controller-Internal-Connector/dp/B00JFR2H64/ref=sr_1_1?keywords=B00JFR2H64&qid=1582645060&sr=8-1

https://www.amazon.com/StarTech-com-Express-SuperSpeed-Dedicated-Channels/dp/B00HJZEA2S/ref=sr_1_1?keywords=B00HJZEA2S&qid=1582645115&sr=8-1

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

• This reply was modified 3 years, 10 months ago by Andrew.
• This reply was modified 3 years, 10 months ago by Andrew.
• This reply was modified 3 years, 10 months ago by Andrew.
• This reply was modified 3 years, 10 months ago by Andrew.
• This reply was modified 2 years, 6 months ago by Andrew.

Agreed 100%, the older Renesas parts seem to be less reliable. I’ve got a Haswell box with both Renesas and Intel root hubs, as well as one of the cheaper Startech expansion cards which has a Renesas chipset itself. It runs an FX3-based spectrum analyzer (not from SH but similar to the BB60C) that works fine on all of the USB 3 ports except the ones attached to the built-in Renesas hub. The SA has never worked on the Sandy Bridge box, at least for more than thirty seconds or so.

I haven’t tried the VSG60A on any of the motherboard ports on that system, but I’d expect similar results. I imagine the secret to SuperSpeed success with the older 3.0 chipsets is a large FIFO backing up the FX3, but who knows.

The new 1.06 build took care of the problem, so that was definitely what was going on. Thanks for the help! It’d be great to have the option to verify data delivery to the hardware as well. If/when you are able to add that I’d be glad to give it a try.

[Author]

Posts