RTL2832U on Pi to Windows 7

Submitted by woodpecker on #1

Hi,

I've just loaded the server onto a raspberry pi, I have an RTL2832U USB dvb-t receiver plugged in which I use for software defined radio.

I have loaded the client on win 7 x64 and can see the device ok.

I am trying to use it with the sdrsharp software, this requires using the winusb driver which is installed using zadig.

I can see the RTL2832U in zadig and it says it has installed the winusb driver for it.

When I try to connect using sdrsharp it says no compatible devices found.

Any ideas how to debug this?

Thanks,
Andy

Submitted by Michael on Thu, 2015/03/05 - 21:45

#2

Actually yes i think i know the issue. Another user reported this issue a few months ago and i figured out the problem. The reason is that libusb cannot find the virtualhere USB host controller, so i made a patch to libusb (which i submitted here http://libusb.6.n5.nabble.com/libusb-Patch-to-support-VirtualHere-td571… ) but i dont think anyone did anything with it, so i compiled libusb with the patch.

(Note: sdrsharp uses libusb which uses winusb which talks to the hardware)

1. Back up your old libusb-1.0.dll

The 64-bit version is available here https://www.virtualhere.com/sites/default/files/usbclient/libusb/win64/…

(and the 32-bit version is here https://www.virtualhere.com/sites/default/files/usbclient/libusb/win32/… )

copy that over your existing libusb-1.0.dll file. Then run sdrsharp again and it should work.

Thanks for the speedy reply

I backed up the dll and copied the new one into the sdrsharp directory but it throws an exception when I run sdrsharp now, any ideas?

Thanks,
Andy

Submitted by woodpecker on Thu, 2015/03/05 - 23:05

#7

Tried both but it just throws an exception saying error loading SDRSharp.RTLSDR.RtlSdrIO,SDRSharp.RTLSDR

Submitted by Michael on Thu, 2015/03/05 - 23:38

#8

It worked for me with the airspy which is similar, perhaps something has changed. Anyway seems like it might not be compatible for the time being then with that software/device combination.

Submitted by woodpecker on Fri, 2015/03/06 - 01:18

#10

Airspy also not working, I have the 32 bit dll copied over, I checked the original dll and that was 32 bit. With Airspy I get this error:-

Unable to load DLL 'airspy': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Submitted by woodpecker on Fri, 2015/03/06 - 07:19

#11

I patched and recompiled libusb-1.0 and it works now.

I have another issue though, the data from the USB device doesn't seem to be streaming very well, the decoded audio seems to break about every second, I'm using a pi 2, there's hardly any load and its not using much in the way of network bandwidth, are there any settings to change that could improve the streaming of data?

Submitted by Michael on Fri, 2015/03/06 - 07:47

#12

ok great, so that was the fix thats good to know.

My guess is that the usb buffer inside the chip of the pi is overworked and it fills before it can be sent out over the network, so its done in bursts..

Regarding the streaming, could you try running the server on a desktop computer (e.g ubuntu) as the server instead of the pi. If that works well then the pi is indeed underpowered. If that is also jumpy when running on the desktop its probably the network latency. I have quite a few users who use it with ham radio scanners and it works well for them...

Submitted by woodpecker on Fri, 2015/03/06 - 08:05

#13

I don't think its the pi, if I use rtl_tcp with the pi it streams much better, the trouble is with rtl_tcp is that has an issue where the stream just collapses every now and then, most of the time it will stream 1MHz of bandwidth without any breaks, with virutalhere it won't even stream 250khz of bandwidth?

Its worse over wifi, if it worked the same as rtl_tcp without the stream collapse it would be great.

Submitted by Michael on Fri, 2015/03/06 - 08:31

#14

Im still thinking its the pi,if you can try on a ubuntu vm or something as the server at least we would know for sure if its the pi or not.

Submitted by woodpecker on Fri, 2015/03/06 - 09:08

#15

I've powered up an ubuntu vmware machine but cannot get the client to connect?

Submitted by Michael on Fri, 2015/03/06 - 09:16

#16

Perhaps you are using host only networking, you need to use bridge networking in vmware so you can access that ip from another machine where the client is running

Submitted by woodpecker on Fri, 2015/03/06 - 09:36

#18

It doesn't seem to be running:-

andy@ubuntu:/etc/init.d$ /etc/init.d/vhusbdpin start
start-stop-daemon: unable to start /usr/sbin/vhusbdarmhf (Exec format error)

Submitted by Michael on Fri, 2015/03/06 - 10:43

#19

Yeah that is the arm version. You need to run the amd64 or the x86 version.

e.g to see the version of the binary type use the "file" command

Michael,

Not sure if you already considered creating a pull request on the libusb GitHub repository (specifically on https://github.com/libusb/libusb/blob/master/libusb/os/windows_usb.c) for this patch? If not, could you do that?

(I ran into the same problem with New Matter's Mod-t which uses a slightly newer version of libusb-1.0 – and which throws an error about a missing libc library when I replace their libusb.dll with your patched build (On Windows 10)).

Submitted by Alex_F on Tue, 2018/03/13 - 17:15

#23

Hello! To up a subject, the same problem. Links to the changed dll are unavailable. I ask to give access to libusb for the test.
Thanks.

Submitted by Michael on Tue, 2018/03/13 - 18:37

#24

You need to use the latest libusb, i dont have the dll or patch anymore as its been rolled into the mail libusb build

Submitted by Alex_F on Tue, 2018/03/13 - 23:08

#26

Works, but it is bad.

Submitted by Alex_F on Wed, 2018/03/14 - 01:15

#27

There is a lot of free resources of system for vhusbdarm64, but data are perhaps compressed. How to switch off a compression? In the client of "Compression Threshold" = 0 - there are no changes.

For comparing screenshots from the native rtl_tcp program, the data stream is more in a network.
https://drive.google.com/drive/folders/1lhSOMwENoWtZ7w9jQGNECA7R5dRDD-7…
1,2 - vhusbdarm64
3,4 - rtl_tcp

Submitted by Alex_F on Wed, 2018/03/14 - 02:05

#28

On the server in config.ini changed the CompressionLimit parameter from 0 to 999999999999, result zero.

Submitted by Michael on Wed, 2018/03/14 - 07:29

#29

Thanks for the detailed info. So you are getting 16megabits via virtualhere and 30mb direct. I think this is the network latency. I think what is happening is that small packets are being sent by the rtl device and these are ack'ed , and this extra few milliseconds over the network is slowing the total tx/rx speed down. Im not sure this is going to be resolvable as there is no way to reduce network bandwidth. I assume you are using a 1Gbps network cable? and there is no wifi network between the server and client?

Submitted by Alex_F on Sat, 2018/03/17 - 00:26

#30

Lan 1Gbps
I do not think that it is a network problem.
Screenshot 5 - direct broadcasting
Screenshot 6 - vhusbdarm64 broadcasting
there is practically no difference.
7 - test network

Offer the tests if I am able - I will carry out.

Submitted by Michael on Sun, 2018/03/18 - 15:42

#31

So i think when you say "direct broadcast" i assume you mean you are running a signal handler software program for the stream of radio signal data directly on your orange pi.
Whereas "via virtualhere" means you are running that signal handler program on your pc and sending the raw signal to the pc via virtualhere for processing by a desktop version of that program.

Is that what you mean?

Submitted by Alex_F on Mon, 2018/03/19 - 05:02

#32

Server Orange Pi, soft SDR_TCP and vhusbdarm64.
Client always one Windows 7 soft SDRShart#, he accepts from a network and usb.
Broadcasting comparing only through a network.
RTL_TCP - well works, vhusbdarm64 - very strongly stammers.
Screen 7, 8
Forgive for my bad English.

Submitted by Alex_F on Mon, 2018/03/19 - 05:14

#33

Screenshot 8, 9.

Submitted by Michael on Tue, 2018/03/20 - 07:43

#34

Yes it is the network latency, i think RTL_TCP directly communicates with the device locally and then just sends some data over the network for remote control. Whereas virtualhere will send all data over the network so this is why it is a latency issue. All data must be send over the network via virtualhere vs much less with rtl_tcp

Submitted by Alex_F on Tue, 2018/03/20 - 19:34

#35

I cannot agree with your outputs. Earlier I showed a screenshot where it is visible that rtl_tcp sends to a network of data much more, than vhusbdarm64. rtl_tcp obtains data with usb Orange PI. The last screens show that the flow is processed in sdrsharp. USB2 480 Mbit, Lan 1 meter of 1000 Mbit, direct cross-joint. Ping is shown by screens during broadcast of the compared processes.

Here it is possible to look at source codes of rtl_tcp.
https://github.com/osmocom/rtl-sdr/tree/master/src

Submitted by Michael on Tue, 2018/03/20 - 21:03

#36

Having a quick look at https://github.com/osmocom/rtl-sdr/blob/18bf26989c926a5db4fca29e7d859af… shows that the data coming in from the rtl usb device is buffered in a linked list. Another thread takes these samples out of the linked list https://github.com/osmocom/rtl-sdr/blob/18bf26989c926a5db4fca29e7d859af… and puts them on the network.

Virtualhere works similarly but each time a call to e.g https://github.com/osmocom/rtl-sdr/blob/4520f001d85f01d051eaa42af7b18b6… it will go over the network. Whereas when the rtl-tcp is running locally this call is not sent over the network its just sent directly to the device.

Submitted by Alex_F on Wed, 2018/03/21 - 03:34

#37

Unfortunately not the programmer. I can tell one, I would not come to you to the website if understood what is written in source codes.
All the same I do not understand why there is not enough 1 gigabit of a network for usb twice with smaller speed. Especially the complete channel of a network is not used. WiFi 300mb - normally works with RTL_TCP.
Bye.

Submitted by DualC on Sun, 2018/09/09 - 01:30

#38

Michel, it whould be nice if u can post the working DLL files again as the links doesent work any more.

Submitted by Michael on Sun, 2018/09/09 - 12:32

#39

Actually libusb now has support built-in. So copy the latest dlls from here https://github.com/libusb/libusb/releases (download the libusb-xxx.7z file where xxx is the version number) and then open the 7z file with https://www.7-zip.org then copy the dll files from MS64 (or MS32 if you are using windows 32-bit) and overwrite the files which i think are usually in c:\windows\system32