You could just watch a movie or something and build natively on the PI.
Just be careful of memory constraints. Maybe a -j 1 or a USB drive mounted
as swap would be a good idea.
On Jan 13, 2016 11:44 AM, "Matej Kovacic" wrote:
> Hi,
>
> I am trying to crosscompile GNUradio on Ubuntu 15.04 (64-bit)
On 01/13/2016 12:31 PM, Marcus Müller wrote:
> Hi Matej,
>
>
> so, your Toolchain-RaspberryPi.cmake contains this, right?
>
> # this one is important
> SET(CMAKE_SYSTEM_NAME Linux)
> #this one not so much
> SET(CMAKE_SYSTEM_VERSION 1)
>
> # specify the cross compiler
> SET(CMAKE_C_COMPILER
> /h
No problems. As I said, I don't use Ubuntu right now so I'm a bit out of
the loop on these matters. Keep playing around & learn all you can! -
MLD
If you look in <
https://github.com/kik/sdr-tv/blob/master/gr-ntsc/CMakeLists.txt >,
lines 89-94 read:
{{{
# Search for GNU Radio and its components an
Hi Matej,
so, your Toolchain-RaspberryPi.cmake contains this, right?
# this one is important
SET(CMAKE_SYSTEM_NAME Linux)
#this one not so much
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compiler
SET(CMAKE_C_COMPILER
/home/matej/RaspberryPi/toolchain/local/x-tools/arm-unknown-linux-gnueabi
Hi,
I am trying to crosscompile GNUradio on Ubuntu 15.04 (64-bit). The full
procedure is in detail described here:
http://www.rtl-sdr.com/forum/viewtopic.php?f=7&t=516
However, when I run:
cmake
-DCMAKE_TOOLCHAIN_FILE=/home/matej/RaspberryPi/CMakeToolChain/Toolchain-RaspberryPi.cmake
..
... I
Michael,
Thanks for the response, I'm not a software developer so bear with me. Yes I'm
using an OOT at
https://github.com/kik/sdr-tv/blob/master/gr-ntsc/examples/ntsc.grc which I
would like to experiment with. My thinking was to edit the CMakelists.txt???
that comes along with this gr-f
On Tue, Jan 12, 2016 at 6:47 AM, Hitesh Kasera
wrote:
> hello tom,
> i tried to put a block of packing bits after FEC decoder block but still
> received data is not same as transmitted. here i am working in simulation
> environment not on air so i think there will not be any delay problems.
>
> H
Maurizio Crozzoli wrote
>
> Marcus Müller-3 wrote
>> So: you'll really have to define a maximum time that a GPIO toggle may
>> stay undetected. This shouldn't be hard -- I mean, in the end, there's
>> some application's needs that you'll want to satisfy.
> Is it a way to suggest me to use a sleep
Hi shortwavedude - You're trying to configure an OOT module, yes? (GNU
Radio internally would not look for itself, so this is the logical
conclusion. Which OOT module are you trying to build?) That error means
that this OOT module is looking for GR 3.7.2 or newer, and that cmake
can't find GR insta
Thanks Marcus,
It sounds like a good idea but I think I haven't explained my flow graph
well enough. This a simplification of what I've got.
[image: Inline images 1]
I've taken away one of the cards, filters and others. Can I still use your
approach using "streams to vector" -> "vector to streams
Thanks Martin, will look into this. I think we are picking up some very weak
interferers too.
DH
From: Martin Braun
Sent: 12 January 2016 07:30
To: David Halls; GNURadio Discussion List
Cc: Will Thompson
Subject: Re: Schmidl & Cox Detector
Noise shouldn'
Well, that could well be; at 96kHz, 1s after a day is a drift of
$\frac{\SI{1}{\second}}{24\cdot 60 \cdot
60\si{\second}}=11.57\,\mathrm{ppm}$
which would be a relatively good value for soundcard oscillators.
For drifts that small, you probably won't be able to correct this from
signal.
I'd say,
12 matches
Mail list logo
