osmocom-sdr

osmocom-sdr@lists.osmocom.org

904 discussions

No 64-bit librtlsdr for windows.
by Bill Gaylord 07 Apr '17

07 Apr '17

Hello. So I have ran into a small problem. I used a python library called pyrtlsdr which uses ctypes to interact with librtlsdr. But when I upgraded my python form 32 bit to 64 bit the library no longer works because the librtlsdr.dll is 32 bit not 64. So has anyone had luck compiling a 64 bit version of librtlsdr? Or knows how to?

1 0

Re: git.osmocom.org cgit improvements
by Holger Freyther 19 Mar '17

19 Mar '17

> On 18 Mar 2017, at 16:09, Neels Hofmeyr <nhofmeyr(a)sysmocom.de> wrote: > > Hi, > All in all these are excellent improvements! > Holger, what's the status of your promise, made one day in a chat, to make > redmine catch the OS#123s? lol, I love how we go from a private chat to this CC list. I have not looked at it but maybe this is something for an afternoon at Osmodevcon. It should be fairly simple with redmine. holger

1 0

Questions about error when using Osmocom sink
by XueQiuyue 19 Mar '17

19 Mar '17

Dear Mr/Ms, I meet errors when use osmocom sink and source in GNU Radio, I have tried BladeRF and HackRF, and I use Ubuntu 16.04. 1.When I use BladeRF, I set the parameters as "bladerf=701c2ce1da297914cb29695ba79fac54,fpga=<'/Users/qiuyuexue/Documents/BladeRF/hostedx115-latest.rbf'>,fpga-reload=1,buffers=32,buflen=4096,transfers=16,stream_timeout_ms=3000,loopback=none,verbosity=silent,xb200.” and I got error as: “(top_block.py:4795): IBUS-WARNING **: The owner of /home/ceca_517/.config/ibus/bus is not root! gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.10 built-in sink types: hackrf bladerf redpitaya file Opening nuand bladeRF with device identifier string: "*:serial=701c2ce1da297914cb29695ba79fac54" [bladeRF sink] Loading FPGA bitstream </home/ceca_517/LPWAN/SOAR(a)PKU/LPWAN/BladeRF/hostedx115-latest.rbf>... [bladeRF sink] bladerf_load_fpga has failed with -11 [bladeRF sink] Warning: 'loopback' has been specified on a bladeRF sink, and will have no effect. This parameter should be specified on the associated bladeRF source." 2.when I use HackRF, I set the parameter as "hackrf=393b4b,bias=1,bias_tx=1,buffers=32.” and I got error as: "(top_block.py:5108): IBUS-WARNING **: The owner of /home/ceca_517/.config/ibus/bus is not root! gr-osmosdr v0.1.4-86-ge9dde9af (0.1.5git) gnuradio 3.7.10 built-in sink types: hackrf bladerf redpitaya file FATAL: bad lexical cast: source type value could not be interpreted as target Trying to fill up 1 missing channel(s) with null sink(s). This is being done to prevent the application from crashing due to gnuradio bug #528.” I want to know if I set the parameters wrong? Or anything else? Thanks a lot for your help and your time! Thanks very much!! Best, Qiuyue

2 1

git.osmocom.org cgit improvements
by Harald Welte 17 Mar '17

17 Mar '17

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. 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)

1 0

Recording rtl_fm output
by Martin McCormick 14 Mar '17

14 Mar '17

Something I am doing is not quite right. The following example works almost perfectly but please read on. rtl_fm -f 88.3e6 -M wbfm -s 215000 -r 44100 - | aplay -r 44.1k -f S16_LE The audio from the sound card is nearly excellent. To record this stream, I do the following: rtl_fm -f 88.3e6 -M wbfm -s 215000 -r 44100 testfile.bin I get a file so it would appear that the following should sound just like the stream I am listening to using the pipe in the first example. aplay -r 44.1k -f S16_LE testfile.bin The pitch of the audio is fine but instead of almost dead silence between words, there is a lot of hiss and distortion. In theory, I should hear the same mostly noiseless audio I hear in the first example when playing from the file. This is really not a DSP issue but maybe I have saved the audio as unsigned and am trying to play it signed which would preserve the pitch but be a cause for a lot of distortion. Besides, it is apparently signed when piped in to aplay. I am mystified. Thanks. Martin McCormick

1 1

Re: RTL-SDR and RTL-TCP drivers
by Andreas Eriksen 10 Mar '17

10 Mar '17

Thank you for these patches, indeed they fixed my problems with gqrx :-)

1 0

Technical help, umm I think?
by James Clark - KC3CDV 09 Mar '17

09 Mar '17

Hello all, not sure if this will go through or if Ive to subscribe or even if this is the rite place for help like this. I am on a mac running the latest OSX updates and I am waiting for my new SDR to get to me from amazon, Ive got CubicSDR and also Gqrx on the system, well my question is will I be able to just plug and play or will I have to install macports and all that other stuff that goes over my head. Do I have to use turminal? Me trying to use that thing is like a fish trying to live out of water for a year, its vary unlikely it will happen effectivly. Also let me say rite up front please don’t post any photos because I cant see your photos. I hope this is the rite place to ask this question, thank you in advanced. May Peace Be With You. Active skywarn severe weather spotter and Community Collaborative Rain, Hail & Snow Network operative. @HomefrontHugs Volunteer for our Troops and Families

1 0

[hari.blogscripts@gmail.com: reg. a deadlink]
by Harald Welte 01 Mar '17

01 Mar '17

FYI, this was in my personal inbox but is probably better adressed by the people on this list. 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)

1 0

RTLSDR IQ imbalance ???
by a c 27 Feb '17

27 Feb '17

Hello, I use RTL-FM on a raspberry pi3. I notice practically always the presence of a weak carrier accompanying the emission received in AM mode and interferences in NFM mode. When i use rtl-tcp and sdr# or sdrconsole the demodulation is perfect. I assume that IQ amplitude phase correction is involved. I saw in the source of rtlsdr: IQ estimation / compensation (en_iq_comp, en_iq_est) * / Rtlsdr_demod_write_reg (dev, 1, 0xb1, 0x1b, 1); I suppose we use an internal chipset function? Is this function good enough? I did not find anything about it in RTL-FM but I'm not a specialist. Is an improvement possible? Regards, Arnaud

2 1

Floating point error in tuner_r82xx.c
by Steve Knoeck 27 Feb '17

27 Feb '17

Hi, I get a floating point exception when I run rtl_tcp. I traced the error with GDB to line 515 of tuner_r82xx.c if (vco_fra > (2 * pll_ref_khz / n_sdm)) I found that n_sdm was 0. I don't understand how this code work and I'm very new to this software but it sure looks like a programming bug. | 513 /* sdm calculator */|| || 514 while (vco_fra > 1) {|| || 515 if (vco_fra > (2 * pll_ref_khz / n_sdm)) {|| || 516 sdm = sdm + 32768 / (n_sdm / 2);|| || 517 vco_fra = vco_fra - 2 * pll_ref_khz / n_sdm;|| || 518 if (n_sdm >= 0x8000)|| || 519 break;|| || 520 }|| || 521 n_sdm <<= 1;|| || 522 }| If the condition on line 515 ever evaluates to false then vco_fra doesn't get updated. The loop will keep repeating with the same value of vco_fra until n_sdm becomes 0. Steve

2 1

← Newer
1
...
33
34
35
36
37
38
39
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr