osmocom-sdr

osmocom-sdr@lists.osmocom.org

906 discussions

[PATCH] import time library, fixes NameError Exception
by Tony Do 16 Nov '18

16 Nov '18

Error Message in osmocom_spectrum_sense command line tool: tune: Exception: global name 'time' is not defined Undefined command: "tune", Try "help" Simple fix for the osmocom_spectrum_sense utility, the message queue is really good at clearing itself, but for low tune/dwell delays the threads need to sleep while it clears. --- apps/osmocom_spectrum_sense | 1 + 1 file changed, 1 insertion(+) diff --git a/apps/osmocom_spectrum_sense b/apps/osmocom_spectrum_sense index ea365bb..0d280bd 100755 --- a/apps/osmocom_spectrum_sense +++ b/apps/osmocom_spectrum_sense @@ -30,6 +30,7 @@ from gnuradio.eng_option import eng_option from optparse import OptionParser import sys import math +import time import struct import threading from datetime import datetime -- 2.19.1

1 0

fl2k_test sample rate speeds up on Windows
by Francesco Gugliuzza 02 Nov '18

02 Nov '18

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

2 3

(no subject)
by Tom Nash 31 Oct '18

31 Oct '18

Request sibscription

1 0

RTL_SDR dongle not being working with gnuradio
by MB 31 Oct '18

31 Oct '18

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 |

3 2

Disable internal AGC in AirSpy HF+
by Richard Hedlund 30 Oct '18

30 Oct '18

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

1 0

OSMOCOM-fft
by Babak Mafakheri 29 Oct '18

29 Oct '18

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.

2 1

Librtlsdr zerocopy buffers not working on Tinkerboard Armbian
by Carl Laufer 28 Oct '18

28 Oct '18

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

4 7

Re: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt
by Greg Troxel 23 Oct '18

23 Oct '18

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.

2 3

branches, releases
by Greg Troxel 20 Oct '18

20 Oct '18

(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

1 0

Fwd: [PATCH] Related: OS#3663 Fix failed compilation on macOS Mojave with clang in CMakeLists.txt
by Michael Auß 19 Oct '18

19 Oct '18

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. >

1 0

← Newer
1
...
19
20
21
22
23
24
25
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr