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)
Hi,
I encountered this strange behavior when running fl2k_test on Windows 7:
basically after a while the sample rate drifts and speeds up considerably.
Sometimes it even starts up directly like that.
In the command prompt I get:
C:\Users\Francesco
Gugliuzza\Downloads\Sviluppo\FL2000fl2k_win_2018-08-09>fl2k_test.exe -s
138e6
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
real sample rate: 146656386 current PPM: 62727 cumulative PPM: 62727
real sample rate: 150803676 current PPM: 92780 cumulative PPM: 77858
real sample rate: 149716182 current PPM: 84900 cumulative PPM: 80218
real sample rate: 150107883 current PPM: 87738 cumulative PPM: 82104
real sample rate: 150526750 current PPM: 90774 cumulative PPM: 83843
The same thing happens if I compile the latest osmo-fl2k myself using
Cygwin.
I'm running everything on a laptop with an i7 4710HQ CPU and 8 GB of ram,
and I'm using a RayCue HDMI+VGA box.
Do you have an idea why the real sample rate drifts so much?
Thanks!
--
Francesco Gugliuzza
I have a rtl_sdr.com RTL2832U R820T2 dongle. It works with HDSDR and SDRSHARP programs.
Using win10 64 BIT 10.0.17134.345 and GNURadio 3.7.13.4/V1.5Windows reports VID_0BDA, PID_2838
When I run GNUradio, I get [R82XX] PLL not locked!
When I open the GNUradio command prompt and run rtl_test -t, I get this:
setting gnuradio environmentMicrosoft Windows [Version 10.0.17134.345]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Program Files\GNURadio-3.7\bin>rtl_test -t
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.
C:\Program Files\GNURadio-3.7\bin>
At this page, https://osmocom.org/projects/rtl-sdr/wiki/Rtl-sdr shows this table :
VID PID tuner device name
0x0bda 0x2832 all of them Generic RTL2832U (e.g. hama nano) 0x0bda 0x2838 E4000 ezcap USB 2.0 DVB-T/DAB/FM dongle
Is it possible RTL_TEST is looking for a E4000 because of it's dongle's screwy PID, even though it sees a R820T. If not, why is it not working?thanks.
| | Virus-free. www.avast.com |
Hello,
For my purposes in GNU Radio using the osmocom source block i would like to
disable the internal AGC in my AirSpy HF+. I see that i can choose the
"Gain Mode" setting, however i am not sure that will disable (when set to
manual) the AGC on the AirSpy HF+.
Do you know of any good way to achieve this?
I have installed the following library for the AirSpy HF+, where there is
an API which enables you to disable the AGC, however i am not sure how to
achieve this in GNU Radio:
https://github.com/airspy/airspyhf
*$airspyhf_info*
AirSpy HF library version: 1.4.2
S/N: "removed"
Part ID: 0x00000001
Firmware Version: R1.7.2
Available sample rate: 768 kS/s
*$uname -a*
Linux hedric-dev 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Hopefully this is enough information for you, otherwise let me know.
Kind regards,
Richard
Dear all,
I am confused about some parameters of osmocom fft spectrum analyzer.
I am wonder what exactly the vertical axis shows? It is written Power(dB); if so, what is the reference power? Is it 1dBW?
Moreover, by changing the PGA Gain, I will have different values of power (dB). What is the relation between PGA gain and the received power in dBm?
In general, does anyone know how should I find the received power in dBm, having the PGA gain(dB) and the value on vertical axis. (Picture in attach)
Looking forward to your reply.
Bests,
--
--
Le informazioni contenute nella presente comunicazione sono di natura
privata e come tali sono da considerarsi riservate ed indirizzate
esclusivamente ai destinatari indicati e per le finalità strettamente
legate al relativo contenuto. Se avete ricevuto questo messaggio per
errore, vi preghiamo di eliminarlo e di inviare una comunicazione
all’indirizzo e-mail del mittente.
--
The information transmitted is
intended only for the person or entity to which it is addressed and may
contain confidential and/or privileged material. If you received this in
error, please contact the sender and delete the material.
I've been trying to get some RTL-SDRs to function properly on my
Tinkerboard, running Armbian Bionic, Kernel 4.14y. I noticed that with the
Osmocom drivers rtl_test would result in huge sample drops (millions of
samples dropped each time). However, Keenerds branch did not drop any
samples, nor did the presumably older Osmocom drivers from apt-get.
I did a diff against Keenerds and discovered the new zerocopy buffer code
in the Osmocom drivers. After commenting that out, the Osmocom drivers work
fine on the Tinkerboard with Armbian and there is no sample loss.
Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run
Kernel 4.4, I do not get sample loss with the Osmocom drivers and the
zerocopy code enabled.
I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which is
also running Kernel 4.14, and on Raspbian, and on those there is no sample
loss. So it seems to be something specific to the Tinkerboard and Armbian
with Kernel 4.14y.
Not sure if the zerocopy code is just not getting activated on those other
OSes or what. How do I check if the installed libusb API version is >=
0x01000105?
Any ideas what could cause the zero copy code to result in the lost samples?
Regards,
Carl Laufer
Michael Auß <michael.auss(a)gmail.com> writes:
> I did encounter problems with syntax errors when compiling with clang, see
> OS#3663 for details. (Relating to rtl_tcp)
>
> I did not add something to the README.
I can certainly believe you had errors. But, changing the compiler
requirement is significant -- particularly on platforms that don't have
last week's compiler -- and if it isn't the plan to require C++14, then
it seems like a workaround to enable that. My point really is that
there should be a decision about the language, that should be in the
README, and the build system should set --std for that chosen language,
and then whatever needs to be fixed should be fixed.
(I am one of several who look after ham/gnuradio stuff in pkgsrc.)
In gr-osmosdr, it seems 0.1.4 is the most recently release, long ago.
The v0.1.4 tarball seems to build aginst gnuradio 3.7.
There is a gr3.6 branch that has both many commits more than and less
than the v3.6 tag. master has 127 commits beyond v0.1.4 but is not
missing any. This seems odd, as I would expect gr3.6 to be based on
some intermediate commit along the path from 0.1.4 to master.
So I am not following what is going on and why. Now that gnuradio 3.7
seems normal, it seems there should be a release based on master, and
there is no real reason for anyone to use the 3.6 branch (unless they
are on a system that is intentionally using old gnuradio).
Can somebody explain? With any luck I'm confused.
Greg
CC to mailing list
------- Weitergeleitete Nachricht ------
Von: Michael Auß <michael.auss(a)gmail.com>
Datum: Fr. 19. Okt. 2018 um 22:26
Betreff: Re: [PATCH] Related: OS#3663 Fix failed compilation on macOS
Mojave with clang in CMakeLists.txt
An: Greg Troxel <gdt(a)lexort.com>
I did encounter problems with syntax errors when compiling with clang, see
OS#3663 for details. (Relating to rtl_tcp)
I did not add something to the README.
KR
Michael
Greg Troxel <gdt(a)lexort.com> schrieb am Fr. 19. Okt. 2018 um 21:44:
> Michael Auß <michael.auss(a)gmail.com> writes:
>
> > Fix regarding the issue https://osmocom.org/issues/3663macOS Mojave
> > comes with clang but the binary matches by the name c++ instead of
> > clang.Additionally the compiler flag std=c++14 had to be added.
>
> I am surprised about c++14. Is it new that c++14 is required? Is it
> in the README?
>
> gr-osmosdr is at 0.1.4 in pkgsrc, which appears to be the latest
> official release on github. It's marked as needing "c++" which means
> 03, not 11, and not 14.
>
== OsmoCon 2018 ==
OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!
We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.
For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.
Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.
You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.
== Call for Participation ==
We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.
You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp
We are particularly looking for contributions about:
* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects
Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!
Regards,
Harald Welte
--
- 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,
I encountered this strange behavior when running fl2k_test on Windows 7:
basically after a while the sample rate drifts and speeds up considerably.
Sometimes it even starts up directly like that.
In the command prompt I get:
C:\Users\Francesco
Gugliuzza\Downloads\Sviluppo\FL2000fl2k_win_2018-08-09>fl2k_test.exe -s
138e6
Reporting PPM error measurement every 10 seconds...
Press ^C after a few minutes.
real sample rate: 146656386 current PPM: 62727 cumulative PPM: 62727
real sample rate: 150803676 current PPM: 92780 cumulative PPM: 77858
real sample rate: 149716182 current PPM: 84900 cumulative PPM: 80218
real sample rate: 150107883 current PPM: 87738 cumulative PPM: 82104
real sample rate: 150526750 current PPM: 90774 cumulative PPM: 83843
The same thing happens if I compile the latest osmo-fl2k myself using
Cygwin.
I'm running everything on a laptop with an i7 4710HQ CPU and 8 GB of ram,
and I'm using a RayCue HDMI+VGA box.
Do you have an idea why the real sample rate drifts so much?
Thanks!
Francesco
--
Francesco Gugliuzza
M.Sc. in Computer Engineering
Ph.D. Student at DIID, Università degli Studi di Palermo
Qualified to practice as a Professional Engineer
E-mail: fgugliuzza.mail(a)gmail.com
PEC: francesco.gugliuzza(a)pec.it
Reproducible segfault apparently from race condition on my system in librtlsdr.
---
$ uname -r
4.14.67-1.pvops.qubes.x86_64
rtl-sdr and libusb are both current git master.
---
1. run librtlsdr under gdb
$ gdb --args rtl_sdr -f 43M -n 1000 /dev/null
2. place a breakpoint when the cancellation condition is hit,
currently line 1915
1914 if (RTLSDR_CANCELING == dev->async_status) {
1915
next_status = RTLSDR_INACTIVE;
1916
(gdb) break ./src/librtlsdr.c:1915
3. run and continue; segfault after second breakpoint
(gdb) run
(gdb) cont
(gdb) cont
Thread 1 "rtl_sdr" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d76a15 in add_to_flying_list (transfer=0x426590) at
../../libusb/io.c:1396
1396 if (!timerisset(cur_tv) || (cur_tv->tv_sec >
timeout->tv_sec) ||
--
The crash appears to be because the transfers are deallocated while
they are still in flight, and then later referenced by libusb.
I think this happens because the pause gives the transfer time to
complete before it is canceled. The cancel then fails because the
transfer was completed, and the current code assumes this means it is
not in flight, when it actually hasn't been handled yet and will be
resubmitted.
The documentation for libusb_transfer::status at
http://libusb.sourceforge.net/api-1.0/structlibusb__transfer.html#a64b2e70e…
states that it is only correct to read the field from within the
callback handler, and the documentation for libusb_cancel_transfer at
http://libusb.sourceforge.net/api-1.0/group__asyncio.html#ga685eb7731f9a059…
states that the transfer
cancellation is only complete when the callback handler is called with
such status.
Although I imagine there are simpler solutions, I think the correct
solution would be to move cancellation of the transfers into the
callback handler entirely, to eliminate race conditions like this and
respect the libusb documentation. I would enjoy crafting a patch to
make such a change, if that would be helpful.
Karl Semich