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?
> 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
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
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)
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
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
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)
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
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
