Here is a PyBOMBS recipe file that pulls gr-osmosdr from my sdrplay2
branch. If anyone would like to try out this support with a PyBOMBS build,
this would be the easiest way. Best to build everything from scratch, but
you can remove the src/gr-osmosdr directory, do a pybombs fetch/rebuild if
you're comfortable with that.
The SDRplay SDK v2.11 is required, and should be installed before
gr-osmosdr is rebuilt. The ENABLE_NONFREE flag is turned on for this build.
This is just for testing, so I can get some feedback. Hopefully, this will
go into the gr-osmosdr master at some point. It "works for me".
Note that the gains on SDRplay are actually attenuations, so they appear
backward. The LNA attenuation steps on RSPs are frequency dependent, so I
gave up trying to make them look like gains. My main use case is GQRX, and
that way was even more confusing.
There is a GRC sdrplay source that is a little less generic than the
osmocom source.
There are probably ways to repackage this so it can be distributed freely,
but I'll address that if there's more interest. The SDK include file is
redistributable and its terms seem to be compatible with GPL. The shared
object can be dynamically loaded over a placeholder library that does
nothing. Yes, that's hackish and it would be better to have everything free.
SDRplay support, rewritten, supporting RSP1, RSP1A, and RSP2
Requires ENABLE_NONFREE=yes. Requires SDRplay's SDK v2.11 to be installed
by the user. In the future, if there is a way to redistribute
mirsdrapi-rsp.h from the SDK, that problem could be addressed using a shim
library that looks for /usr/local/lib/libmirsdrapi-rsp.so at runtime.
Good afternoon,
I am a complete noob playing with my YardStick one and HackRf one.
I am working a signal that I am fairly certain is using pulse interval encoding and I am having a heck of a time understanding how to turn the NRZ 1's and 0's into the Pulse Interval.
The closest thing I have seen is how RFID uses pulse interval encoding but I don't think that is the same thing.
I started by recording in osmocom_fft
I then used inspectrum to extract symbols and found that most symbols were 1 unit in inspectrum, but there were a few places where there were 2 or 4 in a row of high or low.
Once I exported the symbols I was able to generate a bit string of 1's and 0's representing highs and lows.
I was able to identify the preamble and what I think is the sync word, but that's where I get lost.
I have seen many examples where people take 3 bits and assume that say 001 is a 0 and 011 is a 1n a PWM model but nothing I seem to do seems to work to uncover the PIE encoding and was hoping someone out there could point me in the right direction.
Thanks,
Adam
Sent from my iPad
Hello dear RTL-SDR community,
I just whant to ask if it's possible to modify rtl-sdr.h to lower the
admissible sample rate.
I am currently using 8 dongle successfully but would like to use 12
dongle simultaneously with software (rtlsdr-wsprd) to decode wspr signals.
This one uses the library rtl-sdr.
I would therefore like to be able to use sampling frequencies lower than
250000.
Thanks in advance!
Hello dear RTL-SDR users,
I whant to use multiples dongles as array for decode wspr.
My problem is that I can not use more than 4 USB dongle simultaneously.
I check with usbmon, each dongle uses 500kbits / s around. So I am far
from the maximum bandwidth allowed by usb 2.
I tried using a USB switch with external power supply but it does not
work better.
The default test performed is:
#!/bin/bash
for ((i=0;i<=4;i++))
do
rtl_test -d $i -s 250000 &
done
First 4 is starting but last 5 doesent. And i whant to use more...
Is this a limitation of the RTL-SDR library or the kernel driver?
Do we have a solution to get around the problem?
Thank you in advance for your valuable feedback.
I picked up a SDRplay RSP2 recently, and the gr-osmosdr support needed
some work. Here's a rewrite that works with RSP2 and has other
improvements. When the RSP1A comes in, I'll finish support for that. No
plans to pick up a RSP1, but someone can see if this works if
interested. This was tested against the Nov 2017 binary blob.
https://github.com/willcode/gr-osmosdr/tree/sdrplay2
=====
Complete rewrite of sdrplay support
- Supports RSP2
- Will support RSP1A when hardware arrives
- RSP1 is untested
- Uses streaming callbacks instead of polling
- Tuning, gain control imporoved, AGC supported
- Better performance (one less layer of buffers)