DSheirer
USB error 9: error writing byte buffer: Pipe error
sdrtrunk Version master-branch; Nightly
Describe the bug Each time the software attempts to communicate with either of my RTL-SDRs (one V3, one V4), I receive a "USB error 9: error writing byte buffer: Pipe error". Text files with the console log are attached. This happened with these same SDRs on my old PC (Ryzen 5 3600) as well as my new PC (Ryzen 7 7700X). When these SDRs are connected to an Intel machine with drivers loaded properly, SDRTrunk works great. The waterfall view at the default frequency at startup of the software appears to work correctly, screenshot attached.
To Reproduce Steps to reproduce the behavior:
- Open playlist editor OR the "Tuners" tab.
- Make any attempt to change a setting or otherwise communicate with the tuner.
Expected behavior The SDRs to tune to the correct frequencies and monitor trunked traffic using frequencies pulled from Radio Reference.
Screenshots
Application Log See attached. v0.6.0 log.txt Nightly log.txt
Desktop (optional - complete the following information):
- OS: Windows 11 23H2 (OS Build 22631.4037)
- CPU: Ryzen 7 7700X (8 core/16 thread, 4.5GHz base)
- Motherboard: MSI PRO B650-P WiFi (BIOS: 1.G1, 8/28/2024)
- RAM: 32GB 4800MT/s (2x16GB)
- All drivers on latest versions, just fully updated an hour ago
Additional context This issue has plagued me across two completely different systems now. Is the problem with me mixing V3 and V4 devices?? Drivers were installed properly using Zadig. Each device works properly in SDRsharp and SDR Console v3.3. The V4 has had it's serial changed from 00000101 to 00000102 using SDR Console after finding an obscure thread that mentioned two RTL-SDRs can cause issues if they are set to the same serial numbers, but this didn't change anything.
This issue plagued me for the longest time. I tried reinstalling drivers, disabling ports, switching ports, using externally powered hubs, all to no avail.
What solved my problem was the installation of a new internal usb card. There seems to be a problem with some combination of Ryzen CPUs and the on-board motherboard usb ports. Using the pci based usb expansion card solved my problem instantly. For reference I’m running a Ryzen 7 3800X with a ASUS B550 plus. Hoping this solution might work for you.
I've noticed the same thing where config issues occurred on my Ryzen CPU but not on my intel
Also experiencing this with SDRTrunk 0.6.1 using Nooelec RTL-SDR v5 with intel. Stack looks like so:
2025-01-01 23:21:19.797 INFO i.g.d.s.t.m.TunerManager - Discovered tuner at USB Bus [1] Port [7] Tuner Class [RTL-2832] [10MB/28MB 38%]
2025-01-01 23:21:19.797 INFO i.g.d.s.t.m.TunerManager - Discovered tuner at USB Bus [1] Port [4] Tuner Class [RTL-2832] [10MB/28MB 38%]
2025-01-01 23:21:19.797 INFO i.g.d.s.t.m.TunerManager - Discovered tuner at USB Bus [1] Port [5] Tuner Class [RTL-2832] [10MB/28MB 38%]
2025-01-01 23:21:19.797 INFO i.g.d.s.t.m.TunerManager - Tuner: USB Tuner - RTL-2832 USB Bus:1 Port:7 - Added / Starting ... [10MB/28MB 38%]
2025-01-01 23:21:20.875 ERROR i.g.d.source.tuner.Tuner - Error starting RTL-2832 tuner [14MB/28MB 50%]
org.usb4java.LibUsbException: USB error 9: error writing byte buffer: Pipe error
at io.github.dsheirer.source.tuner.rtl.RTL2832TunerController.write(RTL2832TunerController.java:802)
at io.github.dsheirer.source.tuner.rtl.RTL2832TunerController.write(RTL2832TunerController.java:783)
at io.github.dsheirer.source.tuner.rtl.RTL2832TunerController.writeI2CRegister(RTL2832TunerController.java:654)
at io.github.dsheirer.source.tuner.rtl.RTL2832TunerController$ControllerAdapter.writeI2CRegister(RTL2832TunerController.java:1572)
at io.github.dsheirer.source.tuner.rtl.r8x.R8xEmbeddedTuner.initializeRegisters(R8xEmbeddedTuner.java:465)
at io.github.dsheirer.source.tuner.rtl.r8x.R8xEmbeddedTuner.initTuner(R8xEmbeddedTuner.java:211)
at io.github.dsheirer.source.tuner.rtl.RTL2832TunerController.deviceStart(RTL2832TunerController.java:227)
at io.github.dsheirer.source.tuner.usb.USBTunerController.start(USBTunerController.java:254)
at io.github.dsheirer.source.tuner.Tuner.start(Tuner.java:94)
at io.github.dsheirer.source.tuner.manager.DiscoveredUSBTuner.start(DiscoveredUSBTuner.java:108)
at io.github.dsheirer.source.tuner.manager.TunerManager.tunerStatusUpdated(TunerManager.java:426)
at io.github.dsheirer.source.tuner.manager.TunerManager.startAndConfigureTuner(TunerManager.java:317)
at io.github.dsheirer.source.tuner.manager.TunerManager.addUsbTuner(TunerManager.java:285)
at io.github.dsheirer.source.tuner.manager.TunerManager.discoverUSBTuners(TunerManager.java:272)
at io.github.dsheirer.source.tuner.manager.TunerManager.start(TunerManager.java:126)
at io.github.dsheirer.gui.SDRTrunk.<init>(SDRTrunk.java:193)
at io.github.dsheirer.gui.SDRTrunk.main(SDRTrunk.java:937)
2025-01-01 23:21:20.890 INFO i.g.d.s.t.m.DiscoveredTuner - Tuner Error - Stopping - RTL-2832 USB Bus:1 Port:7 Error: Unable to start RTL-2832 tuner [14MB/28MB 50%]
The weird thing is that it's non-deterministic, working after a couple retries:
2025-01-01 23:23:48.156 INFO i.g.d.s.t.m.TunerManager - LibUsb - discovered [5] potential usb devices [10MB/28MB 37%]
2025-01-01 23:23:48.172 INFO i.g.d.s.t.m.TunerManager - Discovered tuner at USB Bus [1] Port [7] Tuner Class [RTL-2832] [10MB/28MB 38%]
2025-01-01 23:23:48.172 INFO i.g.d.s.t.m.TunerManager - Discovered tuner at USB Bus [1] Port [4] Tuner Class [RTL-2832] [11MB/28MB 39%]
2025-01-01 23:23:48.188 INFO i.g.d.s.t.m.TunerManager - Discovered tuner at USB Bus [1] Port [5] Tuner Class [RTL-2832] [11MB/28MB 39%]
2025-01-01 23:23:48.188 INFO i.g.d.s.t.m.TunerManager - Tuner: USB Tuner - RTL-2832 USB Bus:1 Port:7 - Added / Starting ... [11MB/28MB 39%]
2025-01-01 23:23:49.481 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [14MB/28MB 52%]
2025-01-01 23:23:49.657 INFO i.g.d.s.t.m.TunerManager - Tuner: USB Tuner - RTL-2832 USB Bus:1 Port:4 - Added / Starting ... [14MB/28MB 53%]
2025-01-01 23:23:50.883 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [14MB/28MB 53%]
2025-01-01 23:23:51.047 INFO i.g.d.s.t.m.TunerManager - Tuner: USB Tuner - RTL-2832 USB Bus:1 Port:5 - Added / Starting ... [15MB/28MB 53%]
2025-01-01 23:23:52.277 INFO i.g.d.d.f.c.ComplexPolyphaseChannelizerM2 - Sample Rate [2400000.0] providing [96] channels at [25000.0] Hz each [16MB/28MB 57%]
Some additional notes: Something more to consider when working with Nooelec SDRs. They seem to be especially prone to poor connections. It's so bad, the official faq mentions how easily they disconnect:
My SDR keeps disconnecting from my computer when it is moved slightly. How can I prevent this from happening?
SDRs are a bit heavier than most USB devices and therefore can be more sensitive to movement and more likely to disconnect when inserted into a horizontal USB port.
The solution is generally to use a vertical USB port (for example, a USB hub or the top port of computer case, if available), or to use a high quality USB extension cable, since there is no longer a downward force that can lead to disconnects.
I didn't have this problem with the Nooelec Nano 3, but it seems so much as thinking about the v5 causes it to disconnect/reconnect. It doesn't help that the USB extension cable they ship is complete garbage. I know very little about USB, but this makes me wonder if the same issue can manifest in a manner that's more subtle doesn't lead to a perceivable connect/disconnect. That might explain why what I observed seemed to be nondeterministic.
That aside, I saw other discussions mentioning similar issues were observed when using USB 3.0, and were remediated by switching to a 2.0 port. That isn't an option in my specific case as all the USB-A ports available on the device I'm working with are 3.0. However, I did achieve what is (hopefully) some degree of success by plugging a USB-A hub into the available USB-C port. Having restarted SDRTrunk several times, I am no longer seeing the issue. Fingers crossed.
Finally, and weirdest of all, I have not seen this issue at all when testing using rtl_test. This is interesting because it makes me wonder if SDRTrunk is doing something differently. Perhaps if I find the time I can review RTL2832TunerController.java and create a minimal repro of the issue. Also of note is that along with switching to the USB-C port, I changed the serial numbers of my devices. All had unique serial numbers previously, but they were 6 chars rather than 8, so I added an extra couple chars. A hasty review of Descriptor.getLabel doesn't seem to indicate any hardcoded lengths, and the SNs were as expected in the GUI, but perhaps there's something there. I doubt this is what made the difference, but maybe.
I encountered this error with a noolectric RTL-SDR dongle on a Ryzen PC running windows. I found that the exception is always happening in the 'enableI2CRepeater' method. When I tried checking the I2CRepeater state while debugging the issue I found that the issue no longer occurs.
I don't know exactly how or why this change resolves the problem but making the call to isI2CRepeaterEnabled() before calling writeDemodRegister(Page.ONE, address, value, 1) seems to avoid the USB Error 9 and my device is usable again.
I know a lot of users have reported this issue and I really didn't have a solution for it, since I couldn't get it to happen on any of my testing machines. If you're changes solve the issue, there will be a lot of happy users :-)
Same here but on only 1 out of 2 ryzen machines. Outside of nixos packaging issues, my ryzen framework 16 (7840HS) doesn't run into this issue. On my win 11 ryzen desktop (7800x3d with B650E PG Riptide WiFi using front USB) however, I can see the FFT and waterfall with logs saying the RTL-SDR v4 is connected and working. However, clicking play leads to this issue.
I hope the merged in PR fixes it. I'll see if I can test it.
Just confirming that the nightly build with this merged seems to have fixed my tuning issues with an RTL-SDR v5 on my B650 mobo desktop. Thanks!
Thanks for the update, I really wasn’t sure if the change would help anyone else. I believe I’m on the b650 chipset as well, that could be the common denominator for this problem. Thanks for the update. 😊
On Mon, Apr 28, 2025 at 3:58 PM Gabe @.***> wrote:
gabenp left a comment (DSheirer/sdrtrunk#1963) https://github.com/DSheirer/sdrtrunk/issues/1963#issuecomment-2836961347
Just confirming that the nightly build with this merged seems to have fixed my tuning issues with an RTL-SDR v5 on my B650 mobo desktop. Thanks!
— Reply to this email directly, view it on GitHub https://github.com/DSheirer/sdrtrunk/issues/1963#issuecomment-2836961347, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHMCYOU7E4DERG6WCIS3RD232XCBAVCNFSM6AAAAABNOML5RWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMZWHE3DCMZUG4 . You are receiving this because you commented.Message ID: @.***>
Hate to bump this up again. I'm having this issue as well with the current (Aug 2025) nightly build as well as the final build. Using 2 RTL V4's for some testing, I get the pipe error. Also have issues changing frequencies manually or trying to start a channel with nothing active (will give errors that no tuner is available)
System is a ASRock A320M-ITX mobo, Ryzen 7 3700X and 16GB of RAM.
Full setup is Asus ROG Stryx x670, Ryzen 9 7950x, 64GB RAM. Using two RTL-SDR v3 dongles.
Symptoms were: unable to play channels, unable to manually set sample rate, etc. Logs showed that there was no tuner available.
2025-10-03 15:30:15.780 ERROR i.g.d.g.p.c.ChannelConfigurationEditor - Error starting channel [Control] - No Tuner Available [118MB/224MB 53%]
Using the nightly build seemed to completely fix this issue for me. Looks like the magic combo might be USB 2.0 ports plus the nightly.
