RE: gr version hell gets bigger and bigger...

[Ralph A. Schmid, dk5ras]

Hi,

> Well, I'm coming from exactly the other side as you: GNU Radio's version hell 
> is
> finally getting reduced.

Yep, always a matter of the point of view :)
 
> In other words, while GNU Radio was slowly withering in 3.7 lately, 3.8, after
> about six years of stability and stagnation, was a change of environment that
> was __impossible__ to not have.

Sure, no doubt. I just wonder why it takes so long this time.

> I hence have little regrets: yes, some (many) modules have not been ported
> (yet). That's too bad, but guess what: We can make zero guarantees about GNU
> Radio 3.7 even being buildable on a modern OS. For example, GNU Radio 3.7
> was kicked out of debian at one point, because the python and Qt used were no
> longer available in debian.

And from that I thought it would speed up now. But still waiting.
 
> needs, not us. I think they might be pretty positive if you just contact them 
> and
> tell them that, hey, to use the hardware you paid for in a wide range of
> applications, you'd need them to update their GNU Radio adapter. In the end,
> it's in their best interest, and they'll definitely like knowing the 
> priorities of
> their customers!

When I find some time I intend anyway contacting all maintainers of stuff that 
makes problems and ask what their intentions are. Lime will follow for sure, as 
it is their business selling the stuff.
 
> Best regards,
> Marcus

With best regards

Ralph.

RE: gr version hell gets bigger and bigger...

[Ralph A. Schmid, dk5ras]

Hi,

> Something that I just learned from a quick Google search. It seems that GNU
> Radio 3.8 support in gr-limesdr is now done:
> 
> https://github.com/myriadrf/gr-limesdr/issues/44

Interesting - came right around my rant :)))
 
> Best,
> 
> Daniel.

Thanks a lot!

Ralph.

 

RE: gr version hell gets bigger and bigger...

[Ralph A. Schmid, dk5ras]

Hi,

> > I know, this is mainly a matter of the people who maintain such
> > projects...and I have no idea how the awareness for this could be sharpened.
> 
> Paying the maintainer usually helps.

Sure, in a commercial world things work this way. In a hobbyists world however 
the projects just die :)
 
> Cheers,
> 
>  Sylvain


With best regrads

Ralph.

gr version hell gets bigger and bigger...

[Ralph A. Schmid, dk5ras]

Hi out there,

only a common remark :) I am using gnuradio for around six or seven years
now, and such issues were always present, but I never experienced them in
the extent like nowadays. 

More and more I am trapped in version conflicts. Only one simple example,
for being able to use gnuradio with my gr-limesdr I need to use gr 3.7,
however a LoRaWAN project I wanted to use requires gr 3.8. In other cases
projects I wanted to use combined required even three different gr versions.


As I am not a coder, no, I can't contribute and update the projects - I am
only a user. And also I was not yet motivated enough modifying the cmake
file to fool the procedure, in the hope, it may work somehow if I simply
extend the accepted version range.

I know, this is mainly a matter of the people who maintain such
projects...and I have no idea how the awareness for this could be sharpened.


As a matter of fact, the most stuff I want to play with still loves 3.7,
even going to 3.8 breaks way too much.

Ralph.

--

Ralph A. Schmid, dk5ras
Mondstr. 10
90762 Fürth
+49-171-3631223
+49-911-21650056
ra...@schmid.xxx
http://www.bclog.de/

Re: [Discuss-gnuradio] [VOLK][announcement] VOLK release impeding

[Ralph A. Schmid, dk5ras]

Hi,
 
> Unfortunately having an HDMI connector for a display and a USB port for the
> keyboard with a ready-to-use distribution such as Raspbian makes RPi users
> believe that they have a full computer available and forget proper
> embedded system development practices as I see daily from most students.

They really do connect display and keyboard to it? I did this the very first 
time after maybe two years with my zoo of Raspberries, just to see if my TV 
could cope with it.

> Would anyone consider running gcc on a low-power STM32 or MSP430 for
> compiling the firmware ?

What is the problem? When the aim is not learning how to cross compile stuff 
(what can be quite complicated) but just let the compiler run, who cares if it 
takes one or ten hours? 3.7 went faster on my RasPi, using more cores could 
have helped, but I did not care as I just went to bed, and had a look after my 
morning coffee :) 
 
I agree when you are doing this for a living, then time may be money, but even 
then just letting a RasPi sitting in the office corner and compile is quite 
doable. 

> JM

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] VOLK, gnuradio does not compile

[Ralph A. Schmid, dk5ras]

Hi Hans, 

 

Did you follow the recommendation from the error message, to check out and
enable volk? Then again cmake, make...

 

With best regards


Ralph.

 

 

 

--

 

Ralph A. Schmid

Mondstr. 10

90762 Fürth

+49-171-3631223

+49-911-21650056

ra...@schmid.xxx

http://www.bclog.de/

 

 

 

From: Discuss-gnuradio
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Hans
Kurscheidt
Sent: Wednesday, May 22, 2019 1:31 PM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] VOLK, gnuradio does not compile

 

Hi,

I'm not so sure, if i'm duplicating another issue, but gnuradio does not
compile from source. I have 

libvolk1-bin, libvolk1-dev and libvolk1.3 installed. I also executed ; -- no cure 

Here the log: 

hk@orangepizero:~/Downloads/gnuradio/build$ cmake ../
-- The CXX compiler identification is GNU 6.3.0
-- The C compiler identification is GNU 6.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Build type set to Release.
-- Found Git: /usr/bin/git
-- Extracting version information from git describe...
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_WARN_SIGN_COMPARE
-- Performing Test HAVE_WARN_SIGN_COMPARE - Success
-- Performing Test HAVE_WARN_ALL
-- Performing Test HAVE_WARN_ALL - Success
-- Performing Test HAVE_WARN_NO_UNINITIALIZED
-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
-- Compiler Version: cc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall
-Wno-uninitialized
-- ADDING PERF COUNTERS
-- Building Static Libraries: OFF
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.62.0
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   thread
--   chrono
--   atomic
-- Found PythonLibs: /usr/lib/arm-linux-gnueabihf/libpython2.7.so (found
suitable version "2.7.13", minimum required is "2")
--
-- Checking for module SWIG
-- Found SWIG version 3.0.10.
-- Found SWIG: /usr/bin/swig3.0
--
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
--
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Enabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Checking for module 'cppunit'
--   Found cppunit, version 1.13.2
-- Found CPPUNIT: /usr/lib/arm-linux-gnueabihf/libcppunit.so;dl
--
-- Configuring testing-support support...
--   Dependency CPPUNIT_FOUND = TRUE
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
--
-- Configuring VOLK support...
--   VOLK submodule is not checked out.
--   To check out the VOLK submodule, use:
-- git pull --recurse-submodules=on
-- git submodule update
--   External VOLK disabled.
--   Override with -DENABLE_INTERNAL_VOLK=ON/OFF
--
CMake Error at CMakeLists.txt:313 (message):
  VOLK required but not found.


-- Configuring incomplete, errors occurred!
See also "/home/hk/Downloads/gnuradio/build/CMakeFiles/CMakeOutput.log".
See also "/home/hk/Downloads/gnuradio/build/CMakeFiles/CMakeError.log".
hk@orangepizero:~/Downloads/gnuradio/build$ cd ..
hk@orangepizero:~/Downloads/gnuradio$ cd ..

hk@orangepizero:~/Downloads/gnuradio$ git pull --recurse-submodules=on
Already up-to-date.
hk@orangepizero:~/Downloads/gnuradio$

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] no uhd/osmocom blocks with 3.8?

[Ralph A. Schmid, dk5ras]

Hi,

> Yes, 3.8 is not exactly all that usable at the moment.

...

> We're in the 3.8 early days (no 3.8 release yet AFAIK) and now that it's in
> master, people need to test, report issues, submit patches, port their OOT to
> 3.8, 

OK, this is great to know, so I do not need to worry and just stay for now with 
3.7 :)

Thanks a lot, and with best regards

Ralph.

> Cheers,
> 
>  Sylvain


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] no uhd/osmocom blocks with 3.8?

[Ralph A. Schmid, dk5ras]

Hi,

I am using gnuradio on Kubuntu 18.04, built from source, also uhd,
osmocom-sdr-stuff, limesdr etc. is built from sources.

Up to gnuradio 3.7 this was all fine, no problems, but with the update to
3.8 the problems began. First issue is that many projects simply do not
recognize 3.8 as valid dependency - in those cases it is a matter of the
project maintainers, and those who work on this need to consider the latest
gnuradio release. Most of them are not important to me and just were
installed for playing around -> no big deal, maybe time will heal this.

However gnuradio 3.8 offers me no source/sink blocks to my SDR hardware
anymore. I completely emptied /usr/locale/, reloaded the repositories and
built and installed it all from scratch, with no remarkable errors, but
still gnuradio-companion offers me no SDR source/sink blocks at all. 

Checking out maint-3.7 fixes this, all build and installs and becomes usable
as before. 

I am not a coding guy, but this leaves me back somehow baffled, as in all
the years I compile this stuff from sources I never had such issues. 

Cmake output of all those packages is normal, gnuradio builds all parts,
none is left out, the SDR stuff builds the blocks normally, and the uhd and
limesdr probe/test utils detect their SDRs just fine, so at this point I am
done with my limited knowledge.

Any ideas out there? 

Thanks a lot, and with best regards

Ralph, dk5ras. 



--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
+49-911-21650056
ra...@schmid.xxx
http://www.bclog.de/




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER

[Ralph A. Schmid, dk5ras]

> To: discuss-gnuradio@gnu.org; andrescampo...@hotmail.com
> Subject: Re: [Discuss-gnuradio] MAKING A NTSC TV RECEIVER
> 
> Hi Andres,
> 
> just had a short look: doesn't NTSC use a nearly 6 MHz bandwidth?
> 
> Best regards,
> Marcus

Yes, no way with the RTL to catch NTSC, it does in SDR mode only 2.smth MHz 
bandwidth.

Ralph.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] single_threaded_scheduler.cc / gmp?

[Ralph A. Schmid, dk5ras]

Hi,

gnuradio refuses to build with latest commit, with some message
"single_threaded_scheduler.cc not found", apparently because it got removed
and gmp is missing. However libgmp-dev is available. So what Do I miss? :)

With best regards

Ralph.

--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
+49-911-21650056
ra...@schmid.xxx
http://www.bclog.de/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error Linking UHD

[Ralph A. Schmid, dk5ras]

I had this after the last bigger changes, maybe two weeks ago or so. Went back 
to maint, all was fine, forth to master, and again the issues. Deleting the 
build folder did not help, but deleting the whole gnuradio folder and doing a 
new git clone helped. 

 

Ralph.

 

From: Gilad Beeri (ApolloShield) [mailto:gi...@apolloshield.com] 
Sent: Tuesday, June 19, 2018 5:06 PM
To: Ralph A. Schmid, dk5ras 
Cc: Müller, Marcus (CEL) ; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Error Linking UHD

 

Which version of gnuradio works for you now?

 

On Tue, Jun 19, 2018 at 5:22 PM Ralph A. Schmid, dk5ras mailto:ra...@schmid.xxx> > wrote:

Hi,

I had maybe similar issues with gnuradio recently, and when I not only removed 
the build folder but the whole gnuradio folder and did a new git clone, it 
magically went through as if there never had been any issue :) Don't ask how 
much time I wasted on this one :)))

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio- <mailto:discuss-gnuradio-> 
> bounces+ralph=schmid@gnu.org <mailto:schmid@gnu.org> ] On Behalf Of 
> Müller, Marcus (CEL)
> Sent: Tuesday, June 19, 2018 1:33 PM
> To: gi...@apolloshield.com <mailto:gi...@apolloshield.com> ; 
> discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> 
> Subject: Re: [Discuss-gnuradio] Error Linking UHD
> 
> I must admit this is surprising to me, as the line of code where LIBS=... is
> printed is pretty integrally coupled to the line that specifies what
> GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
> I know this is kind of a "haveyoutriedturningitoffandonagain" answer, but
> have you tried completely rm'ing your build/ directory and letting CMake run
> anew?
> 
> Best regards,
> Marcus
> 
> :e ../cmake/Modules/FindG On Tue, 2018-06-19 at 14:19 +0300,
> Gilad Beeri (ApolloShield) wrote:
> > I have a similar problem as described in
> https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> >
> > When I try to run tests (with Python), I get:
> >
> > Traceback (most recent call last):
> >   File "python/myblock.py", line 12, in 
> > from myproj.myproj_swig import mitigation_source
> >   File "/home/user/gr/lib/python2.7/site-
> packages/myproj/myproj_swig.py", line 28, in 
> > _myproj_swig = swig_import_helper()
> >   File "/home/user/gr/lib/python2.7/site-
> packages/myproj/myproj_swig.py", line 24, in swig_import_helper
> > _mod = imp.load_module('_myproj_swig', fp, pathname, description)
> > ImportError: /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0:
> > undefined symbol: _ZN3uhd11time_spec_tC1Eld
> >
> >
> > I did add "UHD" to the line starting with
> "set(GR_REQUIRED_COMPONENTS"
> > (in my root CMakeLists.txt) so I get the output of
> >
> > Checking for GNU Radio Module: UHD
> > -- Checking for module 'gnuradio-uhd'
> > --   Found gnuradio-uhd, version 3.7.11.1-as
> >  * INCLUDES=/home/user/gr/include
> >  *
> > LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradi
> > o-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.
> > so
> > -- Found GNURADIO_UHD:
> > /home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-run
> > time.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
> > GNURADIO_UHD_FOUND = TRUE
> >
> > I also have in my lib/CMakeLists.txt file ${GNURADIO_ALL_LIBRARIES} in
> both target_link_libraries() lists.
> >
> > I have "#include " in my header file.
> >
> > But for some reason, it doesn't seem to link gnuradio-uhd:
> >
> > readelf -d /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0
> >
> >  0x0001 (NEEDED) Shared library:
> [libboost_system.so.1.58.0]
> >  0x0001 (NEEDED) Shared library: 
> > [libgnuradio-runtime-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [libgnuradio-pmt-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [liblog4cpp.so.5]
> >  0x0001 (NEEDED) Shared library: 
> > [libgnuradio-filter-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [libstdc++.so.6]
> >  0x0001 (NEEDED) Shared library: [libm.so.6]
> >  0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
> >  0x0001 (NEEDED) Shared library: [libc.so.6]
> >  0x000e (SONAME) Library soname: [libgnuradio-
> myproj-1.0.0git.so.0.0.0]
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error Linking UHD

[Ralph A. Schmid, dk5ras]

Hi,

I had maybe similar issues with gnuradio recently, and when I not only removed 
the build folder but the whole gnuradio folder and did a new git clone, it 
magically went through as if there never had been any issue :) Don't ask how 
much time I wasted on this one :)))

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of Müller, Marcus (CEL)
> Sent: Tuesday, June 19, 2018 1:33 PM
> To: gi...@apolloshield.com; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Error Linking UHD
> 
> I must admit this is surprising to me, as the line of code where LIBS=... is
> printed is pretty integrally coupled to the line that specifies what
> GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
> I know this is kind of a "haveyoutriedturningitoffandonagain" answer, but
> have you tried completely rm'ing your build/ directory and letting CMake run
> anew?
> 
> Best regards,
> Marcus
> 
> :e ../cmake/Modules/FindG On Tue, 2018-06-19 at 14:19 +0300,
> Gilad Beeri (ApolloShield) wrote:
> > I have a similar problem as described in
> https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
> >
> > When I try to run tests (with Python), I get:
> >
> > Traceback (most recent call last):
> >   File "python/myblock.py", line 12, in 
> > from myproj.myproj_swig import mitigation_source
> >   File "/home/user/gr/lib/python2.7/site-
> packages/myproj/myproj_swig.py", line 28, in 
> > _myproj_swig = swig_import_helper()
> >   File "/home/user/gr/lib/python2.7/site-
> packages/myproj/myproj_swig.py", line 24, in swig_import_helper
> > _mod = imp.load_module('_myproj_swig', fp, pathname, description)
> > ImportError: /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0:
> > undefined symbol: _ZN3uhd11time_spec_tC1Eld
> >
> >
> > I did add "UHD" to the line starting with
> "set(GR_REQUIRED_COMPONENTS"
> > (in my root CMakeLists.txt) so I get the output of
> >
> > Checking for GNU Radio Module: UHD
> > -- Checking for module 'gnuradio-uhd'
> > --   Found gnuradio-uhd, version 3.7.11.1-as
> >  * INCLUDES=/home/user/gr/include
> >  *
> > LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradi
> > o-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.
> > so
> > -- Found GNURADIO_UHD:
> > /home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-run
> > time.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
> > GNURADIO_UHD_FOUND = TRUE
> >
> > I also have in my lib/CMakeLists.txt file ${GNURADIO_ALL_LIBRARIES} in
> both target_link_libraries() lists.
> >
> > I have "#include " in my header file.
> >
> > But for some reason, it doesn't seem to link gnuradio-uhd:
> >
> > readelf -d /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0
> >
> >  0x0001 (NEEDED) Shared library:
> [libboost_system.so.1.58.0]
> >  0x0001 (NEEDED) Shared library: 
> > [libgnuradio-runtime-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [libgnuradio-pmt-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [liblog4cpp.so.5]
> >  0x0001 (NEEDED) Shared library: 
> > [libgnuradio-filter-
> 3.7.11.1-as.so.0.0.0]
> >  0x0001 (NEEDED) Shared library: [libstdc++.so.6]
> >  0x0001 (NEEDED) Shared library: [libm.so.6]
> >  0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
> >  0x0001 (NEEDED) Shared library: [libc.so.6]
> >  0x000e (SONAME) Library soname: [libgnuradio-
> myproj-1.0.0git.so.0.0.0]
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Hunting for DMR issue with gnuradio?

[Ralph A. Schmid, dk5ras]

Hi all,

Not 100% on-topic, but maybe I am not the only one with such problems. 

I am member of a small team that operates a world-wide DMR ham radio network
(BrandMeister, http://brandmeister.network, and I belong to the German
http://bm262.de guys), and we are hunting down (at least we try) an issue
with talker alias and embedded data transmission. Motorola radios sometimes
lose the voice sync when such data are sent - but it only happens on Hytera
repeaters.

Now the idea is, we know the network data stream (as we create it on our
servers), and at least we are convinced that we follow the specs, so
possibly the Hytera repeater alter it before transmitting the stream - thus
we need to monitor the air interface.

I know that solutions like dsd do exist, but before we step deeper into this
- has anybody here some experience with diving deeper into the DMR CAI,
using free tools? We are not commercial, so we do not have any test
equipment for digital radio, but we have gnuradio, have SDRs... What would
be quite useful is logging superframes and frames with their headers, LC,
voice headers...

Any input is highly welcome and may help making our community driven DMR
radio network better!

Thanks in advance, and with best regards

Ralph, dk5ras. 




--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Performance Issues

[Ralph A. Schmid, dk5ras]

About the discussion pro and con VM, my experiences with VMware are quite good. 
I am using gnuradio on a Micosoft Surface pro 3, Win 10, i7-CPU, 8GB RAM, using 
Kubuntu 16.04 in the VM. Gnuradio and uhd are always built from sources, from 
master branches. When Windows has no other open application running and the 
focus stays on the VM, it runs quite smooth, and openLTE with 5 MHz bandwidth 
works so far good, also transmitting DVB-T with gnuradio is possible. The used 
radio is an Ettus B210, connected with USB3.

The main reason for my choice is mobility, need this stuff being available when 
traveling :) Dual boot on the surface was at least a few years ago a PITA, and 
MS tended to kill the bootloader with updates. Don't know it this is better 
nowadays.

Ralph, dk5ras. 

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of Müller, Marcus (CEL)
> Sent: Tuesday, February 20, 2018 3:36 PM
> To: Discuss-gnuradio@gnu.org; rell...@gmail.com
> Subject: Re: [Discuss-gnuradio] Performance Issues
> 
> Hello Tellrell,
> 
> first observation: Step away from Ubuntu 14.04, if possible. Its compilers 
> aren't
> really as cool as they could be (there's been a lot of performance improvement
> in both GCC and Clang in the last four years), and you do care about
> performance.
> Also, Ubuntu 14.04 won't be around for much longer, so if this is a new
> application, switching to the next LTS is probably a good idea (by the way, 
> I've
> not been able to find significant performance regressions in simulation-only
> GNU Radio flow graphs due to KPTI fixes, i.e. meltdown fixes).
> 
> Then: Virtualizers are getting better every day; whether that makes them the
> best choice for SDR is something that I can't generally answer. Fact is that 
> USB3
> handthrough to VMs is known to be rather flaky, so if you're using a USRP 
> B2xx,
> then native is most likely the way to go.
> If you're using a high-end network card, and a good hypervisor, chances are
> you can actually have a virtualized dedicated network card in the VM (if that 
> is
> the case, you probably know yourself, because you'd have configured your VM
> to be "owner" of part of your network card).
> 
> What you should most definitely not do is have a "NAT" networking solution
> between your VM and your Host – that way, every UDP packet for a network-
> attached USRP would have to go through a packet analyzer/rewriter, and that's
> going to eat CPU.
> 
> I don't know what your CustomBlock does, but if it not a hier_blopck, Python 
> is
> really not the thing you want for highest performance. Also, to avoid the
> vec2stream, make your block consume vectors instead of single samples; the
> complex_to_magnitude_squared block can be configured to directly work on
> vectors, too!
> 
> Generally, you'll find that most guys on here are happy running a modern Linux
> on their machines. Setting up a Fedora 27 that boots alternatively to the pre-
> installed windows took about 15 minutes on my new laptop, but it's definitely
> not the first installation of that I did, so calculate let's say 30 minutes. 
> That's
> actually something that you might just want to try out. After that, it was 
> really
> just a matter of "sudo dnf update -y; dnf install -y gnuradio" to be up and
> running a halfway recent GNU Radio. On debian unstable or testing, you'd get
> something even more recent.
> 
> Best regards,
> Marcus
> 
> On Tue, 2018-02-20 at 08:48 -0500, Tellrell White wrote:
> > Hello Guys
> > Currently I'm running a flow graph that looks like the following:
> >
> > UHD Source -> Stream2Vec -> FFT -> Vec2Stream -> Com2Mag^2 ->
> > CustomBlock(Python)
> >
> > I'm running this block inside of a virtual machine running ubuntu 14.04 LTS.
> The host machine runs Windows with an Intel Core i7-4700 MQ processor
> running at 2.4GHZ with 8GB of RAM.
> >
> > Running the flow graph shown above in the VM is a struggle resulting in
> freezing after a few seconds so my question is would it better to go another
> route for performance, either, by installing UHD and Gnu Radio on the host
> machine running windows or using another machine and dual booting and
> installing linux, GNU Radio, and UHD for this application?
> >
> > Regards
> > Tellrell White
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio based application for amateur radio

[Ralph A. Schmid, dk5ras]

Hi Adrian, 

Sounds quite interesting, the compiler already runs, and maybe I will find
this weekend a bit time for a look at it!

With best regards

Ralph, dk5ras. 




> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of Adrian Musceac
> Sent: Thursday, December 7, 2017 12:17 PM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Gnuradio based application for amateur radio
> 
> Hi,
> 
> For any amateur radio people interested in this topic, QRadioLink is a
GNUradio
> SDR transceiver application with the main focus on digital voice and data
> (including Codec2). More details at http://qradiolink.org
> 
> Best regards,
> Adrian
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build from source fails - Kubuntu 16.04 / master

[Ralph A. Schmid, dk5ras]

To give an update, finally I found some time to manually clean my system from 
old uhd remains - and how much quite outdated stuff I did find, amazing! This 
did the trick, now gnuradio master builds just fine. 

Thanks a lot for the hint!

Ralph.

> -Original Message-
> From: Sylvain Munaut [mailto:246...@gmail.com]
> Sent: Tuesday, September 12, 2017 5:26 PM
> To: Ralph A. Schmid, dk5ras
> Cc: GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] build from source fails - Kubuntu 16.04 / 
> master
> 
> > Any ideas would be highly welcome :)
> 
> Most likely you have an old uhd or uhd devel headers installed somewhere.
> 
> Cheers,
> 
>Sylvain


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build from source fails - Kubuntu 16.04 / master

