FCDPro+ support #88
FCDPro+ support #88
Conversation
|
Thanks, I have been waiting for this ;-) |
Add support for Funcube Dongle Pro+
|
On Tue, 16 Jul 2013 07:08:57 -0700
Alexey Bazhin |
|
On Tue, Jul 16, 2013 at 4:18 PM, bazuchan notifications@github.com wrote:
I kept getting aOaOaO... and kernel messages: I have just applied your the patch you posted on the FCD Pro+ list on Alex |
|
On Tue, 16 Jul 2013 07:25:56 -0700
Yes, it's seems to be a bug in ehci_hcd, it reserves too much bandwidth Alexey Bazhin baz@irc.msk.ru |
|
Ok, thanks for the info. we'll work on resolving this issue together with Volker @dl1ksv . |
|
Well, the message "5:1:1: cannot get freq at ep 0x81" is a kernel message from sound/usb/clock.c as some devices don't support reading the sample rate. It's no error and no problem. At the moment I have no real idea how to solve the problem of bandwidth. I saw some discussion on this topic. Some people were of the opinion, that it's a driver error. But there was no fix proposed. Volker |
|
On Tue, Jul 16, 2013 at 5:24 PM, Volker Schroer notifications@github.comwrote:
Alex |
|
I 've now setup a branch hid-usb on gr-fcdproplus. It contains a file hidmac.c, too. In my gnuradio fork on github you'll find a patched version hid-libusb.c |
|
Volker: |
|
hid-usb branch have the same bandwidth problem for me :( But confirming that this hid-libusb.c fixes segfaults (tested with On Tue, 16 Jul 2013 13:18:27 -0700
Alexey Bazhin baz@irc.msk.ru |
|
Hmm, strange. I have tried it on two computers, both running Xubuntu 13.04 64 bit. I will try on a 32 bit PC later today. I suppose there are two issues in play, the original libusb issue which is solved by the patched hid-libusb.c and a another one with the bandwidth. |
|
I take it back. I too have the bandwidth problem but not always. |
|
You most probably won't have the bandwidth problem if you have sucessfully used (with another software which also uses both audio and hid) fcdpro+ after plugging it and before using gr-fcdproplus. Also Volker seems to have ohci_hcd hardware (which is usb1.1 only?) while I have ehci_hcd (which is usb2). So I think that this is the difference rather than kernel. Alexandru Csete notifications@github.com wrote:
Sent from my Android phone with K-9 Mail. Please excuse my brevity. |
|
On Wed, Jul 17, 2013 at 8:31 PM, bazuchan notifications@github.com wrote:
You are so right! I tried on a different computer with kernel 3.2: Fcdpp in Alex |
|
No, I don't have usb1.1 hardware only. I saw that using the hidraw the ehci_hcd driver was involved while using hid driver with lib-usb the ohci_hcd driver seemed to be involved. |
|
Alex, Volker |
|
According to lspci -v I have both ehci, ohci and xhci, but I have no idea how to make usb3 (xhci?) use usb2 driver. 00:10.0 USB controller: Advanced Micro Devices [AMD] Hudson USB XHCI Controller (rev 03) (prog-if 30 [XHCI]) 00:10.1 USB controller: Advanced Micro Devices [AMD] Hudson USB XHCI Controller (rev 03) (prog-if 30 [XHCI]) 00:12.0 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11) (prog-if 10 [OHCI]) 00:12.2 USB controller: Advanced Micro Devices [AMD] Hudson USB EHCI Controller (rev 11) (prog-if 20 [EHCI]) 00:13.0 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11) (prog-if 10 [OHCI]) 00:13.2 USB controller: Advanced Micro Devices [AMD] Hudson USB EHCI Controller (rev 11) (prog-if 20 [EHCI]) 00:14.5 USB controller: Advanced Micro Devices [AMD] Hudson USB OHCI Controller (rev 11) (prog-if 10 [OHCI]) |
|
Fortunately, I have many USB ports on the PC and it seems one of them loads the ohci_hcd driver that works too. dmesg output: So, xhci_hcd and ohci_hcd are good, ehci_hcd is bad because, as Alexey noted before, it reserves too much bandwidth for hid device. |
|
Thanks Alex, Volker |
|
In the meanwhile, do you intend to make the hid-usb branch the default? |
|
I just merged hid-usb into master. The bandwidth problem is independent from hidraw or hid-libusb. It seems to be a kernel driver problem, so I filed a bug. |
|
Interesting, looks like guys on windows having same problems |
|
Recently purchased a Pro+ and am experiencing the "bandwidth" problem described here. When attached, dmesg reports: [92087.515857] usb 2-1.5: new full-speed USB device number 17 using ehci_hcd I'm assuming it's because the ehci driver is being used. I'm running gnuradio 3.7 and fcdproplus "master" branch, and the latest branch of gqrx. Other than trying to find a USB1.1 hub somewhere, is there any patch/fix? BTW, I'm running Debian "wheezy" and vmlinuz-3.2.0-4-amd64. |
|
Yes, there is a fix. No, we do not have it (if we had it we would make it available ;-) |
|
Actually you can workaround this by opening the hid device each time. Here is my workaround bazuchan/gr-fcdproplus@3a887f2 |
|
Hmmm, I thought that worked around another problem but indeed, it appears to work for this issue as well. I will update my PPA to include the patch. |
|
It's a bit more weird. I think it is highly dependend on the hardware. I have an usb3 controller on my system (Etron Technology, Inc. EJ168 USB 3.0 Host Controller ) and here neither the fcd nor the fcdp+ work with gqrx. and gqrx reports audio_alsa_source[hw:3]: using S16_LE terminate called after throwing an instance of 'std::runtime_error' But if I connect the fcd or fcdp+ to an usb 2 port both work. I reported a bug to kernel.org and to the usb mailing list but nobody cared. Perhaps someone could report a bug for the ehci driver. Apart from that I'll wait for a 3.12 kernel and see what happens. |
|
I am seeing the bandwidth problem as well, on an ARM port (the specific hardware is a Zynq), with v3.6.5 gnuradio and 3.6 gr-fcdproplus. I attempted bazuchan's open/close workaround, to no effect. The thread is a little confusing to a newbie to FCD and git alike, so I apologize for having to ask... |
|
I don't think it will make any difference whether you are running gnuradio 3.6 or 3.7 except that gqrx only works with 3.7 (this issue tracker is for gqrx ;-) |
|
@MadBoat Just curious if you could try this, as I have to do it to get my FCDPro+ to work: |
|
@Kateadams I'm guessing those are instructions specific to gqrx? I don't think there is a parallel operation for gr-fcdproplus. |
|
@MadBoat Actually, no; to get GNU Radio to work with my Pro+, I need to do that first, I've no idea why. |
|
@Kateadams I am chasing another lead, but if it doesn't pan out I will try your suggestion. Was my guess correct? Those instructions will make sense if I use gqrx? |
Not sure I understand the question, but, they're UI elements you need to select/click. |
|
Ok. I finally cracked it. What was happening was, csete's gr-fcdproplus gnuradio block was queueing a second periodic transfer (for real time radio control?). Both transfers wanted to happen in every single frame, with no gaps. The ehci driver refused to schedule both, even though it had the bandwidth... I still don't really understand why. The comments I read suggest its to prevent delaying a transfer that is already queued.... or perhaps the USB stack, when it is dealing with a 1.1 device, just can't schedule an operation to begin at a time other than the beginning of a frame... In any case, to fix it, I just removed the gr-fcdproplus block and put in the generic audio block, and I'll use fcdcontrol, or something equivalent, for configuration. Still futzing with it to get the quality right... I think my flowchart as it stands is throwing away either the I or Q portions of the data as it comes out of the generic audio block. |
|
gr-fcdproplus is not my block, though it reuses some code written by me in the past. As far as I know it doesn't do any periodic scheduling; it merely sets and reads settings as requested by the GUI. You may see several requests during startup since the application has to set the frequency and gains and these requests are probably queued as asynchronous messages ad the hidapi/libusb layer. Since gr-fcdproplus and fcdctl uses practically the same code, I wouldn't expect to see any difference between the two. The "not enough bandwidth" message comes in the syslog when you plug in the dongle before you load any application and, as I recall, the audio interface is not usable either. Perhaps your issue is a different one? |
|
"gr-fcdproplus is not my block, though it reuses some code written by me in the past." Oh, sorry, I guess I conflated your name and this project. "As far as I know it doesn't do any periodic scheduling; it merely sets and reads settings as requested by the GUI. You may see several requests during startup since the application has to set the frequency and gains and these requests are probably queued as asynchronous messages ad the hidapi/libusb layer." All I can tell you that, according to my hacked driver, the scheduler ehci-hcd uses reports that there is no bandwidth used when the initial device open occurs, and when I come down to set the first of the radio properties (lna gain, I think), there is a periodic transfer scheduled. Either I'm writing/interpreting my hacks wrong (which is very possible; that driver is the biggest rat's nest I've ever had to wrap my head around), or gr-fcdproplus does indeed caused periodic traffic to be scheduled. I should mention also that it is inheriting some functionality from gnuradio (specifically, the start() and stop() functions). Does the possibility for this error exist in those gnuradio functions? "Since gr-fcdproplus and fcdctl uses practically the same code, I wouldn't expect to see any difference between the two." I cannot do a definitive test until I fix the quality problem I mentioned, but I can say that on my PC, with the dongle in a 2.0 slot, fcdctl does not cause this problem when I change the frequency. Might be that its doing nothing at all for some reason, but I don't think that's likely. "The "not enough bandwidth" message comes in the syslog when you plug in the dongle before you load any application and, as I recall, the audio interface is not usable either. Perhaps your issue is a different one?" If I do not load an application layer program, I do not see a "not enough bandwidth" error at all. |
|
Interesting, thanks for the info. Btw. I use a setup for receiving telemetry from the Funcube satellite (http://flic.kr/p/jeJZYf) where I control using fcdctl and record raw IQ samples from the FCD Pro using sox: sox -r 96k -e signed-integer -b 16 --endian little -c 2 -t alsa hw:2 somefile.raw The file will then contain interleaved IQIQIQ... samples. The same command works with the Pro+ using "-r 192k". |
|
Ooo! Might be thats useful. Thanks. |
|
For me the "bandwidth" problem starts only when hid device is open and Btw, can somebody who has the "bandwidth" problem try following:
Alexey Bazhin baz@irc.msk.ru |
|
@bazuchan All these PCs have been upgraded to Xubuntu 13.10 and perhaps the drivers got fixed for the controllers that I have. |
|
I tried it on a computer that reports not enough bandwidth when the FCDPP is plugged in and I can not capture audio using sox. |
|
Do you see this problem with an FCD, too ? |
|
I have never seen this issue with plain Pro models; only with the Pro+. |
|
Am 26.02.2014 17:39, schrieb Alexandru Csete:
|
|
First, I am so glad I finally found this thread, because I spent an entire day pulling my hair out on this and have gotten nowhere. I've got a brand-new FCDPP and I'm running Ubuntu 14.04, install gnuradio, gqrx from apt, also tried gqrx from source, and have built qthid and fcdctl from source from git. In reality, I was not even planning to try ANY of that software, intending instead to do very minimalist driver myself for a project that will eventually have to run on a very lightweight system. Basically, I have found that that sometimes on some USB ports I can open the audio and read samples out of the FCDPP. grc (using gr-fcdproplus) worked once or twice, but mostly does not work. I never saw gqrx work. I can open up the audio in ALSA and that also worked a few times, but it's not reliably. Unplugging and re-plugging the device helps and oddly, leaving it unplugged longer seems to make a difference. Starting up qthid or running fctctl even once makes the audio stop working, and nothing will make it work again, short of a unplug/replug, and even that not usually. My dmesg is filled with: [31403.428013] 10:1:1: cannot get freq at ep 0x81 Anyway, i'm really stuck! I thought this was going to be easy! Open up an audio interface and a hid interface and send a poke through the latter every time I wanted to change freqs! Is there any progress on this issue? Is there a known workaround? Did I hear that if I just plug in through a physical USB hub it might work? Regards, |
|
Its been a while since I looked at this problem, but IIRC, the standard work around was to use a 3.0 slot rather than a 2.0 slot; doing so will load the xhci driver rather than the ehci driver, which doesn't have this problem. What is your success rate like if you restrict yourself to 3.0 slots? |
|
Thanks, MadBoat. This PC is a bit older (was top end in its time Core2-i7, 16GiB RAM, etc) but AFAIK doesn't have any 3.0 ports. Those are the blue ones right? |
|
yessir. |
|
Now I'll go scrounging for an old USB hub that only does 1.1 (or maybe an add-in USB3 card).... this receiver is getting expensive. I hope it's really better than the RTL2832 devices. :-) |
|
Try all USB ports on your computer. I have a computer where it works on the ports in the front, but not the ones in the back, even though they are all USB 2 ports. Test it using sox or similar. |
FCDPro+ support was added to gr-osmosdr
http://cgit.osmocom.org/gr-osmosdr/commit/?id=3ce7c3398102e49f5fe7411a8e0fb5700236a3c7
gqrx needs to set correct sample rate for FCDPro+