I recently starting using a program called Virtualhere, which send the USB signal over ethernet. The camera is a QHY 5iii 678C. Two questions:
1) The camera won't start streaming frames until I toggle the "force still mode" on and off. (It worked normally under a direct connection)
2) The USB throughput seems to be much higher than what I expect for the images. For example, if I use 800x600, RAW 8, I measure 800-900 Mb/s over the network, whereas I would have expected 800 x 600 x 8 x 30 = 115Mb /s. Not sure if this is how the camera is supposed to work, or something I can blame on Virtualhere's USB to ethernet translation. This is waaaayyy higher than the network bandwidth if I run Sharpcap on the host computer and send the video stream over Remote Desktop. But in this case, the host computer's CPU kind of chokes and I get glitchy video on the client.
Virtualhere, USB thruput, and QHY 678C
-
admin
- Site Admin
- Posts: 13473
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: Virtualhere, USB thruput, and QHY 678C
Hi,
unfortunately I don't have any experience with the VirtualHere product, but my guess would be that it is altering the timings (and possibly even the ordering) of some USB messages between the camera and the computer, meaning that you get glitches like the refusal to start until you switch still mode on and off again (this stops and then restarts the video mode on the camera - presumably the first attempt at video mode start had an issue, but the retry works).
The data overhead on the network sounds very high - your image data calculations look correct, and I can't see why there would be a factor of 8 overhead for video data transfer. Maybe there are a lot of small 'status update' packets that need to be sent across with not much data in each but a lot of overhead? I guess you would need to follow up with the makers of the virtual USB product to see if they have any idea.
cheers,
Robin
unfortunately I don't have any experience with the VirtualHere product, but my guess would be that it is altering the timings (and possibly even the ordering) of some USB messages between the camera and the computer, meaning that you get glitches like the refusal to start until you switch still mode on and off again (this stops and then restarts the video mode on the camera - presumably the first attempt at video mode start had an issue, but the retry works).
The data overhead on the network sounds very high - your image data calculations look correct, and I can't see why there would be a factor of 8 overhead for video data transfer. Maybe there are a lot of small 'status update' packets that need to be sent across with not much data in each but a lot of overhead? I guess you would need to follow up with the makers of the virtual USB product to see if they have any idea.
cheers,
Robin