Hello,
My problem is that I have some values (multiple times 0xFF) that are added to the data I receive from VH.
Below an example of what I receive. If I compare it with the direct USB, the multiple "ff" values do not exist in direct USB.
Thanks for the help.
0000 37 02 00 00 24 00 01 00 70 13 00 00 00 00 39 4c
0010 06 00 02 02 00 f0 0a 5c 5f 67 71 00 f8 ff ff 0b
0020 00 00 00 03 00 01 00 61 01 00 00 de a7 13 54 01
0030 09 00 f0 0a 00 00 7a 17 01 00 00 01 07 3f 00 3f
0040 00 3e 00 3d 00 3b 00 38 00 33 00 44 04 02 00 f0
0050 07 12 04 e0 03 7c 03 e6 02 60 10 60 10 2e 10 ca
0060 0f 34 0f 3a 0e aa 0c 35 00 00 02 00 f1 33 06 af
0070 02 eb 09 ca 09 b0 09 98 09 7f 09 62 09 49 09 32
0080 09 24 09 0b 09 fa 08 e8 08 2e 04 48 04 39 04 85
0090 04 a4 08 97 08 85 08 7b 08 73 08 68 08 61 08 56
00a0 08 54 08 4b 08 46 08 42 08 3f 08 3c 08 39 08 35
00b0 04 00 31 35 08 32 0a 00 f1 1c 3c 08 3c 08 48 08
00c0 48 08 4e 08 50 08 56 08 5f 08 66 08 0a 05 fd 04
00d0 92 05 90 08 99 08 a8 08 b7 08 c4 08 7e 00 7e 00
00e0 7f 00 7f 00 80 06 00 00 0e 00 13 80 02 00 d1 84
00f0 00 85 00 8c 00 36 00 83 00 82 00 82 06 00 00 0a
0100 00 11 84 04 00 35 83 00 84 02 00 11 83 0e 00 00
0110 04 00 00 02 00 0a 08 00 71 7e 00 7c 00 84 00 fe
0120 3e 00 50 81 00 82 00 7f e4 00 0f 02 00 22 4f c6
0130 62 42 41 39 00 22 0f 02 00 ff ff ff ff ff ff ff
0140 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0150 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0160 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0170 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0180 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0190 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
01a0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
01b0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
01c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
01d0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
01e0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
01f0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0210 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0220 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0230 ff ff ff ff ff ff ff ff 50 50 00 00 00 00 00
.
Virtualhere does not add data to the stream, its whatever the device returns. Are you using a device that does time dependent transfers. ? What is the device?
Hi Michael, thanks a lot for
Hi Michael, thanks a lot for your very quick answer.
I'm using Bulk transfer mode for the data.
The device is a custom hardware and firmware. The VH Server is a PiZero W, but I've tried with Android and an Onion module et the result is the same.
Do you have any idea why this happens ?
Thanks again.
Hecnel
.
Yes im almost certain your firmware is not returning the correct values. From looking at this it seems its a short packet being returned from the device. You will have to use a usb hardware analyzer between your device and virtualhere and compare with direct. When people have reported this sort of thing with their custom devices it ends up being a bug in their firmware.
Hi Michel,
Hi Michel,
I just run the USB hardware analyser and I found that my device is sending the right data (and the right quantity).
If I compare it with the data I'm getting on the computer side I get that after passing by the VH server, the data gets 256 bytes with 0xFF values.
Any idea ?
Thanks,
Hecnel.
.
Can you tell me the specifications of the endpoint you are reading from (ie. the endpoint descriptor) https://beyondlogic.org/usbnutshell/usb5.shtml#EndpointDescriptors
Endpoint Descriptor.
bLength: 7 (0x07)
bDescriptorType: ENDPOINT (0x05)
bEndpointAddress: 1 IN (0x81)
bmAttributes.TransferType: Bulk (0x2)
bmAttributes.Reserved0: 0x00
wMaxPacketSize: 64 bytes (0x0040)
bInterval FS:1ms HS:125us (0x01)
That's what you asked for ?
Thanks.
.
Im still pretty certain its your firmware. VirtualHere works like this
1. You plug your device into the pi server
2. Device enumeration occurs by the linux kernel on the server. The device is reset, an ADDRESS is allocated and configuration 1 is selected
3. Sometime later the user uses the device via virtualhere. VirtualHere RESETs the device again, then the remote driver on the pc then sends commands to the device plugged into the server. Which usually includes initializing the device again i.e setting the configuration again for a second time, selecting interfaces etc. ready for communications
Perhaps your device is not liking that sequence.
You can remove most of step 2 by using the setting (https://www.virtualhere.com/configuration_faq)
ClaimPorts=1in your server virtualhere config.ini file.
I think you should try again with that turned on. Make sure reboot your pi. Let virtualhere start then plug in your device.
No changes
In that case I think it should be some connections problems, and I don't have any.
However I have done what you suggested and there is not changes at all.
.
OK well unfortunately your device wont be compatible with virtualhere
.
Ok ! I think that's all.
Thanks a lot for your answers and all your work.
Hecnel.
.
Just one small question.
Even the CPU optimized build may have this issue ?
Thanks.
Hecnel
.
No, im certain the issue is in your driver on the client side or in your firmware on the device side.
That buffer you list is a certain length. That length is the value passed over from the client driver to virtualhere. Virtualhere doesnt know what length a packet should be, everything is driven by the client driver on the client side. The device may also return a certain length of data. VirtualHere also doesnt know what the data values are or should be. It just transfers whatever the device returns. Whenever data returned from the device is less than the original buffer passed in, those values are always zerod. So because you get FF your device is returning this information.