RTL2832U on Pi to Windows 7

37 posts / 0 new
Last post
woodpecker
RTL2832U on Pi to Windows 7

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

Michael
Actually yes i think i know

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-td5714... ) 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/l...

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

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

woodpecker
Thanks for the speedy reply

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

Michael
Try with the 32-bit dll, as i

Try with the 32-bit dll, as i think sdrsharp is a 32-bit program and links to 32-bit dlls...

johannrichard
Pull request on GitHub

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)).

johannrichard
Pull request on GitHubRE:

Actually, I just created the pull request myself.

https://github.com/libusb/libusb/pull/133

Michael
Thanks :) I hadnt yet done

Thanks :) I hadnt yet done that...

woodpecker
Also noticed the new dll is a

Also noticed the new dll is a lot bigger, 743k vs 94k is that right?

Michael
thats ok, i compiled with

thats ok, i compiled with with debug symbols.

woodpecker
Tried both but it just throws

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

Michael
It worked for me with the

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.

woodpecker
I have an airspy as well,

I have an airspy as well, could try that.

woodpecker
Airspy also not working, I

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)

woodpecker
I patched and recompiled

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?

Michael
ok great, so that was the fix

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...

woodpecker
I don't think its the pi, if

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.

Michael
Im still thinking its the pi

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.

woodpecker
I've powered up an ubuntu

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

Michael
Perhaps you are using host

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

woodpecker
The network is bridged with

The network is bridged with replicate physical network connection state ticked

woodpecker
It doesn't seem to be running

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)

Michael
Yeah that is the arm version.

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

Alex_F
Hello! To up a subject, the

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.

Michael
.

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

Alex_F
.

Unfortunately the SDRSharp# device RTL2832 is not found. I set last -
https://sourceforge.net/projects/libusb/files/libusb-1.0/libusb-1.0.21/l...

Alex_F
.

Works, but it is bad.

Alex_F
.

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-7U...
1,2 - vhusbdarm64
3,4 - rtl_tcp

Alex_F
.

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

Michael
.

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?

Alex_F
.

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.

Michael
.

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?

Alex_F
.

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.

Alex_F
.

Screenshot 8, 9.

Michael
.

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

Alex_F
.

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

Michael
.

Having a quick look at https://github.com/osmocom/rtl-sdr/blob/18bf26989c926a5db4fca29e7d859af4... 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/18bf26989c926a5db4fca29e7d859af4... and puts them on the network.

Virtualhere works similarly but each time a call to e.g https://github.com/osmocom/rtl-sdr/blob/4520f001d85f01d051eaa42af7b18b6e... 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.

Alex_F
.

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.

Log in or register to post comments