[Ralph A. Schmid, dk5ras]

Hi,

> Most likely you have an old uhd or uhd devel headers installed somewhere.

Uh, so I will need to search for this. But I never did anything else but git 
pull, make, make install with uhd :) Also the whole system is not too old...but 
who knows?!
 
> Cheers,
> 
>Sylvain

Thanks a lot for the hint :)

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] build from source fails - Kubuntu 16.04 / master

[Ralph A. Schmid, dk5ras]

Hi,

Still building gnuradio from source (latest master from github) fails, while
latest maint builds just fine. OS is Kubuntu 16.04 with all updates, and as
it it uhd related, uhd is also latest master from the official Ettus github.
And I want to add that I was able to use such a setup for years, just some
months ago something changed, inducing this issue.

Of course I deleted the build folders and in fact even completely deleted
uhd and gnuradio folders and cloned again from github. cmake outputs look
unsuspicious. 

Below this mail I will include the output on the build failure. I mark the
job creating the issue with a *, it is 
* [ 97%] Building CXX object
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o


Any ideas would be highly welcome :)

And using precompiled packages or pybombs is not an option. Especially
pybombs has proven creating a whole mess on my VM whenever I used it, making
a restore from backup necessary :)

With best regards

Ralph.


97%] Built target _trellis_swig1
[ 97%] Built target _trellis_swig0
* [ 97%] Building CXX object
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
[ 98%] Built target pygen_gr_uhd_swig_08777
[ 98%] Built target pygen_gr_video_sdl_swig_ce2c9
[ 98%] Built target _video_sdl_swig
[ 98%] Built target pygen_gr_vocoder_swig_43253
[ 98%] Built target _vocoder_swig
[ 98%] Built target _fcd_swig
[ 98%] Built target pygen_gr_fcd_swig_c4332
[100%] Built target pygen_gr_wavelet_swig_89b19
[100%] Built target _wavelet_swig
[100%] Built target _wxgui_swig
[100%] Built target pygen_gr_wxgui_swig_78659
[100%] Built target pygen_gr_zeromq_swig_4d7be
[100%] Built target _zeromq_swig
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function
‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*,
PyObject*)’:
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27935:15:
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’
   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function
‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, PyObject*,
PyObject*)’:
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:29301:16:
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’
   (*arg1)->set_gpio_debug(arg2,arg3);
^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function
‘void init_uhd_swig()’:
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49517:91:
error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
 ant(d, "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49518:94:
error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
 (d, "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49519:94:
error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
 (d, "dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49520:98:
error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
 "dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:70: recipe for target
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o' failed
make[2]: ***
[gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1
CMakeFiles/Makefile2:15048: recipe for target
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed
make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
ras@ras:~/gnuradio/build$



--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dB or dBm

[Ralph A. Schmid, dk5ras]

Well, dBm is an absolute power, based on 0dBm = 1mW. The dB figures of your
receiver are only relative values, they have no meaning. However those get
interesting when something changes. You just need to understand that the
input of -20dBm power has nothing to do with the resulting reading of -58dB.
When you reduce the input power for another 10 dB (no matter if you turn it
down or if you insert an additional 10dB attenuation, makes no difference),
then your reading should change from -58dB to -68dB. 

 

Then you have found a part of the linear range, where a direct relationship
exists between the input power and the power reading. 

 

AGCs may influence this, also nobody knows how accurate the peak power
measuring works. As others already had mentioned, it could be useful to play
with unmodulated carriers, just to get a feeling for this stuff.


Ralph.

 

From: Murat Aksu [mailto:muratc...@hotmail.com] 
Sent: Thursday, June 22, 2017 4:58 PM
To: Ralph A. Schmid, dk5ras
Subject: Re: [Discuss-gnuradio] dB or dBm

 

Dear Ralph,

 

Thank you so much for your support. I really do not understand these dB
values. When I inject 802.11g signal with -20 dBm power level and 20 dB
attenuator which means -40 dBm going in the HackRF One, after running
gr-scan command line or QSpectrumAnalyzer GUI, I am observing peak power
values around -58 dB.

 

As you suggest, if I use 30 dB attenuator instead of 20 dB attenuator, I
will still get some dB values and really don't know how they are related to
power levels.

 

I would appreciate your guidance about this confusion.

 

Best,

Murat

 

  _  

From: Ralph A. Schmid, dk5ras < <mailto:ra...@schmid.xxx> ra...@schmid.xxx>
Sent: Thursday, June 22, 2017 7:38 AM
To: 'GNUBeginner';  <mailto:Discuss-gnuradio@gnu.org>
Discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] dB or dBm 

 

But still the dynamic range usually ends already quite below the maximum
allowed level what is more a kind of hardware protection rule.

Add some more attenuation and see if at least a 5dB change on your
transmitter creates a 5dB change on your SDR. Then you are in the linear
range and can start trying to calibrate the thingy for your frequency. And
turn off AGC if this option is available.

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
>  <mailto:bounces+ralph=schmid@gnu.org>
bounces+ralph=schmid@gnu.org] On Behalf Of GNUBeginner
> Sent: Wednesday, June 21, 2017 10:48 PM
> To:  <mailto:Discuss-gnuradio@gnu.org> Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dB or dBm
> 
> I am already aware of what the maximum allowable receiver power which is
-5
> dBm. That is why I am starting from 0 dBm with 20 dB attenuator before
> injecting it to the HackRF One.
> 
> 
> 
> --
> View this message in context:
<http://gnuradio.4.n7.nabble.com/dB-or-dBm->
http://gnuradio.4.n7.nabble.com/dB-or-dBm-
> tp64323p64335.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
>  <mailto:Discuss-gnuradio@gnu.org> Discuss-gnuradio@gnu.org
>  <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dB or dBm

[Ralph A. Schmid, dk5ras]

But still the dynamic range usually ends already quite below the maximum
allowed level what is more a kind of hardware protection rule.

Add some more attenuation and see if at least a 5dB change on your
transmitter creates a 5dB change on your SDR. Then you are in the linear
range and can start trying to calibrate the thingy for your frequency. And
turn off AGC if this option is available.

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of GNUBeginner
> Sent: Wednesday, June 21, 2017 10:48 PM
> To: Discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] dB or dBm
> 
> I am already aware of what the maximum allowable receiver power which is
-5
> dBm. That is why I am starting from 0 dBm with 20 dB attenuator before
> injecting it to the HackRF One.
> 
> 
> 
> --
> View this message in context: http://gnuradio.4.n7.nabble.com/dB-or-dBm-
> tp64323p64335.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building gnuradio master fails

[Ralph A. Schmid, dk5ras]

This is also my experience, I made exactly this, deleting the build dir, make a 
new one, fresh cmake, and so on.

Ralph.


> -Original Message-
> From: li...@lazygranch.com [mailto:li...@lazygranch.com]
> Sent: Saturday, 20 May, 2017 20:50
> To: Ralph A. Schmid, dk5ras; 'Kostis Triantafyllakis'; 
> discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> 
> Be that as it may, I have noticed that the first "cmake../", that is a fresh
> directory, produces different output than a "make clean" followed by "cmake
> ../". ‎ I've made it a point to do a "rm -r build".
> 
> By output, I means whatever is written to standard output. I don't know if a
> fresh directly effects the actual build or not.
> 
>   Original Message
> From: Ralph A. Schmid, dk5ras
> Sent: Saturday, May 20, 2017 11:32 AM
> To: 'Kostis Triantafyllakis'; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> 
> Hi,
> 
> Forgot to mention that of course I already did so - with no success...
> 
> Ralph.
> 
> > -Original Message-
> > From: Kostis Triantafyllakis [mailto:ctri...@csd.uoc.gr]
> > Sent: Saturday, 20 May, 2017 18:19
> > To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> >
> > Hello,
> >
> > Cleaning (or even deleting the whole build directory) before rebuilding,
> > had helped me in similar cases.
> > Maybe you could give it a try
> >
> > Best,
> > Kostis
> >
> >
> > On 05/20/2017 06:58 PM, Ralph A. Schmid, dk5ras wrote:
> > > Hi,
> > >
> > > on a Kubuntu 16.04 system building gnuradio from source fails. Branch is
> > > master, downloaded right now.
> > >
> > > UHD is also the latest version from right now.
> > >
> > > Any ideas what it could be? Here the output:
> > >
> > >
> > > [ 99%] Built target _trellis_swig1
> > > [ 99%] Building CXX object
> > > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
> > >
> > > [ 99%] Built target _trellis_swig0
> > > [ 99%] Built target pygen_gr_uhd_swig_08777
> > > [ 99%] Built target pygen_gr_video_sdl_swig_ce2c9
> > > [ 99%] Built target pygen_gr_vocoder_swig_43253
> > > [ 99%] Built target _video_sdl_swig
> > > [ 99%] Built target _vocoder_swig
> > > [ 99%] Built target pygen_gr_fcd_swig_c4332
> > > [ 99%] Built target _fcd_swig
> > > [ 99%] Built target pygen_gr_wavelet_swig_89b19
> > > [ 99%] Built target _wavelet_swig
> > > [ 99%] Built target pygen_gr_wxgui_swig_78659
> > > [100%] Built target _wxgui_swig
> > > [100%] Built target pygen_gr_zeromq_swig_4d7be
> > > [100%] Built target _zeromq_swig
> > > /home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In
> > function
> > > ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*,
> > > PyObject*)’:
> > > /home/ras/gnuradio/build/gr-
> > uhd/swig/uhd_swigPYTHON_wrap.cxx:27935:15:
> > > error: ‘class uhd::usrp::dboard_iface’ has no member named
> ‘set_gpio_debug’
> > > (arg1)->set_gpio_debug(arg2,arg3);
> > > ^
> > > /home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In
> > function
> > > ‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*,
> PyObject*,
> > > PyObject*)’:
> > > /home/ras/gnuradio/build/gr-
> > uhd/swig/uhd_swigPYTHON_wrap.cxx:29301:16:
> > > error: ‘class uhd::usrp::dboard_iface’ has no member named
> ‘set_gpio_debug’
> > > (*arg1)->set_gpio_debug(arg2,arg3);
> > > ^
> > > /home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In
> > function
> > > ‘void init_uhd_swig()’:
> > > /home/ras/gnuradio/build/gr-
> > uhd/swig/uhd_swigPYTHON_wrap.cxx:49517:91:
> > > error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
> > > ant(d, "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int
> > >> (uhd::usrp::
> > > ^
> > > /home/ras/gnuradio/build/gr-
> > uhd/swig/uhd_swigPYTHON_wrap.cxx:49518:94:
> > > error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
> > > (d, "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int
> > >> (uhd::usrp::
> > > ^
> > > /home/ras/gnuradio/build/gr-
> > uhd/swig/uhd_swigPYTHON_wrap.cxx:49519:94:
> > > error: ‘ATR_REG_RX_ONLY’ is not a member of

Re: [Discuss-gnuradio] Building gnuradio master fails

[Ralph A. Schmid, dk5ras]

Hi,

Forgot to mention that of course I already did so - with no success...

Ralph.

> -Original Message-
> From: Kostis Triantafyllakis [mailto:ctri...@csd.uoc.gr]
> Sent: Saturday, 20 May, 2017 18:19
> To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Building gnuradio master fails
> 
> Hello,
> 
> Cleaning (or even deleting the whole build directory) before rebuilding,
> had helped me in similar cases.
> Maybe you could give it a try
> 
> Best,
> Kostis
> 
> 
> On 05/20/2017 06:58 PM, Ralph A. Schmid, dk5ras wrote:
> > Hi,
> >
> > on a Kubuntu 16.04 system building gnuradio from source fails. Branch is
> > master, downloaded right now.
> >
> > UHD is also the latest version from right now.
> >
> > Any ideas what it could be? Here the output:
> >
> >
> > [ 99%] Built target _trellis_swig1
> > [ 99%] Building CXX object
> > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o
> >
> > [ 99%] Built target _trellis_swig0
> > [ 99%] Built target pygen_gr_uhd_swig_08777
> > [ 99%] Built target pygen_gr_video_sdl_swig_ce2c9
> > [ 99%] Built target pygen_gr_vocoder_swig_43253
> > [ 99%] Built target _video_sdl_swig
> > [ 99%] Built target _vocoder_swig
> > [ 99%] Built target pygen_gr_fcd_swig_c4332
> > [ 99%] Built target _fcd_swig
> > [ 99%] Built target pygen_gr_wavelet_swig_89b19
> > [ 99%] Built target _wavelet_swig
> > [ 99%] Built target pygen_gr_wxgui_swig_78659
> > [100%] Built target _wxgui_swig
> > [100%] Built target pygen_gr_zeromq_swig_4d7be
> > [100%] Built target _zeromq_swig
> > /home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In
> function
> > ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*,
> > PyObject*)’:
> > /home/ras/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:27935:15:
> > error: ‘class uhd::usrp::dboard_iface’ has no member named
‘set_gpio_debug’
> > (arg1)->set_gpio_debug(arg2,arg3);
> > ^
> > /home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In
> function
> > ‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, PyObject*,
> > PyObject*)’:
> > /home/ras/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:29301:16:
> > error: ‘class uhd::usrp::dboard_iface’ has no member named
‘set_gpio_debug’
> > (*arg1)->set_gpio_debug(arg2,arg3);
> >  ^
> > /home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In
> function
> > ‘void init_uhd_swig()’:
> > /home/ras/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:49517:91:
> > error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
> >   ant(d, "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int
> >> (uhd::usrp::
> >   ^
> > /home/ras/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:49518:94:
> > error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
> >   (d, "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int
> >> (uhd::usrp::
> >   ^
> > /home/ras/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:49519:94:
> > error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
> >   (d, "dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int
> >> (uhd::usrp::
> >   ^
> > /home/ras/gnuradio/build/gr-
> uhd/swig/uhd_swigPYTHON_wrap.cxx:49520:98:
> > error: ‘ATR_REG_FULL_DUPLEX’ is not a member of
‘uhd::usrp::dboard_iface’
> >   "dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int
> >> (uhd::usrp::
> >   ^
> > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:70: recipe for target
> > 'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o' failed
> > make[2]: ***
> > [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error
> 1
> > CMakeFiles/Makefile2:15016: recipe for target
> > 'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed
> > make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
> > Makefile:160: recipe for target 'all' failed
> >
> >
> >
> > --
> >
> > Ralph A. Schmid
> > Mondstr. 10
> > 90762 Fürth
> > +49-171-3631223
> > ra...@schmid.xxx
> > http://www.bclog.de/
> >
> >
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Building gnuradio master fails

[Ralph A. Schmid, dk5ras]

Hi,

on a Kubuntu 16.04 system building gnuradio from source fails. Branch is
master, downloaded right now.

UHD is also the latest version from right now.

Any ideas what it could be? Here the output:


[ 99%] Built target _trellis_swig1
[ 99%] Building CXX object
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o

[ 99%] Built target _trellis_swig0
[ 99%] Built target pygen_gr_uhd_swig_08777
[ 99%] Built target pygen_gr_video_sdl_swig_ce2c9
[ 99%] Built target pygen_gr_vocoder_swig_43253
[ 99%] Built target _video_sdl_swig
[ 99%] Built target _vocoder_swig
[ 99%] Built target pygen_gr_fcd_swig_c4332
[ 99%] Built target _fcd_swig
[ 99%] Built target pygen_gr_wavelet_swig_89b19
[ 99%] Built target _wavelet_swig
[ 99%] Built target pygen_gr_wxgui_swig_78659
[100%] Built target _wxgui_swig
[100%] Built target pygen_gr_zeromq_swig_4d7be
[100%] Built target _zeromq_swig
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function
‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*, PyObject*,
PyObject*)’:
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:27935:15:
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’
   (arg1)->set_gpio_debug(arg2,arg3);
   ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function
‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*, PyObject*,
PyObject*)’:
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:29301:16:
error: ‘class uhd::usrp::dboard_iface’ has no member named ‘set_gpio_debug’
   (*arg1)->set_gpio_debug(arg2,arg3);
^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: In function
‘void init_uhd_swig()’:
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49517:91:
error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’
 ant(d, "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49518:94:
error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
 (d, "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49519:94:
error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’
 (d, "dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
/home/ras/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:49520:98:
error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’
 "dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int
>(uhd::usrp::
 ^
gr-uhd/swig/CMakeFiles/_uhd_swig.dir/build.make:70: recipe for target
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o' failed
make[2]: ***
[gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1
CMakeFiles/Makefile2:15016: recipe for target
'gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all' failed
make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2
Makefile:160: recipe for target 'all' failed



--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OSCAL'17 report, amateur HF reception blog

[Ralph A. Schmid, dk5ras]

Tirana, Albania? WTF?! 

Cool, I really love it that you were able to have this workshop! Congrats!!!
I did not know that there is such an active community, wish I would hear
more of such promising events from other then the "standard" countries :)

Ralph, dk5ras. 

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of Daniel Pocock
> Sent: Friday, May 19, 2017 11:17 AM
> To: GNURadio Mailing List
> Subject: [Discuss-gnuradio] OSCAL'17 report, amateur HF reception blog
> 
> 
> Hi all,
> 
> The workshop at OSCAL[1] was successful and on the second day, the SDR
setup
> was in the courtyard with the info booths where just about everybody
stopped
> to see it.
> 
> I've written a detailed blog[2] about the equipment I used (antenna,
balun,
> ATU, upconverter, dongle, etc) so anybody else can easily replicate this
either
> at home or at other events.
> 
> Thanks to everybody who has contributed to the development and packaging
of
> the tools used in the demo (gqrx, GNU Radio, rtl-sdr)
> 
> At one point I wanted to take my laptop away and somebody else volunteered
a
> laptop with Windows on it.  The Debian Hams live ISO image was downloaded
> onto a USB stick, booted up in the other laptop and worked immediately.
> 
> Regards,
> 
> Daniel
> 
> 
> 1. https://oscal.openlabs.cc
> 2.
https://danielpocock.com/building-loop-antenna-sdr-shortwave-ham-oscal17
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] red pitaya with GR?

[Ralph A. Schmid, dk5ras]

Hi,

Is the red pitaya usable with gnuradio in an easy way, means, sink/source
block, and ready to go, or is this more hassle? Quick google search did not
show me clear results on this answer...

I am searching affordable hardware similar to a B210 (means, small and
portable) and with perfect gr support, but for 0-30 MHz or so.

With best regards

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building a new open-LTE ENodeB

[Ralph A. Schmid, dk5ras]

Maybe you should use the openlte mailing list :) Gnuradio is installed? OpenLTE 
needs it.

 

Ralph.

 

 

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of SOMNATH 
RAY CHOWDHURY.
Sent: Thursday, October 20, 2016 1:14 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Building a new open-LTE ENodeB

 

https://sourceforge.net/p/openlte/wiki/Installing%20OpenLTE/

 

I am trying to run the open LTE ENodeb in Ubuntu 14.04 machine and getting the 
error 

 

"Could not find gnuradio/gnuradio-{core,runtime} after GIT checkout

 GIT checkout of GNU Radio failed!"

 

 

Please help me to get the solution of this issue.

 

 

Regards

Somnath

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IMSI Catcher Catcher?

[Ralph A. Schmid, dk5ras]

Hi,

> Thank you!!!
> 
> That's exactly the kind of information I've been looking for.

These few words?! 

In fact all you need already exists, software to decode GSM network data
already exists; you just need to put the pieces of information together.
Means, look for MCCs/MNCs and ARFCNs, compare if they fit into the official
band plan, check the LAC and cell IDs and T3212 and other timers and flags
and have a look if they follow the official scheme...

Means, it is not only a matter of building some fancy device and writing
some fancy code, you have to take the local network situation into account.
The technical side is one thing, but intelligence is the main factor. There
won't be a device to tell for sure that a tower is rogue, there must be some
heuristics or some human that evaluates the data and knows the local
network, knows how it should look like, to determine what may be wrong.

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] IMSI Catcher Catcher?

[Ralph A. Schmid, dk5ras]

Did you contact this group in Vienna? They worked on something like this...

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Ralph A. Schmid, dk5ras]

The Surface 3 is also my all day machine, usually I run gr within a VM on it, 
but a native version also is quite interesting, I will give it a try later on!!

 

Ralph.

 

From: Discuss-gnuradio 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ben 
Hilburn
Sent: Thursday, April 14, 2016 7:12 PM
To: Tom Rondeau
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

 

Hey Geof -

 

I downloaded the any-arch installer and ran it on a SurfacePro4 Windows10 
machine I have here, and it worked perfectly. I'm now using GRC and have VOLK 
Profile running in the background, and everything is working beautifully. 

 

Thanks so much for taking the time to put this together - I think a lot of 
people will benefit from it, and it's well done.

 

Cheers,

Ben

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] B2xx rates

[Ralph A. Schmid, dk5ras]

61.44 MHz with the latest UHD stuff.

Ralph.

> -Original Message-
> From: Discuss-gnuradio [mailto:discuss-gnuradio-
> bounces+ralph=schmid@gnu.org] On Behalf Of Ron Economos
> Sent: Wednesday, April 13, 2016 4:56 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] B2xx rates
> 
> Correction. The master clock rate can be set to anything from 5 MHz to
> 56 MHz. The bandwidth is 200 kHz to 56 MHz.
> 
> Ron
> 
> On 04/13/2016 07:46 AM, Ron Economos wrote:
> > The B2X0 series has a programmable master clock. You can set it to
> > anything from 200 kHz to 56 MHz.
> >
> > Ron
> >
> > On 04/13/2016 05:55 AM, Alexander Levedahl wrote:
> >> Hello,
> >>
> >> Is there a list of sample rates and associated bandwidths supported
> >> by the B2xx series or a way to generate the list? E.g., the list for
> >> the X310 is to take 120MHz, 184.32MHz, and 200MHz and divide by an
> >> integer.
> >>
> >> Thanks,
> >> Alex
> >>
> >
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Transmit volume very low

[Ralph A. Schmid, dk5ras]

First of all, you are transmitting with 5 KHz of deviation, but when I look at 
your TX frequency, you are listening with a normal FM radio to it. This expects 
75 KHz of deviation! Also your WBFM receive block expects more than 5 KHz.

 

Isn't there also a WBFM transmitting block? If available, this should be able 
to do what you want, I mean to remember the NBFM block is somehow limited in 
its maximum deviation. 

 

What does the resampler do? It gives your audio a pitch, is this intended?

 

The multiply const block should also work, when being used at the place where 
now the resampler is.

 

Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Santos 
Campos
Sent: Monday, March 28, 2016 7:56 PM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Transmit volume very low

 

Hello, all! Newer user here and even newer to the mailing list!

 

I'm trying to transmit a short .wav file via a b200 board (usrp). Before I 
broadcast I was trying to hear what the audio would sound like after going 
through the block diagram and I ended up with the diagram attached. It "works" 
but the volume is very very low. Any ideas? Previously I'd just put a multiply 
const block right before the audio sink, but I want the sample to be already 
transmitting with a higher magnitude. Any help is much appreciated!​ 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Ralph A. Schmid, dk5ras]

This works! Thanks a lot!

Ralph.


>-Original Message-
>From: Marcus Müller [mailto:marcus.muel...@ettus.com]
>Sent: Wednesday, March 16, 2016 10:24
>To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
>Subject: Re: [Discuss-gnuradio] lack of understanding the different formats
to
>store samples
>
>Ok, let "I" and "Q" be single bits each, so each byte would then be
>
>IQIQIQIQ
>
>if I had to take a guess.
>
>You can get get back something that GR commonly deals with by doing
>
>packed to unpacked (type=B, bits per chunk = 1, endianness=your machine)
>-> IChar to Complex
>
>Best regards,
>Marcus
>On 16.03.2016 08:13, Ralph A. Schmid, dk5ras wrote:
>> Each byte seems to contain 4 1 bit I/Q samples. This is the text from
>> the
>> readme:
>>
>> "The output file size can be reduced by using "-b 1" option to store
>> four 1-bit I/Q samples into a single byte."
>>
>> Ralph.
>>
>>> -Original Message-
>>> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
>>> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf
>>> Of Marcus Müller
>>> Sent: Friday, March 11, 2016 2:53 PM
>>> To: discuss-gnuradio@gnu.org
>>> Subject: Re: [Discuss-gnuradio] lack of understanding the different
>> formats
>>> to store samples
>>>
>>> In what format are your 1bit samples? I'd assume they are just the
>>> fact whether a byte is 0x00 or 0x01; in that case, just use unpacked to
packed.
>>>
>>> On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
>>>> Hi,
>>>>
>>>> Being an RF guy I must admit that I am somehow lost in the different
>>>> ways how samples are stored in files. I stumbled over this question
>>>> when I experimented with https://github.com/osqzss/gps-sdr-sim. It
>>>> works great when using 16 bit samples and using a simple two-block
>>>> grc file, feeding them directly from a file source to the UHD sink.
>>>> However the 1 bit variant sounds promising, as the files are much
>>>> smaller this way and also the generation of them runs much faster.
>>>>
>>>> It must only be a matter of finding the right blocks and the right
>>>> settings to convert this, but my google search was highly confusing,
>>>> most probably due to different names for the same thing.
>>>>
>>>> So I do not only ask for how to use "four 1-bit I/Q samples into a
>>>> single byte" (taken from the readme of the gps-sdr-sim), but for a
>>>> more general overview how this stuff is done, to be prepared for
>>>> other upcoming questions of this kind :) Up to now I solved those
>>>> issues by an educated guess or even by try and error, what is not
>>>> very
>> satisfying...
>>>> Ralph.
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Ralph A. Schmid, dk5ras]

OK, I will give this a try :) I hoped that there would be some overview, 
explaining the different interconnect formats when connecting gnuradio blocks...

 

Tnx!



Ralph.

 

 

From: Jacob Gilbert [mailto:mrjacobagilb...@gmail.com] 
Sent: Friday, March 11, 2016 3:50 PM
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] lack of understanding the different formats to 
store samples

 

