Hello,
it's my first mail on this list, so please forgive me if I do something
wrong.
I'm about to post a couple of patches for RTL drivers:
1. RTL-SDR: convert _lut to float[] to reduce size by a factor of 256.
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.
lib/rtl/rtl_source_c.cc | 19 ++++++-------------
lib/rtl/rtl_source_c.h | 4 ++--
2 files changed, 8 insertions(+), 15 deletions(-)
2. RTL-TCP: Convert to single class model
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.
lib/rtl_tcp/CMakeLists.txt | 1 -
lib/rtl_tcp/rtl_tcp_source_c.cc | 352 ++++++++++++++++++++++++++++++++--------
lib/rtl_tcp/rtl_tcp_source_c.h | 32 +++-
lib/rtl_tcp/rtl_tcp_source_f.cc | 327 -------------------------------------
lib/rtl_tcp/rtl_tcp_source_f.h | 125 --------------
5 files changed, 309 insertions(+), 528 deletions(-)
I'm also thinking about merging the code common to RTL-SDR and RTL-TCP,
but this it's done yet.
Comments?
--
Krzysztof Halasa
On Sun, Sep 25, 2016 at 05:54:10PM +0200, Neels Hofmeyr wrote:
> On Sat, Sep 24, 2016 at 08:01:52AM -0600, Sylvain Munaut wrote:
> > I've just put this in place for 'openbsc.osmocom.org' :
> >
> > rewrite ^/trac/wiki/(.*)/(.*)$
> > $scheme://osmocom.org/projects/openbsc/wiki/$1$2 redirect;
> > rewrite ^/trac/wiki(.*)$ $scheme://osmocom.org/projects/openbsc/wiki$1 redirect;
>
> But so far the idea is to keep the trac online and browsable, right?
the main problem is that search engines still primarily seem to index +
link to the old trac instances. So we were keeping that alive for some
time. However, as the content is going out of date, and people still
show an interest in editing the old content, I think we need to switch
the trac off soon and replace it with links to the redmine, even if it
just links to the redmine entry page of that project.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi guys,
I think some of us would like to move to redmine and start using public tickets more frequently. So in case we move there are some topics to be discussed and I would like to start with a couple of them right now.
Tickets:
Redmine has a global linear sequence of ticket numbers. If we move from many tracs to a single redmine we can either:
* not import tickets
* only import from one project
* deal with changing ticket numbers
In terms of installations the GMR trac is broken in regard to tickets, there are some for SDR that are probably not being fixed anytime soon, baseband might be relevant and OpenBSC is unlikely to be relevant. I don't think we have ever used ticket reference in OpenBSC commit messages so in terms of OpenBSC having changing ticket numbers would not be a big deal. E.g. we could add a custom field with the old trac number?
Wiki:
We have external references that should be redirected to the new place. Is there any way besides maintaining a list in the apache2/nginx configuration and making redirects as we find broken references? Can we proactively manage this? Is anybody willing to come up with a script and nginx configuration for doing this?
kind regards
holger
Hi
I have been experimenting writing DSP software, using librtlsdr and a NESDR
dongle from NooElec. After much searching the Internet for code to design and
implement DSP filters (with little success), I remembered that years ago I
bought the "Digital Signal Processing" book by Steven W. Smith. I used the
BASIC software included to produce C code to calculate the a and b coefficients
for Low Pass or High Pass Chebyshev filters, from 2-pole to 20-pole if needed.
Unfortunately, the cut-off frequency for a 6-pole Low Pass filter I implemented
turns out to be 2x the required value, even though the design function that
calculates the a and b coefficients produces values that match exactly values
tabled in the book. This leaves me I think with the following possibilities:
1. That the calculated a and b coefficients are correct but my own code
implementing a recursive filter is incorrect.
2. That I have incorporated the LPF filter function into my librtlsdr-based
application incorrectly, perhaps misunderstanding parameters like the sampling
rate or the required bandwidth.
3. That both the above implementations are correct but the BASIC code included
in the book has a bug somewhere, so that both my own results for a and b and
those tabled in the book are incorrect. Rather unlikely I thought....
So I am asking for help here from more knowledgeable DSP'ers hoping to resolve
this matter, as the above mentioned book is very good, with very clear and
simplified teaching of DSP for engineers _and_ it includes source code in
BASIC for most of the algorithms it teaches. And it is available openly on
the Internet with source code here!: http://dspguide.com/
My own GPL'ed application is available for inspection here:
www.5b4az.org/pkg/sdrx/sdrx-0.3-beta.tar.bz2
The filter functions are in src/filters.c and SDR functions in src/rtlsdr.c
My thanks here in advance!
--
Best Regards
Neoklis - Ham Radio Call:5B4AZ
http://www.5b4az.org/
Hi All,
This video shows that one can run a rtlsdr at 2.4 MHz on a
Raspberry Pi 2B. Maybe interesting for portable use.
https://www.youtube.com/watch?v=qGZmD8O4Flk
Regards
Leif
