It would rule out if any or all of the dongles are bad or not. Just to be sure.
I am fresh out of thumbdrives i gotta wait lol
Last edited:
RTL Test Losing bytes on USB3.1
- Thread starter air-scan
- Start date
- Status
I am fresh out of thumbdrives i gotta wait lol
lwvmobile
DSD-FME
It would rule out if any or all of the dongles are bad or not. Just to be sure.
I am fresh out of thumbdrives i gotta wait lol
Cant' say I've tried it, but in the Google Play Store, there is an app called 'SDR driver' by Martin Marinov, it looks like it might include rtl_test, but that would just be a guess based on its inclusion of rtl_fm and rtl_tcp. Some of those other apps probably include some form of the osmocom rtl_sdr package I would imagine, but I really have no idea if you can plug in an RTL dongle and run rtl_test in a terminal in through any of those apps or not. If I had to take a wild guess, to get something like this to go as a test just to see the output of rtl_test in an android device, I have a feeling this is going to require a rooted device and the need to compile a custom version of osmocom rtl-sdr package libraries for said device. I honestly have no idea where to start on something like that.
I would also say you might try using a blank DVD and burn the image to it for that Skywave Linux, but I have a feeling you don't have a blank DVD or a DVD drive or something.
Lol I wish! this laptop doesn't have DVD nor CDROM everything has to be booted from usb thumbdrive. Very new laptop. I ran my RTLSDR on SDRTouch (full) without a hitch moments ago.
lwvmobile
DSD-FME
Yeah, I think that's what I keep coming back to. If everything else seems to work without a hitch then I don't really think that the output of rtl_test is the end all be all litmus test just because it says you are losing bytes here and there. If everything else is working with it software wise except that one issue you are having in DSD, then it makes it very difficult to say for certain that those two things are correlated. That's why you need another computer to test this on.
I think what kind of makes it frustrating to test to be honest is that you only have one computer. I don't know how you live like that
I can't bring myself to toss out working machines if they have at least a Core2Duo or higher in them. I can always find some use for them, even as a lowly file server or media center or something. I recently literally had to force myself to toss out 5 Pentium 4 era computers that were taking up too much space on my shelving area.My old Dell was 13 years old. It's display backlight decided to go bust. I felt it wasn't worth saving so I ditched it. It had a Intel Pentium M. I threw it out lol. I needed to move along sometime. I used it for all of the 5 years I owned it. I got it on barter. Guy wanted WIFI access so we traded. LOL!Yeah, I think that's what I keep coming back to. If everything else seems to work without a hitch then I don't really think that the output of rtl_test is the end all be all litmus test just because it says you are losing bytes here and there. If everything else is working with it software wise except that one issue you are having in DSD, then it makes it very difficult to say for certain that those two things are correlated. That's why you need another computer to test this on.
I think what kind of makes it frustrating to test to be honest is that you only have one computer. I don't know how you live like that
lwvmobile
DSD-FME
Yeah, that one was definitely getting up there in age, and with a busted screen, certainly not worth the money to repair. I think my rule of thumb is if a Raspberry Pi can outperform it, then can it.
totally agreed. I am enjoying the speed of this new laptop. It sure does a bang up job otherwise. I think If in time money is right I ll buy a i5 with better USB 2.0 compatibility. I really don't want to beat this one over the head to long. Still have SDRTrunk for P25. Thanks for all replies!
slicerwizard
Member
Do you have any USB 2.0 hubs? Have you tried running a dongle via a hub?
The only thing i have that has USB2.0 is my android devices. The laptop is USB 3.1 xHCI with one 3.0 hub (2 port) and 1 type-c USB3.1 only port.
Last edited:
check in your bios if you have a hardware EHCI fallback USB mode.
I know that some earlier supporters of hardware allow you to enable a fallback mode for stubborn devices, you may be able to force it into ECHI mode for different USB 2.0 support, which might entail a different set of drivers at the OS level.
Nothing there for that. thanks for trying. Can we let this topic die? I am tired of wrestling with it.
I understand the frustration, you can report your own thread to the mods with a request to lock it. They should oblige.
slicerwizard
Member
Sorry air-scan, I'm dragging this one out of the crypt...
Just ran into this problem today with a machine that only has USB 3.1 ports. Plugged in one of my FlightAware dongles, did the driver update with Zadig and had FMP24/DSD+ working fine for a while on the local Phase II PS system. But after maybe 15 minutes, the audio got really bad. Pressed L in FMP24 and it immediately started reporting lost I/Q samples. Shut down FMP24 and DSD+ and tried rtl_test (32 and 64 bit versions); they both reported near-continuous errors.
Messed around with Windows power plan settings, then BIOS settings, then updated a bunch of out of date hardware drivers. Still got lots of errors for dropped I/Q samples.
Then, while still getting I/Q stream errors, I started a very large unzipping job (data transfer to new machine). The errors immediately stopped. Go figure.
What seems to be happening is that rtl_test, FMP24 and DSD+ all use so little resources that the power saving gremlins are kicking in and messing up USB transfers. When the CPU usage graph in Windows Task Manager is raised to about 10%, I'm seeing about one lost samples event every minute, which is isn't going to cause any noticeable decoding issues. So the other decoders avoid this by keeping the machine warm?
Light CPU load (2%), massive errors (more than two stream dropouts *per second*):
Moderate CPU load (9-10%), about one stream dropout per *minute*:
Same *everything* except for me firing up a simple CPU cooker. It doesn't do anything but make some random integer calculations. No network I/O, no disk accesses, no screen output, no GPU, nada.
I guess I just need to run enough dongles and FMP24/DSD+ pairs to keep the CPU warm. Unbelievable...
Just ran into this problem today with a machine that only has USB 3.1 ports. Plugged in one of my FlightAware dongles, did the driver update with Zadig and had FMP24/DSD+ working fine for a while on the local Phase II PS system. But after maybe 15 minutes, the audio got really bad. Pressed L in FMP24 and it immediately started reporting lost I/Q samples. Shut down FMP24 and DSD+ and tried rtl_test (32 and 64 bit versions); they both reported near-continuous errors.
Messed around with Windows power plan settings, then BIOS settings, then updated a bunch of out of date hardware drivers. Still got lots of errors for dropped I/Q samples.
Then, while still getting I/Q stream errors, I started a very large unzipping job (data transfer to new machine). The errors immediately stopped. Go figure.
What seems to be happening is that rtl_test, FMP24 and DSD+ all use so little resources that the power saving gremlins are kicking in and messing up USB transfers. When the CPU usage graph in Windows Task Manager is raised to about 10%, I'm seeing about one lost samples event every minute, which is isn't going to cause any noticeable decoding issues. So the other decoders avoid this by keeping the machine warm?
Light CPU load (2%), massive errors (more than two stream dropouts *per second*):
Moderate CPU load (9-10%), about one stream dropout per *minute*:
Same *everything* except for me firing up a simple CPU cooker. It doesn't do anything but make some random integer calculations. No network I/O, no disk accesses, no screen output, no GPU, nada.
I guess I just need to run enough dongles and FMP24/DSD+ pairs to keep the CPU warm. Unbelievable...
lwvmobile
DSD-FME
Sounds like the power savings features in BIOS/UEFI or baked into whatever chipset that laptop is using is a little bit TOO active. Does it do it when its plugged in, or on battery power? When I first saw this, I was expecting to see Ryzen attached to it somehow, but its a i7-9750H. I swear, manufacturers are so obsessed with saving every little iota of power so things like this seem to start occurring more and more often. Either that, or they are too incompetent and can't create stable usable USB interfaces anymore. Maybe a workaround would be to have some sort of program running in the background to keep the CPU under just enough load to keep things from dropping out?
My computer will idle at around 1.6ghz. It has a Intel core i7 1065G7 cpu 4 core 8 thread 64bit. It'll drop I/Q samples as well. Thanks for bringing this out of the crypt. Finally someone else found the issue. Maybe the dsd+ FL devs can work it out. It has USB 3.1 too. No Usb 2.0
Windows policy editor allows fine-tuning some power settings that are not otherwise exposed. These also include beating Windows Update into submission so that unattended systems don't reboot into a bad state after an ill-advised package jams the gears on that remote computer.
gpedit.msc
secpol.msc
for starters.
Not for home edition. This thread is about losing bytes on USB 3.1 only computers not Windows Update. Windows Update doesn't interfere. Please remain on topic. Changing power settings like slicerwizard mentions doesn't help. I feel like you're trying to derail this thread.
Last edited:
@slicerwizard I ran the same test. I am not getting the audio problem as bad. Still choppy at times. it shows 11/million. I also tried increasing the power setting for minimum CPU plugged in from 5% to 10%.
slicerwizard
Member
slicerwizard
Member
You're dealing with 20 dropouts per minute; that's one every three seconds. That'd definitely be noticeable.
- Status