Ralph,

 

If I understand this, each 8-bit byte of data contains four two-bit IQ samples, 
in which case the "Unpack K Bits" block is likely what you are looking for. It 
will treat each bit in a byte (from Byte File Source in this case) as an 
individual item, which can then be type-converted and interleaved to give you 
complex data. There are a couple other tools under the category of "Byte 
Operators" that may be helpful.

 

Jacob

 

On Fri, Mar 11, 2016 at 2:24 AM, Ralph A. Schmid, dk5ras <ra...@schmid.xxx 
<mailto:ra...@schmid.xxx> > wrote:

Hi,

Being an RF guy I must admit that I am somehow lost in the different ways
how samples are stored in files. I stumbled over this question when I
experimented with https://github.com/osqzss/gps-sdr-sim. It works great when
using 16 bit samples and using a simple two-block grc file, feeding them
directly from a file source to the UHD sink. However the 1 bit variant
sounds promising, as the files are much smaller this way and also the
generation of them runs much faster.

It must only be a matter of finding the right blocks and the right settings
to convert this, but my google search was highly confusing, most probably
due to different names for the same thing.

So I do not only ask for how to use "four 1-bit I/Q samples into a single
byte" (taken from the readme of the gps-sdr-sim), but for a more general
overview how this stuff is done, to be prepared for other upcoming questions
of this kind :) Up to now I solved those issues by an educated guess or even
by try and error, what is not very satisfying...

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] lack of understanding the different formats to store samples

[Ralph A. Schmid, dk5ras]

Each byte seems to contain 4 1 bit I/Q samples. This is the text from the
readme:

"The output file size can be reduced by using "-b 1" option to store four
1-bit I/Q samples into a single byte."

Ralph.

> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
> Marcus Müller
> Sent: Friday, March 11, 2016 2:53 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] lack of understanding the different
formats
> to store samples
> 
> In what format are your 1bit samples? I'd assume they are just the fact
> whether a byte is 0x00 or 0x01; in that case, just use unpacked to packed.
> 
> On 03/11/2016 10:24 AM, Ralph A. Schmid, dk5ras wrote:
> > Hi,
> >
> > Being an RF guy I must admit that I am somehow lost in the different
> > ways how samples are stored in files. I stumbled over this question
> > when I experimented with https://github.com/osqzss/gps-sdr-sim. It
> > works great when using 16 bit samples and using a simple two-block grc
> > file, feeding them directly from a file source to the UHD sink.
> > However the 1 bit variant sounds promising, as the files are much
> > smaller this way and also the generation of them runs much faster.
> >
> > It must only be a matter of finding the right blocks and the right
> > settings to convert this, but my google search was highly confusing,
> > most probably due to different names for the same thing.
> >
> > So I do not only ask for how to use "four 1-bit I/Q samples into a
> > single byte" (taken from the readme of the gps-sdr-sim), but for a
> > more general overview how this stuff is done, to be prepared for other
> > upcoming questions of this kind :) Up to now I solved those issues by
> > an educated guess or even by try and error, what is not very
satisfying...
> >
> > Ralph.
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Picking up RF cellular signals

[Ralph A. Schmid, dk5ras]

The phones will register to your base station, when there is no infrastructure 
any more - this is a common scenario in a real disaster, the cell phone 
infrastructure will collapse quite soon. In this situation all surviving phones 
will search for a new signal, find your BTS and register. Then you can find out 
the TA values and try locating then. 

 

In fact exactly this is done when people get lost out in the woods, or in the 
mountains - putting a GSM cell on board a helicopter...


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Meny 
Sidar
Sent: Tuesday, March 15, 2016 3:18 PM
To: Nikos Balkanas
Cc: discuss-gnuradio@gnu.org; Marcus Müller
Subject: Re: [Discuss-gnuradio] Picking up RF cellular signals

 

Thank you for your comments.

Marcus, sorry for bugging you with this issue.

I am well aware of the previous discussions with you, and have learned from 
them as well as from other people.

however, when i come across something like this for example:

https://www.youtube.com/watch?v=ZUqzdrB1o2U

i keep thinking that there is some kind of heat signature in the spectrum that 
the cellular produces (please correct me if im wrong)

how else can you explain this works?

 

I know my approch is not ideal, and i'm not ruling out opening a bts base 
station,

but i cant find a way to make phones register to my station automatically..

 

thanks again for your comments guys,

really appreciate it.

 

Meny

 

2016-03-15 4:11 GMT+02:00 Nikos Balkanas  >:

Indeed, there is phone locator protocol, and a service offered as by some 
companies. They work through provider contracts. The problem is that you have 
to know the phone number beforehand and the carrier. Not very useful in a 
disaster case :(

 

BR,

Nikos

 

On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller  > wrote:

True, at least unless you send them something they have to react to. Which 
the phone will only do if you're the infrastructure, and usually implies you 
authenticate as such[2]. Which will hence most likely only work if the cellular 
providers cooperate with you.




​[...snip...]​





On 03/14/2016 03:54 PM, Meny Sidar wrote:

Hi guys,

 

I am currently working on a project for my university, where i'm trying to 
locate cellular phones using SDR (USRP B210).

The idea of the project is to be able to find survivors/victims in disaster 
areas, such as earthquakes, by assuming they have their cellular on them.

 

What i did so far, is a program that calculates and outputs in a loop the power 
transmitted from a cellular phone from it's uplink channel. that can tell me my 
distance to it.

problem is, that cellular phones are usually in idle mode and not transmitting 
at all. 

So it works, but only if the phone is currently transmitting to the network 
(phone call, internet, etc..)

 

I'm trying to find a solution for this,

There has to be a way of knowing that some kind of RF transmitter/receiver is 
near me...

If anyone can shed some light on this subject, what can i do or if i need to go 
in another way, i'll be very grateful! 

right now i'm stuck.

 

Thanks a lot,

Meny

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org  
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org  
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org  
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] lack of understanding the different formats to store samples

[Ralph A. Schmid, dk5ras]

Hi,

Being an RF guy I must admit that I am somehow lost in the different ways
how samples are stored in files. I stumbled over this question when I
experimented with https://github.com/osqzss/gps-sdr-sim. It works great when
using 16 bit samples and using a simple two-block grc file, feeding them
directly from a file source to the UHD sink. However the 1 bit variant
sounds promising, as the files are much smaller this way and also the
generation of them runs much faster.

It must only be a matter of finding the right blocks and the right settings
to convert this, but my google search was highly confusing, most probably
due to different names for the same thing.

So I do not only ask for how to use "four 1-bit I/Q samples into a single
byte" (taken from the readme of the gps-sdr-sim), but for a more general
overview how this stuff is done, to be prepared for other upcoming questions
of this kind :) Up to now I solved those issues by an educated guess or even
by try and error, what is not very satisfying...

Ralph. 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

[Ralph A. Schmid, dk5ras]

This is some quite good information, thank you very much!

 

We need to set up some 5GHz-Links, and therefore I would like to test if the 
link partners reliably find each other again after a radar detection.

 

Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Jawad 
Seddar
Sent: Friday, 08 January, 2016 23:24
To: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

 

I managed to find an old document that details the output from the driver and 
the pulses I generated.

I tried it with 2 different pulse characteristics :
- Pulse width of 15 μs and PRF equal to 1000 Hz
- Pulse width of 15 μs and PRF equal to 3000 Hz

Image below details the second signal (PRF = 3kHz).

Images intégrées 1

This is some log when detecting the first signal
Images intégrées 2

This is some log when detecting the second signal
Images intégrées 3

You can see the driver recognizes the PRF quite well.

 

I hope this helps a bit,

Jawad

 

 

2016-01-08 23:13 GMT+01:00 Jawad Seddar <jawad.sed...@gmail.com>:

Hi Ralph,

I did this 2 and half years ago and I basically followed the directions in 
pages 60-61 of the ETSI document linked by Marcus to generate the signals.

By watching the channel on which the WiFi card was operating, I generated the 
signal at the right frequency and I could see the card changing frequencies. I 
could then access some log files that detailed why the frequency change 
happened (In this case it was saying that it had detected a radar with a given 
Pulse Repetition Frequency and gave some details about the detected signal).

I believe I was using the ath5k drivers (see madwifi-project).

Regards,

Jawad

 

2016-01-08 22:56 GMT+01:00 Marcus Müller <marcus.muel...@ettus.com>:

Hi Ralph,

hm; depends, I think.

So, there's two things:
If you're referring to a channel switch announcement, that can be part
of a management frame [1]. But I think it can also be part of a beacon
frame. Or a probe response frame.
Luckily, 802.11 is not confusing the least.
Blind guess is that you should look into airprobe-ng's "aireplay"
program and see whether it can synthesize such a frame. Basically, you
should be able to forge at least beacon frames, which might be helpful
as soon as you deauthenticated a station; a very common attack.

More likely, even, is that you're talking about mimicking a fake radar.
I guess the appropriate way to do that is probably sending something
that looks sufficiently close enough to a chirp to the OFDM demod, I think.
I'm too lazy to read this myself :D, so go and read 5.3.8.1 and
following of ETSI EN 301 893 [2], and refer to a trustworthy free and
open WiFi card driver (hint hint: atheros 9k, dfs_pattern_detector.c).

Best regards,
Marcus

[1]
https://mentor.ieee.org/802.11/dcn/10/11-10-0097-06-00ae-management-frame-analysis.xls
[2]
https://www.etsi.org/deliver/etsi_en/301800_301899/301893/01.05.01_60/en_301893v010501p.pdf


On 08.01.2016 21 <tel:08.01.2016%2021> :47, Ralph A. Schmid, dk5ras wrote:
> Hi,
>
> Does anybody know how a signal must look to trigger a 5 GHz WLAN for a
> frequency change? I intend testing this feature by transmitting a radar-like
> signal with gnuradio, but for this I should know how this detection works,
> how such a signal does look :)
>
> Ralph.
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Trigger 5GHz-WLAN radar detection?

[Ralph A. Schmid, dk5ras]

Hi,

Does anybody know how a signal must look to trigger a 5 GHz WLAN for a
frequency change? I intend testing this feature by transmitting a radar-like
signal with gnuradio, but for this I should know how this detection works,
how such a signal does look :)

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ham/amateur getting started

[Ralph A. Schmid, dk5ras]

Be careful, an antenna filters less than one would expect :)

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Marcus 
Müller
Sent: Thursday, December 24, 2015 16:21
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] ham/amateur getting started

 

Hi Daniel,

about to take a walk, so please excuse my brevity:

On 12/24/2015 01:26 PM, Daniel Pocock wrote:

 
 
On 24/12/15 08:31, Marcus Müller wrote:

Forgot:
 
[1] http://marcus.hostalia.de/sdra/pres.pdf
 

 
 
Thanks for the fast reply, I had a look and I notice you emphasize the
USRP products, you mention the B200 and B210 (the OZ9AEC link I found
also mentioned USRP but didn't specify model numbers)
 
I had a look at the FAQ[1] and spec sheet[2] to try and find comments
about amateur radio use cases, for example,
- how much TX output power?

Up to +20dBm, depending on frequency.



- suggestions about use with an external TX power amplifier

Anything goes if it has 50Ohm impedance, and can deal with the B210's output 
power range (so, close to zero to 20dBm). 



- is RX or TX restricted on any frequencies by hardware?

No; the device really doesn't care what you do with the spectrum -- it's all 
yours.
Technically, as mentioned, TX power is higher on some frequencies than on 
others. That's a pretty intuitivie effect of covering sub-100MHz to 6GHz with 
one and the same device.



 
- antenna impedance (50 Ohm?)

Exactly.



 
 
and I didn't find any comments on these things.
 
Looking at the accessory list I found that 782781-01 is a 50 Ohm cable
so I guess everything is 50 Ohm?

Yes. The RF ports are, so is, if you want to use such a device, the input port 
for an external 10MHz reference (all USRPs to date have integrated oscillators 
and don't need one).



 
 
Even before getting into the software setup, is there any useful guide
on hardware considerations for SDR in an amateur station?  For example:
- power supply requirements

Well, the B200/B210 can work with a sufficiently "beefy" USB3 controller on a 
laptop computer, but I'd generally recommend using the 6V "wall wart" power 
adapter.



- risk of interference between difference devices in the shack, precautions

That is an interesting aspect of operation, always.

The point is that, though our filtering is quite OK, SDR devices, especially 
direct conversion (or low-IF) transceivers, suffer from modulation products at 
the harmonics of the clocks used. 

However, if you put your B2x0 into a metal enclosure [1], it'll be only 
significant what reaches your RF port; so, if you can have an analog filter 
that let's say has a passband of e.g. $\frac{f_\text{desired}}2<
f_\text{passband}<2f_\text{desired}$, you shouldn't even be having any problems 
with those. You definitely don't necessarily need such a filter -- you can just 
connect an antenna (which typically has pretty strong filter characteristics, 
too!), and tune to whatever carrier you want.



 
- use with other typical amateur equipment (antennas, RX pre-amplifiers,
TX power amplifiers)

Preamps will seldom be necessary, unless your antenna is far away. With a B2x0 
as it is, you can get (if you set the RX gain high enough) Noise Figures that 
compete well with many LNAs.



- suitability for mobile use-cases, using DC/battery or vehicle power
and with a laptop or even a tablet as user interface

I'll refer to the Balint's show talent to answer that question :) [2]



 
Any feedback or links would be really helpful, maybe they could go in
the GNU Radio wiki Ham page too.

Good idea! By the way, please feel more than welcome to register on the wiki, 
and add & modify that with anything you find!

Cheers,
Marcus



 
 
1. http://www.ettus.com/kb/detail/usrp-b200-and-b210-faq
2. http://www.ettus.com/content/files/kb/b200-b210_spec_sheet.pdf
[1] http://files.ettus.com/b2x0_enclosure/
[2] https://www.youtube.com/watch?v=cygDXeZaiOM
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ham/amateur getting started

[Ralph A. Schmid, dk5ras]

Hi,

First of all, the USRP radios are kind of experimental radios, using them for 
real ham radio operation on antennas will require filters and PAs. "Out of the 
box" it will only be some proof of concept when you create a ham radio 
application with it. 

All 50 ohms, no limitations other than upper and lower border, regarding 
frequency. But connecting a roof-top antenna will most likely not work, due to 
the lack of preselection, you will receive lots of images and other garble.

Ralph, dk5ras. 

> -Original Message-
> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss-
> gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Daniel Pocock
> Sent: Thursday, December 24, 2015 13:27
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] ham/amateur getting started
> 
> 
> 
> On 24/12/15 08:31, Marcus Müller wrote:
> > Forgot:
> >
> > [1] http://marcus.hostalia.de/sdra/pres.pdf
> >
> 
> 
> Thanks for the fast reply, I had a look and I notice you emphasize the USRP
> products, you mention the B200 and B210 (the OZ9AEC link I found also
> mentioned USRP but didn't specify model numbers)
> 
> I had a look at the FAQ[1] and spec sheet[2] to try and find comments about
> amateur radio use cases, for example,
> - how much TX output power?
> - suggestions about use with an external TX power amplifier
> - is RX or TX restricted on any frequencies by hardware?
> - antenna impedance (50 Ohm?)
> 
> and I didn't find any comments on these things.
> 
> Looking at the accessory list I found that 782781-01 is a 50 Ohm cable so I 
> guess
> everything is 50 Ohm?
> 
> Even before getting into the software setup, is there any useful guide on
> hardware considerations for SDR in an amateur station?  For example:
> - power supply requirements
> - risk of interference between difference devices in the shack, precautions
> - use with other typical amateur equipment (antennas, RX pre-amplifiers, TX
> power amplifiers)
> - suitability for mobile use-cases, using DC/battery or vehicle power and 
> with a
> laptop or even a tablet as user interface
> 
> Any feedback or links would be really helpful, maybe they could go in the GNU
> Radio wiki Ham page too.
> 
> 
> 1. http://www.ettus.com/kb/detail/usrp-b200-and-b210-faq
> 2. http://www.ettus.com/content/files/kb/b200-b210_spec_sheet.pdf
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How can i determine my current phone's frequency?

[Ralph A. Schmid, dk5ras]

It looks like the downlink, like here:

 

http://dk5ras.dyndns.org/screenshots/London_940.png

 

Chunks of 4.something wide carriers. 

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Meny 
Sidar
Sent: Thursday, 17 December, 2015 22:07
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] How can i determine my current phone's frequency?

 

Hi guys,
I want to know which frequency my cellular phone is using (for uplink - UMTS).
I'm using USRP B210, i tried the spectrum analyzer tool but i don't really know 
what to expect- isn't the transmitting power of my cellular supposed to be 
higher (in a single frequency) than all other frequencies? 
my goal is to try and see if i can notice a change in dB when i get my phone 
closer/further to the B210.

 

Thanks a lot,

Meny

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testing

[Ralph A. Schmid, dk5ras]

Wow, fantastic!

 

Installed it on my Surface Pro Win10, worked without issues, a simple FM 
transmitter worked immediately.

 

What refuses to run with a python crash is a DVB-T2 transmitter, but hey, it is 
a beta...

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Geof 
Nieboer
Sent: Monday, October 19, 2015 23:12
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] 3.7.8 Windows Binaries available for testing

 

Hello all,

 

I've completed a *beta* version of a windows binary installer for GNURadio 
3.7.8.

 

Information about it is available at http://www.gcndevelopment.com/gnuradio as 
is the download itself of course.

 

Essentially I compiled every package in the dependency chain from source in 
64-bit VS 2015, so it contains everything needed to run.  It also includes 
UHD/osmocom drivers for UHD, RTLSDR, HackRF, BladeRF, FCD, and AirSpy.  It 
should run on Win 7+ and has been roughly tested on Win 7 & 10.

 

IMPORTANT: This is just a beta version; is 64-bit only, and I set all the 
optimizations for AVX2, so it will NOT run on any CPU prior to Haswell.  Sorry 
about that, the 'production' version will come with two options, AVX2 or SSE2+.

 

So I'd sure appreciate feedback as I prep the next version, even if Windows 
isn't your primary platform.  The install is completely removable and doesn't 
impact any other Python installations or environment variables (see the website 
for more details).  It's ~400MB download.  Documentation and notes as to "why" 
are available on the site.

 

Cheers,

 

Geof

 

 

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ADSB receiver?

[Ralph A. Schmid, dk5ras]

Hi,

You enter on the command line ais_rx - then the program starts. 

Ralph.

-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
numeric
Sent: Saturday, June 13, 2015 05:15
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] ADSB receiver?

Hi,

I have gnuradio version v3.7.7.1 installed using pybombs. Installation was
successful. I also installed gr-air-modes from the app store. Although the
recipe installed with no problem, I cannot find how to use gr-air-modes. No
GRC flow graph component found and all documentation, so far, is changed.
 
Questions:

1. How do I use the ADSB receiver?
2. Is there a ADSB component for the GRC flow graph?
3. Is there a GRC flow graph model?
4. Is there up to date documentation for using gr-air modes?

Thank you





--
View this message in context:
http://gnuradio.4.n7.nabble.com/ADSB-receiver-tp54169.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] HAM RADIO Friedrichshafen anyone?

[Ralph A. Schmid, dk5ras]

Hi,

 

Will some gnuradioers visit the German Friedrichshafen ham fest? 

 

http://www.hamradio-friedrichshafen.de/ham-en/

 

There is also some sdr context:

 

http://www.sdra-2015.de/

 

My wife and me will be there, as every year :)

 

Ralph.

 

 

 

--

 

Ralph A. Schmid

Mondstr. 10

90762 Fürth

+49-171-3631223

 mailto:ra...@schmid.xxx ra...@schmid.xxx

 http://www.bclog.de/ http://www.bclog.de/

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about reverse-engineering a new mode

[Ralph A. Schmid, dk5ras]

Well, I do not expect public safety standards for bus AVL, often enough they 
are nothing more than a pimped APRS system. Would be interesting how the 
standard is called, what manufacturer...

 

I have built a system for an aviation authority (!), some years ago. They 
needed a system to transmit high precision location data from planes to ground 
station, for periodical recertification of ILS, radars, beacons and such stuff 
around airports. Their demand was, the new box must look exactly like the old 
one, in case somebody asks if the stuff is still the hardware mentioned in the 
license; I'm not kidding. So I have bought some 9k6 packet radio controllers 
with TRX on board, modified the filters for around 300 MHz, programmed their 
assigned frequencies into them, set them in some special mode to simulate a 4k8 
RS232 cable...then took the sample of the old system, went to a milling shop, 
with the order make me six boxes like this one, but so that I can install this 
different PCB into it. We put the modified ham gear into the boxes, made the 
interfacing 100% compatible, so the drop-in replacement was perfect.

 

If you find (in central Europe) 9k6 FSK packet radio bursts in MIL AV UHF band 
containing NMEA packets, it is very likely that it is my fault :) Quite often 
you can find simple stuff in places where really something highly sophisticated 
is expected.

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Robert 
McGwier
Sent: Tuesday, May 26, 2015 12:27 PM
To: Mark Haun
Cc: GnuRadio Discuss GnuRadio
Subject: Re: [Discuss-gnuradio] Question about reverse-engineering a new mode

 

FIPS compliant security, device security, network security, access controls, 
and application level security are all integral parts of Public Safety Network 
design and operation and AVL in particular.  It is just not intended to be 
super duper  APRS.  I would not spend a lot money on equipment if this is 
your only goal and the amount of money I would spend would cover a RTL-SDR 
dongle and not much more until such time as I was certain that these serious 
impediments were surmountable.  That said, hackers (the good definition) live 
for this, and I encourage it.

 

Bob

 

 

On Tue, May 19, 2015 at 3:04 PM, Mark Haun hau...@keteu.org 
mailto:hau...@keteu.org  wrote:

This is a bit of an idle question, but I'm hoping some knowledgable folks on
here can offer advice.  Mostly I'm trying to understand better what I
don't know, and the size of the challenge, before jumping in to a project:

I'd like to try decoding some AVL traffic in the 700-MHz band (GPS locations
broadcast by transit vehicles to a central collector, where predictors are
used to generate the ETAs displayed on electronic bus-stop signs).  The
modulation is 4-FSK, similar to P25 except wider with a higher symbol rate,
emission designator 20K0F1D.  The particular frequency(s) should be easy
enough to discover.  Transmissions are short packets on shared channels with
some kind of slotted aloha or CSMA MAC.  A rate-3/4 convolutional code is
used.  The preceding is public information gleaned from the web.  I haven't
captured any signals yet.

The known unknowns:  preambles and framing stuff, symbol mapping,
the particular rate-3/4 code used (only a couple of candidates though), and,
the scrambler (whitener) and its initialization.  AFAIK there is no
encryption per se.  The payload is supposed to be TCP/IP, so there could be
some sort of header compression.

My question, then, is given this information, are there reasonable odds of
success?  I have some digital comms background from grad school but little
to no practical experience.  Wondering if this might be an excuse to pick up
a HackRF etc. and learn GNU Radio, or if it's likely to be a dead end.

Thanks,

Mark

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





 

-- 

Bob McGwier
Co-Founder and Technical Director, Federated Wireless, LLC

Research Professor Virginia Tech

Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY

Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dtv-questions

[Ralph A. Schmid, dk5ras]

Hi,

For the video stuff I prefer some kind of Windows software; it is just about
storage capacity and horsepower, Linux runs in a VM. The problem is that I
know almost nothing about all this stuff, so I am collecting bits and pieces
of information...

Thanks a lot, I will have a look at obe.

Ralph.


 -Original Message-
 From: Rafael Diniz [mailto:raf...@riseup.net]
 Sent: Sunday, May 17, 2015 4:48 PM
 To: Ralph A. Schmid, dk5ras
 Cc: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] dtv-questions
 
 Hi Ralph,
 
 I don't think there is something specific inside the TS for a transmission
 mode, unless there are some packets or packet complement, just like in
 ISDB-T (I do not know too much about DVB-T2), where you place information
 of which PID goes to which hierarchical layer.
 
 All you have to do is configure your MPEG2-TS muxer to place all the
 information you want inside the TS.
 
 I recommend the Open Broadcast Encoder:
 http://obe.tv/download
 
 Best regards,
 Rafael Diniz
 
 On 2015-05-17 11:36, Ralph A. Schmid, dk5ras wrote:
  Hi,
 
 
 
  when playing with DVB-T2, I see there are example ts files of
  different size, somehow optimized for the transmission mode, 4k or 8k,
  64QAM or 256QAM.
 
 
 
  Now when I have a look at them with my recoding software, they all
  look identical, same bitrate and stuff, just different size. So I
  wonder, what are the differences, what qualifies a transport stream
  for a certain transmission mode? I would like to prepare some on my
  own :)
 
 
 
  And another question, how do I set the ID stuff, name, PID?



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dtv-questions

[Ralph A. Schmid, dk5ras]

Thanks a lot for the detailed explanation. This will help me!!

Ralph.

-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ron
Economos
Sent: Monday, May 18, 2015 03:53
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] dtv-questions

The primary requirement is to the set the Transport Stream bitrate properly.
Otherwise, you'll get audio or video stuttering. For DVB-T, the bitrate
calculation is straight forward, and there are only so many combinations. I
have a command line utility here.

https://github.com/drmpeg/dtv-utils/blob/master/dvbtrate.c

For DVB-T2, the bitrate calculation is much more complex, and there are a
huge number of combinations. I have a command line utility, but I've been
reluctant to publish it on Github since it's so difficult to use. 
What it really needs is a GUI, but I haven't got around to that. 
However, it does work and I've put a copy on my website.

http://www.w6rz.net/dvbt2rate.c

You have to enter eleven parameters like so:

usage: dvbt2rate channel bandwidth fft size guard interval number of
data symbols number of FEC blocks code rate modulation frame 
size extended carrier pilot pattern L1 modulation

For example, the BBC 32K mode (vv003-cr23.grc flow graph) would be:

./dvbt2rate 8 32 4 59 202 3 4 0 1 7 3

The results are:

$ ./dvbt2rate 8 32 4 59 202 3 4 0 1 7 3
FFT size = 32768
guard interval = 1/128
number of data symbols = 59
number of FEC blocks = 202
code rate = 2/3
constellation = 256QAM
frame size = normal
carrier mode = extended
pilot pattern = PP7
L1 constellation = 64QAM

clock rate = 9142857.142857, TF = 216.944000 ms
bitrate = 40214645.204775
max symbols = 68, max blocks = 229
symbols = 60, max blocks = 202
cells = 1639268, stream = 1636200, L1 = 2090, dummy = 978, unmodulated = 0

The bitrate for that mode is 40.214645 Mbps.

For the other test flow graph (vv009-4kfft.grc) it would be:

$ ./dvbt2rate 8 4 0 100 31 3 3 0 0 7 2
FFT size = 4096
guard interval = 1/32
number of data symbols = 100
number of FEC blocks = 31
code rate = 2/3
constellation = 64QAM
frame size = normal
carrier mode = normal
pilot pattern = PP7
L1 constellation = 16QAM

clock rate = 9142857.142857, TF = 48.272000 ms
bitrate = 27588664.235996
max symbols = 541, max blocks = 166
symbols = 104, max blocks = 31
cells = 341682, stream = 334800, L1 = 2216, dummy = 4192, unmodulated = 474

The bitrate for that mode is 27.588664 Mbps.

There are two rules that must be followed. First, the DVB-T2 frame 
length (TF) can't be longer than 250 milliseconds. Second, the number of 
dummy cells must be positive or 0. Dummy cells are just filler to 
match the number of cells in FEC blocks to the number of cells in OFDM 
symbols. To get the maximum bitrate, you want to select the number of 
symbols and number of FEC blocks combination that minimizes the number 
of dummy cells.

In the first example, the line max symbols = 68, max blocks = 229 is 
showing the maximum number of symbols and FEC blocks that will fit in 
250 milliseconds. The line symbols = 60, max blocks = 202 is showing 
the total number of symbols you've chosen (in this case, 59 data symbols 
+ 1 P2 symbol = 60) and the maximum number of FEC blocks that will fit 
into that number of symbols.

Here's the guideline for choosing DVB-T2 parameters. See chapter 5.

http://www.etsi.org/deliver/etsi_ts/102800_102899/102831/01.02.01_60/ts_1028
31v010201p.pdf

If you do some Googling, there are probably some DVB-T2 bitrate 
calculators available that are much easier to use.

As for PID selection, the range 1 to 0x1f is reserved for specific DVB 
functions, so stay away from those. For my test streams, I've been using:

PAT = 0 (the PAT is always at PID 0);
PMT = 0x30
Video and PCR = 0x31
Audio = 0x34
Stuffing = 0x1fff (stuffing packets are always PID 0x1fff)

Most receivers will decode a simple Transport Stream without any 
additional PIDs or service information beyond PAT, PMT, PCR, video, 
audio and stuffing. If you want to get more complex, the DVB 
specification for service information is here:

http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.14.01_60/en_3004
68v011401p.pdf

Ron

On 05/17/2015 07:48 AM, Rafael Diniz wrote:
 Hi Ralph,

 I don't think there is something specific inside the TS for a 
 transmission mode, unless there are some packets or packet complement, 
 just like in ISDB-T (I do not know too much about DVB-T2), where you 
 place information of which PID goes to which hierarchical layer.

 All you have to do is configure your MPEG2-TS muxer to place all the 
 information you want inside the TS.

 I recommend the Open Broadcast Encoder:
 http://obe.tv/download

 Best regards,
 Rafael Diniz

 On 2015-05-17 11:36, Ralph A. Schmid, dk5ras wrote:
 Hi,



 when playing with DVB-T2, I see there are example ts files of different
 size, somehow optimized for the transmission mode, 4k or 8k, 64QAM or
 256QAM

[Discuss-gnuradio] dtv-questions

[Ralph A. Schmid, dk5ras]

Hi,

 

when playing with DVB-T2, I see there are example ts files of different
size, somehow optimized for the transmission mode, 4k or 8k, 64QAM or
256QAM.

 

Now when I have a look at them with my recoding software, they all look
identical, same bitrate and stuff, just different size. So I wonder, what
are the differences, what qualifies a transport stream for a certain
transmission mode? I would like to prepare some on my own :)

 

And another question, how do I set the ID stuff, name, PID?

 

With best regards

 

Ralph.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Transition to new digtal TV blocks...

[Ralph A. Schmid, dk5ras]

OK, so far everything is fine, it was no big deal, works great.

Can you provide a link to the transport streams for dvb-s2 your examples are
referring to? 

Thank you very much!

Ralph.


-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ron
Economos
Sent: Monday, May 11, 2015 10:44
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Transition to new digtal TV blocks...

You'll have to rebuild them. All the block names have changed from dvbt2_xxx
to dtv_dvb_xxx (for blocks that are common to both DVB-T2 and
DVB-S2) or dtv_dvbt2_xxx.

However, there are new versions of vv003-cr23.grc, vv009-4kfft.grc and
vv018-miso.grc in gnuradio/gr-dtv/examples that you can start with.

Ron

On 05/11/2015 01:12 AM, Ralph A. Schmid, dk5ras wrote:
 Hi,

 Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded 
 as source, compiled and installed. Now gnuradio brings this stuff by
default.
 So I wonder what may happen when I remove the duplicate blocks from 
 the
 gr-dvbt2 package with a make uninstall. Will my grc files still be 
 functional by using the new and probably identical blocks, or will I 
 have to manually rebuild my grc files?

 Ralph.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Transition to new digtal TV blocks...

[Ralph A. Schmid, dk5ras]

Hi,

Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded as
source, compiled and installed. Now gnuradio brings this stuff by default.
So I wonder what may happen when I remove the duplicate blocks from the
gr-dvbt2 package with a make uninstall. Will my grc files still be
functional by using the new and probably identical blocks, or will I have to
manually rebuild my grc files?

Ralph.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Transition to new digtal TV blocks...

[Ralph A. Schmid, dk5ras]

OK, tnx, no big deal, just good to know beforehand :)

Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Ron Economos
 Sent: Monday, May 11, 2015 10:44 AM
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Transition to new digtal TV blocks...
 
 You'll have to rebuild them. All the block names have changed from
 dvbt2_xxx to dtv_dvb_xxx (for blocks that are common to both DVB-T2 and
 DVB-S2) or dtv_dvbt2_xxx.
 
 However, there are new versions of vv003-cr23.grc, vv009-4kfft.grc and
 vv018-miso.grc in gnuradio/gr-dtv/examples that you can start with.
 
 Ron
 
 On 05/11/2015 01:12 AM, Ralph A. Schmid, dk5ras wrote:
  Hi,
 
  Maybe a dumb question, but up to now I was using gr-dvbt2 downloaded
  as source, compiled and installed. Now gnuradio brings this stuff by
default.
  So I wonder what may happen when I remove the duplicate blocks from
  the
  gr-dvbt2 package with a make uninstall. Will my grc files still be
  functional by using the new and probably identical blocks, or will I
  have to manually rebuild my grc files?
 
  Ralph.
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] No scope with gr?

[Ralph A. Schmid, dk5ras]

Hi,

 Hi Ralph,

 I see... Hm. The point is that most of us is not really deep into the WX
code
 base, and GNU Radio is planning to move away from WX to QT, and since I
 can't reproduce the problem locally, it's going to be very hard to get you
 running. It really *is* an odd failure if only the scope is failing.

So I will have a look at the qt stuff and simply forget about wx. To by
honest, I never bothered what kind of GUI I am using, but when qt GUI offers
the same functionality, so why stay with wx?! 

 Generally, if your application is simple enough to just switch Generate
 Options from WX to Qt and replace a few GUI elements, then I'd
 recommend using Qt; it's more modern, and it will stick around longer.
Most
 features can be configured even at runtime using middle-click on the
 visualization.

Yep, it is all quite simple stuff, nothing special. The scope I even do not
really need most of the time, just the waterfall is nice to have.
 
 Greetings,
 Marcus

Ralph.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] No scope with gr?

[Ralph A. Schmid, dk5ras]

Hi,

 Hi Ralph,
 
 first of all: that's the WX GUI Scope, right?

Yes.
 
  Where can I start searching for the reason?
 Do other Instrumentations from the same GUI framework work?

The WX GUI Waterfall Sink works as always. 

Usually I do not use those gfx stuff that much, I just stumbled over it when
firing up my DSD+ flow for DMR radio decoding, then I tried other flows
using WX GUI Scope Sink, with the same result.

 Tough one, but I'd tackle this with a debug build and GDB:
 http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB

Looks complicated to a Windows guy like me, may take some days until I find
time for such an adventure :)

 Greetings,
 Marcus

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] No scope with gr?

[Ralph A. Schmid, dk5ras]

Hi,

With latest gnuradio the scope view refuses to work in my flowgraphs.
Execution ends completely without any error message. Removing the block and
putting it newly into the flowgraph changes nothing. Disabling the scope
makes the projects work, the water fall works without issues. 

Uninstalling gnuradio, deleting the build folder and rebuilding everything
changed nothing. All elements are built, cmake seems to be fine with the
prerequisites, still no working scope.

Kubuntu 14.04 64 bit, latest kernel and all other updates, gnuradio from
sources (master), no pybombs...

Where can I start searching for the reason?

Thx!

Ralph.







___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

Thanks for all the research - sound reasonable, now I know what is going
wrong, great!

 

Regarding the TX gain, I was never able to see any nonlinearity from
saturation, the amp seems to be way below the critical input level. The
signal is 1a clean, no spurs and no excessive harmonics, no IM.

 

Ralph.

 

 

From: Ian Buckley [mailto:i...@ionconcepts.com] 
Sent: Monday, April 20, 2015 20:05
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 

To close the loop on this thread, 3.8.3-RC1 has a bug in new code that
automatically calculates master_clock_rates when they are not explicitly
stated. This specifically affects B2x0 and E3x0 since they are AD9361 based
with a very flexible master_clock_rate. In this case Ralph asked for a
sample_rate of 9.142857 MHz and UHD erroneously forced a master_clock_rate
of 8MHz. An explicit master_clcok_rate request (in this case for
9.142857MHz) works around the bug as shown (green without, yellow with):
http://ianbuckley.net/ralph_spectrum.jpg. The master_clock_rate override
does print a warning in the UHD log so you can see that this is happening:

 

UHD Warning:

The hardware does not support the requested TX sample rate:

Target sample rate: 9.142857 MSps

Actual sample rate: 8.00 MSps

 

There is also another bug in RC1 that also prints incorrect warnings.
Warnings of this form can currently be ignored until this is fixed should
you know that you have actually set sensible sample_rates:

 

UHD Warning:

The requested decimation is odd; the user should expect CIC rolloff.

Select an even decimation to ensure that a halfband filter is enabled.

decimation = dsp_rate/samp_rate - 37 = (9.142857 MHz)/(0.25 MHz)

 

NOTE: Ralph, your flow graph used a TX gain of 99.this is way too high for
the signal being driven to the USRP, you were driving the output amp into
saturation.

-Ian

 

On Apr 18, 2015, at 12:24 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx
wrote:





Yes, I can confirm hash 2fe3..., and the images were downloaded with the
supplied uhd_image_downloader, what is configured like this:

 

_DEFAULT_BASE_URL =  http://files.ettus.com/binaries/images/
http://files.ettus.com/binaries/images/;

_AUTOGEN_IMAGES_FILENAME  = uhd-images_003.008.003-rc1.zip

_AUTOGEN_IMAGES_CHECKSUM  = 8522b02386f5fe0bb51baa3ba0001ef0

 

The GRC filkes are accessible now, the only modifications I made were due to
Ron Economos' hints regarding sampling rate, and I added a frequency slider
to choose the correct European TV channel without having to know the
frequency.

 

Ralph.

 

 

From: Ian Buckley [mailto:ianb@ http://ionconcepts.com ionconcepts.com] 
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun';  mailto:usrp-us...@lists.ettus.com
usrp-us...@lists.ettus.com; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 

Ralph,

I'm not able to access either of the .grc files on your website, but using
the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I
generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same
as your uhd_master screen shot. I don't see the truncated bandwidth of your
uhd_rc1 screenshot.  http://ianbuckley.net/dvbt.jpg
http://ianbuckley.net/dvbt.jpg

Can you verify please that you have UHD at the current 003.008.003-RC1 tag
position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
downloaded FPGA images are from:
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip

 

I'll need your exact flow graph if I'm to debug this anymore.

 

-Ian

 

 

 

On Apr 17, 2015, at 11:48 AM, Ralph A. Schmid, dk5ras 
mailto:ra...@schmid.xxx ra...@schmid.xxx wrote:






I have put it all here, flow graphs and screenshots of the flow graphs:

 http://dk5ras.dyndns.org/tmp/DVB/ http://dk5ras.dyndns.org/tmp/DVB/

This way we can keep it on the list without sending attachments.

They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.

Ralph.



-Original Message-
From: Ian Buckley [ mailto:i...@ionconcepts.com
mailto:i...@ionconcepts.com] 
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun';  mailto:usrp-us...@lists.ettus.com
usrp-us...@lists.ettus.com; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.

Thanks
-Ian

On Apr 17, 2015, at 10:00 AM, Ralph A. Schmid, dk5ras 
mailto:ra...@schmid.xxx ra...@schmid.xxx
wrote:





OK, here we go. The hotel TV was dvb-c only, so I had to do the tests 
back

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

Yes, I can confirm hash 2fe3..., and the images were downloaded with the
supplied uhd_image_downloader, what is configured like this:

 

_DEFAULT_BASE_URL = http://files.ettus.com/binaries/images/;

_AUTOGEN_IMAGES_FILENAME  = uhd-images_003.008.003-rc1.zip

_AUTOGEN_IMAGES_CHECKSUM  = 8522b02386f5fe0bb51baa3ba0001ef0

 

The GRC filkes are accessible now, the only modifications I made were due to
Ron Economos' hints regarding sampling rate, and I added a frequency slider
to choose the correct European TV channel without having to know the
frequency. 

 

Ralph.

 

 

From: Ian Buckley [mailto:i...@ionconcepts.com] 
Sent: Saturday, April 18, 2015 03:45
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 

Ralph,

I'm not able to access either of the .grc files on your website, but using
the original dvbt_tx_demo_8k flow graph from gr-dvbt, the spectrum I
generate with 003.008.003-RC1 has a 3dB bandwidth of about ~7.5MHz the same
as your uhd_master screen shot. I don't see the truncated bandwidth of your
uhd_rc1 screenshot. http://ianbuckley.net/dvbt.jpg

Can you verify please that you have UHD at the current 003.008.003-RC1 tag
position git hash 2fe319d9790c7ec0bcdb9582c4fea95f3fd809b9, and that the
downloaded FPGA images are from:
http://files.ettus.com/binaries/images/uhd-images_003.008.003-rc1.zip

 

I'll need your exact flow graph if I'm to debug this anymore.

 

-Ian

 

 

 

On Apr 17, 2015, at 11:48 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx
wrote:





I have put it all here, flow graphs and screenshots of the flow graphs:

http://dk5ras.dyndns.org/tmp/DVB/

This way we can keep it on the list without sending attachments.

They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.

Ralph.



-Original Message-
From: Ian Buckley [mailto:i...@ionconcepts.com] 
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.

Thanks
-Ian

On Apr 17, 2015, at 10:00 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx
wrote:




OK, here we go. The hotel TV was dvb-c only, so I had to do the tests 
back at home.

I took my perfectly working Kubuntu 14.04 64 bit VM container together 
with my B210, made a copy and updated this one, first I made a git 
pull to get latest master, built it, rebuilt gnuradio, rebuilt 
gr-dvbt, updated the FPGA images, and everything still was fine. The

chosen dvb-t bandwidth is 8 MHz.




Then I changed to 003_008_003_rc1, did the same procedure, fired up 
grc, and the signal was not decodable both with a dvb-t PC receiver 
and with an dvb-x analyzer. The analyzer saw the RF level, but no 
data, no constellation, nothing, it looked to him like interference.

When you have a look at the two uhd screenshots here 
http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then 
you will find that RC1 produces a somehow narrower signal, so it 
really looks something gets cut at the ends with all the filtering and DSP

stuff.



Adjusting the channel bandwidth in the uhd sink block from 0 to a 
sensible value changes nothing.

Btw., the dvb-t2 package behaves identical.

Ralph.


-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com]
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

master works, but RC1 does not? Huh, I'm confused now. Can you give 
some detail on what's going on, so we can try and reproduce this?

Thanks,
Martin

On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:



RC1, master seems to work.

Ralph.

-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com]
Sent: Wednesday, April 15, 2015 15:44
To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean 
3.8.3-RC1, or latest master?

Martin

On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:



It is a B210, but as a note, due to the up to now missing FPGA 
images I used 003.008.003-RC1, not the latest master. Still I had no 
access to a spectrum and DVB-T analyzer, so I have no idea what is 
happening, I just can confirm that RF is transmitted, and the 
receiver doesn't get a picture, while with the snapshot of the same 
VM before the upgrade

is received without problems.



I will know more in about three hours.

Ralph.




-Original Message-
From

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

I have put it all here, flow graphs and screenshots of the flow graphs:

http://dk5ras.dyndns.org/tmp/DVB/

This way we can keep it on the list without sending attachments.

They were taken from the VM container before all the upgrades were made, but
I did not change anything when upgrading.

Ralph.



-Original Message-
From: Ian Buckley [mailto:i...@ionconcepts.com] 
Sent: Friday, April 17, 2015 19:25
To: Ralph A. Schmid, dk5ras
Cc: 'Martin Braun'; usrp-us...@lists.ettus.com; 'GNU Radio Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

Great Ralph, thats a big help. Can you send me your exact flow graph used to
generate these 2 plots off list please. I want to re run this scenario and
see your exact configuration.

Thanks
-Ian

On Apr 17, 2015, at 10:00 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx
wrote:

 OK, here we go. The hotel TV was dvb-c only, so I had to do the tests 
 back at home.
 
 I took my perfectly working Kubuntu 14.04 64 bit VM container together 
 with my B210, made a copy and updated this one, first I made a git 
 pull to get latest master, built it, rebuilt gnuradio, rebuilt 
 gr-dvbt, updated the FPGA images, and everything still was fine. The
chosen dvb-t bandwidth is 8 MHz.
 
 Then I changed to 003_008_003_rc1, did the same procedure, fired up 
 grc, and the signal was not decodable both with a dvb-t PC receiver 
 and with an dvb-x analyzer. The analyzer saw the RF level, but no 
 data, no constellation, nothing, it looked to him like interference.
 
 When you have a look at the two uhd screenshots here 
 http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then 
 you will find that RC1 produces a somehow narrower signal, so it 
 really looks something gets cut at the ends with all the filtering and DSP
stuff.
 Adjusting the channel bandwidth in the uhd sink block from 0 to a 
 sensible value changes nothing.
 
 Btw., the dvb-t2 package behaves identical.
 
 Ralph.
 
 
 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 21:14
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
 
 master works, but RC1 does not? Huh, I'm confused now. Can you give 
 some detail on what's going on, so we can try and reproduce this?
 
 Thanks,
 Martin
 
 On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
 RC1, master seems to work.
 
 Ralph.
 
 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 15:44
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
 
 Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean 
 3.8.3-RC1, or latest master?
 
 Martin
 
 On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
 It is a B210, but as a note, due to the up to now missing FPGA 
 images I used 003.008.003-RC1, not the latest master. Still I had no 
 access to a spectrum and DVB-T analyzer, so I have no idea what is 
 happening, I just can confirm that RF is transmitted, and the 
 receiver doesn't get a picture, while with the snapshot of the same 
 VM before the upgrade
 is received without problems.
 I will know more in about three hours.
 
 Ralph.
 
 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 3:15 PM
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
 
 On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
 Hi,
 
 Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more 
 with latest uhd. A quick check during lunch break showed, the 
 produced output is not decodable any more. I will take a closer 
 look this evening at home, where I have more and better equipment.
 
 Ralph,
 
 which device is this on?
 
 Thanks,
 Martin
 
 
 
 
 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

OK, here we go. The hotel TV was dvb-c only, so I had to do the tests back
at home. 

I took my perfectly working Kubuntu 14.04 64 bit VM container together with
my B210, made a copy and updated this one, first I made a git pull to get
latest master, built it, rebuilt gnuradio, rebuilt gr-dvbt, updated the FPGA
images, and everything still was fine. The chosen dvb-t bandwidth is 8 MHz.

Then I changed to 003_008_003_rc1, did the same procedure, fired up grc, and
the signal was not decodable both with a dvb-t PC receiver and with an dvb-x
analyzer. The analyzer saw the RF level, but no data, no constellation,
nothing, it looked to him like interference. 

When you have a look at the two uhd screenshots here
http://dk5ras.dyndns.org/tmp/DVB/ made with my spectrum analyzer then you
will find that RC1 produces a somehow narrower signal, so it really looks
something gets cut at the ends with all the filtering and DSP stuff.
Adjusting the channel bandwidth in the uhd sink block from 0 to a sensible
value changes nothing. 

Btw., the dvb-t2 package behaves identical.

Ralph.


-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com] 
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

master works, but RC1 does not? Huh, I'm confused now. Can you give some
detail on what's going on, so we can try and reproduce this?

Thanks,
Martin

On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
 RC1, master seems to work.

 Ralph.

 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 15:44
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean 
 3.8.3-RC1, or latest master?

 Martin

 On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
 It is a B210, but as a note, due to the up to now missing FPGA images 
 I used 003.008.003-RC1, not the latest master. Still I had no access 
 to a spectrum and DVB-T analyzer, so I have no idea what is 
 happening, I just can confirm that RF is transmitted, and the 
 receiver doesn't get a picture, while with the snapshot of the same 
 VM before the upgrade
 is received without problems.
 I will know more in about three hours.

 Ralph.

 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 3:15 PM
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
 Hi,

 Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more 
 with latest uhd. A quick check during lunch break showed, the 
 produced output is not decodable any more. I will take a closer 
 look this evening at home, where I have more and better equipment.

 Ralph,

 which device is this on?

 Thanks,
 Martin






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

It is a B210, but as a note, due to the up to now missing FPGA images I used
003.008.003-RC1, not the latest master. Still I had no access to a spectrum
and DVB-T analyzer, so I have no idea what is happening, I just can confirm
that RF is transmitted, and the receiver doesn't get a picture, while with
the snapshot of the same VM before the upgrade is received without problems.
I will know more in about three hours. 

Ralph.

 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 3:15 PM
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...
 
 On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
  Hi,
 
  Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more
  with latest uhd. A quick check during lunch break showed, the produced
  output is not decodable any more. I will take a closer look this
  evening at home, where I have more and better equipment.
 
 Ralph,
 
 which device is this on?
 
 Thanks,
 Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

RC1, master seems to work.

Ralph.

-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com] 
Sent: Wednesday, April 15, 2015 15:44
To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean
3.8.3-RC1, or latest master?

Martin

On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
 It is a B210, but as a note, due to the up to now missing FPGA images 
 I used 003.008.003-RC1, not the latest master. Still I had no access 
 to a spectrum and DVB-T analyzer, so I have no idea what is happening, 
 I just can confirm that RF is transmitted, and the receiver doesn't 
 get a picture, while with the snapshot of the same VM before the upgrade
is received without problems.
 I will know more in about three hours.

 Ralph.

 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 3:15 PM
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
 Hi,

 Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more 
 with latest uhd. A quick check during lunch break showed, the 
 produced output is not decodable any more. I will take a closer look 
 this evening at home, where I have more and better equipment.

 Ralph,

 which device is this on?

 Thanks,
 Martin




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

Due to a mistake I lost this copy of the VM yesterday :/ I try to reproduce
the issues this evening, I am traveling, so lots of time in the evening, but
no test equipment. Hopefully the hotel TV set will do DVB-T :) Otherwise it
will have to wait for the weekend...

Ralph.

-Original Message-
From: Martin Braun [mailto:martin.br...@ettus.com] 
Sent: Wednesday, April 15, 2015 21:14
To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio
Discussion List'
Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

master works, but RC1 does not? Huh, I'm confused now. Can you give some
detail on what's going on, so we can try and reproduce this?

Thanks,
Martin

On 15.04.2015 12:52, Ralph A. Schmid, dk5ras wrote:
 RC1, master seems to work.

 Ralph.

 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 15:44
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 Thanks, Ralph. Just to clarify: When you say 'New UHD', do you mean 
 3.8.3-RC1, or latest master?

 Martin

 On 15.04.2015 08:40, Ralph A. Schmid, dk5ras wrote:
 It is a B210, but as a note, due to the up to now missing FPGA images 
 I used 003.008.003-RC1, not the latest master. Still I had no access 
 to a spectrum and DVB-T analyzer, so I have no idea what is 
 happening, I just can confirm that RF is transmitted, and the 
 receiver doesn't get a picture, while with the snapshot of the same 
 VM before the upgrade
 is received without problems.
 I will know more in about three hours.

 Ralph.

 -Original Message-
 From: Martin Braun [mailto:martin.br...@ettus.com]
 Sent: Wednesday, April 15, 2015 3:15 PM
 To: Ralph A. Schmid, dk5ras; usrp-us...@lists.ettus.com; 'GNU Radio 
 Discussion List'
 Subject: Re: [Discuss-gnuradio] New UHD seems to break a lot...

 On 15.04.2015 06:20, Ralph A. Schmid, dk5ras wrote:
 Hi,

 Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more 
 with latest uhd. A quick check during lunch break showed, the 
 produced output is not decodable any more. I will take a closer 
 look this evening at home, where I have more and better equipment.

 Ralph,

 which device is this on?

 Thanks,
 Martin






___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ais fails?

[Ralph A. Schmid, dk5ras]

Great, I will do a basic test later, to see if the application starts. Just no 
ships here around, real reception trials have to wait :)

 

Ralph.

 

From: Nick Foster [mailto:bistrom...@gmail.com] 
Sent: Tuesday, April 14, 2015 5:34 PM
To: Ralph A. Schmid, dk5ras
Cc: Kevin Reid; GNU Radio Discussion List
Subject: Re: [Discuss-gnuradio] gr-ais fails?

 

Just FYI, I've added the things I needed to add to get gr-ais working against 
mainline Gnuradio again. I've tested with USRP1 and N210 and it works OK here. 
More testing is of course welcome.

 

--n

 

On Tue, Mar 31, 2015 at 6:59 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx 
mailto:ra...@schmid.xxx  wrote:

Hey, thanks a lot! I will give it a shot when finished, maybe I will be in 
reach of some ships them again. 

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
mailto:schmid@gnu.org  [mailto:discuss-gnuradio-bounces+ralph 
mailto:discuss-gnuradio-bounces%2Bralph =schmid@gnu.org 
mailto:schmid@gnu.org ] On Behalf Of Nick Foster
Sent: Tuesday, March 31, 2015 3:32 AM
To: Kevin Reid
Cc: GNU Radio Discussion List
Subject: Re: [Discuss-gnuradio] gr-ais fails?

 

Yes, this is my fault. I've been catastrophically lazy about removing the 
commits to gr-ais's trunk in order to make it work with mainline GR, because 
I've been hoping things would have been integrated sooner. Tell you what, I'll 
create a branch of gr-ais which just includes the required blocks, in-tree, and 
push that to the trunk until we get all the GR work sorted out. It's going to 
take me some time though.

 

--n

 

On Mon, Mar 30, 2015 at 6:29 PM, Kevin Reid kpr...@switchb.org 
mailto:kpr...@switchb.org  wrote:

On Mar 30, 2015, at 9:19, Martin Braun martin.br...@ettus.com 
mailto:martin.br...@ettus.com  wrote:

 Did you also clean and rebuild gr-ais?

 On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
[...]
 self.preamble_detect = digital.msk_correlate_cc(self.preamble, 0.4,
 self._samples_per_symbol)

 AttributeError: 'module' object has no attribute 'msk_correlate_cc'

I hit this myself just recently.

Apparently, trunk gr-ais is “too new”: it requires a block 
gnuradio.digital.msk_correlate_cc, which was proposed but not yet merged:
https://github.com/gnuradio/gnuradio/pull/376

I, too, would like to use gr-ais and hope this problem gets resolved soon 
(either by gnuradio accepting the patch or gr-ais offering a “stable branch”).

--
Kevin Reid  http://switchb.org/kpreid/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New UHD seems to break a lot...

[Ralph A. Schmid, dk5ras]

Hi,

Not only OpenBTS is affected, also gr-dvbt/t2 do not work any more with
latest uhd. A quick check during lunch break showed, the produced output is
not decodable any more. I will take a closer look this evening at home,
where I have more and better equipment.

Ralph.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Short update: I was able to transmit my own stream now, audio stuttered a bit, 
but for sure I will find out how to fix this. It was a short iPhone video of a 
snake in front of our office (we do not have so much snakes here in Germany), 
and it was fun seeing this transmitted via DVB-T :) 

 

Ralph.

 

From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com] 
Sent: Wednesday, April 8, 2015 5:13 PM
To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hi Ralf,

 

having Us when moving the mouse does not looks good. Can you show a picture 
taken with htop (on Linux).

 

the coding is a setting of the transmitter and receiver and it just need to be 
the same on both. It does impact the maximum bitrate of the stream as in the 
table.

 

Look into the 4.5.4 and 4.5.5 chapters. It says that reference information is 
sent at boosted power level with imaginary equal zero. This is what you see 
in the two dots on left and right.

 

Bogdan

 

 

 

 

 

 

 

On Wednesday, April 8, 2015 5:34 PM, Ralph A. Schmid, dk5ras 
ra...@schmid.xxx mailto:ra...@schmid.xxx  wrote:

 

Hi, 

 

The Us are when I do something else with the machine. They do not show when I 
keep my fingers off the mouse, so no reason to worry, it runs for ages without 
a single U when the machine is kept alone. 



 

I already found out about the rate. The coding also needs to be reflected by 
the transport stream, or just regarding the bitrate? I did not find a setting 
for that, but I will look deeper into it during the next days, when I find some 
time. My first test trying to set identical settings like from the working test 
stream brought just a black picture. 

 

Another question...when looking into the constellation, what are the two dot 
clouds on the X/I-axis, outside the expected 4*4 cloud matrix? Some embedded 
BPSK? I could not find this in the DVB-T specs at first glance...

 

Ralph.

 

 

From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com] 
Sent: Wednesday, April 8, 2015 2:57 PM
To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org 
mailto:discuss-gnuradio@gnu.org 
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hi Ralph,

 

DVB-T.png shows some u's on the command line which means the whole flowgraph do 
not provide data to USRP at the right speed. It basically mean the computer 
cannot cope with the required processing requirement.

 

As for the video parameters, in the DVB-T specs 
(http://www.etsi.org/deliver/etsi_en/300700_300799/300744/01.06.01_60/en_300744v010601p.pdf)
 you will find Table 17 where the rates are presented. FYI, the settings you 
have used are 8Mhz bandwidth, QAM-16 constellation, coding 1/2, guard interval 
1/32. The video should be constant bit rate but it is not a hard requirement 
(see below).

 

If you just broadcast video from a file and not plan to use a live streaming 
from camera, the rate should not matter too much. The video is sent at the rate 
of the DVB-T according to it's parameters and with RTL2832 receiver it is 
buffered and played at the correct speed (at least for short files like 
test.ts).

 

Bogdan

 

 

On Wednesday, April 8, 2015 11:55 AM, Ralph A. Schmid, dk5ras 
ra...@schmid.xxx mailto:ra...@schmid.xxx  wrote:

 

Yep, this would be quite useful!

Bogdan, as you are here, too - I don't know very much about all the crazy video 
file stuff, but maybe you can give me some basic parameters I need to comply 
with for a transport stream, to be able to transmit it with your package?! I 
need to use Windows for the conversion, as my Linux installation is only on a 
virtual machine, with limited space and power. A capable looking Windows 
program is available, but there are so many options I have no clue about :(

 

I modified your flow graph according to Rons hints, and now I have a stable and 
reliable DVB-T transmission path with your package. See 
http://dk5ras.dyndns.org/tmp/DVB/ with a screenshot. I am using the Ettus B210, 
and for reception a second PC with DVB-T stick, or a DVB-x tester that does 
them all, DVB-C/S/S2/T/T2. 

 

You and Ron really did a great job with coding those DVB-x packages!

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org  
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Bogdan 
Diaconescu
Sent: Wednesday, April 8, 2015 8:01 AM
To: Ron Economos; discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org 
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Ok, it would be useful to have receivers too like for the DVB-T. 

 

Bogdan

 

 

On Tuesday, April 7, 2015 11:23 PM, Ron Economos w...@comcast.net 
mailto:w...@comcast.net  wrote:

 

Only transmitter implementations for now. They are here:

https://github.com/drmpeg/gr-dvbs2

https://github.com/drmpeg/gr-dvbt2

The DVB-T2 implementation supports T2-Lite, tone reservation PAPR reduction and 
MISO processing.

Ron

On 04

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Yep, this would be quite useful!

Bogdan, as you are here, too - I don't know very much about all the crazy video 
file stuff, but maybe you can give me some basic parameters I need to comply 
with for a transport stream, to be able to transmit it with your package?! I 
need to use Windows for the conversion, as my Linux installation is only on a 
virtual machine, with limited space and power. A capable looking Windows 
program is available, but there are so many options I have no clue about :(

 

I modified your flow graph according to Rons hints, and now I have a stable and 
reliable DVB-T transmission path with your package. See 
http://dk5ras.dyndns.org/tmp/DVB/ with a screenshot. I am using the Ettus B210, 
and for reception a second PC with DVB-T stick, or a DVB-x tester that does 
them all, DVB-C/S/S2/T/T2. 

 

You and Ron really did a great job with coding those DVB-x packages!

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Bogdan 
Diaconescu
Sent: Wednesday, April 8, 2015 8:01 AM
To: Ron Economos; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Ok, it would be useful to have receivers too like for the DVB-T. 

 

Bogdan

 

 

On Tuesday, April 7, 2015 11:23 PM, Ron Economos w...@comcast.net 
mailto:w...@comcast.net  wrote:

 

Only transmitter implementations for now. They are here:

https://github.com/drmpeg/gr-dvbs2

https://github.com/drmpeg/gr-dvbt2

The DVB-T2 implementation supports T2-Lite, tone reservation PAPR reduction and 
MISO processing.

Ron

On 04/07/2015 06:38 AM, Bogdan Diaconescu wrote:

Hi Ron,

 

I have not followed the development of DVB-T2/S2 lately. Are there receiver 
implementations for the T2/S2 or just transmitters?

 

Thanks,

Bogdan

 

 

On Tuesday, April 7, 2015 1:32 PM, Ralph A. Schmid, dk5ras  
mailto:ra...@schmid.xxx ra...@schmid.xxx wrote:

 

Great to hear that you work finds its way into the official thing! 

 

At the moment, as the RF stuff works, I am trying to learn about all this crazy 
video file stuff, for being able to create transport streams with my own 
content. Up to now I am still testing with the cartoon .ts :) Still my laptop 
(with DVBViewer software) will not decode the audio, while the DVB tester 
decodes audio just fine. 

 

Ralph.

  

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Hi,

 

Don't be worried by the Us, I am running the whole thing in a virtual machine 
that lives on a Windows tablet PC, so it is normal that Linux stutters a bit 
when Windows claims its rights. I just must not touch Windows, and everything 
is fine. 

 

OK, so I just need to set the correct bitrate, and the stream should run. 
Great. Can I keep frame rate as it is from the original video? And what do the 
stream ID fields for video and audio mean?

 

My version of the specs does not have the mentioned chapters, but I have 
already guessed something like this. It just made me curious because the 
constellation plots in the specs do not show this. Ah, here, the stuff linked 
in Wikipedia is what you referred to. My documents seem newer, but different. 
tr_101190v010302p.pdf and ts_102831v010201p.pdf


Ralph.

 

 

 

From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com] 
Sent: Wednesday, April 8, 2015 17:13
To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hi Ralf,

 

having Us when moving the mouse does not looks good. Can you show a picture 
taken with htop (on Linux).

 

the coding is a setting of the transmitter and receiver and it just need to be 
the same on both. It does impact the maximum bitrate of the stream as in the 
table.

 

Look into the 4.5.4 and 4.5.5 chapters. It says that reference information is 
sent at boosted power level with imaginary equal zero. This is what you see 
in the two dots on left and right.

 

Bogdan

 

 

 

 

 

 

 

On Wednesday, April 8, 2015 5:34 PM, Ralph A. Schmid, dk5ras 
ra...@schmid.xxx wrote:

 

Hi, 

 

The Us are when I do something else with the machine. They do not show when I 
keep my fingers off the mouse, so no reason to worry, it runs for ages without 
a single U when the machine is kept alone. 



 

I already found out about the rate. The coding also needs to be reflected by 
the transport stream, or just regarding the bitrate? I did not find a setting 
for that, but I will look deeper into it during the next days, when I find some 
time. My first test trying to set identical settings like from the working test 
stream brought just a black picture. 

 

Another question...when looking into the constellation, what are the two dot 
clouds on the X/I-axis, outside the expected 4*4 cloud matrix? Some embedded 
BPSK? I could not find this in the DVB-T specs at first glance...

 

Ralph.

 

 

From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com] 
Sent: Wednesday, April 8, 2015 2:57 PM
To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hi Ralph,

 

DVB-T.png shows some u's on the command line which means the whole flowgraph do 
not provide data to USRP at the right speed. It basically mean the computer 
cannot cope with the required processing requirement.

 

As for the video parameters, in the DVB-T specs 
(http://www.etsi.org/deliver/etsi_en/300700_300799/300744/01.06.01_60/en_300744v010601p.pdf)
 you will find Table 17 where the rates are presented. FYI, the settings you 
have used are 8Mhz bandwidth, QAM-16 constellation, coding 1/2, guard interval 
1/32. The video should be constant bit rate but it is not a hard requirement 
(see below).

 

If you just broadcast video from a file and not plan to use a live streaming 
from camera, the rate should not matter too much. The video is sent at the rate 
of the DVB-T according to it's parameters and with RTL2832 receiver it is 
buffered and played at the correct speed (at least for short files like 
test.ts).

 

Bogdan

 

 

On Wednesday, April 8, 2015 11:55 AM, Ralph A. Schmid, dk5ras 
ra...@schmid.xxx wrote:

 

Yep, this would be quite useful!

Bogdan, as you are here, too - I don't know very much about all the crazy video 
file stuff, but maybe you can give me some basic parameters I need to comply 
with for a transport stream, to be able to transmit it with your package?! I 
need to use Windows for the conversion, as my Linux installation is only on a 
virtual machine, with limited space and power. A capable looking Windows 
program is available, but there are so many options I have no clue about :(

 

I modified your flow graph according to Rons hints, and now I have a stable and 
reliable DVB-T transmission path with your package. See 
http://dk5ras.dyndns.org/tmp/DVB/ with a screenshot. I am using the Ettus B210, 
and for reception a second PC with DVB-T stick, or a DVB-x tester that does 
them all, DVB-C/S/S2/T/T2. 

 

You and Ron really did a great job with coding those DVB-x packages!

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Bogdan 
Diaconescu
Sent: Wednesday, April 8, 2015 8:01 AM
To: Ron Economos; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Ok, it would be useful to have receivers too like for the DVB-T. 

 

Bogdan

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Hi, 

 

The Us are when I do something else with the machine. They do not show when I 
keep my fingers off the mouse, so no reason to worry, it runs for ages without 
a single U when the machine is kept alone. 

 

I already found out about the rate. The coding also needs to be reflected by 
the transport stream, or just regarding the bitrate? I did not find a setting 
for that, but I will look deeper into it during the next days, when I find some 
time. My first test trying to set identical settings like from the working test 
stream brought just a black picture. 

 

Another question...when looking into the constellation, what are the two dot 
clouds on the X/I-axis, outside the expected 4*4 cloud matrix? Some embedded 
BPSK? I could not find this in the DVB-T specs at first glance...

 

Ralph.

 

 

From: Bogdan Diaconescu [mailto:b_diacone...@yahoo.com] 
Sent: Wednesday, April 8, 2015 2:57 PM
To: Ralph A. Schmid, dk5ras; 'Ron Economos'; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hi Ralph,

 

DVB-T.png shows some u's on the command line which means the whole flowgraph do 
not provide data to USRP at the right speed. It basically mean the computer 
cannot cope with the required processing requirement.

 

As for the video parameters, in the DVB-T specs 
(http://www.etsi.org/deliver/etsi_en/300700_300799/300744/01.06.01_60/en_300744v010601p.pdf)
 you will find Table 17 where the rates are presented. FYI, the settings you 
have used are 8Mhz bandwidth, QAM-16 constellation, coding 1/2, guard interval 
1/32. The video should be constant bit rate but it is not a hard requirement 
(see below).

 

If you just broadcast video from a file and not plan to use a live streaming 
from camera, the rate should not matter too much. The video is sent at the rate 
of the DVB-T according to it's parameters and with RTL2832 receiver it is 
buffered and played at the correct speed (at least for short files like 
test.ts).

 

Bogdan

 

 

On Wednesday, April 8, 2015 11:55 AM, Ralph A. Schmid, dk5ras 
ra...@schmid.xxx mailto:ra...@schmid.xxx  wrote:

 

Yep, this would be quite useful!

Bogdan, as you are here, too - I don't know very much about all the crazy video 
file stuff, but maybe you can give me some basic parameters I need to comply 
with for a transport stream, to be able to transmit it with your package?! I 
need to use Windows for the conversion, as my Linux installation is only on a 
virtual machine, with limited space and power. A capable looking Windows 
program is available, but there are so many options I have no clue about :(

 

I modified your flow graph according to Rons hints, and now I have a stable and 
reliable DVB-T transmission path with your package. See 
http://dk5ras.dyndns.org/tmp/DVB/ with a screenshot. I am using the Ettus B210, 
and for reception a second PC with DVB-T stick, or a DVB-x tester that does 
them all, DVB-C/S/S2/T/T2. 

 

You and Ron really did a great job with coding those DVB-x packages!

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org  
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Bogdan 
Diaconescu
Sent: Wednesday, April 8, 2015 8:01 AM
To: Ron Economos; discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org 
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Ok, it would be useful to have receivers too like for the DVB-T. 

 

Bogdan

 

 

On Tuesday, April 7, 2015 11:23 PM, Ron Economos w...@comcast.net 
mailto:w...@comcast.net  wrote:

 

Only transmitter implementations for now. They are here:

https://github.com/drmpeg/gr-dvbs2

https://github.com/drmpeg/gr-dvbt2

The DVB-T2 implementation supports T2-Lite, tone reservation PAPR reduction and 
MISO processing.

Ron

On 04/07/2015 06:38 AM, Bogdan Diaconescu wrote:

Hi Ron,

 

I have not followed the development of DVB-T2/S2 lately. Are there receiver 
implementations for the T2/S2 or just transmitters?

 

Thanks,

Bogdan

 

 

On Tuesday, April 7, 2015 1:32 PM, Ralph A. Schmid, dk5ras  
mailto:ra...@schmid.xxx ra...@schmid.xxx wrote:

 

Great to hear that you work finds its way into the official thing! 

 

At the moment, as the RF stuff works, I am trying to learn about all this crazy 
video file stuff, for being able to create transport streams with my own 
content. Up to now I am still testing with the cartoon .ts :) Still my laptop 
(with DVBViewer software) will not decode the audio, while the DVB tester 
decodes audio just fine. 

 

Ralph.

  

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Great to hear that you work finds its way into the official thing! 

 

At the moment, as the RF stuff works, I am trying to learn about all this
crazy video file stuff, for being able to create transport streams with my
own content. Up to now I am still testing with the cartoon .ts :) Still my
laptop (with DVBViewer software) will not decode the audio, while the DVB
tester decodes audio just fine. 

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ron
Economos
Sent: Tuesday, April 7, 2015 8:14 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Yes, rotated constellations are a new feature of DVB-T2. More reading here.

http://www.etsi.org/deliver/etsi_ts/102800_102899/102831/01.02.01_60/ts_1028
31v010201p.pdf

See section 9.2.3. In addition to the rotation, the I and Q components of a
QAM/QPSK symbol are cyclically delayed. Since there's a time and a frequency
interleaver after the modulator, the I and Q components of a symbol get sent
at a different time and a different frequency (OFDM carrier). Almost all
DVB-T2 broadcasters turn this feature on, even with 256QAM. All DVB-T2
receivers must support rotated constellations.

Be sure to change the Constellation rotation parameter in both the
Modulator block and the Frame Mapper block, or the receiver will get
confused.

BTW, both the DVB-T2 and DVB-S2 transmitters will be included in GNU Radio
in the next release (3.7.7) as part of gr-dtv.

If you place a Scope Sink after the modulator, you can see the virtual
constellation mentioned in the link above.



Ron

On 04/06/2015 10:14 PM, Ralph A. Schmid, dk5ras wrote:

It _is_ intended:

 

http://dcis2009.unizar.es/FILES/CR2/p41.pdf

 

So forget about my question :)

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 07:04
To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org 
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hmm, now I see, there is an option constellation rotation in the modulator
block. Maybe this is not an accident, but wanted behavior?! I will check
this evening...


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 06:39
To: discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org 
Subject: [Discuss-gnuradio] DVB-T/T2

 

Hi,

 

With Rons help I got the DVB-T/T2 flowgraphs up and running.

 

DVB-T works great, no issues at all, while DVB-T2 is somehow flaky in
reception.

 

When using a cheap DVB-x tester, the DVB-T2 constellation is phase shifted.
I have no real world T2 signals to compare, but at least the tester shows
normal constellation views when looking at S and T signals off the air.

 

This is how things look:

 

http://dk5ras.dyndns.org/tmp/DVB/

 

The flowgraphs are almost original, just adopted to the USRP B210, and I
added channel slider...

 

Any ideas what I could tweak?

 

Ralph.

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Hi,

 

With Rons help I got the DVB-T/T2 flowgraphs up and running.

 

DVB-T works great, no issues at all, while DVB-T2 is somehow flaky in
reception.

 

When using a cheap DVB-x tester, the DVB-T2 constellation is phase shifted.
I have no real world T2 signals to compare, but at least the tester shows
normal constellation views when looking at S and T signals off the air.

 

This is how things look:

 

http://dk5ras.dyndns.org/tmp/DVB/

 

The flowgraphs are almost original, just adopted to the USRP B210, and I
added channel slider...

 

Any ideas what I could tweak?

 

Ralph.

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

Hmm, now I see, there is an option constellation rotation in the modulator
block. Maybe this is not an accident, but wanted behavior?! I will check
this evening...


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 06:39
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] DVB-T/T2

 

Hi,

 

With Rons help I got the DVB-T/T2 flowgraphs up and running.

 

DVB-T works great, no issues at all, while DVB-T2 is somehow flaky in
reception.

 

When using a cheap DVB-x tester, the DVB-T2 constellation is phase shifted.
I have no real world T2 signals to compare, but at least the tester shows
normal constellation views when looking at S and T signals off the air.

 

This is how things look:

 

http://dk5ras.dyndns.org/tmp/DVB/

 

The flowgraphs are almost original, just adopted to the USRP B210, and I
added channel slider...

 

Any ideas what I could tweak?

 

Ralph.

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DVB-T/T2

[Ralph A. Schmid, dk5ras]

It _is_ intended:

 

http://dcis2009.unizar.es/FILES/CR2/p41.pdf

 

So forget about my question :)

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 07:04
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] DVB-T/T2

 

Hmm, now I see, there is an option constellation rotation in the modulator
block. Maybe this is not an accident, but wanted behavior?! I will check
this evening...


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, April 7, 2015 06:39
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] DVB-T/T2

 

Hi,

 

With Rons help I got the DVB-T/T2 flowgraphs up and running.

 

DVB-T works great, no issues at all, while DVB-T2 is somehow flaky in
reception.

 

When using a cheap DVB-x tester, the DVB-T2 constellation is phase shifted.
I have no real world T2 signals to compare, but at least the tester shows
normal constellation views when looking at S and T signals off the air.

 

This is how things look:

 

http://dk5ras.dyndns.org/tmp/DVB/

 

The flowgraphs are almost original, just adopted to the USRP B210, and I
added channel slider...

 

Any ideas what I could tweak?

 

Ralph.

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ais fails?

[Ralph A. Schmid, dk5ras]

Yes, I did, even deleted the gr-ais folder and loaded a completely new git
repo...

Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Martin Braun
 Sent: Monday, March 30, 2015 6:20 PM
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] gr-ais fails?
 
 Did you also clean and rebuild gr-ais?
 
 M
 
 On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
  Hi,
 
  with latest UHD and Gnuradio built from sources, gr-ais throws this
  error when callin ais_rx:
 
  ras@ubuntu:~$ ais_rx
 
  linux; GNU C++ version 4.8.2; Boost_105400;
  UHD_003.008.002-143-g8c20712d
 
  -- Operating over USB 3.
 
  -- Initialize CODEC control...
 
  -- Initialize Radio control...
 
  -- Performing register loopback test... pass
 
  -- Performing register loopback test... pass
 
  -- Performing CODEC loopback test... pass
 
  -- Performing CODEC loopback test... pass
 
  -- Asking for clock rate 32.00 MHz...
 
  -- Actually got clock rate 32.00 MHz.
 
  -- Performing timer loopback test... pass
 
  -- Performing timer loopback test... pass
 
  -- Setting master clock rate selection to 'automatic'.
 
  -- Tune Request: 162.00 MHz
 
  --   The RF LO does not support the requested frequency:
 
  -- Requested LO Frequency: 162.00 MHz
 
  -- RF LO Result: 162.00 MHz
 
  --   Attempted to use the DSP to reach the requested frequency:
 
  -- Desired DSP Frequency: -0.00 MHz
 
  -- DSP Result: -0.00 MHz
 
  --   Successfully tuned to 162.00 MHz
 
  --
 
  Tuned to 162.000MHz
 
  Setting gain to 38
 
  Gain is 38
 
  Rate is 25
 
  Using Volk machine: avx_64_mmx_orc
 
  Traceback (most recent call last):
 
 File /usr/local/bin/ais_rx, line 23, in module
 
   main()
 
 File /usr/local/bin/ais_rx, line 18, in main
 
   tb = ais.radio.ais_radio(options)
 
 File /usr/local/lib/python2.7/dist-packages/ais/radio.py, line
  88, in __init__
 
   self._rx_paths = (ais_rx(161.975e6 - 162.0e6, options.rate, A),
 
 File /usr/local/lib/python2.7/dist-packages/ais/radio.py, line
  63, in __init__
 
   self.demod = ais.ais_demod(options) #ais_demod takes in complex
  baseband and spits out 1-bit unpacked bitstream
 
 File /usr/local/lib/python2.7/dist-packages/ais/ais_demod.py,
  line 37, in __init__
 
   self.preamble_detect = digital.msk_correlate_cc(self.preamble,
  0.4,
  self._samples_per_symbol)
 
  AttributeError: 'module' object has no attribute 'msk_correlate_cc'
 
  ras@ubuntu:~$
 
  Any ideas what is wrong?
 
  Ralph.
 
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ais fails?

[Ralph A. Schmid, dk5ras]

Hey, thanks a lot! I will give it a shot when finished, maybe I will be in 
reach of some ships them again. 

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Nick 
Foster
Sent: Tuesday, March 31, 2015 3:32 AM
To: Kevin Reid
Cc: GNU Radio Discussion List
Subject: Re: [Discuss-gnuradio] gr-ais fails?

 

Yes, this is my fault. I've been catastrophically lazy about removing the 
commits to gr-ais's trunk in order to make it work with mainline GR, because 
I've been hoping things would have been integrated sooner. Tell you what, I'll 
create a branch of gr-ais which just includes the required blocks, in-tree, and 
push that to the trunk until we get all the GR work sorted out. It's going to 
take me some time though.

 

--n

 

On Mon, Mar 30, 2015 at 6:29 PM, Kevin Reid kpr...@switchb.org 
mailto:kpr...@switchb.org  wrote:

On Mar 30, 2015, at 9:19, Martin Braun martin.br...@ettus.com 
mailto:martin.br...@ettus.com  wrote:

 Did you also clean and rebuild gr-ais?

 On 29.03.2015 08:53, Ralph A. Schmid, dk5ras wrote:
[...]
 self.preamble_detect = digital.msk_correlate_cc(self.preamble, 0.4,
 self._samples_per_symbol)

 AttributeError: 'module' object has no attribute 'msk_correlate_cc'

I hit this myself just recently.

Apparently, trunk gr-ais is “too new”: it requires a block 
gnuradio.digital.msk_correlate_cc, which was proposed but not yet merged:
https://github.com/gnuradio/gnuradio/pull/376

I, too, would like to use gr-ais and hope this problem gets resolved soon 
(either by gnuradio accepting the patch or gr-ais offering a “stable branch”).

--
Kevin Reid  http://switchb.org/kpreid/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gr-ais fails?

[Ralph A. Schmid, dk5ras]

Hi,

 

with latest UHD and Gnuradio built from sources, gr-ais throws this error
when callin ais_rx:

 

ras@ubuntu:~$ ais_rx 

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.002-143-g8c20712d

 

-- Operating over USB 3.

-- Initialize CODEC control...

-- Initialize Radio control...

-- Performing register loopback test... pass

-- Performing register loopback test... pass

-- Performing CODEC loopback test... pass

-- Performing CODEC loopback test... pass

-- Asking for clock rate 32.00 MHz... 

-- Actually got clock rate 32.00 MHz.

-- Performing timer loopback test... pass

-- Performing timer loopback test... pass

-- Setting master clock rate selection to 'automatic'.

-- Tune Request: 162.00 MHz

--   The RF LO does not support the requested frequency:

-- Requested LO Frequency: 162.00 MHz

-- RF LO Result: 162.00 MHz

--   Attempted to use the DSP to reach the requested frequency:

-- Desired DSP Frequency: -0.00 MHz

-- DSP Result: -0.00 MHz

--   Successfully tuned to 162.00 MHz

-- 

Tuned to 162.000MHz

Setting gain to 38

Gain is 38

Rate is 25

Using Volk machine: avx_64_mmx_orc

Traceback (most recent call last):

  File /usr/local/bin/ais_rx, line 23, in module

main()

  File /usr/local/bin/ais_rx, line 18, in main

tb = ais.radio.ais_radio(options)

  File /usr/local/lib/python2.7/dist-packages/ais/radio.py, line 88, in
__init__

self._rx_paths = (ais_rx(161.975e6 - 162.0e6, options.rate, A),

  File /usr/local/lib/python2.7/dist-packages/ais/radio.py, line 63, in
__init__

self.demod = ais.ais_demod(options) #ais_demod takes in complex baseband
and spits out 1-bit unpacked bitstream

  File /usr/local/lib/python2.7/dist-packages/ais/ais_demod.py, line 37,
in __init__

self.preamble_detect = digital.msk_correlate_cc(self.preamble, 0.4,
self._samples_per_symbol)

AttributeError: 'module' object has no attribute 'msk_correlate_cc'

ras@ubuntu:~$

 

 

Any ideas what is wrong?



Ralph.

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Openbts-discuss] -------'Range' network is not detected-------

[Ralph A. Schmid, dk5ras]

First of all, it is normal that the USRP is not detected anymore with the uhd 
tools when it is claimed by OpenBTS. So this looks not alarming.

 

Are you able to verify if RF is transmitted? Is there some spectrum analyzer 
available, or a receiver that can tune into the used GSM frequency, best is AM 
mode and open squelch, to see if a carrier is present? This way you can find 
out if it transmits at all, and if so, it must be continously, uninterruptes, 
without stuttering.

 

I assume your successful tests used the very same USRP, so the frequency should 
not be off too far?!

 

Ralph.

 

From: Zamrath Nizam [mailto:zamiguy...@gmail.com] 
Sent: Tuesday, March 24, 2015 5:33 AM
To: openbts-disc...@lists.sourceforge.net; GNURadio Discussion List
Subject: [Openbts-discuss] ---'Range' network is not detected---

 

Hi all,

 

I have recently installed OpenBTS-2.8 on a Banana-Pi (Processor: ARMv7) board 
for USRP N210 functioning. All the prerequisites including GNURadio, UHD were 
successfully built on the board prior to OpenBTS installation. With all 
configurations done, still there is a problem in the USRP connection.

I have configured MCC, MNC and ethernet IP connection. ping 192.168.10.2 
works fine. Once the ethernet connection is established and until ./OpenBTS 
is executed, uhd_find_devices and uhd_usrp_probe detect USRP. After the 
execution of ./OpenBTS, surprisingly uhd_find_devices and uhd_usrp_probe 
do not detect the device and say No device found... ('ping' is still working 
though). The strangest thing is even at this stage, ./OpenBTS works fine even 
at a re-run. 

After all these drama, no ('range') network is detected by a properly 
configured mobile phone. (Note: We have successfully placed calls and SMS with 
almost same procedure using a PC instead of B-Pi). 

I am bit confused here whether this is a deal of OpenBTS or GNURadio. Does the 
processor speed come in to play in this scenario?

Any valuable suggestions would be highly appreciated.

 

Thank you.

 

Zamrath Nizam

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Issues Installing From Source

[Ralph A. Schmid, dk5ras]

I am afraid I did not document this, but I ran into similar issues with the
script and Kubuntu 14.04. However doing it all by hand, resolving
dependencies, load uhd and gnuradio sources, compile the stuff, installing
udev rules, installing the gnuradio icons by hand and such, this all was not
a big deal, and in some cases I simply read the script as a manual how to do
it.

Pybombs is something I could not become friends with yet. For many people it
seems to work, for me all attempts were disastreous. 

Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Marcus D. Leech
 Sent: Wednesday, March 4, 2015 5:43 PM
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] Issues Installing From Source
 
 On 03/04/2015 10:40 AM, Peter Witkowski wrote:
  Hello,
 
  In the past, I've always used the build-gnuradio script to install
  everything with great success.  This ensures that I have all the
  latest versions of both GNU Radio and UHD.
 
  However, I recently got a new machine and installed Ubuntu 14.04 on it
  (I haven't had any issues with 14.04 before). I updated the OS to the
  latest version and then tried using build-gnuradio.  Immediately I
  started having issues.  First, the script was unable to install git,
  cmake, and other dependencies.  However, I was manually able to do a
  sudo apt-get on all of these packages and at least get to the point
  where the script tries to install UHD.
 This is the first I've heard of it having problems doing the pre-req
installs.  If
 you run build-gnuradio with -v, you get more details about why.
If the underlying OS tooling is falling over, there's very little that
build-
 gnuradio can do about it.  It has as much troubleshoot-and-repair
ability as a moribund gnat.
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] mimo beam forming on USRP

[Ralph A. Schmid, dk5ras]

When I read this, pCell comes in mind:
http://www.rearden.com/artemis/An-Introduction-to-pCell-White-Paper-150224.p
df 

Quite exciting stuff!

Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Martin Braun
 Sent: Tuesday, March 3, 2015 5:26 PM
 To: Pengyu Zhang
 Cc: Discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] mimo beam forming on USRP
 
 Can you give us some details (frequency, number of antennas) that you want
 to have?
 
 A lot of people have done MIMO with USRPs, up to 100x100 antennas, so
 there is some precedent. For beam forming, you'll need very good phase
 alignment, depending on what you're planning to set up. This is always
 difficult, because all sorts of things affect phase. You should, in any
case,
 have a way to test phase alignment.
 
 Cheers,
 Martin
 
 On 03.03.2015 08:18, mle...@ripnet.com wrote:
  If you use the phase-resynch feature of the SBX card, and you have
  common refclock and 1PPS across all your USRPs in the array,
then you should be OK.
 
  In *general*, synthesized downconverters use fractional-N synthesizers
  where their starting phase after a re-tune is random with respect to
  any other synthesizer using the same reference clock.  That's just the
  way
  fractional- N synthesis works.  It happens that SBX uses an ADF4351
  synthesizer, which has a (rare!) hardware feature to allow
  phase-resynch after tuning.  In order to make this work, all SBXes in
your
 array
  must be tuned at exactly the same time, so the timed_commands feature
  must be used to do the tuning.
 
  See:
 
  http://files.ettus.com/manual/page_sync.html
 
  On 2015-03-03 11:05, Pengyu Zhang wrote:
 
  Hi Guys,
  I am planning to build a mimo system which supports beam forming. Is
  USRP a good platform for my target? I do not want to use WARP because
  I need to operate at frequencies lower than 2.4GHz.
  A potential problem of USRP is phase alignment. As the following doc
  suggests, phase alignment can be done by MANUALLY tuning the phase.
  This process can be labor intensive when the number of antennas
  increases. I am also worried about the problem that the manual phase
  calibration might need to be done each time you use the mimo system.
  Is there any approach that can make this process much easier?
 
 http://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updat
 ed
  .pdf Would be great if you can give me some suggestions about what
  devices should I use for building a mimo system for beam forming.
  Thanks.
  Pengyu
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org  mailto:Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0

[Ralph A. Schmid, dk5ras]

I made tests with the bladeRF at 30 MHz bandwidth, and I was able to see the 
spectrum just fine, not matter if I used a USB2 or a USB3 cable. No hacks, no 
switching chunks of the spectrum, just using a standard receiver program. The 
lost samples are not a problem as longs as you do not want to listen in.


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Jorge 
Gallo
Sent: Thursday, January 29, 2015 4:07 PM
To: Martin Braun
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0

 

Martin,

 

The alternative of a USB 3.0 is not having 5 USRPs. It is just reading 5 times 
at different centrer frequencies in order to get 40MHz information although 
that information will not be gathered at the same time.

 

For my application I just need to see the sprectrum. I do not need to 
demodulate data so that it would be fine to proceed that way. However i would 
rather get 40MHz in a row.

 

Many thanks, 

Jorge

 

On 29 January 2015 at 14:07, Martin Braun martin.br...@ettus.com 
mailto:martin.br...@ettus.com  wrote:

On 01/29/2015 01:48 PM, Jorge Gallo wrote:
 I understand the given values of host bandwidth for each protocol:

 USB 2.0  8 (MS/s @ 16-bit I/Q)

If you go down to 8-bit IQ, you will get twice that amount, if that's
any help.

 USB 3.061.44 (MS/s @ 16-bit I/Q)



 However I would like to process 40MHz of analogue BW in GNURadio over
 USB 2.0


 I fully understand  a continuous reception is not possible to manage
 since it would require 40 IQ MS/s and I am limited to 8MS/s.



 However, is it possible to take snapshots of 40MHz over the time so that
 I am able to receive bits of 40MHz with USB 2.0 which are not continuous
 in time?

 Are there buffers in the FPGA that manage this kind of operation?

None big enough for anything useful.

It seems like attaching a USB3.0 connector would be simpler than running
5 USRPs? Not that I would complain about the sales :)

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0

[Ralph A. Schmid, dk5ras]

I understand his question that he just wants to let the whole thing pump out
samples, and he takes only a portion of it. I have no idea if this works in
a controlled manner, but at least for spectrum display this works just fine,
the lost samples are not a big issue.

Ralph.

 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Martin Braun
 Sent: Thursday, January 29, 2015 2:08 PM
 To: discuss-gnuradio@gnu.org
 Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0
 
 On 01/29/2015 01:48 PM, Jorge Gallo wrote:
  I understand the given values of host bandwidth for each protocol:
 
  USB 2.0  8 (MS/s @ 16-bit I/Q)
 
 If you go down to 8-bit IQ, you will get twice that amount, if that's
 any help.
 
  USB 3.061.44 (MS/s @ 16-bit I/Q)
 
 
 
  However I would like to process 40MHz of analogue BW in GNURadio over
  USB 2.0
 
 
  I fully understand  a continuous reception is not possible to manage
  since it would require 40 IQ MS/s and I am limited to 8MS/s.
 
 
 
  However, is it possible to take snapshots of 40MHz over the time so that
  I am able to receive bits of 40MHz with USB 2.0 which are not continuous
  in time?
 
  Are there buffers in the FPGA that manage this kind of operation?
 
 None big enough for anything useful.
 
 It seems like attaching a USB3.0 connector would be simpler than running
 5 USRPs? Not that I would complain about the sales :)
 
 M
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0

