Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
This is not meaningful with bladeRF hardware
|
|
|
|
|
|
|
|
|
|
|
|
Relies on some new libbladeRF API calls. Has been tested
with gqrx on new bladeRF hardware (as a source) but have
not yet tested sink, or existing bladeRF hardware.
|
|
Fix from c98be5dd for MSVC which does not require pthreads for boost threading library.
Under gcc -pthread adds support for multithreading with the pthreads library.
|
|
|
|
Signed-off-by: Steve Markgraf <steve@steve-m.de>
|
|
|
|
|
|
|
|
|
|
gpio0
|
|
|
|
The existing RTL TCP driver is quite different from its brother RTL_SDR.
It's much more complicated, uses gr::blocks::deinterleave and
gr::blocks::float_to_complex, and generally doesn't work correctly
(e.g. https://github.com/csete/gqrx/issues/99
Spectrum is mirrored when filter or demodulator changes (rtl_tcp) #99)
I've converted the RTL TCP driver to the model used by RTL_SDR,
simplifying it in the process, and fixing the GQRX issue.
|
|
The _lut is being indexed by I + Q (16 bits = 65536 entries), however
both samples can be processed independently, resulting in 8-bit LUT.
Saves a bit of RAM and CPU cache.
|
|
This is a typo, some modules use the "CORR" string
in the setFrequency(dir, chan, name, value) API
to perform fine frequency adjustments.
Updated modules will use setFrequencyCorrection(),
this is support for backwards compatible implementations.
|
|
backwards compatible changes with #ifdef
set/get_freq_corr() call directly into the SoapySDR
equivalent when supported by the API version.
|
|
Switch to the newer API call which can provide a list of ranges.
There are feature detection ifdefs provided by the library
so that code will always correctly compile.
|
|
set_freq_corr() is often a NOP for devices.
checking avoids crashes for some applications (ex GQRX)
|
|
This patch adds support for both receiving and transmitting using
the FreeSRP. More information on the FreeSRP can be found at:
http://freesrp.org
The gr-osmosdr blocks added make use of libfreesrp, the library
required for interfacing with this device. The libfreesrp source
code is freely available at
https://github.com/freesrp/libfreesrp
Usage example:
osmocom_fft -a "freesrp"
|
|
|
|
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
|
|
|
|
|
|
Fixes compile error on Mac OS X.
|
|
|
|
This patch enables sending keep-alive packets at 1 minute interval to
RFSpace networked radios. Without this the TCP connection to the radio
is closed after about 5 minutes (by the OS?).
|
|
This is necessary to esatablish a working connection to the RFSpace
CloudIQ. Without this delay the radio will not be ready and we never
receive any response to the queries and the radio will close the
connection after 5 seconds.
|
|
* This change is backwards compatible and checks for API support for step size.
* Created soapy_common.cc/h to house common gain range functions
* Moved factory mutex declaration to common source files as well
|
|
Was missing from the implementation.
Now devices with a label show up nicely in GQRX
|
|
Switch to the newer API call which can provide a list of ranges.
There are feature detection ifdefs provided by the library
so that code will always correctly compile.
|
|
The soapysdr range type does not provide a step size,
however apps like the osmocom siggen use this size for a slider,
and a value of zero will cause a divide by zero error.
Although many ranges are not actually linear,
the idea to provide some default step to avoid crashes.
A future addition to the API may include providing a step.
|
|
When the special 0.0 bandwidth setting is used, set the filter bandwidth to rate * 0.75.
Passing automatic 0.0 bandwidth for some devices was problematic.
|
|
Patch provided by Martin Smith.
Last July there were several changes made to the Airspy firmware and
libairspy that added support for a new bit packing mode where 4 sets of
12 bit samples are packed into 3 sets of 16 bits for the transfer across
the USB bus ( https://i.imgur.com/qXnWoEK.png?1 ). 25% less data is
transferred across the bus and this is good for some computers with
cheap USB chipsets. There is an overhead of extra memory bandwidth
required on the host side to unpack the data into a useful format, so
for optimal performance bit packing is disabled by default.
The data is automatically unpacked within libairspy before being passed
along, so no changes are required anywhere else if packing is enabled
(or not enabled). Airspy firmware older than v1.0.0-rc6 does not have
the function, but that is detected and handled by libairspy.
I wrote the attached patch to enable packing in gr-osmosdr, which I
tested and it works. It is basically a clone of the bias=0|1 lines as
pack=0|1 and calls the needed libairspy function.
ref:
https://github.com/airspy/firmware/commit/7e1806b
https://github.com/airspy/firmware/commit/5b7dcab
https://github.com/airspy/host/commit/a51eccb
---
Do some Baseline test with Airspy command line tools to have something
to compare USB throughput results
--------------------------------------------------------------------------------------------------------
$ sudo mount -t debugfs none /sys/kernel/debug
$ sudo modprobe usbmon
$ wireshark -i usbmod3 &
$ airspy_info ; sleep 120 ; \
airspy_rx -t 4 -r /dev/null -n 2400000000 ; sleep 120 ; \
airspy_rx -t 4 -r /dev/null -p 1 -n 2400000000 ; sleep 120 ; \
airspy_info
Wireshark->Statistics->IO Graph
The Bytes/Tick are double the actual data rate because of way wireshark
collects the USB packets, I could have added a filter to fix this. But
the relationship is valid 25% less with packing enabled. The data rate
in the IO Grahp drops from 80MB/sec (in+out) [really 40MB/sec] to
60MB/second (in+out) [really 30MB/sec] from unpacked to packed.
10MSPS no packing, packing https://i.imgur.com/pA9LPdE.png?1
2.5MSPS no packing, packing https://i.imgur.com/lA8q5aq.png?1
Verification test with my patched gr-osmosdr
--------------------------------------------
$ sudo mount -t debugfs none /sys/kernel/debug
$ sudo modprobe usbmon
$ wireshark -i usbmod3 &
$ osmocom_fft -a "airspy=0" -s 10000000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=1" -s 10000000 --fft-rate=1
$ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=1" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=0" -s 2500000 --fft-rate=1
I ran all of the above tests and the wireshark USB throughput graphs
showed exactly what was expected.
40MB/sec(10MSPS+normal),30MB/sec(10MSPS+packing),10MB/sec(2.5MSPS
+normal),7.5MB/sec(2.5MSPS+packing),10MB/sec(2.5MSPS+normal),10MB/
sec(2.5MSPS+normal).
25% less when packing was enabled and if you did not specify the
"pack=1", then no bit packing is performed by libairspy. All the
magnitudes within the FFT windows looked exactly the same as they do
without bit packing.
|
|
|
|
|
|
Since firmware 2016.01-rc1 bladeRF has the ability to lock to an
external reference as well as produce arbitrary frequency signal
(25 MHz here) on its clock output.
Use gr-osmosdr source with the following arguments to produce 25
MHz on the SMB connector:
osmocom_fft -a bladerf,smb=25e6
smb=25e6
To lock the bladeRF itself to an external GPSDO reference, use
additional arguments tamer=external for 10MHz or tamer=external_1pps for
1PPS GPSDO signals.
osmocom_fft -a bladerf,smb=25e6,tamer=external
tamer={internal,external_1pps,external}
The described method requires https://github.com/Nuand/bladeRF/releases/
tag/2016.01-rc1
Carefully *read the instructions for external reference locking*
(especially max allowed voltage levels) on Nuand's blog https://
www.nuand.com/blog/2016-01-rc1-release/
|
|
|
|
|
|
use them with airspy,linearity (the default) or airspy,sensitivity
device arguments. Range is 0 to 21. Named gains still work as before.
Requires libairspy commit dc5cbca2f6f03458c40eab7c0f88fdfed60a08ff
|
|
|
|
|
|
|
|
the build system distribution.
Signed-off-by: Philip Balister <philip@balister.org>
|
|
|