I tried to use a device for flashing some cart via VirtualHere, but it is not very reliable. It seems that the connection to the device is unstable. It seems to work on very short periods of time (a few seconds), but not over 1 or 2 minutes of work.
To be more specific, I am trying to use a flashing device for GameBoy cartridges. The software provided with it works flawlessly when connected directly on the machine, but not when connected via VirtualHere (and since my mouse/keyboard and Bluetooth game pad work perfectly via VirtualHere, I think the connection is ok). It struggles to detect the device, and it produces bad dumps if the dump takes more than a few seconds to produce.
I am wondering if you have any suggestion to solve my problem? (it’s not a big issue if I can’t use VirtualHere with it but it would have been much more convenient).
Thanks in advance :).
- I connect my device on an Nvidia Shield TV Pro 2019, and I use VirtualHere to connect it onto a Windows 11 PC.
- I noticed the flashing device is listed under section “COM ports” in device manager.
OK, sounds like your latency is too high. Is the shield connected via ethernet or wifi? In the virtualhere client right click USB Hubs->About->Statistics. What does that graph show generally?
My usual setup is PC <--5Ghz wifi (1 wall) --> Router <---Ethernet---> Nvidia Shield.
I also run a long ethernet cable from my PC to my router for testing, and I encounter the same issues.
ok to see the statistics can you uninstall the virtualhere client as a service and start it again normally and the statistics button will be there
The statistics button appeared, here is the file.
I first played a bit with the keyboard and the controller, than I connected my flasher and started to dump a rom (it took a few tries to detect the flasher, unlike when connected directly). The dump was bad as before, but I noticed the writing speed was both slower and more stable when VirtualHere is not running as a service.
On the statistics graph, it seems to be low and consistent.
Thanks, yes the latency looks fine. I'm not sure what the problem is unfortunately. I dont think it will work with virtualhere. It might be really sensitive to latency... that's my only guess
I think so. Do you think it could be related to some kind of resets? I wouldn’t be surprised if it needs to make special things to access all the content of a GB game (while accessing saves, which seems to work, wouldn’t require such operations).
If it only presents a COM port to windows and everything goes through that then there is no way for it to reset anything. Especially if it fails half way through. If it failed right at the end then it might be something to do with some internal firmware reset in the cartriage after it has written the new firmware. But i would think in that case it would still write ok.
When it appears as a COM port in Device Manager , right click on that and see if there are any settings to change the buffer window. For example a quick search on google shows this https://docs.openbci.com/Troubleshooting/FTDI_Fix_Windows/ Basically if you have those parameters available it would probably help But i dont know what serial chip (if any) they are using for their USB interface. The above example is for an FTDI chip but there are other types like silabs CP chips
I’ve played a bit with the settings but it’s not working. Anyway, thanks a lot for your help it’s not a big issue :).