[Ralph A. Schmid, dk5ras]

To be honest, I have no idea :) However I did not yet test this with the B210, 
as now USB3 works flawless. In the beginning the BladeRF was not compatible 
with my USB3 setup for whatever reason, so I had to stay with USB2 for a while 
until those issues were sorted out both in BladeRF software and VMware. 

 

Let’s see…FPGA loading really takes a while through a USB2 cable…HDSDR is 
starting…master_clock_rate=56e6…

 

Tadaaa – here we go: http://dk5ras.dyndns.org/screenshots/B210_USB2.png with an 
USB 2 cable on an USB2 port. 

 

And in comparison http://dk5ras.dyndns.org/screenshots/B210_USB3.png with an 
USB3 cable on an USB3 port of the same PC.

 

Same portion of the spectrum, same receiver location (just with a short 
wideband Delock 88451 antenna, sitting on my table), similar picture…

 

Ralph.

 

From: Jorge Gallo [mailto:jmig...@gmail.com] 
Sent: Thursday, January 29, 2015 4:44 PM
To: Ralph A. Schmid, dk5ras
Cc: Martin Braun; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0

 

How is that possible since only 8MHz can be placed over USB 2.0 ?

 

On one hand I have a B200 which is supposed to deliver 56 MHz.

On the other hand, for my final application, I am thinking of a low-cost host 
(such as BeagleBone Black) which I am afraid only has USB 2.0

 

My question was about getting 40MHz BW over USB 2.0 without tuning the central 
frequency of the USRP several times.

 

Regards,

Jorge

 

On 29 January 2015 at 16:35, Ralph A. Schmid, dk5ras ra...@schmid.xxx 
mailto:ra...@schmid.xxx  wrote:

I made tests with the bladeRF at 30 MHz bandwidth, and I was able to see the 
spectrum just fine, not matter if I used a USB2 or a USB3 cable. No hacks, no 
switching chunks of the spectrum, just using a standard receiver program. The 
lost samples are not a problem as longs as you do not want to listen in.


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
mailto:schmid@gnu.org  [mailto:discuss-gnuradio-bounces+ralph 
mailto:discuss-gnuradio-bounces%2Bralph =schmid@gnu.org 
mailto:schmid@gnu.org ] On Behalf Of Jorge Gallo
Sent: Thursday, January 29, 2015 4:07 PM
To: Martin Braun
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] USRP B200 host BW with USB 3.0/2.0

 

Martin,

 

The alternative of a USB 3.0 is not having 5 USRPs. It is just reading 5 times 
at different centrer frequencies in order to get 40MHz information although 
that information will not be gathered at the same time.

 

For my application I just need to see the sprectrum. I do not need to 
demodulate data so that it would be fine to proceed that way. However i would 
rather get 40MHz in a row.

 

Many thanks, 

Jorge

 

On 29 January 2015 at 14:07, Martin Braun martin.br...@ettus.com 
mailto:martin.br...@ettus.com  wrote:

On 01/29/2015 01:48 PM, Jorge Gallo wrote:
 I understand the given values of host bandwidth for each protocol:

 USB 2.0  8 (MS/s @ 16-bit I/Q)

If you go down to 8-bit IQ, you will get twice that amount, if that's
any help.

 USB 3.061.44 (MS/s @ 16-bit I/Q)



 However I would like to process 40MHz of analogue BW in GNURadio over
 USB 2.0


 I fully understand  a continuous reception is not possible to manage
 since it would require 40 IQ MS/s and I am limited to 8MS/s.



 However, is it possible to take snapshots of 40MHz over the time so that
 I am able to receive bits of 40MHz with USB 2.0 which are not continuous
 in time?

 Are there buffers in the FPGA that manage this kind of operation?

None big enough for anything useful.

It seems like attaching a USB3.0 connector would be simpler than running
5 USRPs? Not that I would complain about the sales :)

M

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Example of DMR receiver

[Ralph A. Schmid, dk5ras]

Yep, gr-dsd works great, I can monitor my DMR repeater with it just fine. I 
just wonder why they left out TETRA, the infrastructure (by means of SW) should 
be already there…

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of John D. 
Hays
Sent: Monday, January 26, 2015 7:03 PM
To: Veijo Arponen
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Example of DMR receiver

 

Veijo,

 

https://github.com/argilo/gr-dsd

 

Be advised that mbelib may not be legal to use, hence the anonymity of the 
authors.

 

This ambiguity could be eliminated if someone created a block to use an 
AMBE-3000 device. 

 

One source of AMBE devices is  
http://nwdigitalradio.com/thumbdv-and-dv3000-resource-page (I am affiliated 
with this company).

Talking to the AMBE-3000 devices listed is pretty straightforward, should 
someone be inclined.

 

Open the device as a serial port at 230.4 kbps.

 

It's a simple packet interface and every packet has a reply.

 

Send a reset packet  hex 61 00 01 00 33 at program startup

 

Then query for model number packet with hex 61 00 01 00 30 and look for 
AMBE3000 in reply 

 

Set D-STAR mode with 61 00 0c 00 0a 01 30 07 63 40 00 00 00 00 00 00 48

Set Yaesu, P25 , DMR, etc. HR mode with 61 00 0c 00 0a 04 31 07 54 24 00 00 00 
00 00 6F 48 

(See page 83 of AMBE-3000 manual -- link below)

 

From there, you send in audio  16-bit linear PCM data sampled at 8 kHz in 
packets and it sends out AMBE in packets. (You can also use 8-bit ulaw/alaw 
but the PCM is better quality)

 

Audio header is 61 01 42 02 00 A0

 

Or send in AMBE packets and receive audio packets.

 

AMBE header is 61 00 0B 01 01 48

 

Pretty much it, just need to frame packet data based on the packet protocol.

 

The manual is at http://www.dvsinc.com/manuals/AMBE-3000_manual.pdf -- see 
Chapter 6.  Current software uses the non-parity field version, but you are 
free to use either.  

 

 

 

On Mon, Jan 26, 2015 at 7:37 AM, Veijo Arponen oh3...@gmail.com 
mailto:oh3...@gmail.com  wrote:

Hello,

My first touch to the Gnu Radio happened this weekend. I managed to listen a 
local FM repeater but building a DMR receiver was too tough. 

Please, could someone send me a simple working DMR receiver file (*.grc) which 
has a DSD block.

Thanks advanced

73 de Veijo OH3NFC


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





 

-- 

 

  _  

John D. Hays
K7VE

 

PO Box 1223, Edmonds, WA 98020-1223 

 http://k7ve.org/blog   http://twitter.com/#!/john_hays   
http://www.facebook.com/john.d.hays 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[Ralph A. Schmid, dk5ras]

We are using almost the same IC in our product, as a driver for a transmitting 
coil in industrial environment, for material test, and we had never ever fail 
one of those. Must be around 4k or 5k of those ICs we have out in the field, 
and the only failures were two or three that came dead from the PCB 
manufacturer. Even a hard short never was able to kill one.


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Marcus 
D. Leech
Sent: Friday, January 16, 2015 8:12 PM
To: khalid.el-darymli; Michael Rahaim
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX

 

On 01/16/2015 02:08 PM, khalid.el-darymli wrote:

Hi All, 

 

Just to update you in case somebody else comes across this problem. Following 
Mike's advice, we replaced the LFTX daughterboard with a new one. We're getting 
now 1 V p-p. This is around 4 dBm.

 

Thanks very much for your help.

 

Best regards,

Khalid

 

 

Interesting.  The driver chip that's used, as a unity-gain 
differential-to-single-ended driver, is, according to the datasheets, pretty 
robust.  So, it would
  be interesting to know exactly what the failure mode is.





 

 

On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim mrah...@bu.edu 
mailto:mrah...@bu.edu  wrote:

Hi Khalid, 

 

I had a similar issue with an LFTX that I had been working with for about two 
years. I actually had two boards running on separate USRP2's and both were 
working fine for quite a while, but I recently noticed that one had a 
drastically lower output range. I ended up replacing the LFTX and all is 
working well now, so I'm assuming it was a hardware issue that came up at some 
point. 

 

I didn't take the time to look for the problem, but I figured I'd share this 
info since what you're seeing might be a hardware issue rather than something 
you can resolve with settings.

 

-Mike

 

On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli khalid.el-dary...@mun.ca 
mailto:khalid.el-dary...@mun.ca  wrote:


 Output power is determined largely by baseband signal magnitude in that case.

Yes, I understand. And I noticed that for baseband signal with an amplitude  
1,  the pass-band signal gets clipped off. So I assume that an amplitude of 1 
for the baseband signal should deliver the maximum output power (for the 
pass-band signal).

My question was, what is the maximum power one can get for the pass-band signal 
output from LFTX? In your earlier reply, you said it is around +7dBm, am I 
getting this right? In my case, for a baseband amplitude of around 1, I am only 
getting -28.13dBm, much less than what you said, I am not sure, why?

Thanks,

Khalid

 

On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech mle...@ripnet.com 
mailto:mle...@ripnet.com  wrote:

Thanks Marcus for your reply.

 Probably somewhere in the neighborhood of +7dBm, maybe a little more.

 The LF/BASIC series have *no* gain in either path, so you're just looked
at buffered ADC ouput.

So, ~ +7dBm is the max output power I supposed to get from the LFTX 
daughterboard? How do I get that?

Since I am only getting -28.13 dBm, does that mean I have some issue with my 
LFTX daughterboard?

 

Khalid

 

Output power is determined largely by baseband signal magnitude in that case. 













Message: 2
Date: Tue, 6 Jan 2015 10:13:45 -0330
From: khalid.el-darymli khalid.el-dary...@mun.ca 
mailto:khalid.el-dary...@mun.ca 
To: Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org  
discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org 
Subject: [Discuss-gnuradio] Max Output Power from the LFTX
daughterboard
Message-ID:
CACdmG=zCHATiwrtv=wBVLwG0_ 

5GQr0y=wksequrcajrtuv5...@mail.gmail.com 
mailto:wksequrcajrtuv5...@mail.gmail.com 
Content-Type: text/plain; charset=utf-8

Hi,

What is the maximum output power from the LFTX daughterboard when used with
the USRP N200?

According to this datasheet [1], the N200 with the WBX daughterbaord
provide an output power of 15 dBm. However, when using the LFTX
daughterboard, I am getting a much less output power.
[1] http://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR.pdf

In GNU Radio with the USRP N200, we use a sinusoid with a frequency of 150
kHz and an amplitude of 0.98, fed into the LFTX daughterboard for a center
frequency of 5 MHz. When the output of LFTX is plugged into a scope
terminated with a 50-ohm terminator, the scope reads 24.8 mV
(peak-to-peak). This is around -28.13 dBm.

Is this the max power one can get out of the LFTX daughterboard?


Thanks.

Best regards,
Khalid
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20150106/37846ff4/attachment.html

--

Message: 3
Date: Tue, 06 Jan 2015 08:48:08 -0500
From: Marcus D. Leech mle...@ripnet.com mailto:mle...@ripnet.com 
To: discuss-gnuradio@gnu.org 

Re: [Discuss-gnuradio] Max Output Power from the LFTX

[Ralph A. Schmid, dk5ras]

Usually you just see, the IC is defective, that’s all, and this is what we 
already know anyway :)

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Marcus 
D. Leech
Sent: Friday, January 16, 2015 8:59 PM
To: khalid.el-darymli
Cc: Discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Max Output Power from the LFTX

 

On 01/16/2015 02:54 PM, khalid.el-darymli wrote:

I see. If you would like to diagnose the problem, we can ship you the 
malfunctioned daughterboard? 

 

Thanks,

Khalid

 

Thanks.  I personally wouldn't have time/equipment to really diagnose it.  So 
it would be up to Ettus RD as to whether they want it back to see
  what the failure mode is.

I've been doing Ettus support for 6 years, and LF_TX are not generally items 
that show up with RMA requests very often.  






 

On Fri, Jan 16, 2015 at 4:17 PM, Marcus D. Leech mle...@ripnet.com 
mailto:mle...@ripnet.com  wrote:

On 01/16/2015 02:42 PM, khalid.el-darymli wrote:

We were using only one Tx channel with the Subdev Spec in the USRP Sink is set 
to A:AB 

 

Could the failure be due to that the other (idle) Tx channel is left open 
circuit (i.e., not terminated by 50 ohms)?

That seems quite unlikely.  These aren't precious princess RF power 
transistors, but reasonably-robust differential-to-unbalanced drivers.  I'd
  be very surprised if they couldn't handle an open-circuit condition. 








 

Khalid

 

 

On Fri, Jan 16, 2015 at 3:41 PM, Marcus D. Leech mle...@ripnet.com 
mailto:mle...@ripnet.com  wrote:

On 01/16/2015 02:08 PM, khalid.el-darymli wrote:

Hi All, 

 

Just to update you in case somebody else comes across this problem. Following 
Mike's advice, we replaced the LFTX daughterboard with a new one. We're getting 
now 1 V p-p. This is around 4 dBm.

 

Thanks very much for your help.

 

Best regards,

Khalid

 

 

Interesting.  The driver chip that's used, as a unity-gain 
differential-to-single-ended driver, is, according to the datasheets, pretty 
robust.  So, it would
  be interesting to know exactly what the failure mode is. 







 

 

On Tue, Jan 6, 2015 at 2:38 PM, Michael Rahaim mrah...@bu.edu 
mailto:mrah...@bu.edu  wrote:

Hi Khalid, 

 

I had a similar issue with an LFTX that I had been working with for about two 
years. I actually had two boards running on separate USRP2's and both were 
working fine for quite a while, but I recently noticed that one had a 
drastically lower output range. I ended up replacing the LFTX and all is 
working well now, so I'm assuming it was a hardware issue that came up at some 
point. 

 

I didn't take the time to look for the problem, but I figured I'd share this 
info since what you're seeing might be a hardware issue rather than something 
you can resolve with settings.

 

-Mike

 

On Tue, Jan 6, 2015 at 12:59 PM, khalid.el-darymli khalid.el-dary...@mun.ca 
mailto:khalid.el-dary...@mun.ca  wrote:


 Output power is determined largely by baseband signal magnitude in that case.

Yes, I understand. And I noticed that for baseband signal with an amplitude  
1,  the pass-band signal gets clipped off. So I assume that an amplitude of 1 
for the baseband signal should deliver the maximum output power (for the 
pass-band signal).

My question was, what is the maximum power one can get for the pass-band signal 
output from LFTX? In your earlier reply, you said it is around +7dBm, am I 
getting this right? In my case, for a baseband amplitude of around 1, I am only 
getting -28.13dBm, much less than what you said, I am not sure, why?

Thanks,

Khalid

 

On Tue, Jan 6, 2015 at 1:56 PM, Marcus D. Leech mle...@ripnet.com 
mailto:mle...@ripnet.com  wrote:

Thanks Marcus for your reply.

 Probably somewhere in the neighborhood of +7dBm, maybe a little more.

 The LF/BASIC series have *no* gain in either path, so you're just looked
at buffered ADC ouput.

So, ~ +7dBm is the max output power I supposed to get from the LFTX 
daughterboard? How do I get that?

Since I am only getting -28.13 dBm, does that mean I have some issue with my 
LFTX daughterboard?

 

Khalid

 

Output power is determined largely by baseband signal magnitude in that case. 













Message: 2
Date: Tue, 6 Jan 2015 10:13:45 -0330
From: khalid.el-darymli khalid.el-dary...@mun.ca 
mailto:khalid.el-dary...@mun.ca 
To: Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org  
discuss-gnuradio@gnu.org mailto:discuss-gnuradio@gnu.org 
Subject: [Discuss-gnuradio] Max Output Power from the LFTX
daughterboard
Message-ID:
CACdmG=zCHATiwrtv=wBVLwG0_ 

5GQr0y=wksequrcajrtuv5...@mail.gmail.com 
mailto:wksequrcajrtuv5...@mail.gmail.com 
Content-Type: text/plain; charset=utf-8

Hi,

What is the maximum output power from the LFTX daughterboard when used with
the USRP N200?

According to this datasheet [1], the N200 with the WBX daughterbaord
provide an output power of 15 dBm. However, when using the LFTX

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

Good to know! In my case it was a pulse issue, and removing parts of this stuff 
fixed it, but who know what else may happen :)

 

At least now gr-dsd works, I can decode DMR transmissions with it in relative 
good quality, and also other audio applications should cause no trouble. Not 
that I do very much audio stuff, for receiving audio usually I use Windows / 
HDSDR. 

 

And I only can second your “thanks guys” message. Great work, gnuradio is a 
fantastic tool that opens whole new worlds! 

 

Ralph.

 

From: Remington Furman [mailto:remicl...@gmail.com] 
Sent: Friday, January 16, 2015 5:42 AM
To: Ralph A. Schmid, dk5ras
Cc: Marcus D. Leech; Tom Rondeau; Christopher Hallinan; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy 
audio

 

Ok, here are the contents of my ~/.gnuradio/config.conf:

[audio_alsa]
default_input_device = default
default_output_device = default
#period_time = 0.010  # in seconds (default)
period_time = 0.100  # in seconds
nperiods = 4 # total buffering = period_time * nperiods
#verbose = false

verbose = true


The actual change I made was to increase audio_alsa/period_time from 0.010 to 
0.100.  Play around with it until it works on your system.  My only guess is 
that perhaps the default ALSA buffer sizes are small enough that they are often 
consumed by ALSA before GnuRadio will fill them.

Cheers,

-Remington

PS. Thanks to everyone for your fantastic work on building this whole system 
and answering all the questions on the list.  I've been learning a ton reading 
this over the last year, and I appreciate it.  I'll try not to be so shy next 
time I know something that might be useful to others.

 

On Thu, Jan 15, 2015 at 1:38 PM, Remington Furman remicl...@gmail.com 
mailto:remicl...@gmail.com  wrote:

Hi,

 

I had this same aU problem a few months ago on Linux Mint, but was able to 
resolve it by editing the default ALSA settings in ~/.gnuradio/config.conf .

 

I will send detailed notes on the exact fix I made when I get home, but I just 
found this page also describing the fix:

http://www.funwithelectronics.com/?id=167

(Increase 'nperiods' under [audio_alsa])

 

After the config change ALSA audio worked with my own WBFM flowgraph and all 
the sample flowgraphs that were previously broken for me.

 

Apologies for not sending something to the list when I found the problem.  I 
knew it would have saved folks from some hair pulling.

 

Hope this helps,

-Remington

W7REM

 

On Thu, Jan 15, 2015 at 4:47 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx 
mailto:ra...@schmid.xxx  wrote:

No chance, I do not get any stable audio performance, I assume the Kubuntu
sound system is defective somehow. It is not about sampling rates, the pitch
is correct, just choppy. When calling the dial tone script repeatedly,
sometimes it works, sometimes it causes garbled sounds, then again it works,
with one attempt after another without doing anything else.

Update: Right now I was so brave to uninstall some pulse library stuff, and
what should I say, the stuttering is gone, DMR is not decoding 100% fine,
but I assume now it is a matter of fine tuning the receiver chain and
decoder, audio itself looks OK. Thank you very much for putting me into the
right direction! How can find such a load of BS its way into an official and
widely used Linux distribution?!

Ralph.


 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
 mailto:schmid@gnu.org 
 [mailto:discuss-gnuradio-bounces+ralph 
 mailto:discuss-gnuradio-bounces%2Bralph =schmid@gnu.org 
 mailto:schmid@gnu.org ] On Behalf Of
 Ralph A. Schmid, dk5ras
 Sent: Thursday, January 15, 2015 8:14 AM
 To: 'Marcus D. Leech'; 'Tom Rondeau'
 Cc: 'GNURadio Discussion List'
 Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has
choppy
 audio


 Hi Marcus,

  If you use plughw:0,0 as the hardware designator, it's often willing
  to do resampling to the actual hardware rate.

 Yep, I will try this later. Made my tests this morning on my way to work
by
 train, now it has to wait until lunch break :)

 Ralph.


 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

No chance, I do not get any stable audio performance, I assume the Kubuntu
sound system is defective somehow. It is not about sampling rates, the pitch
is correct, just choppy. When calling the dial tone script repeatedly,
sometimes it works, sometimes it causes garbled sounds, then again it works,
with one attempt after another without doing anything else. 

Update: Right now I was so brave to uninstall some pulse library stuff, and
what should I say, the stuttering is gone, DMR is not decoding 100% fine,
but I assume now it is a matter of fine tuning the receiver chain and
decoder, audio itself looks OK. Thank you very much for putting me into the
right direction! How can find such a load of BS its way into an official and
widely used Linux distribution?! 

Ralph.


 -Original Message-
 From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
 [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
 Ralph A. Schmid, dk5ras
 Sent: Thursday, January 15, 2015 8:14 AM
 To: 'Marcus D. Leech'; 'Tom Rondeau'
 Cc: 'GNURadio Discussion List'
 Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has
choppy
 audio
 
 Hi Marcus,
 
  If you use plughw:0,0 as the hardware designator, it's often willing
  to do resampling to the actual hardware rate.
 
 Yep, I will try this later. Made my tests this morning on my way to work
by
 train, now it has to wait until lunch break :)
 
 Ralph.
 
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

One could just try dial_tone.py example.  That will exercise the audio 
subsystem.

Output is some garbled noise, and

python$ python dial_tone.py 
INFO: Audio sink arch: alsa
aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU

So my audio stuff is defective, good to know :)

For alsa, in the device field in the audio sink, try something like
hw:0,0  or plughw:0,0

Seems to be alsa already...hmm...so this comes later.

Ralph.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

Only 44100 works, giving a clear dial tone. As DSD has fixed sampling rate 8k, 
a resampler should do the trick. Things could be so easy :) I hate this audio 
stuff...

Ralph.

-Original Message-
From: Marcus D. Leech [mailto:mle...@ripnet.com] 
Sent: Thursday, January 15, 2015 06:41
To: Ralph A. Schmid, dk5ras; 'Tom Rondeau'
Cc: 'GNURadio Discussion List'
Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy 
audio

On 01/15/2015 12:29 AM, Ralph A. Schmid, dk5ras wrote:
 One could just try dial_tone.py example.  That will exercise the audio 
 subsystem.
 Output is some garbled noise, and

 python$ python dial_tone.py
 INFO: Audio sink arch: alsa
 aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU

 So my audio stuff is defective, good to know :)

 For alsa, in the device field in the audio sink, try something like
 hw:0,0  or plughw:0,0
 Seems to be alsa already...hmm...so this comes later.

 Ralph.


It may just be that your audio-subsystem doesn't actually support the 
sample-rate that the graph is configuring it for.

Here's the --help for dial_tone.py

Usage: dial_tone.py [options]

Options:
   -h, --helpshow this help message and exit
   -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT
 pcm output device name.  E.g., hw:0,0 or /dev/dsp
   -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE
 set sample rate to RATE (48000)



Looks like the default is 48e3

Try other rates, like 44.1e3  or 32e3





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

Hi,

How would I change this, skipping PulseAudio and using Alsa? The only audio 
application I try with gnuradio at the moment behaves similar here. I try to 
decode DMR, and I get choppy audio although everything should be OK. I blamed 
gr-dsd, but maybe it is a common issue. Will have to try a simple FM RX to 
verify :)

