Here is a PyBOMBS recipe file that pulls gr-osmosdr from my sdrplay2
branch. If anyone would like to try out this support with a PyBOMBS build,
this would be the easiest way. Best to build everything from scratch, but
you can remove the src/gr-osmosdr directory, do a pybombs fetch/rebuild if
you're comfortable with that.
The SDRplay SDK v2.11 is required, and should be installed before
gr-osmosdr is rebuilt. The ENABLE_NONFREE flag is turned on for this build.
This is just for testing, so I can get some feedback. Hopefully, this will
go into the gr-osmosdr master at some point. It "works for me".
Note that the gains on SDRplay are actually attenuations, so they appear
backward. The LNA attenuation steps on RSPs are frequency dependent, so I
gave up trying to make them look like gains. My main use case is GQRX, and
that way was even more confusing.
There is a GRC sdrplay source that is a little less generic than the
osmocom source.
There are probably ways to repackage this so it can be distributed freely,
but I'll address that if there's more interest. The SDK include file is
redistributable and its terms seem to be compatible with GPL. The shared
object can be dynamically loaded over a placeholder library that does
nothing. Yes, that's hackish and it would be better to have everything free.
SDRplay support, rewritten, supporting RSP1, RSP1A, and RSP2
Requires ENABLE_NONFREE=yes. Requires SDRplay's SDK v2.11 to be installed
by the user. In the future, if there is a way to redistribute
mirsdrapi-rsp.h from the SDK, that problem could be addressed using a shim
library that looks for /usr/local/lib/libmirsdrapi-rsp.so at runtime.
Good afternoon,
I am a complete noob playing with my YardStick one and HackRf one.
I am working a signal that I am fairly certain is using pulse interval encoding and I am having a heck of a time understanding how to turn the NRZ 1's and 0's into the Pulse Interval.
The closest thing I have seen is how RFID uses pulse interval encoding but I don't think that is the same thing.
I started by recording in osmocom_fft
I then used inspectrum to extract symbols and found that most symbols were 1 unit in inspectrum, but there were a few places where there were 2 or 4 in a row of high or low.
Once I exported the symbols I was able to generate a bit string of 1's and 0's representing highs and lows.
I was able to identify the preamble and what I think is the sync word, but that's where I get lost.
I have seen many examples where people take 3 bits and assume that say 001 is a 0 and 011 is a 1n a PWM model but nothing I seem to do seems to work to uncover the PIE encoding and was hoping someone out there could point me in the right direction.
Thanks,
Adam
Sent from my iPad
Hello dear RTL-SDR community,
I just whant to ask if it's possible to modify rtl-sdr.h to lower the
admissible sample rate.
I am currently using 8 dongle successfully but would like to use 12
dongle simultaneously with software (rtlsdr-wsprd) to decode wspr signals.
This one uses the library rtl-sdr.
I would therefore like to be able to use sampling frequencies lower than
250000.
Thanks in advance!
Hello dear RTL-SDR users,
I whant to use multiples dongles as array for decode wspr.
My problem is that I can not use more than 4 USB dongle simultaneously.
I check with usbmon, each dongle uses 500kbits / s around. So I am far
from the maximum bandwidth allowed by usb 2.
I tried using a USB switch with external power supply but it does not
work better.
The default test performed is:
#!/bin/bash
for ((i=0;i<=4;i++))
do
rtl_test -d $i -s 250000 &
done
First 4 is starting but last 5 doesent. And i whant to use more...
Is this a limitation of the RTL-SDR library or the kernel driver?
Do we have a solution to get around the problem?
Thank you in advance for your valuable feedback.
I picked up a SDRplay RSP2 recently, and the gr-osmosdr support needed
some work. Here's a rewrite that works with RSP2 and has other
improvements. When the RSP1A comes in, I'll finish support for that. No
plans to pick up a RSP1, but someone can see if this works if
interested. This was tested against the Nov 2017 binary blob.
https://github.com/willcode/gr-osmosdr/tree/sdrplay2
=====
Complete rewrite of sdrplay support
- Supports RSP2
- Will support RSP1A when hardware arrives
- RSP1 is untested
- Uses streaming callbacks instead of polling
- Tuning, gain control imporoved, AGC supported
- Better performance (one less layer of buffers)
Hello. Question about gsm0503_tch_ahs_decode function in gsm0503_coding
from libosmocore (
http://ftp.osmocom.org/api/latest/libosmocore/coding/html/group__coding.htm…)
. Can you please explain wat's "int odd" mean? If it's odd frame
number then which of the 8? And why to function need 8 burst if in function
loop to 4?
Dear Osmocom Community,
[please respect the Reply-To and post all follow-up discussion to this
to openbsc(a)lists.osmocom.org, so we avoid having long threads
cross-posted to several mailing lists.]
Like every year in early December, it is time to discuss as schedule for
OsmoDevCon in the upcoming year.
Note: Ths is about OsmoDevCon, the more private meeting of developers,
*NOT* about OsmoCon, the public conference.
== When, Who, Where ==
I propose the following date for OsmoDevCon 2018:
April 20 - April 23rd, 2018
* Who: Active developers/contributors of Osmocom projects (as usual)
* Where: IN-Berlin, Berlin (as usual)
Please let me know ASAP if that proposed date works for everyone who'd
want to attend. We can still change it now, but I would want to nail
down the date pretty soon.
== Format ==
After the experiment of reducing from 4 to 3 days last year (due to
OsmoCon), we will again go for *four days* in 2018.
However, we should clearly divide the days in a way that e.g. "GSM/3G"
topics are on two days, while SDR+Other topics are on the other days, so
people not interested in some topics can skip one or two days, as
needed.
We could even divide it further like:
* 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...)
* 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.)
* 2 days misc
Regards, and looking forward to meeting you [again] in 2018,
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)
Waiting for your response.
Warm Regrads,
Shiv Gautam | Manager Communication Systems
--------------------------------------------------------------------------
--------------------------
The Tata Power Company Limited Strategic Engineering Division (Tata Power
SED)
42 - 43 Electronics City Hosur Road Bengaluru 560 100 India
Tel: +91 80 6785 4501 | Fax: +91 80 6785 9901 | Mobile: +91 74110 01394
Website: www.TataPowerSED.in <http://www.tatapowersed.in/>
From: Shiv Shankar Gautam [mailto:ssgautam@tatapowersed.com]
Sent: 21 November 2017 10:01
To: 'osmocom-sdr(a)lists.osmocom.org'
Subject: SDR board design for hand Held tactical SDR
We are looking for SCA compliance SDR hardware design. Please send us the
design
Warm Regrads,
Shiv Gautam | Manager Communication Systems
--------------------------------------------------------------------------
--------------------------
The Tata Power Company Limited Strategic Engineering Division (Tata Power
SED)
42 - 43 Electronics City Hosur Road Bengaluru 560 100 India
Tel: +91 80 6785 4501 | Fax: +91 80 6785 9901 | Mobile: +91 74110 01394
Website: www.TataPowerSED.in <http://www.tatapowersed.in/>
*Disclaimer*
------------------------------------------------------------
Notice: This e-mail and / or attachments (communication) may contain information that is confidential and proprietary to The Tata Power Company Limited, Strategic Engineering Division (Tata Power SED). If you are not the intended recipient of this communication, please do not use or disseminate the information contained therein, notify the sender by e-mail or telephone and delete the communication (permanently) from your system.
Any information in this communication that does not relate to the official business of Tata Power SED shall be understood as neither given nor endorsed by it. Please note that e-mails are susceptible to change and Tata Power SED shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt. This communication is not guaranteed to be free from computer viruses and it is recommended that you check for all viruses before download.
Print this communication only if absolutely essential. Thank you for your co-operation.
------------------------------------------------------------
Hello
Under gnuradio platform, when I send a pure sinusoid using gr-osmocom, what
is the modulation format that osmocom uses? Thank you very much.
Regards
Shuai
We are looking for SCA compliance SDR hardware design. Please send us the
design
Warm Regrads,
Shiv Gautam | Manager Communication Systems
--------------------------------------------------------------------------
--------------------------
The Tata Power Company Limited Strategic Engineering Division (Tata Power
SED)
42 - 43 Electronics City Hosur Road Bengaluru 560 100 India
Tel: +91 80 6785 4501 | Fax: +91 80 6785 9901 | Mobile: +91 74110 01394
Website: <http://www.tatapowersed.in/> www.TataPowerSED.in
*Disclaimer*
------------------------------------------------------------
Notice: This e-mail and / or attachments (communication) may contain information that is confidential and proprietary to The Tata Power Company Limited, Strategic Engineering Division (Tata Power SED). If you are not the intended recipient of this communication, please do not use or disseminate the information contained therein, notify the sender by e-mail or telephone and delete the communication (permanently) from your system.
Any information in this communication that does not relate to the official business of Tata Power SED shall be understood as neither given nor endorsed by it. Please note that e-mails are susceptible to change and Tata Power SED shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt. This communication is not guaranteed to be free from computer viruses and it is recommended that you check for all viruses before download.
Print this communication only if absolutely essential. Thank you for your co-operation.
------------------------------------------------------------
Hello
I am installing a satgate on the raspberry pi with an rtl dongle
I use the rtl_fm from the sources and I get an error about bias tee
I have had to use another source
Here is my install script
#!/bin/sh
clear
echo "VK4TEC SATGATE install"
echo " "
#sudo apt-get update
#sudo apt-get install cmake build-essential libusb-1.0-0-dev
git clone https://github.com/niofis/rtl-sdr.git
cd rtl-sdr/
mkdir build
cd build
cmake ../
make
sudo make install
sudo ldconfig
git clone https://www.github.com/wb2osz/direwolf
cd ~/direwolf
make
sudo make install
make install-rpi
make install-conf
cd ~
sudo mv sdr.old sdr.confcd ~
sudo cp sdr.conf sdr.old
cd ~
sudo apt-get uninstall rtl-sdr
sudo apt-get install rtl-sdr
sudo apt-get install librtlsdr-dev
/usr/bin/rtl_fm -f 145.825M - | direwolf -t 0 -dii -c sdr.conf -r 24000 -D 1
-
Andrew Rich Nov 2017
The commit ba64a745 fixed rtlsdr_set_gpio_output() but also caused librtlsdr
to stop working with (at least some) dongles with the FC0012 tuner. It seems
that the FC0012 is connected to GPIO 4 while rtlsdr_open() assumes it's
connected to GPIO 5. Before ba64a745 the bug in rtlsdr_set_gpio_output()
caused GPIOs 3 and 4 to be set low and so everything worked.
This changes the GPIO used in rtlsdr_open() from 5 to 4. At least on my
dongle this fixes the regression.
---
src/librtlsdr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/librtlsdr.c b/src/librtlsdr.c
index b369a5d..4fb2128 100644
--- a/src/librtlsdr.c
+++ b/src/librtlsdr.c
@@ -1565,11 +1565,11 @@ int rtlsdr_open(rtlsdr_dev_t **out_dev, uint32_t index)
}
/* initialise GPIOs */
- rtlsdr_set_gpio_output(dev, 5);
+ rtlsdr_set_gpio_output(dev, 4);
/* reset tuner before probing */
- rtlsdr_set_gpio_bit(dev, 5, 1);
- rtlsdr_set_gpio_bit(dev, 5, 0);
+ rtlsdr_set_gpio_bit(dev, 4, 1);
+ rtlsdr_set_gpio_bit(dev, 4, 0);
reg = rtlsdr_i2c_read_reg(dev, FC2580_I2C_ADDR, FC2580_CHECK_ADDR);
if ((reg & 0x7f) == FC2580_CHECK_VAL) {
--
2.14.2
Dear Osmocom community,
I would like to point out that at sysmocom, we're currently (again)
hiring [1]. If you happen to have an interest in open source cellular
communications and are fluent in C language development, we would
love to hear from you.
sysmocom probably doesn't need any introduction here, but just in case:
The company was founded by Holger Freyther and Harald Welte, two of the
leading OpenBSC and Osmocom developers from the very early days of the
project. Today we are responsible for by far the largest number of commits
to the Osmocom GSM/3G infrastructure related git repositories.
Among our current priorities are automatic testing for the GPRS PCU,
generalization of the OsmoMGW media gateway, support for load-based hand-over,
inter-BSC hand-over as well as various improvements on the lower layers
of the GPRS protocol stack.
We're very dedicated to the cause in furthering the capabilities of
open source cellular infrastructure from 2G to 4G. We believe in
working upstream, no open core or dual licensing.
If you have an interest working with an enthusiastic, strong technical
and dedicated team of Osmocom hackers, please don't hesitate to let me know,
best by e-mail to jobs(a)sysmocom.de
Thanks,
Harald
p.s.: I hope this kind of message is not disturbing to anyone. I think
it is important to the Osmocom project to have more paid people working
on the stack, so it is justified. The positions we are seeking to fill
will work [almost exclusively] on Osmocom, so it's not a random job ad
but in the very interest of Osmocom, and hence on-topic for this list.
[1] https://www.sysmocom.de/jobs/
--
- Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
Hi - I presume since I'm receiving a number of these types of errors
while compiling
/opt/gnuradio/src/gr-oot/gr-osmosdr/lib/rtl_tcp/rtl_tcp_source_c.cc:307:7: warning: extended initializer lists only available with -std=c++11 or -std=gnu++11
cmd = { 0x0a, htonl(offset_tune) };
i.e., complaining about -std=gnu++11, that I should probably be
compiling gr-osmosdr with the -std=gnu++11 flag.
Typically, I fall asleep at the wheel during the build - so I don't know
which version these warning started. If it wasn't for my dog's wet nose
pressing against my elbow, I'd still be sleeping.
I'm using the following git pulls for
rtl-sdr:
commit 18bf26989c926a5db4fca29e7d859af42af1437c
Author: hayati ayguen <h_ayguen(a)web.de>
Date: Sun Jun 11 00:18:53 2017 +0200
gr-osmosdr:
commit c653754dde5e2cf682965e939cc016fbddbd45e4
Merge: b7aab45 cf95494
Author: Dimitri Stolnikov <horiz0n(a)gmx.net>
Date: Mon Jun 12 00:04:36 2017 +0200
and I have somewhat recent git pulls for libosmocore and libosmo-dsp.
Should I be compiling the programs rtl-sdr and gr-osmosdr with
-std=gnu++11?
How about libosmocore and libosmo-dsp?
-- Cinaed
I am having difficulty in searching archives as the search page does not
have search window. How do I specific topic or problem?
I am trying to use DAB+FM+DVB-T dongle in gnuradio-companion installed with
latest pre-built package on Windows 10 OS. But, it is throwing error as
follows:
QUOTE
Generating: 'C:\\Users\\vsrks_000\\Documents\\top_block.py'
Executing: C:\GNURadio-3.7\gr-python27\python.exe -u
C:\Users\vsrks_000\Documents\top_block.py
Win32; Microsoft Visual C++ version 14.0; Boost_106000;
UHD_003.010.001.001-0-unknown
gr-osmosdr ae686c46 (0.1.5git) gnuradio 3.7.11
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf
airspy redpitaya
Using device #0 Generic RTL2832U OEM
usb_open error -12
FATAL: Failed to open rtlsdr device.
Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
gr::pagesize: no info; setting pagesize = 4096
UNQUOTE
Can you please suggest a solution.
--
Best Regards,
vsrk sarma
Hi folks,
something wasn't quite right with current git master of rtl-sdr, since
it wouldn't detect the Fitipower FC0012 tuner on a couple (dozen) of my
dongles.
So, I had a quick git-bisect session that basically went:
git checkout master
git bisect start
[build]
[connect dongle]
build/src/rtl_eeprom | grep "Found Fitipower"
then git bisect good
else git bisect bad
[disconnect dongle]
jump back to build, rinse, repeat
turns out, when you _initialize_ the dongle with an older version, it
works, even with the newer revisions (hence my un- and replugging
exercises).
The (reproducibly) offending commit is the GPO/GPD register swap in
ba64a74 : librtlsdr.c, l. 570,
- rtlsdr_write_reg(dev, SYSB, GPO, r & ~gpio, 1);
+ rtlsdr_write_reg(dev, SYSB, GPD, r & ~gpio, 1);
Now, that commit's msg mentions
http://lea.hamradio.si/~s57uuu/mischam/rtlsdr/ports.html
and I don't want to break their application, but I can't get my dongles
to run :(
How to proceed from here? I'm not quite sure what I'd break if I just
reverted that commit; _my_ R820T dongle continues to work if I revert,
but I'm sure this commit didn't come out of thin air.
Best regards,
Marcus
Cinead,
My apologies for this and thanks for your clarification. I have followed
thorough with the suggestions made by yourself and Marcus, including
installing the provided ruleset and checking the device power usage. I
have also tried another USB cable and another computer. However I did
miss the point you made about leaving off the '-t' in the detail of your
original response.
Also, I have been responding to the messages I received from the mailing
list thinking that I was responding to the mailing list, but it seems
that I have actually been responding directly to individuals. This was
unintentional and I apologise, but the e-mail 'From:' header on the
messages I have received from the list shows the e-mail address of the
individual who sent the message rather than the mailing list address
which seems rather unusual. It means I have to manually copy in the
'osmocom-sdr(a)lists.osmocom.org' address into the 'To:' header each time
I reply, as I have done in this case.
So this is what I get with just rtl_test:
$ rtl_test
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
usb_claim_interface error -5
Failed to open rtlsdr device #0.
Its the same whether I run it as user or with root privileges. I don't
see the dvb_usb_rtl28xxu kernel driver being loaded in the output of lsmod.
>
> Okay, if you send another email with output of
>
> rtl_test -t
>
> I'm going to blacklist your email address.
>
> Use
>
> rtl_test
>
> to run the test for a 2832.
>
> Use
>
> rtl_test -t
>
> to run the test for a 2838.
>
> Type
>
> rtl_test --help
>
> It clearly indicates the -t flag in rtl_test is for the E4000.
>
> The system claims you have a 2832 - and not a 2838 or E4000 - so get
> over it.
>
> Clear enough?
>
>
>> Found 1 device(s):
>> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>>
>> Using device 0: Generic RTL2832U OEM
>> Found Rafael Micro R820T tuner
>
> This is your device:
>
> Using device 0: Generic RTL2832U OEM
> Found Rafael Micro R820T tuner
>
> It clearly states it's a RTL2832 device with a Rafael Micro R820T tuner.
>
>
>> r82xx_write: i2c wr failed=-1 reg=1a len=7
>> r82xx_write: i2c wr failed=-1 reg=0c len=1
>> r82xx_init: failed=-1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> 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
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> r82xx_write: i2c wr failed=-1 reg=0a len=1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> WARNING: Failed to set sample rate.
>> No E4000 tuner found, aborting.
>
> No E4000 tuner found, aborting.
>
> This statement clearly indicates your device is NOT a E4000 - or a 2838.
>
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_write_reg failed with -1
>>
>
> Did you remove the your home brewed file from /etc/udev/rules.d? If not
> then remove it and reboot.
>
> Send me a listing of
>
> /etc/modprobe.d
>
> and the contents of the file you're using to blacklist the RTL devices.
>
> Also, update your system listing and install the following
>
> apt-get update
> apt-get install librtlsdr-dev
> apt-get install libusb-1.0-0-dev
>
> What type of computer are you using? If you're using a computer with
> more than 1 USB port, try plugging the dongle into another port.
>
> It's possible the RTL dongle is bad or you have problems with your USB
> ports - but you need to eliminate system possible system software issues
> first.
>
> -- Cinaed
>
>
>>> Cinaed Simson<mailto:cinaed.simson@gmail.com>
>>> 22 October 2017 03:53
>>> On 10/21/2017 09:08 AM, John wrote:
>>>> Hello,
>>>>
>>>> I am new to this list and to SDR radio. I have purchased an SDR dongle
>>>> but am having trougble getting it to work. The dongle was described as
>>>> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and
>>>> lsusb detects the device as follows:
>>>>
>>>> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
>>>>
>>>> Is it an RTL2832U or an RTL2838? I'm not really sure.
>>>>
>>>> > From research it seems that It seems like the fist order of business is
>>>> to blacklist the kernel driver? So I have done this by adding a
>>>> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I
>>>> have also added a rules file to /etc/udev/rules.d with the following
>>>> content:
>>>>
>>>> # Realtek Semiconductor Corp. RTL2838 DVB-T
>>>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",
>>>> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr"
>>>>
>>>> I can now access the device in user mode without permission errors so I
>>>> assume that this is working OK.
>>>>
>>>> So my next step was to run rtl_test -t. The output I got contained
>>>> errors.If I then try to run any sdr software such as rtl_fm or gqrx, the
>>>> device is reset and the application fails to run. Subsequentlly running
>>>> 'rtl_test -t' gives:
>>>>
>>>> No supported devices found.
>>>>
>>>> Even running rtl_test-t sometimes does the same so i'm not sure whether
>>>> the device is 'dropping out' of its own accord.
>>>>
>>>> I am wondering whether the current crop of devices are supported? Or is
>>>> this a configuration problem?
>>>>
>>>>
>>>> The output from rtl_test:
>>>>
>>>> rtl_test -t
>>> The output from rtl_test indicates it's a "2832" - but your home brewed
>>> rule is probing for a "2838" which is the E4000.
>>>
>>> I recommend you install the enclosed udev rules.
>>>
>>> After you copy them to /etc/udev/rules.d, try
>>>
>>> udevadm control --reload
>>> udevadm trigger
>>>
>>> If that doesn't work, reboot.
>>>
>>> The correct rules should have been installed when you installed the
>>> sofware - so you may have other problems.
>>>
>>> And use
>>>
>>> rtl_test
>>>
>>> The command
>>>
>>> rtl_test -t
>>>
>>> is for the E4000 - and your enclosed error message indicates it's not E4000.
>>>
>>> -- Cinaed
>>>
>>>> Found 1 device(s):
>>>> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>>>>
>>>> Using device 0: Generic RTL2832U OEM
>>>> Found Rafael Micro R820T tuner
>>>> r82xx_write: i2c wr failed=-1 reg=13 len=7
>>>> r82xx_write: i2c wr failed=-1 reg=0c len=1
>>>> r82xx_init: failed=-1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> 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
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> r82xx_write: i2c wr failed=-1 reg=0a len=1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> WARNING: Failed to set sample rate.
>>>> No E4000 tuner found, aborting.
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_demod_write_reg failed with -1
>>>> rtlsdr_demod_read_reg failed with -1
>>>> rtlsdr_write_reg failed with -1
>>>>
>>>>
>>>>
>>> John<mailto:subs@qcontinuum.plus.com>
>>> 21 October 2017 17:08
>>> Hello,
>>>
>>> I am new to this list and to SDR radio. I have purchased an SDR dongle
>>> but am having trougble getting it to work. The dongle was described as
>>> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and
>>> lsusb detects the device as follows:
>>>
>>> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838
>>> DVB-T
>>>
>>> Is it an RTL2832U or an RTL2838? I'm not really sure.
>>>
>>> From research it seems that It seems like the fist order of business
>>> is to blacklist the kernel driver? So I have done this by adding a
>>> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I
>>> have also added a rules file to /etc/udev/rules.d with the following
>>> content:
>>>
>>> # Realtek Semiconductor Corp. RTL2838 DVB-T
>>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",
>>> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr"
>>>
>>> I can now access the device in user mode without permission errors so
>>> I assume that this is working OK.
>>>
>>> So my next step was to run rtl_test -t. The output I got contained
>>> errors.If I then try to run any sdr software such as rtl_fm or gqrx,
>>> the device is reset and the application fails to run. Subsequentlly
>>> running 'rtl_test -t' gives:
>>>
>>> No supported devices found.
>>>
>>> Even running rtl_test-t sometimes does the same so i'm not sure
>>> whether the device is 'dropping out' of its own accord.
>>>
>>> I am wondering whether the current crop of devices are supported? Or
>>> is this a configuration problem?
>>>
>>>
>>> The output from rtl_test:
>>>
>>> rtl_test -t
>>> Found 1 device(s):
>>> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>>>
>>> Using device 0: Generic RTL2832U OEM
>>> Found Rafael Micro R820T tuner
>>> r82xx_write: i2c wr failed=-1 reg=13 len=7
>>> r82xx_write: i2c wr failed=-1 reg=0c len=1
>>> r82xx_init: failed=-1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> 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
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> r82xx_write: i2c wr failed=-1 reg=0a len=1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> WARNING: Failed to set sample rate.
>>> No E4000 tuner found, aborting.
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_demod_write_reg failed with -1
>>> rtlsdr_demod_read_reg failed with -1
>>> rtlsdr_write_reg failed with -1
>>>
>>>
>>>
>> --
>> John
>
> John <mailto:subs@qcontinuum.plus.com>
> 22 October 2017 17:02
> Cinead,
>
> Thank you for this information and the ruleset. I have been looking
> for an 'official' ruleset to try, but couln't find one. For whatever
> reason a ruleset was not automatically installed. However, I installed
> the software from the repository via apt-get rtl-sdr rather than
> downloading and compiling.
>
> I have now removed the file I created and installed the one you
> provided. Unfortunately it made no difference. I initially used just
> the two udev commands to re-initialise udev, but then also rebooted
> for good measure.
>
> You observation is interesting however, as this device identifies
> itself as vendorID '0bda' and deviceID '2838' in lsusb:
>
> Bus 002 Device 012: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
>
> and likewise in dmesg:
>
> [ 622.683133] usb 2-1.6: new high-speed USB device number 12 using
> ehci-pci
> [ 622.787405] usb 2-1.6: New USB device found, idVendor=0bda,
> idProduct=2838
> [ 622.787410] usb 2-1.6: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 622.787413] usb 2-1.6: Product: RTL2838UHIDIR
> [ 622.787415] usb 2-1.6: Manufacturer: Realtek
> [ 622.787417] usb 2-1.6: SerialNumber: 00000001
>
> As you point out however, it has an R820T tuner, which has now been
> visually confirmed by the markings on the IC, so if RTL and other
> programs are expecting an E4000 then this is probably not going to
> work. I expect that the device will always match the second rule in
> the ruleset and it seems that it is possible to access the device in
> user mode. However I'm not sure how to get around the expectations of
> the driver? Curiously the second rule refers to 'Newsky TV28T
> (E4000/R820T)' which mentions both radios for the same product ID, so
> then one might expect that the driver looks for either and tries to
> determine which it is?
>
> rtl_test seemed to identify it correctly - 'Found Rafael Micro R820T
> tuner' but then then also fails to find an E4000 radio 'No E4000 tuner
> found, aborting.' so my assumption was that it was trying to determine
> which one was present, but then I am not familiar with the code.
>
> So the question in my mind is whether rtl_test is indeed making a
> determination and the errors are due to a problem communicating with
> the device, or whether it is looking for E4000 hardware as you say and
> failing because it is sending inappropriate commands. If the latter,
> then is there a way to fool it, e.g. by temporarily changing the
> device ID or forcing the driver to communicate with an RT820T radio?
>
> I did find the -d flag and tried rtl_test -d0 but this yielded a
> similar response, although it did not identify any tuner and simply
> returned 'No supported tuner found'.
>
> The full output is below:
>
> $ rtl_test -t
> Found 1 device(s):
> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>
> Using device 0: Generic RTL2832U OEM
> Found Rafael Micro R820T tuner
> r82xx_write: i2c wr failed=-1 reg=1a len=7
> r82xx_write: i2c wr failed=-1 reg=0c len=1
> r82xx_init: failed=-1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> 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
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> r82xx_write: i2c wr failed=-1 reg=0a len=1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> WARNING: Failed to set sample rate.
> No E4000 tuner found, aborting.
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_write_reg failed with -1
>
>
>
>
>
> Cinaed Simson <mailto:cinaed.simson@gmail.com>
> 22 October 2017 03:53
> On 10/21/2017 09:08 AM, John wrote:
>> Hello,
>>
>> I am new to this list and to SDR radio. I have purchased an SDR dongle
>> but am having trougble getting it to work. The dongle was described as
>> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and
>> lsusb detects the device as follows:
>>
>> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
>>
>> Is it an RTL2832U or an RTL2838? I'm not really sure.
>>
>> From research it seems that It seems like the fist order of business is
>> to blacklist the kernel driver? So I have done this by adding a
>> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I
>> have also added a rules file to /etc/udev/rules.d with the following
>> content:
>>
>> # Realtek Semiconductor Corp. RTL2838 DVB-T
>> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",
>> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr"
>>
>> I can now access the device in user mode without permission errors so I
>> assume that this is working OK.
>>
>> So my next step was to run rtl_test -t. The output I got contained
>> errors.If I then try to run any sdr software such as rtl_fm or gqrx, the
>> device is reset and the application fails to run. Subsequentlly running
>> 'rtl_test -t' gives:
>>
>> No supported devices found.
>>
>> Even running rtl_test-t sometimes does the same so i'm not sure whether
>> the device is 'dropping out' of its own accord.
>>
>> I am wondering whether the current crop of devices are supported? Or is
>> this a configuration problem?
>>
>>
>> The output from rtl_test:
>>
>> rtl_test -t
>
> The output from rtl_test indicates it's a "2832" - but your home brewed
> rule is probing for a "2838" which is the E4000.
>
> I recommend you install the enclosed udev rules.
>
> After you copy them to /etc/udev/rules.d, try
>
> udevadm control --reload
> udevadm trigger
>
> If that doesn't work, reboot.
>
> The correct rules should have been installed when you installed the
> sofware - so you may have other problems.
>
> And use
>
> rtl_test
>
> The command
>
> rtl_test -t
>
> is for the E4000 - and your enclosed error message indicates it's not E4000.
>
> -- Cinaed
>
>> Found 1 device(s):
>> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>>
>> Using device 0: Generic RTL2832U OEM
>> Found Rafael Micro R820T tuner
>> r82xx_write: i2c wr failed=-1 reg=13 len=7
>> r82xx_write: i2c wr failed=-1 reg=0c len=1
>> r82xx_init: failed=-1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> 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
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> r82xx_write: i2c wr failed=-1 reg=0a len=1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> WARNING: Failed to set sample rate.
>> No E4000 tuner found, aborting.
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_demod_write_reg failed with -1
>> rtlsdr_demod_read_reg failed with -1
>> rtlsdr_write_reg failed with -1
>>
>>
>>
>
> John <mailto:subs@qcontinuum.plus.com>
> 21 October 2017 17:08
> Hello,
>
> I am new to this list and to SDR radio. I have purchased an SDR dongle
> but am having trougble getting it to work. The dongle was described as
> an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and
> lsusb detects the device as follows:
>
> Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838
> DVB-T
>
> Is it an RTL2832U or an RTL2838? I'm not really sure.
>
> From research it seems that It seems like the fist order of business
> is to blacklist the kernel driver? So I have done this by adding a
> backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I
> have also added a rules file to /etc/udev/rules.d with the following
> content:
>
> # Realtek Semiconductor Corp. RTL2838 DVB-T
> SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",
> MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr"
>
> I can now access the device in user mode without permission errors so
> I assume that this is working OK.
>
> So my next step was to run rtl_test -t. The output I got contained
> errors.If I then try to run any sdr software such as rtl_fm or gqrx,
> the device is reset and the application fails to run. Subsequentlly
> running 'rtl_test -t' gives:
>
> No supported devices found.
>
> Even running rtl_test-t sometimes does the same so i'm not sure
> whether the device is 'dropping out' of its own accord.
>
> I am wondering whether the current crop of devices are supported? Or
> is this a configuration problem?
>
>
> The output from rtl_test:
>
> rtl_test -t
> Found 1 device(s):
> 0: Realtek, RTL2838UHIDIR, SN: 00000001
>
> Using device 0: Generic RTL2832U OEM
> Found Rafael Micro R820T tuner
> r82xx_write: i2c wr failed=-1 reg=13 len=7
> r82xx_write: i2c wr failed=-1 reg=0c len=1
> r82xx_init: failed=-1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> 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
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> r82xx_write: i2c wr failed=-1 reg=0a len=1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> WARNING: Failed to set sample rate.
> No E4000 tuner found, aborting.
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_demod_write_reg failed with -1
> rtlsdr_demod_read_reg failed with -1
> rtlsdr_write_reg failed with -1
>
>
>
--
John
Hello,
I am new to this list and to SDR radio. I have purchased an SDR dongle
but am having trougble getting it to work. The dongle was described as
an RTL8232U/R820T2 device. I am running on Linux MINT version 18.2 and
lsusb detects the device as follows:
Bus 002 Device 051: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Is it an RTL2832U or an RTL2838? I'm not really sure.
From research it seems that It seems like the fist order of business is
to blacklist the kernel driver? So I have done this by adding a
backlist-rtl.conf file to /etc/modprobe.d and rebooted the computer. I
have also added a rules file to /etc/udev/rules.d with the following
content:
# Realtek Semiconductor Corp. RTL2838 DVB-T
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="2838",
MODE:="0666", GROUP="adm", SYMLINK+="rtl_sdr"
I can now access the device in user mode without permission errors so I
assume that this is working OK.
So my next step was to run rtl_test -t. The output I got contained
errors.If I then try to run any sdr software such as rtl_fm or gqrx, the
device is reset and the application fails to run. Subsequentlly running
'rtl_test -t' gives:
No supported devices found.
Even running rtl_test-t sometimes does the same so i'm not sure whether
the device is 'dropping out' of its own accord.
I am wondering whether the current crop of devices are supported? Or is
this a configuration problem?
The output from rtl_test:
rtl_test -t
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
Found Rafael Micro R820T tuner
r82xx_write: i2c wr failed=-1 reg=13 len=7
r82xx_write: i2c wr failed=-1 reg=0c len=1
r82xx_init: failed=-1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
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
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
r82xx_write: i2c wr failed=-1 reg=0a len=1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
WARNING: Failed to set sample rate.
No E4000 tuner found, aborting.
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_write_reg failed with -1
--
John
I am running Debian 7 on a system and Debian 8 on two
other PC's and a raspberry PI and having no luck on running the build-gnuradio
script.
All the Debian 8 systems get as far as stating that the
version is unsupported and that's it.
The Debian 7 system (wheezy) goes through a number of
tests before bombing on not being able to execute certain
processes but it appears to get farther than any of the Debian 8
(jessie) systems so it appears that Debian 7 is closest.
Is there any place in the script to find a version number
so as to be sure that this script is the latest version?
I would like to try to receive DMR transmissions as well
as try some of the other interesting decoding possibilities but
so far, nothing but failure to launch.
Thanks for any constructive ideas.
Martin McCormick
[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org]
Dear all,
time is flying, and I would like to start early with discussions and planning
about OsmoCon and OsmoDevCon in 2018. It helps to start early.
Side note: We have some pending issues about the events from last year at
http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them
in the text below.
== OsmoDevCon ==
For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as
every year, which means:
* same venue, same catering options
* same concept of 'anyone contributing to Osmocom can apply for
registration until all seats are taken'
* same idea of inviting some few speaker[s] doing other FOSS mobile
communications work to join us
The parts that we need to change, IMHO:
* don't reduce from 4 to 3 days like last year. Have full 4 days again
* sort topics per day / half-day, i.e. have "GSM/UMTS Cellular
Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co,
but then have other days for other projects. This would enable people
not interested in the [continued evolvement] of the cellular projects
be able to skip those days, or to simply meet in an adjacent room for
parallel hacking sessions/discussions
* try to be a bit more structured with the schedule in general. The
existing approach works for people who attend all the event all day
long, but not so well for people with other plans / limited time
Any further change requests or topics to discuss?
Please note that Pablo Neira has offered to kindly host an OsmoDevCon in
Seville (Spain). I've attended a number of netfilter workshops he
organized there, and he's doing a great job! However, given the large
number of attendees from Berlin (and Germany in general), I think this
would make things more complicated, and more expensive for most
attendees. If you disagree with that assessment: I'm open for having
the discussion, I just thought it's more practical/economic to do it in
Berlin.
=== 10 year Anniversary Party ===
Given that 2018 marks the 10 year anniversary of Dieter and me hacking
with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves
some special celebration of some form. I have no concrete idea yet, but
for sure we should so something, and it should be at/around
OsmoDevCon. And for sure we should have a BS-11 around :)
== OsmoCon ==
The public OsmoCon was welcomed and was a success. However,
let's start this discussion with a review of last years event.
=== Registration ===
* Registrations came in way too late. Two weeks ahead of the event, we were
considering to cancel it. And then within the last few days, we had
to turn people down due to limited seating capacity
* To make planning more reliable, we see on other option but to
significantly raise the registration fee combined with an equally
significant discount for early booking
=== Duration ===
* Many people requested multiple days rather than just one, in order to
make more out of (long distance) travels. This is obvious, but as we
had no idea how many people would attend at all (or if we have to
cancel due to lack of attendance), planning multiple days in the first
incarnation would have been high risk and a multitude of work
* I would suggest to expand to two or even three days this week,
possibly one days with tutorials and the other day with tech talks
* Slightly less crammed schedule due to multiple days
=== Venue ===
We recognize this yearso venue was not the best option, due to
* Bad ventilation in the basemenet
* Difficult to find
* No space next to the conference room where people can meet / hang out
in parallel to talks (not everyone attends every talk)
I still like the "understatement" of the venue. I'd prefer any hostel /
non-profit / hackerspace / university over luxurious hotels any time.
Going to an expensive venue means more or less automatically more
expensive ticket fees, which again is more likely to exclude pure
community members without a commercial activity related to Osmocom.
So any future venue would ideally:
* be able to hold slightly more people than this year
* have a second room or large lobby in which people can meet for
extended coffee breaks in parallel to some talks, as needed
* be slightly easier to find (and we have to put up some signs outside
and in the lobby)
* have better WiFi and/or wired connectivity
=== Programme / Format ===
* less crammed over multiple days
* some more "interactive" formats were requested, for users to provide
feedback to developers
* there was some discussion about topics / speakers in redmine last
year, but not too much participation [until it was too late].
* I'd suggest a more formal CfP process with a submission deadline that
allows us to publish a preliminary schedule long ahead of the event
=== Video Recordings ===
I think they were a big success, and it was a very big surprise that the
CCC Video Operations Center was volunteering to help such a small and
niche-interest event like OsmoCon. We should make sure that we can
repeat this for 2018.
== Dates / Frequency ==
Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if
OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at
a full week for those of you who would like to attend both events. But
then, I think the number of people attending both events is actually not
all that big. Without checking the details, I think not more than half
of the OsmoDevCon attendees were attending OsmoCon. I would expect that
tendency to remain or even increase.
I still think it's good to keep them back-to-back.
In terms of frequency, I would actually suggest we move to a 6-month
cycle rather than a 12-month cycle. There's a lot of development going
on at all time. I understand that not everyone is able to attend two
events just on Osmocom, especially if it's a spare time / hobby type
activity. That's ok, I think there's no problem with attending either
of the two only, and catching up by video recordings and/or mail on the
other.
The qeustion is: Should that second event be developer-oriented or
user-oriented? Or again both? Any comments here?
Ok, that was a somewhat lengthy e-mail. Please make sure to provide any
feedback you may have as early as possible, to increase the chances of
your feedback being reflected in the planning.
Happy hacking,
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 day,
I found an issue, when i call rtl_test from external program with "-p” argument. PPM is written into stdout, which means it will be automatically flushed on interactive shell or when fflush called manually. Neither of this was used. All other output was written to stderr, hence simple patch:
diff --git a/src/rtl_test.c b/src/rtl_test.c
index 9a6cfda..c7e60c5 100644
--- a/src/rtl_test.c
+++ b/src/rtl_test.c
@@ -202,7 +202,7 @@
interval += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec);
nsamples_total += nsamples;
interval_total += interval;
- printf("real sample rate: %i current PPM: %i cumulative PPM: %i\n",
+ fprintf(stderr, "real sample rate: %i current PPM: %i cumulative PPM: %i\n",
(int)((1000000000UL * nsamples) / interval),
ppm_report(nsamples, interval),
ppm_report(nsamples_total, interval_total));
Best Regards,
Andrey
Hi All,
I recently purchased a couple of DVB-sticks on Amazon, titled:
"RTL-SDR, FM+DAB, DVB-T USB Stick Set with RTL2832U & R820T. Great SDR
for SDR#, HDSD"
I got "No supported tuner found" when running the rtl_test command. I
see others have had the same issue, so when I finally figured it out, I
thought some of you might be interested.
First of all, this stick has a FC0012 tuner despite the title. Secondly
this stick is obliviously wired differently than other sticks with
FC0012 because it needs different gpio settings. I added a few lines to
the rtlsdr_open() function in librtlsdr.c, just before probing for FCxxx:
/* initialise GPIOs */
rtlsdr_set_gpio_output(dev, 0);
rtlsdr_set_gpio_output(dev, 3);
rtlsdr_set_gpio_output(dev, 4);
rtlsdr_set_gpio_output(dev, 5);
rtlsdr_set_gpio_output(dev, 6);
rtlsdr_set_gpio_bit(dev, 3, 1);
rtlsdr_set_gpio_bit(dev, 4, 0);
rtlsdr_set_gpio_bit(dev, 6, 0);
/* reset tuner before probing */
rtlsdr_set_gpio_bit(dev, 5, 1);
rtlsdr_set_gpio_bit(dev, 5, 0);
With this modification the tuner comes a live and everything works.
Kindest regards,
Gabor Mikes
I've prepared this patch in response to Debian bug #870804
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870804
It passes the text from the -a and -p options through
getaddrinfo() and uses the first result that has a valid
socket with a successful bind.
While not a complete bind to all possible valid names, it
does appear to address the use case of the bug submitter
without completely changing the program flow.
I submit this for inclusion in the osmocom rtl-sdr repo
as it may be of use to others.
Thanks for your consideration,
-Maitland
Dear Osmocom community,
from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org
redmine could not send any e-mails. This was due to a configuration
file syntax error introduced by me, my apologies.
If you rely on redmine e-mail notifications to the issues you have
subscribed to, please double-check as related notifications during that
interval were unfortunately lost.
Best regards,
Harald
p.s.: The reason for the config change was to enable e-mail
notifications from jenkins.osmocom.org (which it now has, if you want to
configure e.g. post-build notification actions).
--
- 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’m trying to switch the state of the pin J2_3 of my xb100 through the argument line of the osmosdr block in gnuradio.
To do this, I added this code to the file bladerf_common.cc
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/* Support of the XB100 to control pin J2_3 through the argument line*/
if ( dict.count("xb100") ) {
if (bladerf_expansion_attach(_dev.get(), BLADERF_XB_100)) {
std::cout << "Could not attach XB-100" << std::endl;
} else {
_xb_100_attached = true;
std::cout << "Expension XB-100 attached" << std::endl;
if ( bladerf_expansion_gpio_dir_masked_write(_dev.get(),BLADERF_XB100_PIN_J2_3, 1)) {
std::cout<< "Could not set TRX pin direction" << std::endl;
}
std::cout << "J2_3 output direction selected" << std::endl;
if ( dict["xb100"] == "TX" ) {
if(bladerf_expansion_gpio_masked_write (_dev.get(),BLADERF_XB100_PIN_J2_3, BLADERF_XB100_PIN_J2_3)){
std::cout<< "sorry, but I cannot set pin to 1" << std::endl;}
}
else if(dict["xb100"] == "RX" ) {
if(bladerf_expansion_gpio_masked_write (_dev.get(),BLADERF_XB100_PIN_J2_3, 0)){
std::cout<< "sorry, but I cannot set pin to 1" << std::endl;}
} else {
std::cout<< "Wrong parameter specified, should be TX or RX" << std::endl;}
}
}
In my osmosdr bloc, I added this argument “ xb100=tx” but I don’t have my 5V on my pin :(
I don’t understand why the pin is not setted when I start my flowgraph… Could you help me please?
Thank you
Samuel Verdon
After a successful build of the Gnuradio plus extras by modifying the
build-gnuradio script to point to the osmocom git repository for rtlsdr,
I get an error and backtrace/memory map similar to the attached
osmosdr-error-output.txt when I exit from, e.g., osmo_fft (the program
seems to run fine until exit). Fabian suggested that I post this to the
list.
I also installed op25 on this system, and it fails at runtime with a
bunch of errors that I'm attaching as "op25-error-output.txt"; the end
of the sring is:
wx._core.PyAssertionError: C++ assertion "!m_frameStatusBar" failed at
../src/common/framecmn.cpp(381) in CreateStatusBar(): recreating status
bar in wxFrame
I wonder if this error is related, as op25 on a several-month-old
gnuradio installation works fine.
Thanks for any pointers on how to resolve this issue (or these issues).
John
-------- Forwarded Message --------
Subject: Re: Problem with latest version (master) of gr-osmosdr
Date: Sat, 24 Jun 2017 14:35:45 -0400
From: John Ackermann N8UR <jra(a)febo.com>
To: kerel <kerel-fs(a)gmx.de>
Here you go, Fabian. Thanks much for looking into this!
I have noticed this problem each time I've managed to get a successful
build-gnuradio completion on this system (e.g., after I commented out
the changes that made the build fail). I have another machine that was
updated using build-gnuradio perhaps three months ago, and it does not
exhibit this behavior.
One difference is that the other machine is running Linux Mint 18.0,
while the current one is on 18.1 (both "apt-get dist-upgraded" to
current levels at the time of the build).
John
----
On 06/24/2017 02:23 PM, kerel wrote:
> Hi John,
> this seems like an unrelated issue in gr-osmosdr, but I can't tackle it
> with the partial? backtrace you provided and can't reproduce it myself.
> Could you provide the full backtrace?
>
> Sincerely,
> Fabian
Hi --
I've recently been trying to install the Gnu Radio system on a new
machine using the build-gnuradio script. The script is failing with an
error in the gr-osmocom build phase, and I've been able to verify this
with a separate attempt to build.
In rtl_source_c.cc, line 224, the build fails with:
error: 'rtlsdr_set_bias_tee' was not declared in this scope
ret = rtlsdr_set_bias_tee(_dev, bias_tee);
It appears that changes were merged into the tree on about June 11 to
add bias tee support, and that this error results from that change set.
I'm able to get a successful build if I comment out those few lines of
code, but when I try to run an application (e.g., osmocom_fft), upon
exit there is a bunch of traceback output and a lengthy memory map
printed. I'm no debugging expert, but I can tell that the exact error
and address change on different runs, but always appear to be related to
a memory map or corrupted list.
I don't know if anyone else has seen either the build issue, or the
traceback issue, so thought I should report it here.
FWIW, I'm building on a fresh install of Linux Mint 18.1 using the
latest version of the build-gnuradio script on a Lenovo M900 i7-6700T
system. I've used the build-gnuradio script on several other systems in
the past without encountering this issue. If you need any further info,
I'm happy to provide it.
Thanks,
John N8UR
I'm using the latest fosphor from git
(7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I
believe related) issues. Firstly, I see the following error:
[+] Selected device: TITAN X (Pascal)
[!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to
queue clear of spectrum buffer
This is CL_INVALID_VALUE returning from clEnqueueFillBuffer, so I added
some debug fprints to cl.c to see what parameters were being passed
into clEnqueueFillBuffer:
Edits:
fprintf(stderr, "size = %d\n", 2 * 2 * sizeof(cl_float) * FOSPHOR_FFT_LEN);
fprintf(stderr, "pattern_size = %d\n", sizeof(float));
fprintf(stderr, "pattern = %p\n", &noise_floor);
fprintf(stderr, "offset = %d\n", 0);
Output:
size = 16384
pattern_size = 4
pattern = 0x7fb66b7fdd2c
offset = 0
These parameters look like they shouldn't cause CL_INVALID_VALUE:
https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/clEnqueueFil…
But there is this one condition that might be met, which is that somehow
size (16384) is larger than the underlying buffer (cl->mem_spectrum). The
underlying OpenGL buffer being too small brings me to my next (I believe
related) issue. The spectrum plot in fosphor is weirdly pixelated, please
see the attachment, which shows a screencap from "osmocom_fft -F -f 100e6
-g 20 -s 10e6".
Where is the cl->mem_spectrum buffer ultimately declared / initialized? My
OpenCL / OpenGL sharing knowledge is nonexistent, any pointers for how I
can help debug this issue?
Output of clinfo is attached as well, and I'm on Ubuntu 16.04 on x86_64.
--
Raj Bhattacharjea, PhD
Georgia Tech Research Institute
Information and Communications Laboratory
http://www.prism.gatech.edu/~rb288/
404.407.6622
Hello,
it's my first mail on this list, so please forgive me if I do something
wrong.
I'm about to post a couple of patches for RTL drivers:
1. RTL-SDR: convert _lut to float[] to reduce size by a factor of 256.
The _lut is being indexed by I + Q (16 bits = 65536 entries), however
both samples can be processed independently, resulting in 8-bit LUT.
Saves a bit of RAM and CPU cache.
lib/rtl/rtl_source_c.cc | 19 ++++++-------------
lib/rtl/rtl_source_c.h | 4 ++--
2 files changed, 8 insertions(+), 15 deletions(-)
2. RTL-TCP: Convert to single class model
The existing RTL TCP driver is quite different from its brother RTL_SDR.
It's much more complicated, uses gr::blocks::deinterleave and
gr::blocks::float_to_complex, and generally doesn't work correctly
(e.g. https://github.com/csete/gqrx/issues/99
Spectrum is mirrored when filter or demodulator changes (rtl_tcp) #99)
I've converted the RTL TCP driver to the model used by RTL_SDR,
simplifying it in the process, and fixing the GQRX issue.
lib/rtl_tcp/CMakeLists.txt | 1 -
lib/rtl_tcp/rtl_tcp_source_c.cc | 352 ++++++++++++++++++++++++++++++++--------
lib/rtl_tcp/rtl_tcp_source_c.h | 32 +++-
lib/rtl_tcp/rtl_tcp_source_f.cc | 327 -------------------------------------
lib/rtl_tcp/rtl_tcp_source_f.h | 125 --------------
5 files changed, 309 insertions(+), 528 deletions(-)
I'm also thinking about merging the code common to RTL-SDR and RTL-TCP,
but this it's done yet.
Comments?
--
Krzysztof Halasa
How to choose nfm mode?
According to rtl_fm help, there is no nfm among available mode: fm, wbfm, raw, am, usb, lsb
rtl-sdr-git 1:v0.5.3.r13.ge3e6ee2-1
--
This is a workaround for a crash triggered by the following scenario:
using gqrx, if the automatically generated device string
"addr=1d50:6108,driver=lime,media='USB
3.0',module=STREAM,name=LimeSDR-USB,serial=XXXX,soapy=0" is passed into
gr-osmosdr, args_to_io_signature(args) will generate an io_signature
with two channels, because the space in 'USB 3.0' causes dev_nchan to be
incremented twice. Then, in source_impl::source_impl(), GNU Radio will
gneerate an exception of the form "FATAL: destination port 1 out of
range for source_impl(47)", which causes the exception-handling null
channel code to be executed. But, since
output_signature()->max_streams() returns 1, channel is 2, and
missing_chans has size_t type, the subtraction will underflow to
(unsigned int)(-1), which causes another GNU Radio exception when
connect(). Since this is an exception in an exception handler, the
program will terminate immediately.
Thanks,
Dominic
---
lib/source_impl.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/source_impl.cc b/lib/source_impl.cc
index a28f314..ac7c3af 100644
--- a/lib/source_impl.cc
+++ b/lib/source_impl.cc
@@ -426,7 +426,7 @@ source_impl::source_impl( const std::string &args )
connect(null_source, 0, throttle, 0);
size_t missing_chans = 0;
- if ( output_signature()->max_streams() > 0 )
+ if ( output_signature()->max_streams() > 0 && ((size_t)
output_signature()->max_streams()) > channel)
missing_chans = output_signature()->max_streams() - channel;
std::cerr << "Trying to fill up " << missing_chans
--
2.7.4
This shouldn't be necessary as it's part of the default compiler include
paths anyway. Morever, it can cause GCC 6 C++ build failures in
downstream packages when combined with QMake (such as
qtmultimedia-rtlfm-radio-plugin).
Fix these issues by removing it.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
---
librtlsdr.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/librtlsdr.pc.in b/librtlsdr.pc.in
index 5e55049..84b6d0c 100644
--- a/librtlsdr.pc.in
+++ b/librtlsdr.pc.in
@@ -6,6 +6,6 @@ includedir=@includedir@
Name: RTL-SDR Library
Description: C Utility Library
Version: @VERSION@
-Cflags: -I${includedir}/ @RTLSDR_PC_CFLAGS@
+Cflags: @RTLSDR_PC_CFLAGS@
Libs: -L${libdir} -lrtlsdr -lusb-1.0
Libs.private: @RTLSDR_PC_LIBS@
--
2.1.4
Hi,
To teach myself Swift, I’m writing my own version of librtlsdr (in Swift on MacOS). I’m confused about the I2C interface between the RTL2832U and the R820T. It seems the first 16 registers of the R820T can be read but not any after that. I get a pipe stall when trying to read more than 16 bytes. Is this true or am I missing something? Is this why the shadow registers are used to maintain the state of the R820T’s registers?
Thanks
Chris
Hello,
a few days ago I tried to install rtl-sdr on my raspberry pi. I'm using a dvb-t usb stick with Realtek, RTL2838UHIDIR chipset. I build the software following the guide in the wiki. I used two additional switches: cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
After installing the software I created a blacklist in cd /etc/modprobe.d:
blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830
blacklist rtl2838
After rebooting the device I tried to test rtl-sdr with rtl_test -t and got this result:
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001
Using device 0: Generic RTL2832U OEM
usb_claim_interface error -6
Failed to open rtlsdr device #0.
I don't know how to fix this error. I tried many suggestions found via google but it doesn't work.
Can someone help me to fix this?
Thanks for your help!!
Joachim
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)