Hi, Andrew —

We talked briefly a few years ago regarding the need for a way for applications to detect if there have been dropouts in the outgoing data stream ( https://signalhound.com/support/forums/topic/vsg60a-stability-in-cw-mode-versus-multitone/ ). Has any further thought gone into this?

How far apart are the frequencies you need to switch between? Maybe you could do it yourself with a “second conversion” in software.

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.

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?

Thanks much, Andrew, that’s what I thought.

[Author]

Posts