Ralph.

You almost certainly have a sample-rate mismatch somewhere in the 
flow--likely, your audio sink is configured for a sample-rate other than what
the hardware (or PulseAudio) can support.  Sometimes also, PulseAudio gets 
into trouble and gets all under-runny.   I'd go with Alsa direct if it
were my problem, and skip Pulse entirely.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

It may just be that your audio-subsystem doesn't actually support the 
sample-rate that the graph is configuring it for.

Maybe. At least the test audio from the audio control panel is clear.

Here's the --help for dial_tone.py

Usage: dial_tone.py [options]

Options:
   -h, --helpshow this help message and exit
  -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT
pcm output device name.  E.g., hw:0,0 or /dev/dsp
   -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE
 set sample rate to RATE (48000)



Looks like the default is 48e3

Try other rates, like 44.1e3  or 32e3

I will test it and tell you :)

Ralph.




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio

[Ralph A. Schmid, dk5ras]

Hi Marcus,

 If you use plughw:0,0 as the hardware designator, it's often willing to do
 resampling to the actual hardware rate.

Yep, I will try this later. Made my tests this morning on my way to work by 
train, now it has to wait until lunch break :)

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC

[Ralph A. Schmid, dk5ras]

The latency is an issue when action of one side is dependent on reaction of
the other side. Usually there are narrow time limits that have to be
considered, and the time an action travels over USB or Ethernet may simply
be to long. The other thing may be jitter, many protocols do not like
variations in the timing, but those are more or less normal for USB or
Ethernet. The closest binding between hardware and controller is doing it
all in the FPGA, what could be considered as a real time system. 


Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Mostafa Alizadeh
Sent: Tuesday, January 13, 2015 2:44 PM
To: Jeff Long
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC

 

 

Yeah I have had a look at Bluetooth PHY. The hop rate of Bluetooth in paging
substate increases as 3200 hop/sec too. So you mean the N210 USRP can't
support 1600 (or 3200) hop/sec? 

What do you mean by latency? Is that the latency of the USB or Ethernet?

Jeff, please clarify your stance. Why the latency problem doesn't matter
X-series USRP? 

 

Best, 

Mostafa

 

 

On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long willco...@gmail.com
mailto:willco...@gmail.com  wrote:

On 01/12/2015 01:07 PM, Mostafa Alizadeh wrote:

Hi Jeff,

What is your reason for saying: Latency and tuning of the N210 device
isn't appropriate???


I should have said that, with either USB or Ethernet, and with a
non-real-time O/S, the latency to too great. Hop rate is generally 1600
hops/sec. Take a look at the Bluetooth physical layer spec for more info.


Best,
Mostafa

On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.com
mailto:willco...@gmail.com 
mailto:willco...@gmail.com mailto:willco...@gmail.com  wrote:

On 01/10/2015 02:46 PM, vaibhav kulkarni wrote:

Hi All,

I am searching for an implementation of a complete Bluetooth
stack on
GRC 3.7 ( Including the Bluetooth Transmitter and Receiver)
preferably
working with USRP N210. So far I got this gr-Bluetooth,
Bluetooth for


You could build one in the FPGA of an X-series box. Latency and
tuning requirements exceed what you can do with a N210.

GNU Radio (http://gr-bluetooth.__sourceforge.net/
http://sourceforge.net/ 
http://gr-bluetooth.sourceforge.net/), However it is not a
complete stack and I guess it doesent include the Bluetooth
Transmitter.
I built it and checked but couldn't find one. Can you suggest any
existing implementation of complete Bluetooth stack ?
Any Help is appreciated.

Regards,
Vaibhav


_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
mailto:Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



_
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
mailto:Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




--
***
Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/
***

 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





 

-- 

***

Department of Electrical Engineering

Aboureyhan Building

MMWCL LAB

Amirkabir University Of Technology

Tehran

IRAN

Tel: +98 (919) 158-7730

LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411

Homepage: http://ele.aut.ac.ir/~alizadeh/

***

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CentOS pymbombs install

[Ralph A. Schmid, dk5ras]

You did not forget a „sudo ldconfig“? Sometimes the simple things… :)

 

Ralph. 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Richard 
Bell
Sent: Wednesday, January 7, 2015 2:10 AM
To: Tom Rondeau
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] CentOS pymbombs install

 

Well, completed a sudo make install for pygobject-2.27.91 with no errors. (I 
ignored the fail of make test and pushed on to sudo make install)

Unfortunately now, and this is what I feared, when I run ./pybombs install 
gnuradio, it can't tell that pygobjects is already installed. I know I can tell 
pybombs to assume pygobjects is installed, but I'm scared to death of what will 
happen later when I try and open gnuradio I get a big error message. 

Rich

 

On Tue, Jan 6, 2015 at 4:31 PM, Richard Bell richard.be...@gmail.com 
mailto:richard.be...@gmail.com  wrote:

This link fixed the previous error, at least getting me through 'make':

http://permalink.gmane.org/gmane.linux.scientific.user/4096

but when I run 'make check', I have the following error:

TEST_FILES=test_everything.py test_gi.py test_gdbus.py test_overrides.py 
PYTHONPATH=..:../tests:${PYTHONPATH:+:$PYTHONPATH} 
LD_LIBRARY_PATH=./.libs:$LD_LIBRARY_PATH GI_TYPELIB_PATH=.:$GI_TYPELIB_PATH 
XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share /usr/bin/dbus-launch  /usr/bin/python 
./runtests.py
Traceback (most recent call last):
  File ./runtests.py, line 24, in module
suite = loader.loadTestsFromNames(names)
  File /usr/lib64/python2.6/unittest.py, line 612, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
  File /usr/lib64/python2.6/unittest.py, line 575, in loadTestsFromName
module = __import__('.'.join(parts_copy))
  File 
/home/tsvcis/Documents/pybombs/src/pygobject-2.27.91/tests/test_gdbus.py, 
line 11, in module
from gi.repository import Gio
  File ../gi/importer.py, line 76, in load_module
dynamic_module._load()
  File ../gi/module.py, line 242, in _load
overrides_modules = __import__('gi.overrides', fromlist=[self._namespace])
  File ../gi/overrides/Gio.py, line 98, in module
Settings = override(Settings)
  File ../gi/overrides/__init__.py, line 63, in override
registry.register(type_)
  File ../gi/overrides/__init__.py, line 38, in register
self[override_class] = override_class
  File ../gi/overrides/__init__.py, line 28, in __setitem__
assert g_type != gobject.TYPE_NONE
AssertionError
make[2]: *** [check-local] Error 1
make[2]: Leaving directory 
`/home/tsvcis/Documents/pybombs/src/pygobject-2.27.91/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory 
`/home/tsvcis/Documents/pybombs/src/pygobject-2.27.91/tests'
make: *** [check-recursive] Error 1

Still digging...

 

On Tue, Jan 6, 2015 at 3:51 PM, Richard Bell richard.be...@gmail.com 
mailto:richard.be...@gmail.com  wrote:

Sorry I forgot to mention the version, it is CentOS 6.6. 

pygobject is my problem. I'm still unable to get it installed correctly. I 
downloaded both version 2.27.91 and 2.28 from the ftp site I posted and tried a 
manual install, but they fail with the following error:

In file included from /usr/include/python2.6/Python.h:125,
 from ../glib/pyglib.h:25,
 from gobjectmodule.c:28:
/usr/include/python2.6/modsupport.h:136: error: expected ')' before 'uid'
/usr/include/python2.6/modsupport.h:137: error: expected ')' before 'gid'
/usr/include/python2.6/modsupport.h:139: error: expected declaration specifiers 
or '...' before 'uid_t'
/usr/include/python2.6/modsupport.h:140: error: expected declaration specifiers 
or '...' before 'gid_t'
make[2]: *** [_gobject_la-gobjectmodule.lo] Error 1
make[2]: Leaving directory 
`/home/tsvcis/Documents/pybombs/src/pygobject-2.27.91/gobject'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/tsvcis/Documents/pybombs/src/pygobject-2.27.91'
make: *** [all] Error 2

I'm posting questions on the CentOS forums as well, but no response yet. Tom, 
have you run into this problem on a CentOS6 system? If not, I wonder why mine 
is different...

Rich

 

On Tue, Jan 6, 2015 at 3:46 PM, Tom Rondeau t...@trondeau.com 
mailto:t...@trondeau.com  wrote:

On Tue, Jan 6, 2015 at 4:43 PM, Richard Bell richard.be...@gmail.com 
mailto:richard.be...@gmail.com  wrote:

Thanks, I did try 'sudo yum clean all'. I've tried a lot of things, this is the 
fifth or 6th time I've tried installing gnuradio on this CentOS laptop. 

 

If I follow the link to the ftp site its looking for the tarball in, which is 
here:

http://ftp.acc.umu.se/pub/GNOME/sources/pygobject/2.27/

There seems to be no more tarball with a 'patched' modifier at the end of it. 
Will gnuradio be ok if I install pygobject-2.27.91.tar.gz, or a newer version 
perhaps? I just don't know enough about these packages and the inner workings 
of gnuradio.

Rich

 

Rich,

 

Is this CentOS 7? If so, 

Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

[Ralph A. Schmid, dk5ras]

The fix worked out :) Thanks a lot!

Ralph.

-Original Message-
From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of
Ralph A. Schmid, dk5ras
Sent: Tuesday, December 30, 2014 17:01
To: 'Johnathan Corgan'; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

Waaah - and I was so sure that the problem sits in front of the PC :) Well,
at least I had a task during a longer and boring trip by train...

OK, so I will wait for the next commit. Thank you for all the efforts!!

Ralph.

-Original Message-
From: Johnathan Corgan [mailto:johnat...@corganlabs.com]
Sent: Tuesday, December 30, 2014 16:26
To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

 Old Signed by an unverified key: 2014-12-30 at 16:25:35

On 12/30/2014 06:37 AM, Ralph A. Schmid, dk5ras wrote:

 I installed gnuradio master from source on a Kubuntu 14.04 64 bit 
 system, and it appears that all wxgui stuff does not work. What may be 
 the issue here? Gnuradio and uhd build without error, without missing 
 features, but for example uhd_fft gives this output:

This is indeed a bug, an unfortunate side effect of a semi-last minute
commit before the 3.7.6 release.

Fortunately, it's a one line bug fix I'll be committing to the repository
shortly.

--
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services http://corganlabs.com

* Johnathan Corgan johnat...@corganlabs.com
* 0x671DA2F7 - Unverified


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] uhd_fft and other wx stuff does not work...

[Ralph A. Schmid, dk5ras]

Hi,

 

I installed gnuradio master from source on a Kubuntu 14.04 64 bit system,
and it appears that all wxgui stuff does not work. What may be the issue
here? Gnuradio and uhd build without error, without missing features, but
for example uhd_fft gives this output:

 

ras@ubuntu:~/gnuradio/build$ uhd_fft 

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-42-g8c87a524

 

-- Operating over USB 3.

-- Initialize CODEC control...

-- Initialize Radio control...

-- Performing register loopback test... pass

-- Performing register loopback test... pass

-- Performing CODEC loopback test... pass

-- Performing CODEC loopback test... pass

-- Asking for clock rate 32.00 MHz... 

-- Actually got clock rate 32.00 MHz.

-- Performing timer loopback test... pass

-- Performing timer loopback test... pass

-- Setting master clock rate selection to 'automatic'.

Using Volk machine: avx_64_mmx_orc

Traceback (most recent call last):

  File /usr/local/bin/uhd_fft, line 349, in module

main ()

  File /usr/local/bin/uhd_fft, line 341, in main

app = stdgui2.stdapp(app_top_block, UHD FFT, nstatus=1)

  File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py,
line 46, in __init__

wx.App.__init__ (self, redirect=False)

  File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py,
line 7981, in __init__

self._BootstrapApp()

  File /usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py,
line 7555, in _BootstrapApp

return _core_.PyApp__BootstrapApp(*args, **kwargs)

 File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py,
line 49, in OnInit

frame = stdframe (self.top_block_maker, self.title, self._nstatus)

  File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py,
line 76, in __init__

self.panel = stdpanel (self, self, top_block_maker)

  File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py,
line 98, in __init__

self.top_block = top_block_maker (frame, self, vbox, sys.argv)

  File /usr/local/bin/uhd_fft, line 121, in __init__

fft_rate=options.fft_rate)

  File
/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/fftsink_gl.py, line
132, in __init__

self.wxgui_connect(self, fft, sink)

  File /usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/common.py,
line 51, in wxgui_connect

copy = blocks.copy(self._hb.input_signature().sizeof_stream_item(0))

  File /usr/local/lib/python2.7/dist-packages/gnuradio/gr/hier_block2.py,
line 93, in __getattr__

return getattr(self._impl, name)

AttributeError: 'hier_block2_sptr' object has no attribute '_hb'

^C

ras@ubuntu:~/gnuradio/build$

 

 

I am not a coder, so at the moment I am somehow out of business. Doing this
all new from scratch made no difference, all prereqs seem fulfilled, and
after two hours of fiddling and poking around the only consequence is to ask
here J

 

Thank you for any hint!

 

Ralph.

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

[Ralph A. Schmid, dk5ras]

Waaah - and I was so sure that the problem sits in front of the PC :) Well,
at least I had a task during a longer and boring trip by train...

OK, so I will wait for the next commit. Thank you for all the efforts!!

Ralph.

-Original Message-
From: Johnathan Corgan [mailto:johnat...@corganlabs.com] 
Sent: Tuesday, December 30, 2014 16:26
To: Ralph A. Schmid, dk5ras; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] uhd_fft and other wx stuff does not work...

* PGP Signed by an unverified key: 2014-12-30 at 16:25:35

On 12/30/2014 06:37 AM, Ralph A. Schmid, dk5ras wrote:

 I installed gnuradio master from source on a Kubuntu 14.04 64 bit 
 system, and it appears that all wxgui stuff does not work. What may be 
 the issue here? Gnuradio and uhd build without error, without missing 
 features, but for example uhd_fft gives this output:

This is indeed a bug, an unfortunate side effect of a semi-last minute
commit before the 3.7.6 release.

Fortunately, it's a one line bug fix I'll be committing to the repository
shortly.

--
Johnathan Corgan, Corgan Labs
SDR/DSP Training and Consulting Services http://corganlabs.com

* Johnathan Corgan johnat...@corganlabs.com
* 0x671DA2F7 - Unverified


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] build fails

[Ralph A. Schmid, dk5ras]

Hi all,

 

With latest sources (after a git pull) the build fails. Kubuntu 14.04 32
bit, and a new gnuradio folder did not change things. Here the output:

[  5%] Building C object
volk/lib/CMakeFiles/volk.dir/volk_machine_avx_32_mmx_orc.c.o

In file included from
/home/ras/gnuradio/build/volk/lib/volk_machine_avx_32_mmx_orc.c:65:0:

/home/ras/gnuradio/volk/kernels/volk/volk_64u_popcntpuppet_64u.h: In
function 'volk_64u_popcntpuppet_64u_a_sse4_2':

/home/ras/gnuradio/volk/kernels/volk/volk_64u_popcntpuppet_64u.h:43:9:
warning: implicit declaration of function 'volk_64u_popcnt_a_sse4_2'
[-Wimplicit-function-declaration]

 volk_64u_popcnt_a_sse4_2(outVector+ii, num_points );

 ^

In file included from
/home/ras/gnuradio/build/volk/lib/volk_machine_avx_32_mmx_orc.c:149:0:

/home/ras/gnuradio/volk/kernels/volk/volk_32f_log2_32f.h: At top level:

/home/ras/gnuradio/volk/kernels/volk/volk_32f_log2_32f.h:64:0: warning:
LOG_POLY_DEGREE redefined [enabled by default]

#define LOG_POLY_DEGREE 6

^

In file included from
/home/ras/gnuradio/build/volk/lib/volk_machine_avx_32_mmx_orc.c:140:0:

/home/ras/gnuradio/volk/kernels/volk/volk_32f_x2_pow_32f.h:35:0: note: this
is the location of the previous definition

#define LOG_POLY_DEGREE 3

^

Linking C shared library libvolk.so

[  5%] Built target volk

Scanning dependencies of target test_all

[  5%] Building CXX object volk/lib/CMakeFiles/test_all.dir/testqa.cc.o

[  5%] Building CXX object volk/lib/CMakeFiles/test_all.dir/qa_utils.cc.o

Linking CXX executable test_all

libvolk.so.0.0.0: undefined reference to `volk_64u_popcnt_a_sse4_2'

collect2: error: ld returned 1 exit status

make[2]: *** [volk/lib/test_all] Error 1

make[1]: *** [volk/lib/CMakeFiles/test_all.dir/all] Error 2

make: *** [all] Error 2

ras@ubuntu:~/gnuradio/build$

 

 

 

Ralph.

 

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] HELP: USRP1+WBXv3 Overflow

[Ralph A. Schmid, dk5ras]

An antenna made for 400-1000 MHz is not exactly the right thing to receive 
88-108 MHz :) Just use a piece of wire, length about 75cm, this should be 
enough for first tests.

 

Ralph.

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org 
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Thesis 
2015
Sent: Tuesday, December 16, 2014 6:24 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] HELP: USRP1+WBXv3 Overflow

 

Good day,

 

We are beginners using the USRP1 with WBX v.3 50-2200 daughterboard and GNU 
radio Companion version 3.7.5.1 with UHD_003.008.000-18-g864f84b5 installed on 
Ubuntu 14.04 LTS operating system. Our goal in using these is to create an SDR 
WBFM receiver.

We have followed what was done in the video posted by the ettus research 
(http://www.ettus.com/kb/detail/sdr-for-beginners-building-an-fm-receiver-with-the-usrp-and-gnu-radio)
 but have encountered some problems. As we ran the GRC file, both the FFT plot 
and Scope plot appeared but all we could hear are static sounds together with 
the script shown below:

 

Executing: /media/thesis/Data/Downloads/Thesis/FM Reciever using 
GRC/fm_example.py

 

linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-18-g864f84b5

 

Using Volk machine: sse4_1_64_orc

-- Opening a USRP1 device...

-- Using FPGA clock rate of 64.00MHz...

 

UHD Warning:

The hardware does not support the requested RX sample rate:

Target sample rate: 5.00 MSps

Actual sample rate: 5.33 MSps

-- Tune Request: 88.10 MHz

--   The RF LO does not support the requested frequency:

-- Requested LO Frequency: 88.10 MHz

-- RF LO Result: 88.099634 MHz

--   Attempted to use the DSP to reach the requested frequency:

-- Desired DSP Frequency: -0.000366 MHz

-- DSP Result: -0.000366 MHz

--   Successfully tuned to 88.10 MHz

-- 

INFO: Audio sink arch: alsa

OO

 Done

 

 

As we are doing all the simulations, we did not use any antenna yet. However, 
we are waiting for the arrival of the antenna LP0410 400 MHz to 1 GHz Log 
Periodic PCB directional antenna, at 5-6dBi Gain. We have purchased this 
antenna for it is capable to receive signals from 88.1MHz to 107.9MHz 
(frequency range of all the FM stations that we are about to receive).

 

-SKA15-

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [USRP-users] How to correct for the drift in an (FMCW) Rx signal?

[Ralph A. Schmid, dk5ras]

In my job we have learned that lesson and fitted on all our DSP systems (you 
could call them direct digitizing SDRs, although we do not radio stuff) a cheap 
I2C temperature sensor. No big thing by means of software, costs and PCB space, 
but already proved being very useful. Could be considered for future products…

 

Ralph.

 

From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Marcus D. Leech via USRP-users
Sent: Tuesday, December 2, 2014 4:11 PM
To: khalid.el-darymli
Cc: usrp-us...@lists.ettus.com; Discuss-gnuradio@gnu.org
Subject: Re: [USRP-users] How to correct for the drift in an (FMCW) Rx signal?

 

On 12/02/2014 10:06 AM, khalid.el-darymli wrote: 

Hi Marcus,

Is there a temperature sensor on-board the N200 unit? If not, does it support 
installing any such sensor?

Thanks.

No, and no.

But there are a tonne of USB-based temperature sensors out there.  Google is 
your friend, etc.






 

Best regards,
Khalid

 

On Fri, Nov 28, 2014 at 5:44 PM, Marcus D. Leech mle...@ripnet.com 
mailto:mle...@ripnet.com  wrote:



On 11/28/2014 03:41 PM, khalid.el-darymli wrote: 

 





Back to my original question, what should I do to correct for this?




Thanks in advance.




Best,
Khalid

 

Khalid:

Thanks very much for the very-extensive data.  My main concern, as one of the 
Ettus support team, was that there was something wrong with
  the hardware, but the magnitude of both the apparent phase and magnitude 
drift is entirely consistent with analog-hardware temperature
  effects, unrelated to clock stability, etc.

Coax cables, for example, will change their loss characteristics and *effective 
length* with temperature, so with precise hardware like USRPs, it's
  easy to see these effects.

FMCW radar isn't my area of expertise, so hopefully others can comment on 
RX-processing strategies to deal with this, as it *must* also be a problem
  with non-SDR FMCW radar implementations.









 

On Fri, Nov 28, 2014 at 12:08 PM, mle...@ripnet.com mailto:mle...@ripnet.com 
 wrote:



What is the magnitude of the frequency drift?

What is the magnitude of the gain drift?

What are you measuring backscatter *from*?

 

 

 

On 2014-11-28 10:14, khalid.el-darymli via USRP-users wrote:

Hi,

Given a set of synced (i.e., using external GPS REF/PPS), time-commanded and 
calibrated (i.e., through compensating for the phase/mag offset between digital 
Tx chirp prior to transmission and ADC'ed Rx signals) N200 devices with 
LFTX/LFRX daughterboards, that work with coherent LFMCW chirps, I am still 
seeing a tiny drift (both in the magnitude and frequency) of the calibrated  
back-scatter Rx chirp received at time t1 when compared to an Rx chirp received 
at an earlier time t0. 

The more the N200 device runs (e.g., 5 hours), the greater the drift is. 
Obviously, this drift is pertinent to both the DAC and ADCs and the GPS 
referenced clocks of the N200 devices.


My questions are:

1- Why I still see such drift although my devices are synced with an external 
GPS? and how do I correct for it?


2- Can the PLL Carrier Tracking block in GRC be used to track and correct for 
such a drift? If so, how do I set the max/min freq inputs for this block?

3- Can AGC2 or AGC3 block be useful in this regard? If so, are there any 
examples to explain how the input parameters of these blocks can be set up?



Thanks.

Best regards,

Khalid

 

___
USRP-users mailing list
usrp-us...@lists.ettus.com mailto:usrp-us...@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

 

 

 






-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

 

 

 






-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] EnOcean?

[Ralph A. Schmid, dk5ras]

Hi,

are there already projects out in the wild to use EnOcean  ISO/IEC
14543-3-10 protocol with gnuradio?

Ralph.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] pybombs?

[Ralph A. Schmid, dk5ras]

Hi,

I wanted to do a quick and dirty gnuradio install with pybombs, and all
looked fine, built uhd and gnuradio and what else is included in the
default, but it seems it did not add any paths and such. Is this possible,
do I have to take additional measures to have the executables reachable in a
shell, or went something wrong?

The early pybombs seemed to me a total mess, so I did not touch it for a
very long time, now I thought it should be somehow grown up and just work :)
Guess the problem sits in front of the PC...

Ralph.


--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio