Thanks Ron. I think this is narrowing down the issue. When I ran that
command, I did not get any entries containing libgnuradio back. When I run
the same command on a working Ubuntu 14.04 install, I get many of those
entries.
I added the file you mentioned with the path to the base install gnuradi
Thanks everyone for your support !
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi Olivier,
thanks for the reply! Ah, I was confusing UAT and ADS-B then, sorry!
You should really be sending this email to the discuss-gnuradio@gnu.org
list - with the graphs attached, it's much easier for the others to help!
Just a question: the time_dom.png indeed looks like there's something
Everyone's tips here are great. A minor clarification:
UAT is not Mode S. UAT is 978MHz FSK at 1.041667Ms/s. Mode S (and thus,
ADS-B) is 1090MHz PPM OOK at 1Ms/s. I'm unaware of any existing Gnuradio
UAT implementations, although there are a couple of prototype scratch-built
decoders (https://gith
You probably don't have a path to the GNU Radio libraries for the
linker. Try this command:
sudo ldconfig -v | grep gnuradio
The way I like to resolve this is to add a file to /etc/ld.so.conf.d
called gnuradio.conf with the path to the libraries. On my setup, it
contains:
/opt/gnuradio-3.7.
What release / branch of GNU Radio are you using?
Cheers,
Ben
On Thu, May 26, 2016 at 2:41 PM, Richard Bell
wrote:
> I tried making a fresh OOT module and I get the same problem. So it seems
> to be connected to gr_modtool.
>
> On Thu, May 26, 2016 at 11:05 AM, Richard Bell
> wrote:
>
>> Yeah
I tried making a fresh OOT module and I get the same problem. So it seems
to be connected to gr_modtool.
On Thu, May 26, 2016 at 11:05 AM, Richard Bell
wrote:
> Yeah I've blown away build a few times now. I tried this to a few
> different OOT modules as well. They all produce the same output I'v
On Thu, 2016-05-26 at 11:04 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Thu, 26 May 2016 11:03:55 -0400
> From: Olivier Goyette
> Hi everyone,
>
> I'm currently doing an internship at school and i'm working with USRP N210
> and GNUradio. It's been a month since I began working with t
Yeah I've blown away build a few times now. I tried this to a few different
OOT modules as well. They all produce the same output I've posted. Weird
how GNU Radio istelf had no cmake issues but child OOT modules do.
On Thu, May 26, 2016 at 10:52 AM, Ben Hilburn wrote:
> Pretty strange. Stupid qu
Pretty strange. Stupid question: I assume you have tried blowing away the
build directory and giving it another go? Wondering if this is the CMake
cache mucking you up.
This might be worth a try?
https://github.com/dmlc/mxnet/issues/1131
Cheers,
Ben
On Thu, May 26, 2016 at 12:47 PM, Richard Bell
On Thu, May 26, 2016 at 12:06 PM, Marcus Müller
wrote:
> That's pretty much what I wanted to stress:
>
> Dear SangHyuk,
>
> as you've been told you multiple times:
> > Martin, 25. March 2016:
> > you're not using the more recent OFDM blocks, so you won't get a lot of
> > support here -- I recomme
Then it spit out this error message:
CMake Error at
/usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:203
(CMAKE_PARSE_ARGUMENTS):
Unknown CMake command "CMAKE_PARSE_ARGUMENTS".
Call Stack (most recent call first):
/usr/share/cmake-3.5/Modules/FindPkgConfig.cmake:52
(find_p
It seems to be looking into the grprefix directory, this is what I get from
ccmake:
CMAKE_BUILD_TYPE
*
CMAKE_INSTALL_PREFIX
*/usr/local
ENABLE_DOXYGEN
*ON
GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Documents/grprefix/lib/libgnuradio-pmt.so
GNURADIO_RUNTIME_LIBRARIES_gnu
*/home/rbell/Document
A bias in the dither algorithm could explain that, which is why turning
off dither clears up the problem. The drifting-out-of-lock problem is
due to charge-pump current settings being too low in some cases.
On 2016-05-26 11:47, Juha Vierinen wrote:
> Would either of these issues in the rtlsdr d
That's pretty much what I wanted to stress:
Dear SangHyuk,
as you've been told you multiple times:
> Martin, 25. March 2016:
> you're not using the more recent OFDM blocks, so you won't get a lot of
> support here -- I recommend moving to the tx_ofdm and rx_ofdm stuff
> instead.
> I, 10. April 20
Hi Olivier!
Nice to meet you.
So, first off, a hint: GRC has a "screen capture" menu / toolbar button
that lets you just export your GRC canvas, so you don't have to make a
screenshot of your whole dual-desktop screen (by the way, cropping that
would have worked, too ;) ).
UAT == ADS-B transmitte
Also, that block is going away soon.
I recommend looking at the carrier allocator block instead.
M
On 05/25/2016 10:20 PM, SangHyuk Kim wrote:
> Dear all,
>
> Sorry, my source code was wrong.
>
> There is only one /d_bit_offset += d_nbits;
>
> /
> /Thanks .
> /
>
> 2016-05-26 10:38 GMT+09:00
Would either of these issues in the rtlsdr driver consistently tune the two
dongles on slightly different frequencies, even if you ask them to tune to
exactly the same frequency? This is what the problem seems to be.
juha
On Wed, May 25, 2016 at 10:35 AM, wrote:
> There are a couple of issues w
Hi Richard -
Can you try peeking into the CMAKE madness to see what paths it selected
for those two gnuradio libraries? I've found the curses-based CMAKE UI to
be pretty helpful in seeing what the build parameters are: $ ccmake
Cheers,
Ben
On Wed, May 25, 2016 at 4:19 PM, Richard Bell
wrote:
>
I was using a dongle with r820.
juha
> On May 25, 2016, at 23:27, Piotr Krysik wrote:
>
> Juha,
>
> What type of demodulator did you have in the dongles used for the test?
>
> --
> Piotr
>
> W dniu 25.05.2016 o 14:46, Juha Vierinen pisze:
>> In my testing, this phase rate difference seemed c
Hi Ben,
thank you for your interest and feedback!
To your first question: The desired behaviour of the signal detector would
be to recognize a multi-carrier system (like OFDM) as one signal, since all
the carriers are needed to transmit the information. If the frequency
resolution is very fine, a
@Nick No this effect I see after the GPSDO already has a lock and is
running (is powered) for more than 30min.
@Andy Interesting. I agree, I also plan to use the hack, but would really
like to try to find the root cause. Also, maybe I stumbled on something
useful that the Ettus guys can use to imp
Is there some good candidate that can be asked to do that? When I search
for rtlsdr driver the first page with actual source code is osmocom's site:
sdr.osmocom.org/trac/wiki/rtl-sdr
Maybe they have the maintainer who feels responsible for how this code
works?
I can try to correct this offset in
23 matches
Mail list logo
