Gets rid of librt, which doesn't exist on OpenBSD. The version of librtlsdr in the OpenBSD ports tree is extremely old (~2013), so this should help some users.
Tested against tag 0.6.0, but it should apply just fine to HEAD.
Thanks,
Brian Waters
--
Brian M. Waters
brian(a)brianmwaters.net
Based on some cursory googling, it's _not_ needed for FreeBSD, but I haven't tested. I'm not sure about the others.
A check for librt.so would be good; something like autoconf's AC_SEARCH_LIBS that actually searches libs for clock_get time() would be best. I don't know what CMake has to offer in that regard.
BWOn Nov 9, 2019 11:56 AM, Adrian Chadd <adrian(a)freebsd.org> wrote:
>
> is this applicable to the other BSDs too?
>
> Ideally the rule would be "only link in rt if it's present", right?
>
>
> -adrian
>
> On Sat, 9 Nov 2019 at 03:08, Brian Waters <brian(a)brianmwaters.net> wrote:
> >
> > Looks like I mistakenly included the patch as an attachment, so it may not have gone through. Here it is:
> >
> > diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
> > index 07d64ab..015fd48 100644
> > --- a/src/CMakeLists.txt
> > +++ b/src/CMakeLists.txt
> > @@ -125,7 +125,7 @@ if(UNIX)
> > target_link_libraries(rtl_fm m)
> > target_link_libraries(rtl_adsb m)
> > target_link_libraries(rtl_power m)
> > -if(APPLE)
> > +if(APPLE OR CMAKE_SYSTEM MATCHES "OpenBSD")
> > target_link_libraries(rtl_test m)
> > else()
> > target_link_libraries(rtl_test m rt)
> >
> > Thanks,
> > BW
> >
> > --
> > Brian M. Waters
> > brian(a)brianmwaters.net
> >
> > On Tue, Nov 5, 2019, at 5:05 PM, Brian Waters wrote:
> > > Gets rid of librt, which doesn't exist on OpenBSD. The version of
> > > librtlsdr in the OpenBSD ports tree is extremely old (~2013), so this
> > > should help some users.
> > >
> > > Tested against tag 0.6.0, but it should apply just fine to HEAD.
> > >
> > > Thanks,
> > > Brian Waters
> > >
> > > --
> > > Brian M. Waters
> > > brian(a)brianmwaters.net
> > > Attachments:
> > > * openbsd.patch
Hello,
When doing a setFrequency I usually have this error afterwards and the
frequency is actually not changed
rtlsdr_demod_write_reg failed with -9
r82xx_write: i2c wr failed=-9 reg=17 len=1
r82xx_set_freq: failed=-9
By searching around I found this commit that makes the trick for me.
https://github.com/keenerd/rtl-sdr/commit/
9ed9ffa37e24f3293fa960cfcd74909ac3e9996c
This will actually really set the frequency and remove the last 2 errors
related to "r82xx". The only error remaining is then
rtlsdr_demod_write_reg failed with -9
If you can include that upstream that would be nice.
I created a pull request here : https://github.com/steve-m/librtlsdr/pull/56
Actually the commit is part of a large PR that you may be interested in ?
https://github.com/keenerd/rtl-sdr/pull/8
Regards,
CC to osmocom sdr ML
> Dear friends and fans of software-defined radio and free/open-source radio topics in general,
>
> FOSDEM 2020 (the free and open-source developer's meeting in Brussels, Europe) will, once again, feature a track on Software Defined Radio, and any other radio-related topics in the (now known as) Free Software Radio devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your talks or demos.
>
>
> Software Radio has become an important tool to allow anyone to access the EM spectrum. Using free software radio libraries and applications and cheap hardware, anyone can now start hacking on wireless communications, remote sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, we hope to network all these projects and improve collaboration, bring new ideas forward and get more people involved.
>
>
> The track's web site resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website.
>
> https://fosdem.org/2020/schedule/track/free_software_radio/
>
>
> Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2020
>
>
> ** Submit your presentations
>
> To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM20 and follow the instructions (you need an account, but can use your account from last year if you have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Lengths aren't fixed, but give a realistic estimate and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). Also, don't forget to include time for Q&A.
> We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much.
>
> You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an open-source conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff.
>
> Topics discussed in this devroom include:
>
> * SDR Frameworks + Tools
> * Cellular/telecoms software
> * Free/Open SDR hardware
> * Wireless security
> * Random fun wireless hacks
> * SDR in education
> * Satellite/spacecraft communication
> * Ham radio related topics
>
>
> ** Important Dates
>
> FOSDEM is February 1st and 2nd, 2020. The Free Software Radio devroom is happening on Sunday, the 2nd of February.
>
> The submission deadline is Friday, December 6th. A complete schedule for the presentations in the devroom will be available on the 15th of December.
>
>
> In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon!
>
> ** Steering Committee
> The track committee consists of:
>
> * Phil Balister - "Crofton"
> * Sylvain Munaut -"tnt"
> * Derek Kozel - "dkozel"
> * Nicolas Cuervo - "primercuervo"
> * Martin Braun - "mbr0wn" (Emeritus)
Cheers,
Sylvain
Dear Osmocom SDR community,
Dear Dimitri,
the situation around gr-osmosdr has been deteriorating for years.
Among other things, I notice:
* there has not been a tagged release since 2014
* patches (e.g. fixing clang support) are not merged
* there is no support for gnuradio 3.8
I raised at least some of this both on-list (in June 2018 at
http://lists.osmocom.org/pipermail/osmocom-sdr/2018-June/001766.html)
and off-list in personal discussions, e.g. at CCCamp2019
It is clear that technically there are alternatives these days
(mainly SoapySDR, which didn't exist when gr-osmosdr started in 2012).
However, at the same time I'm seeing plenty of users asking about gr3.8
support, as there are [probably] lots of existing applications which
are not ported to other input blocks. As the overall Osmocom project
leader, this puts me in a difficult position: I've never been involved
with gr-osmosdr myself, but I get various related e-mail which show that
there are users, and that they are struggling by a lack of maintenance.
It appears that original author and maintainer Dimitri has lost time
and/or interest in maintaining gr-osmosdr. That's very sad, but it is a
fact that people have a limited amount of time, and priorities change.
I'd like to thank Dimitri and all other gr-osmosdr
developers/contributors for what they have done so far.
But what has unfortunately been missed here during the last 1-2 years is
passing the project over to a new maintainer or group of maintainers.
Just because the original author is not around anymore, it doesn't mean
the project has to die. So with this message, I'm publicly calling for
some other community member[s] to step up and become maintainer[s] of
gr-osmosdr.
Who is interested in gr-osmosdr and willing to maintain it, possibly in
a team with other interested folks?
I would be more than happy to provide the respective accounts/access on
the osmocom.org redmine as well as the official osmocom.org upstream
repository.
There's a list of open issues at http://osmocom.org/projects/gr-osmosdr/issues
I know there are also many forks on github, including
* https://github.com/igorauad/gr-osmosdr/tree/gr3.8 gr3.8 support
* https://github.com/xtrx-sdr/gr-osmosdr/ with xtrx support
* https://github.com/zhovner/gr-osmosdr and https://github.com/Sevyls/gr-osmosdr
with clang/MacOS related fix
* https://github.com/wirstrom/gr-osmosdr with soapy end-of-burst fix
* https://github.com/thegildedturtle/gr-osmosdr hackrf raspi signedness fix?
* https://github.com/ScanOC/gr-osmosdr print AirSpy serial number on connect
* https://github.com/romeojulietthotel/gr-osmosdr cosmetics
* https://github.com/racerxdl/gr-osmosdr spyserver support?
* https://github.com/rascustoms/gr-osmosdr airspy related patches
* https://github.com/newdreamlj/gr-osmosdr bladerf multi stream fix
* https://github.com/Lukeekul/gr-osmosdr bladerf pass source/sink args
* https://github.com/IW0HDV/gr-osmosdr perseus HF support
* https://github.com/dl1ksv/gr-osmosdr rs-hfiq support
* https://github.com/carpikes/gr-osmosdr/ hackRF AVX/SSE performance
* https://github.com/aports-ugly/gr-osmosdr gr3.8 + xtrx support
* https://github.com/amungo/gr-osmosdr ADSDR support
* https://github.com/0pq76r/gr-osmosdr/commits/master expose rtl-sdr gain stages
So there's no shortage of interesting fixes and features to investigate
and/or merge, even beyond the 'make a release and port to gr3.8'.
Thanks in advance!
Regards,
Harald
--
- 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 everyone,
I've created a branch of fosphor with the goal of making it compatible with
GNU Radio 3.8 (specifically the maint-3.8 branch). I've branched fosphor
from
https://github.com/osmocom/gr-fosphor/tree/gr38-qt5.
My branch is located at
https://github.com/the-aerospace-corporation/gr-fosphor/tree/gr38-qt5-aero
The changes are updates to the cmake scripts and modules, most of which are
derived directly from the 3.8 module porting guide located at
https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide
Development was performed in Ubuntu 18.04 with GNU Radio installed using
pybombs and Python 3 support as described at
https://github.com/gnuradio/gnuradio
and using a prefix-based GNU Radio install. The updated fosphor branch has
been tested with NVidia and Intel OpenCL. At this point GLFW works but QT
does not.
To build and install the updated fosphor branch, install GNU Radio 3.8 from
the maint-3.8 branch, install all dependencies as described at the fosphor
wiki, then execute
git clone https://github.com/the-aerospace-corporation/gr-fosphor
cd gr-fosphor
git checkout gr38-qt5-aero
mkdir build
cd build
cmake ..
make
make install
I'm interested in the process for merging my updates back to the official
repository. For instance, additional testing using different platforms
might be a good idea.
Best,
Terry Ferrett, Signal Processing and Estimation Engineer
The Aerospace Corporation <https://aerospace.org/>, El Segundo, CA
Hello,
I'm creating a GNU Radio OOT module in C++ language, in which I instantiate
an osmosdr source. The syntax is : osmosdr::source ::sptr m_source =
osmosdr::source::make();
I also implement other blocks in my design.
In CMakeLists.txt file, I specify all these components:
set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS FFT OSMOSDR)
find_package(Gnuradio-osdmosdr REQUIRED)
include_directories(
...
${GNURADIO_OSMOSDR_INCLUDE_DIRS}
)
link_directories(
...
${GNURADIO_OSMOSDR_LIBRARY_DIRS}
)
In cmake/Modules folder, I copied the FindGnuradio-osmosdr.cmake file from
gqrx project.
The logs of cmake command show that the osmosdr library is found:
-- checking for module 'gnuradio-osmosdr'
-- Found gnuradio-osmosdr, version v0.1.4-127-g4d83c606
-- Found GNURADIO_OSMOSDR: /usr/local/lib/libgnuradio-osmosdr.so
After compiling the module (cmake .. -> make -> make install -> ldconfig),
I got the error 'AttributeError: 'module' object has no attribute 'test'. I
analysed the undefined symbol, and it was due to osmosdr module.
Any suggestion to solve this problem?
PS:
- I'm working on Ubuntu 16.04 (VM), gnuradio 3.7.9, cmake 3.5.1
- In GRC, the osmosdr source and sink work fine
Thanks.
Hello! I am an undergraduate student at Oregon State University working
with RTL-SDR dongles for an academic project under supervision from
Benjamin Brewster, and I had a dev question.
I'm trying to run utilities that capture 978
<https://github.com/mutability/dump978> & 1090Mhz
<https://github.com/mutability/dump1090> traffic simultaneously, but I
can't seem to stop rtl_sdr from allocating too many zero-copy buffers and
preventing both programs from running simultaneously (I'd like to cut down
from 15). I've been through librtlsdr.c and rtl_adsb.c with the hope of
manually changing some variable that will let me accomplish this to no
avail.
Is there some line I might have overlooked, or some additional parameter(s)
I might need to enter?
Thank you for your email, and I appreciate the communication. I did have
one last question: If I were to make a change to the code and need to
recompile it, are the steps the same ones listed on the wiki under
"building the software", or is there a different make process?
On Thu, Aug 15, 2019, 10:51 AM Karl <gmkarl(a)gmail.com> wrote:
> Hi Robert,
>
> It sounds like you're looking for the `buf_num` argument to
> rtlsdr_read_async. This is in rtl-sdr.h:
> https://git.osmocom.org/rtl-sdr/tree/include/rtl-sdr.h#n362 .
>
> I run into problems like that all the time, myself. Due to my issues,
> I've found it hard to collaborate on this project myself. See mailing
> list archive of contributions that were minimally addressed. I try to
> focus around communication that's more reliable than radio now, like
> memo.cash .
>
> But I'm still passionate about helping rtl-sdr grow.
>
> Karl
>
> On 8/15/19, Hudspeth, Robert Lee <hudspero(a)oregonstate.edu> wrote:
> > Hello! I am an undergraduate student at Oregon State University working
> > with RTL-SDR dongles for an academic project under supervision from
> > Benjamin Brewster, and I had a dev question.
> >
> > I'm trying to run utilities that capture 978
> > <https://github.com/mutability/dump978> & 1090Mhz
> > <https://github.com/mutability/dump1090> traffic simultaneously, but I
> > can't seem to stop rtl_sdr from allocating too many zero-copy buffers and
> > preventing both programs from running simultaneously (I'd like to cut
> down
> > from 15). I've been through librtlsdr.c and rtl_adsb.c with the hope of
> > manually changing some variable that will let me accomplish this to no
> > avail.
> >
> > Is there some line I might have overlooked, or some additional
> parameter(s)
> > I might need to enter?
> >
>
I have enabled the direct sampling option to the rtl_tcp. I would like to
submit it as a PR but I need authorization. How do we get authorization?
Thanks,
Richard Frye
Dear Steve,
Could you give a note if there is still work in progress for a linux fix?
I noticed I am affected by this on 5.2, and the last message I find
about this is yours on the arm-kernel list dating back to 9 Nov 2018.
Thanks,
Nuno
I've been studying the rtl_adsb.c code and it's very interesting how it
works..
But, I have question.
I noticed that if I request verbose output using the "-V" option, then the
CRC is printed out. But, it doesn't look like the code actually does any
Reed-Soloman error correction to the data the ADS-B specification
documents.
Am I reading this correctly?
Thanks.
-brad w.
Fix memory leak in librtlsdr.
The problem came up when using rtlsdr_open() twice with the same index.
The variable dev->devh is never cleaned if libusb_claim_interface() fails.
This causes a leak if the device is already claimed by another handle.
rtlsdr_close() did not free that space since the returned handle is invalid
if libusb_claim_interface fails
Here is the patch file in text format. (it is also joined to this email).
~~~~
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index a71609b..89ec903 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1520,10 +1520,6 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t
index)
r = libusb_claim_interface(dev->devh, 0);
if (r < 0) {
fprintf(stderr, "usb_claim_interface error %d\n", r);
- if (dev)
- {
- libusb_close(dev->devh);
- }
goto err;
}
~~~~
-Vincent Perrier
In RTL_SDR, option -b
What does:
"output_block_size (default 16*16384)" mean?
I have been searching and I just can't find that explained anywhere.
Thanks,
Pete
And another thing - the configuration demonstrated on the image you
provided is an actual Π (pi) type low pass filter composed by R-L-R
elements.
There, the individual resistor is 150 ohm, in DC they are parallel, in RF
they make a low pass filter along with the coil in btw.
Some implementations do not use any coil but a 0-ohm shunt resistor
instead. That means the resistors are parallel and they yield 75 ohms.
Cheers
On Sat, 25 May 2019 at 16:10, Ioannis Makris <makrisj(a)gmail.com> wrote:
> I mean that each RGB analog output of the FL2k on the PCB has permanent
> fixed terminations of 150 ohm. Still, I need to apologise for having to add
> a correction:
>
> Some of the dongles having only analog output are being terminated @ 75
> ohms at the factory.
>
> Ref.1: http://www.marsport.org.uk/smd/mainframe.htm
> Ref.2: See attached image
>
> This is normal. Those outputs are most probably open emitter outputs;
> hence they need a termination in order to actually produce any current.
> Leaving them floating in DC would most probably lead to unexpected and
> unaccounted for results.
> One could experiment by adding different values for termination or even a
> 330 ohms trimmer in rheostat configuration,while maintaining at least an 75
> ohms resistor in series so as to give a range of 75-405 ohms of
> termination.
> What is to be monitored is the actual spectral behavior of the DAC rather
> its maximum output, as there are unwanted spectral elements that could
> register as power output on the wanted frequency in conventional needle
> meters, when it actually that is far from truth.
> Affecting terminations yields intermodulation in amplifiers and unwanted
> spectral elements may occur due to several effects I can think of.
> Always monitor spectral output if you want to transmit with this thing.
> What I've seen is that if you just add 20dB of gain on its output without
> applying heavy filtering beforehand you could easily end up to jail for
> interfering aviation frequencies used at airports nearby.
>
Hi!
due to work overloead I've asked Martin to take over doing the various
design changes of osmo-clock-gen towards v2. As the work progresses, we
have some questions about your preference.
The major changes performed so far in the design:
1) switch from SAMD11 to SAMD21 processor (more flash/ram)
https://osmocom.org/issues/3856
We also used the opportunity of having more UARTs available to use a
different UART on the UEXT than on the 2.5mm console port.
There are no questions here.
2) allow different output voltages for two of the four banks of the Silabs chip
https://osmocom.org/issues/3905
* have jumpers in-line of two of the four output banks of the PLL chipc
* jumper closed: reference is drawn from one (shared) "other voltage" LDO onboard
* jumper open: reference voltage can be provided/injected by user from external reference
What's still open to discuss is whether or not the LDO will be fixed
(you have to change resistors to change the voltage) or adjustable. In
the latter case, we'd apply the DAC output of the SAMD21 as an input to
the tracking input of the LDO. However, this would mean that we'd no
longer have the DAC output for driving a VCTCXO.
Which brings us to
3) should we keep the VCTCXO?
I really only placed it in v1 as PCB space was available. Note that
while v1 can drive the VCTCXO Control voltrage from the microcontroller,
there is no circuitry on board to acually measure/compare/count the
output frequency and hence it's not possible to really have a control
*loop* as the feedback is missing. That makes it rather useless.
So for the v2, we can either
a) remove the VCTCXO altogether and use the DAC output for
software-modifiable output voltage levels of [some of] the clocks, or
b) try to come up with a way to actually count the clock cycles and
compare it against some reference. I'm not sure the SAMD21 could do
a very good job of that, as I'm assuming that all inputs are sampled
to some internal clock and hence experience jitter.
I personally would go for 'a', as to me this board/module was always only
about the PLL, and not about providing a stable reference itself. I'd
much rather have a separate board/module with a GPS-DO, which then
provides a 10MHz reference into any number of osmo-clk-gen boards to
derive any number of other clocks. Sort of like the good old unix
philosophy of doing only one thing in one program and chaining them
together.
Any thoughts?
There's also still to be done:
4) Use SAMD XOSC / PLL / GCLK to allow lower reference frequencies
https://osmocom.org/issues/3857
Where we'd actually use one of the SAMD GCLK outputs as one of the
intputs to the Si5351C, and expose a GCLK input of the SAMD on an
external header. This way, much lower frequencies can be used to
driver the Si5351C. Or one could even go for deriving them from the
SAMD RTC XTAL.
Regards,
Harald
--
- 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)
While this is truly unexpected behaviour, please understand that the device
was designed for a termination load of 75+j0 ohms (that's what all
video/VGA analog signals require to be present at the load side) so any
other load impedance value is untested at factory.
I have independently tested that shorting the output to the ground causes
an instant halt to the output of the plain VGA dongle, so there might be
some protection circuit. Also, the VGA circuit has 150 ohms termination
loads.
Hello.
Managed to compile gr-osmosdr from git with gnuradio
3.8tech-preview-365-gd66bc948 (Python 3.7.3)
Having some issue converting osmosdr-source and sink block files from xml
verion to yml.
Anyone done such they'd be willing to share?
Thank you.
--
If something is requisite, how can it possibly be, prerequisite?
vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo
Hi. When running the command line
fl2k_fm -c 5000 /dev/zero
to generate a continuous wave, the output voltage of the fl2k dongle
regularly switches between two different amplitude levels (peak to
peak voltage) every 2 or 3 seconds, by about %30 to %70 depending on
the load. There's no visible gradual transition, it just switches
instantly. The output peak-to-peak voltage is about 350 milivolts with
no load. I've calculated the output impedance to be about 750 ohm at
that frequency for the larger output level.
I'm using the HDMI version of the dongle with the wire soldered after
a capacitor (or resistor maybe) which was already there, to the red
VGA pixel output of the chip.
Could the issue be because some signal conditioning circuitry is
missing that is present in the actual VGA version of the dongle, or
that the pin is actually pulled to ground in this dongle as it is
unused, and the chip doesn't like it and for some reason it then
decides to regularly switch voltages? Any other ideas?
If I write software that uses the rtlsdr library that is already installed
on the computer, does my software also have to be opensource?
Thanks,
Richard
Hi all
I am trying to use osmocom fl2k in my macbook pro. I have compiled the software but when I plugged the new falcon 2000 base usb3 to vga adapter I am not getting that in USB list. Please guide me , should i need any specific driver? And the next steps
Thank you
Hello,
I am trying to develop a simple application using rtlsdr's library functions as simple as rtlsdr_get_device_count().
But, at the moment of compilation GCC is unable to find the reference to the function and exit the errors :
« Undefinded reference to the function rtlsdr_get_device_count() ; »
« ld returned 1 exit status »
My code is below :
#include <stdio.h>
#include <stdlib.h>
#include «/usr/include/rtl-sdr.h »
int main(int argc, char *argv[])
{
int device_count ;
device_count = rtlsdr_get_device_count() ;
printf(« Device ID : %d », device_count) ;
return 0 ;
}
That sounds normal because source code and headers files are dispatched in different files and not compiled.
A solution would be to copy each headers, each sources together and compile them. But it should take a lot of times...
It should exists another solution but I don't find it.
For example, in the acarsdec software, how the developer was able to compile his software ?
I hope I well explained my issue,
Thank you in advance for your help
Best regards,
____________________________________________________________________
Justin Guérinot
Intern | Capgemini Digital Engineering & Manufacturing Services
Capgemini France | Toulouse
Mob.: + 33 6 33 77 14 32
www.capgemini.com<http://www.capgemini.com/>
[https://visualidentity.capgemini.com/capgemini.png]
____________________________________________________________________
Connect with Capgemini:
[cid:image002.png@01D41855.E5D1B680]<https://www.capgemini.com/insights-and-resources/blogs>[cid:image003.png@01D41855.E5D1B680]<https://www.twitter.com/capgemini> [cid:image004.png@01D41855.E5D1B680] <https://www.facebook.com/capgemini> [cid:image005.png@01D41855.E5D1B680] <https://www.linkedin.com/company/capgemini> [cid:image006.png@01D41855.E5D1B680] <https://www.youtube.com/capgeminimedia> [cid:image007.png@01D41855.E5D1B680] <https://www.slideshare.net/capgemini> [cid:image009.png@01D41855.E5D1B680] <https://plus.google.com/+CapgeminiGlobal>
Please consider the environment and do not print this email unless absolutely necessary.
Capgemini encourages environmental awareness.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
This is my first post and I have been experimenting with an rtl-sdr for
only a few weeks. So I am sure I am not doing a lot of things
correctly. But:
I have created a GRC flow graph that does what I want. It has a
rtl-sdr>FIR filter> I/Q samples> file.
I need to create a stand alone program that when run, implements the
same functions but rather then sending the samples to a file, passes
them to my program for further processing.
I intend to run it on a Raspberry Pi so the less overhead the better.
Thanks In Advance.
Pete
Hi
I'm experiencing a "bus error" everytime rtl-sdr tries to interact with my
SDR. Here's a sample:
rtl_fm -f 1000000
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Tuner gain set to automatic.
[R82XX] PLL not locked!
Tuned to 1252000 Hz.
Oversampling input by: 42x.
Oversampling output by: 1x.
Buffer size: 8.13ms
Exact sample rate is: 1008000.009613 Hz
Allocating 15 zero-copy buffers
Bus error
I'm running Kali on a Raspberry Pi, and I've used the repository version,
and compiled from source — no change. The only thing that makes this error
go away in `rtl_test` is to pass it the -S flag (forcing synchronous) flow.
Does anyone have any idea how to fix this?
If you'd like the Karma and would like to help solve this problem publicly
for future users, Stack Overflow question continuously being updated is
here:
https://stackoverflow.com/questions/54657089/rtl-sdr-crashes-with-bus-error…
―Amin Shah Gilani <https://amin.gilani.me/>
I have managed to replace both buck DC-DC converters with AMS1117 3.3 &
lm317 linear regulators and I successfully got rid of the mentioned 1 MHz
buck converter clock to obtain as pure a signal as possible. Do not expect
miracles as the DAC's are 8-bit and have a best case SNR of -48dB, but
getting the sideband modulation out of the signal surely improves the
resulting spectrum a lot.
I have performed the mod on 4 fl2k adapters.
Two of them came with a 1.2V AMS1117 for the 1.2V and a buck psu for the
3.3V. Another two came with 2 buck psu's
Using 2 LM317 is a bit complex but can be done, as my proof of concept
testbed has demostrated. One could actually fit them inside the plastic
box. Mind you, linear regulators can get quite hot. Still not hot enough to
inflict any damage after a 8-hour operation of the device.
Another notable effect was the total elimination of "cb status 1" message
on the testbed. The testbed suffered a lot of USB connection drops due to
poor power delivery to the chip, which is also the plague of those devices
that is causing bad reviews along with the poor assembly of the cable from
those that use the device in regular vga output mode. The workaround is
extremely simple; we use the onboard capacitors for filtering the output of
the linear regulators, I install them inverted and add metal pins from 1/4W
resistors to patch the power from the pin of the buck chip to the input of
the linear regulator. Same with ground.
Of course we are using USB3 interface that can provide more than 2.5W
(500mA) of output power. I haven't thorougly tested device operation and
stability under USB2.0 which has the aforementioned power limiting. The
device looks stable though.
There are implementations utilizing a pair of AMS1117 from factory.
[image: 20190125_194224_001.jpg]
Has anyone tried replacing the MT34TL/AS11D buck converter/supply
chip with a LDO regulator as Steve Markgraf suggested - my goal is to
remove the harmonics, for HF tx.
The MT34TL/AS11D(xx) datasheet is available online so it seems very do-
able - just considering all the pitfalls - issues/ obvious things I
missed ;)
Any input/advice is much appreciated.
-Matt
I'm a RTL-SDR researcher and DSP learner currently working on a project for
properly figuring RTL2832 and I/Q fundamentals out. The project is about
reading raw I/Q samples, processing samples and creating FFT graph from
them. I tried to explain what I'm doing in detail with comment lines. I'm
hoping that I will be helpful to RTL-SDR beginners with this rtl_map [C]
project. Another purpose of the rtl_map project is making a frequency
scanner application for signal security researches.
Another information about the project, installation instructions and
example usages exist at the GitHub repository.
https://github.com/KeyLo99/rtl_map
Hi Rey + Robert,
I've just also been hit by a bug that was already filed some 5 months ago
in the osmocom.org bug tracker: http://osmocom.org/issues/3512
It seems that the bladerf support to gr-osmosdr added in 2018 unconditionally
accepts any libbladerf version installed and subseequently enables the support
for it, only then to fails to compile as it actually appears to require a minimum
version of 2.0.0 for which it doesn't check during the cmake step.
I don't know much about Cmake and hence it would be great if you as the authors
of the related code could find a minute to ensure that gr-osmosdr will simply
not try to build bladerf support if the version of libbladerf is too old.
I'm aware that I can of course manually disable bladerf support, but that's
more a work-around than a proper solution, IMHO.
Thanks in advance!
Regards,
Harald
--
- 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, after I make the appropriate bandpass filters, I wanted to attach the
device to an antenna and try some SSB HF, maybe 10 or 20 meter band. I
noticed there are no SSB examples and so I will need to write the program
myself.
I was contacting to ask if there is any reason that the examples use
standalone binaries to interact with the fresco chip rather than writing a
library for gnuradio. Did something about gnuradio make the fresco's
integration with it impractical? Would I be better off proceeding by
writing a gnuradio block for the Fresco sink or a standalone SSB-tx program?
The novelty of demonstrating that such a cheap setup is feasible really
appeals to me.
Thanks,
Joseph Hutchins
This allows to get the device index based on the usb bus and port number
Signed-off-by: Nicolas Sugino <nsugino(a)3way.com.ar>
---
include/rtl-sdr.h | 12 ++++++++++++
src/librtlsdr.c | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index 3ed13ae..d1e3c1e 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -60,6 +60,18 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index,
*/
RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial);
+/*!
+ * Get device index by USB bus and port number
+ *
+ * \param bus bus number where the device is connected
+ * \param port port number where the device is connected
+ * \return device index of first device where the name matched
+ * \return -1 on libusb initialization failure
+ * \return -2 if no devices were found at all
+ * \return -3 if devices were found, but none with matching bus and port
+ */
+RTLSDR_API int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port);
+
RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index);
RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev);
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 89ec903..0d0804d 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1436,6 +1436,48 @@ int rtlsdr_get_index_by_serial(const char *serial)
return -3;
}
+int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port)
+{
+ int r = -2, index = 0;
+ int i, found = 0;
+ libusb_context *ctx;
+ libusb_device **list;
+ struct libusb_device_descriptor dd;
+ uint8_t reg, dev_bus, dev_port;
+ ssize_t cnt;
+
+ r = libusb_init(&ctx);
+ if(r < 0){
+ return -1;
+ }
+
+ cnt = libusb_get_device_list(ctx, &list);
+ if (!cnt) {
+ libusb_exit(ctx);
+ return -2;
+ }
+
+ for (i = 0; i < cnt; i++) {
+ libusb_get_device_descriptor(list[i], &dd);
+
+ if (find_known_device(dd.idVendor, dd.idProduct)) {
+ dev_bus = libusb_get_bus_number(list[i]);
+ dev_port = libusb_get_port_number(list[i]);
+ if(bus == dev_bus && port == dev_port) {
+ found = 1;
+ break;
+ }
+ index++;
+ }
+ }
+
+ libusb_free_device_list(list, 1);
+
+ libusb_exit(ctx);
+
+ return found ? index : -3;
+}
+
int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
{
int r;
--
2.13.6
Hi my friends
I'w got a problem wen install direct sampling mode. When install openwebrx everything is ok up and running.
The problem is when I install the direct sampling mode (Have install 3 other and no problem). This is the
first Ubuntu 18.04. I copy the log here but it is only from startup script.
[openwebrx-main] Configuration script not specified. I will use: "config_webrx.py"
[openwebrx-main] nmux_bufsize = 602112, nmux_bufcnt = 84
[openwebrx-main] Started rtl_thread: rtl_sdr -s 2400000 -f 144250000 -p 0 -g 5 -| nmux --bufsize 602112 --bufcnt
84 --port 4951 --address 127.0.0.1
[openwebrx-main] Waiting for I/Q server to start...
rtl_sdr: symbol lookup error: rtl_sdr: undefined symbol: rtlsdr_set_dithering
nmux: listening on 127.0.0.1:4951
nmux: (main thread/for) end input stream, exiting.
Lars SM6HOC
Hi!
today I discovered that the gr-osmosdr package in debian unstable contains
a whooping list of 96 patches. This is due to the fact that since November
2014 there hasn't been any tagged versions in the repository.
I'd like to suggest to tag releases a bit more often.
@horizon: What about jumping to 1.0.0 right away?
Regards,
Harald
--
- 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)
Good evening -
I am trying to make modifications to rtl_fm so that I can change
frequencies, gains, modulation types, and squelch values on the fly (and
thus avoiding a restart).
Its unclear to me what functions need to be called in order to apply
changes to the sdr device so that I can do the above. The rtl_fm code isnt
documented so I dont have much to go off of...
GQRX doesnt run reliably on any RPi3's I've tried so I hoping to use a
modified rtl_fm in its place. Any help would be appreciated.
Thanks :)
This allows to get the device index based on the usb bus and port number
Signed-off-by: Nicolas Sugino <nsugino(a)3way.com.ar>
---
include/rtl-sdr.h | 12 ++++++++++++
src/librtlsdr.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index 3ed13ae..d1e3c1e 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -60,6 +60,18 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index,
*/
RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial);
+/*!
+ * Get device index by USB bus and port number
+ *
+ * \param bus bus number where the device is connected
+ * \param port port number where the device is connected
+ * \return device index of first device where the name matched
+ * \return -1 on libusb initialization failure
+ * \return -2 if no devices were found at all
+ * \return -3 if devices were found, but none with matching bus and port
+ */
+RTLSDR_API int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port);
+
RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index);
RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev);
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 89ec903..12a196f 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1436,6 +1436,47 @@ int rtlsdr_get_index_by_serial(const char *serial)
return -3;
}
+int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port)
+{
+ int r = -2, index = -3;
+ int i;
+ libusb_context *ctx;
+ libusb_device **list;
+ struct libusb_device_descriptor dd;
+ uint8_t reg, dev_bus, dev_port;
+ ssize_t cnt;
+
+ r = libusb_init(&ctx);
+ if(r < 0){
+ return -1;
+ }
+
+ cnt = libusb_get_device_list(ctx, &list);
+ if (!cnt) {
+ libusb_exit(ctx);
+ return -2;
+ }
+
+ for (i = 0; i < cnt; i++) {
+ libusb_get_device_descriptor(list[i], &dd);
+
+ if (find_known_device(dd.idVendor, dd.idProduct)) {
+ index == -3 ? index = 0 : index++;
+ dev_bus = libusb_get_bus_number(list[i]);
+ dev_port = libusb_get_port_number(list[i]);
+ if(bus == dev_bus && port == dev_port) {
+ break;
+ }
+ }
+ }
+
+ libusb_free_device_list(list, 1);
+
+ libusb_exit(ctx);
+
+ return index;
+}
+
int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
{
int r;
--
2.13.6
This allows to get the device index based on the usb bus and port number
Signed-off-by: Nicolas Sugino <nsugino(a)3way.com.ar>
---
include/rtl-sdr.h | 12 ++++++++++++
src/librtlsdr.c | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/include/rtl-sdr.h b/include/rtl-sdr.h
index 3ed13ae..d1e3c1e 100644
--- a/include/rtl-sdr.h
+++ b/include/rtl-sdr.h
@@ -60,6 +60,18 @@ RTLSDR_API int rtlsdr_get_device_usb_strings(uint32_t index,
*/
RTLSDR_API int rtlsdr_get_index_by_serial(const char *serial);
+/*!
+ * Get device index by USB bus and port number
+ *
+ * \param bus bus number where the device is connected
+ * \param port port number where the device is connected
+ * \return device index of first device where the name matched
+ * \return -1 on libusb initialization failure
+ * \return -2 if no devices were found at all
+ * \return -3 if devices were found, but none with matching bus and port
+ */
+RTLSDR_API int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port);
+
RTLSDR_API int rtlsdr_open(rtlsdr_dev_t **dev, uint32_t index);
RTLSDR_API int rtlsdr_close(rtlsdr_dev_t *dev);
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index 89ec903..eca093a 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1436,6 +1436,47 @@ int rtlsdr_get_index_by_serial(const char *serial)
return -3;
}
+int rtlsdr_get_index_by_usb_bus_port(uint8_t bus, uint8_t port)
+{
+ int r = -2, index = -3;
+ int i;
+ libusb_context *ctx;
+ libusb_device **list;
+ struct libusb_device_descriptor dd;
+ uint8_t reg, dev_bus, dev_port;
+ ssize_t cnt;
+
+ r = libusb_init(&ctx);
+ if(r < 0){
+ return -1;
+ }
+
+ cnt = libusb_get_device_list(ctx, &list);
+ if (!cnt) {
+ libusb_exit(ctx);
+ return -2;
+ }
+
+ for (i = 0; i < cnt; i++) {
+ dev_bus = libusb_get_bus_number(list[i]);
+ dev_port = libusb_get_port_number(list[i]);
+
+ libusb_get_device_descriptor(list[i], &dd);
+
+ if (find_known_device(dd.idVendor, dd.idProduct) &&
+ bus == dev_bus && port == dev_port) {
+ index = i;
+ break;
+ }
+ }
+
+ libusb_free_device_list(list, 1);
+
+ libusb_exit(ctx);
+
+ return index;
+}
+
int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
{
int r;
--
2.13.6
Dear fellow Osmocom developers,
I'm a bit surprised to notice that not more people have signed up for
OsmoDevCon 2019. I guess it was mostly an oversight when the date was
originally announced, and not a lack of interest? ;)
All details about the event are available at the related wiki page at:
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019
Please enter your name at
https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested
in case you would like to attend. Registering early allows proper
planning. Thanks!
Looking forward to meeting old and new Osmocom developers in April 2019.
Regards,
Harald
--
- 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)
Hello and thanks for the amazing piece of software.
Despite having managed to do much stuff with it under x64 linux, I failed
miserably to make it work under ARM architecture.
To be more specific, I tried the Odroid-XU usb3.0 capable board and the
Odroid-C1 Usb2.0 board to no avail.
Odroid XU kernel: 3.4.y Odroid-C1 kernel: 3.10.107
I used all reasonable ranges of sampling rates and here are the results:
Program seems to run normally. No error codes and.. no buffer underruns at
all. In my i3 laptop I get some buffer underruns but to arm I have never
spotted such a message no matter what the sampling rate is.
When the sampling rate is a fraction of what fl2k_test reports as maximum,
I see the sampling rate spike on my spectrum analyzer (Advantest TR4132).
But when I opt for fl2k_fm, I see no response whatsoever other than the
enabling of the DAC visible as an increase of a few dB's of noise and a
hint (3dB C/N) at the sampling frequency.
I tried the binary repositories of libusb for my distribution, and I even
compiled locally libusb from source - nothing changed.
What could be making such a mess? I have spent over 3 days on efforts to no
avail. I just want to explore upconversion possibilities but I need to
encapsulate both the host and the FL2000 into a shield in order to get
meaningful experimental results.
Please help if you can
Thanks
Ioannis (John) Makris
SV9OFO
Hi Martin, hi Community,
first of all: thanks for all the fish err GREPs! We need to kick off
this discussion.
So, this PR is very dear to my heart, because I consider log4cpp to be
an especially problematic dependency.
And I consider our logging to be subpar considering the size of the
code base, user base and the fact that people are using GNU Radio in
infrastructure for rather expensive things.
So, I took the opportunity (being at 35c3, just to pose around a little
bit) and talked to a couple Osmocom folks. Osmocom people, please
correct me if I make any mistakes.
What they have in osmocore is essentiall logging in both quantized
severity and in categories, and logging routing.
For them, that's very important, as they use that to supply resilient
infrastructure. I hope I'm representing the idea kinda correctly here:
They might want to log system events ("SUPERVISOR: INFO system load
surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a
preamble") on-screen, and critical messages ("gr-digital: FATAL run out
of developer coffee") everywhere.
I want that too. I want this to be easily integratable into software
that uses GNU Radio as library. And if I'm already making wishes here,
I want loggers that interface to modern logging systems, be it
journald, graylog or SNMP. Something.
So, I think that's pretty similar to what UHD does (correct me please,
Martin). I think that UHD is a bit more flexible on the logging
"categories" than I'd like to be, but that really just means we need to
set a convention.
So, I'm stuck wondering whether we adopt the self-implemented system
that UHD uses, or the self-implemented system that osmocore uses, or
implement our own.
Familiarity suggests UHD, maturity osmocore.
Best regards,
Marcus
On Thu, 2018-12-27 at 13:49 -0800, Martin Braun wrote:
> This GREP was recently submitted here:
>
>
https://github.com/gnuradio/greps/blob/master/grep-0013-remove-log4cpp.md
>
> We may or may not go through with this. However, we like to kill
> dependencies (hey there node.js developers :D ), and log4cpp has some
> issues of its own that we're currently inheriting.
>
> Personally, I use GR logging only for debugging purposes. But I know
> that others use it for other reasons, and this thread is a good place
> to discuss:
> - Alternatives to log4cpp (I've listed Boost.Log and hand-spun as
> options)
> - What people need it for
> - Is the current logging in a good shape as it is
> - Who wants to own this task?
> - etc.
>
> Cheers,
> Martin
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio(a)gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio