Hi,
Is there any bug tracker for the gr-osmosdr somewhere?
It would be nice if the "audio_alsa_source[hw:X]: Device or resource
busy" could be fixed.
The problem with that bug is you can't even interogate the device driver
for supported gain, etc... If the device is used by another application.
For example, I have permanently 2 devices plugged in, I use an FCD to
send AIS data to aishub.com, and a RTL to experiment with.
The problem with this bug is that if you use python you can't even catch
the exception, it simply crash the script. I think that the behaviour is
different when using C++.
Another "bug" I discovered is that if you just do a device scan to print
available device and exit the python script, it will generate plenty of
error messages like "libusb:warning [cancel_bulk_transfer] unrecognised
discard errno 9", the workaround is to simply wait a bit before exiting.
It seems that some USB packets are still pending after calling
osmosdr.source_c().
Chris
--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
From: Christian Gagneraud <chris(a)techworks.ie>
gr-osmosdr uses the driver in a multi-thread context, as a side effect the
cancel_async() can be called before read_async(), in such a case the cancel is
"forgotten". This patch fixed that by being a bit more relaxed with
state machine transitions.
This patch doesn't fix any race conditions, it just make an anoying one less
likely to happen.
This patch goes along this one [1]
[1] http://lists.osmocom.org/pipermail/osmocom-sdr/2012-August/000201.html
Signed-off-by: Christian Gagneraud <chris(a)techworks.ie>
---
src/librtlsdr.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 4e54d8e..d83010d 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1256,6 +1256,12 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx,
if (!dev)
return -1;
+ /* It can happen if cancel_async is called before read_async */
+ if (dev->async_status != RTLSDR_INACTIVE)
+ return -1;
+
+ dev->async_status = RTLSDR_RUNNING;
+
dev->cb = cb;
dev->cb_ctx = ctx;
@@ -1284,8 +1290,6 @@ int rtlsdr_read_async(rtlsdr_dev_t *dev, rtlsdr_read_async_cb_t cb, void *ctx,
libusb_submit_transfer(dev->xfer[i]);
}
- dev->async_status = RTLSDR_RUNNING;
-
while (RTLSDR_INACTIVE != dev->async_status) {
r = libusb_handle_events_timeout(dev->ctx, &tv);
if (r < 0) {
@@ -1326,7 +1330,7 @@ int rtlsdr_cancel_async(rtlsdr_dev_t *dev)
if (!dev)
return -1;
- if (RTLSDR_RUNNING == dev->async_status) {
+ if (RTLSDR_CANCELING != dev->async_status) {
dev->async_status = RTLSDR_CANCELING;
return 0;
}
--
1.7.7
Hi there,
I saw a message in the July archive (I wasn't subscribed yet at that
date) about updating gr-ais with osmosdr support.
I was working on the same thing recently, so i decided to publish my
fixes on top of Antoine's one.
The result can be found here:
https://github.com/chgans/gr-ais
I got it working with both an FCD and an RTL:
ais_rx.py --rate 96e3 --gain 30 --error -17 -d -D fcd=0
ais_rx.py --rate 1024e3 --gain 30 --error -110 -d -D rtl=0
Strangely passing freq_err=XX parameter to the source (using -D),
doesn't work, the use of --error is thus needed (which will do a
set_freq_corr()).
Antoine, if you want sample file, just let me know.
Nick, are you willing to integrate these changing back in gr-ais, Apart
from the added automatic decimation filter, the changes are not
intrusive at all.
The default settings for UHD are 256Khz sampling with decimation filter
4, with this change, the decimation is one when using FCD (96KHz fixed
frequency) and 16 for RTL when used at 1.024MHz (this was the minimum
working frequency for me).
Or maybe would you prefer to allow the user to set it manually, and use
this technique as a fall back only.
Please let me know what you guys think.
Thx,
Chris
--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
Hi,
I started do add documentation to the wiki page of gr-osmosdr [1].
For now i've just added documentation about the "constructor"
parameters. Any feedback welcome.
[1] http://sdr.osmocom.org/trac/wiki/GrOsmoSDR
PS: Could anyone tell me what the mcr is? (used for osmosdr source)
--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
Hi there,
In a python script, I would like to iterate over things like
get_gain_names, get_gain_ranges, ...
The problem is that these functions return a std::vector<std::string> *.
The error i get is: TypeError: 'SwigPyObject' object is not iterable
It would be very nice to be able to do something like:
for src.get_sample_rates():
# do something
for name in get_gain_names():
# do smth
I found this: http://reference-man.com/files/generators.i
But i haven't been able to use it so far. :(
Any help or comments appreciated.
Chris
--
Christian Gagneraud,
Embedded systems engineer.
Techworks Marine
1 Harbour road
Dun Laoghaire
Co. Dublin
Ireland
Tel: + 353 (0) 1 236 5990
Web: http://www.techworks.ie/
Hi,
I have tried to modify the AIS decoding implementation from Nick Foster
(https://cgran.org/wiki/AIS) in order to be able to use an rtl dongle as
a source. Unfortunately I am not living by the sea and I cannot test it
before a couple of week. Is there anybody able to receive AIS messages
willing to test my changes? You can find it on github:
https://github.com/asirinelli/gr-ais
The 2 main assumptions I made are:
- Nick first implementation is working
- rtl-sdr is able to have a sample rate of 256 kHz.
Many thanks,
Antoine
Hello people,
in some experiments with my RTL2832 stick, I managed to find out how the
FIR filter works. The FIR filter is running at the XTAL frequency
(typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR
filter with 32 real-number-valued taps. Using the symmetry, only 16
coefficients need to be specified. The coefficients are stored in the 20
bytes written to the FIR register. The first coefficient describes the
outermost tap, the last one the tap 0.5 taps away from the symmetry
axis. The first 8 values are 8-bit numbers, the second 8 values are 12
bit numbers, resulting in 64 + 96 = 160 bits (20 bytes).
The first 8 bytes written to the chip are the first 8 coefficients. The
12-bit coefficients are stored like this pairwise in three bytes: In the
byte sequence "12 34 56", the first coefficient is 0x123 and the second
coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be
interpreted as two's complement signed numbers (thus the 8-bit
coefficients range from -128 to +127, while the 12-bit coefficients
range from -2048 to +2047). The resolution of all 16 coefficients is the
same.
I furthermore found out that this is not the only filtering going on in
the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing
filter before the DAC, making signals disappear that are at frequencies
above 0.7 times the sample rate (in the baseband), even if the
programmable FIR filter lets them pass.
As an example, I provide the decoded default coefficients:
-54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421
421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54
This filter has a quite flat passband in the interesting range for DAB
(-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which
will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory
adjacent channel rejection. The experimentally observed alias rejection
is good enough, which lead to the conclusion that there is another
low-pass filter, which might be part of the resampling unit.
Regards,
Michael Karcher
Hello people,
in some experiments with my RTL2832 stick, I managed to find out how the
FIR filter works. The FIR filter is running at the XTAL frequency
(typically 28.8MHz). In the SDR mode, the filter is a symmetric FIR
filter with 32 real-number-valued taps. Using the symmetry, only 16
coefficients need to be specified. The coefficients are stored in the 20
bytes written to the FIR register. The first coefficient describes the
outermost tap, the last one the tap 0.5 taps away from the symmetry
axis. The first 8 values are 8-bit numbers, the second 8 values are 12
bit numbers, resulting in 64 + 96 = 160 bits (20 bytes).
The first 8 bytes written to the chip are the first 8 coefficients. The
12-bit coefficients are stored like this pairwise in three bytes: In the
byte sequence "12 34 56", the first coefficient is 0x123 and the second
coefficient is 0x456. Both the 8-bit and the 12-bit numbers are to be
interpreted as two's complement signed numbers (thus the 8-bit
coefficients range from -128 to +127, while the 12-bit coefficients
range from -2048 to +2047). The resolution of all 16 coefficients is the
same.
I furthermore found out that this is not the only filtering going on in
the RTL2832 chip in SDR mode. There seems to be a second anti-aliasing
filter before the DAC, making signals disappear that are at frequencies
above 0.7 times the sample rate (in the baseband), even if the
programmable FIR filter lets them pass.
As an example, I provide the decoded default coefficients:
-54 -36 -41 -40 -32 -14 14 53 101 156 215 273 327 372 404 421
421 404 372 327 273 215 156 101 53 14 -14 -32 -40 -41 -36 -54
This filter has a quite flat passband in the interesting range for DAB
(-768kHz..+768kHz) but by far not enough attenuation at 1280kHz (which
will alias to 768kHz at a sampling rate of 2048kHz) to get satisfactory
adjacent channel rejection. The experimentally observed alias rejection
is good enough, which lead to the conclusion that there is another
low-pass filter, which might be part of the resampling unit.
BTW: the 900kHz low sample rate limit seems to be valid for a 36MHz
XTAL, not the common 28.8MHz XTAL.
Regards,
Michael Karcher
