Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

RPi soapy + rtlsdr stutter #17

Closed
viraptor opened this issue Feb 28, 2016 · 2 comments
Closed

RPi soapy + rtlsdr stutter #17

viraptor opened this issue Feb 28, 2016 · 2 comments

Comments

@viraptor
Copy link

I'm not sure if that's an issue in soapy remote, or just strange parameters, but I can't seem to get more than 1Msps without stutter. Some information:

Transferring RPi -> linux over wifi.
IPerf says I can do 2.5 MB/s on tcp, I can send 3 MB/s on udp without packet drops. (1 reorder over a minute of testing)

Both sides use recent versions: SoapyRemote 0.2.0, SDR 0.4.1, RTLSDR 0.2.0 (nothing relevant changed in git since then)

At 1Msps, I get a really good reception both with standard parameters and with those mentioned at the end of issue #9, but still get a few "S"es in the logging output. At any higher sampling rate, I get really choppy sound (listening to fm radio over cubicsdr) and start getting "SOOSOOOSOOSOSOO...". rtl_test is happy up to 2.6Msps without samples lost, so it looks like the receiver should be fine.

With CS8 format, I'm expecting at least 2Msps to be possible without issues, but it doesn't seem to work well.

@guruofquality
Copy link
Contributor

Double check that the sysctrl limits are set on both the PI and PC: https://github.com/pothosware/SoapyRemote/wiki#remotewindow If the window cant set properly because system defaults, the flow control can really get in the way. Also keep in mind that 3 MB/s would equate to 1.5 Msps at CS8 (2 bytes per sample). So that may be an issue as well.

@viraptor
Copy link
Author

I was under the impression that CS8 means 8bit samples. If it's 2 bytes, that explains everything - I just don't have that much bandwidth available.

I'll wait for the compression implementation in that case :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants