Just as a note, I also did not get the gui to work with my USRP1, the error
messages are different, but at least it did not receive.
Ralph.
From: Nick Foster [mailto:bistrom...@gmail.com]
Sent: Tuesday, 5 November, 2013 19:14
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subjec
Hi Ting -
Sorry, there really wasn't a good reason for me to not answer your
question, regardless =)
So the ADCs are indeed 14 bits, but those samples go through a lot of
processing on a number of different platforms, and get sent over a few
different buses. At any of these stages, depending on y
On Nov 5, 2013, at 8:41 AM, Michael Dickens wrote:
> I'm not sure how to do that yet; I'll experiment & post back once I've
> figured it out.
I'm pretty sure we can use the legacy libstdc++ provided by Apple, but it
requires that "port" be either from the SVN trunk (as of a few days ago) or
th
*False alarm. This is not a problem.
I had accidentally installed to a different directory than I was importing
from.
Tom
On Sun, Nov 3, 2013 at 11:23 PM, Tommy Tracy wrote:
> Dear GNU Radio,
>
> If I have a:
> GR_LOG_DEBUG(d_debug_logger, );
>
> in my c++ application, the program will write
Ting -
This question really isn't GNURadio related. If you resend it over the
USRP-Users list, though, we will help explain things quickly!
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Cheers,
Ben
On Sat, Nov 2, 2013 at 12:22 AM, Ting Wu <
wu.t...@comf5.comm.eng.osaka-u.a
Sema -
Also, please be sure you run the calibrations provided by UHD. The TX DC
Offset calibration addresses exactly what you are talking about.
http://files.ettus.com/uhd_docs/manual/html/calibration.html
Cheers,
Ben
On Fri, Nov 1, 2013 at 9:04 AM, Mike Jameson wrote:
> Hi Sema,
>
> You are
Im afraid I am not a programmer, so I do not know if I can find something
there, but I will have l look later or tomorrow J
Ralph.
From: Nick Foster [mailto:bistrom...@gmail.com]
Sent: Tuesday, 5 November, 2013 19:14
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion List
Subject: Re
I've only tested osmocom in gr-air-modes with the HackRF. The relevant code
is in python/radio.py lines 177-189. modes_gui does reinstantiate the
source block a couple of times (to populate the options boxes) -- it's
possible that this isn't allowing gr-osmocom enough time to close/open the
USB dev
Yes, works just fine, also other toolchains like gqrx gr-osmosdr bladerf
do not show any strange effects, so osmosdr seems to be OK.
Ralph
From: Nick Foster [mailto:bistrom...@gmail.com]
Sent: Tuesday, 5 November, 2013 18:10
To: Ralph A. Schmid, dk5ras
Cc: GNURadio Discussion Lis
Dear Manu,
Do you have any performance numbers on your LDPC decoder? I could not
find any info, even in your presentation. Do you have also a BER
figure, or even better would be some technical report. I would love to
get some sense on the performance of your implementation.
Best,
Miklos
On Tue,
Dear Max,
You are correct. It is a bug. Now I'm wondering why I didn't get any
segmentation faults.
Probably I didn't get any segmentation faults because, after i = M - 1, EOF
has reached.
Thanks for the correction.
On Tue, Nov 5, 2013 at 9:14 PM, ikjtel wrote:
> Greetings
>
> I was very int
Does osmocom_fft work?
--n
On Tue, Nov 5, 2013 at 9:00 AM, Ralph A. Schmid, dk5ras wrote:
> Hi,
>
> gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions,
> built directly from the repo.
>
> modes_rx works just fine, the messages come through.
>
> modes_gui throws this error, w
Hi,
gr-airmodes, gr-osmosdr, gnuradio and bladerf all with latest versions, built
directly from the repo.
modes_rx works just fine, the messages come through.
modes_gui throws this error, when switching insinde the gui to osmosdr:
ras@ubuntu:~$ modes_gui
linux; GNU C++ version 4.6.3; Boost_104
Greetings
I was very interested in this project for possible application to the op25
project, since P25 uses several FEC codes
including RS and other block codes. I've brought up the gr-ldpc library and
have a few questions. Due to the hateful YAhoo mail composer, I'm hesitant to
post lengthy
On Mon, Nov 4, 2013 at 10:25 AM, Vanush Vaswani wrote:
> Hi all,
>
> I am using GR 3.6.5.1 to receive BPSK modulated data from a third
> party RF chip / microcontroller combination and am having a strange
> experience. I am implementing a very simple protocol by constantly
> transmitting 0x7E cons
Or, rather, with Apple's new libc++ runtime. I'm working on the MacPorts
ticket: < https://trac.macports.org/ticket/41162 >.
The high level advice right now is: If you update to 10.9, you won't be using
GNU Radio for a while.
It looks like there is will be 2 issues encountered when compiling
On Tue, Nov 05, 2013 at 12:56:24PM +, y...@solid.co.kr wrote:
> I want to call another gnu-blocks (or another hier-block) in work function.
> (Line 14~16)
>
> 1) How to connect input item to another block’s input
>
> 2) How to connect local array to another block’s output
In GNU Radi
Hi,
Can you help me to call gnu-blocks from my own out-of-tree code written in
python?
For example, from this code
(http://gnuradio.org/redmine/projects/gnuradio/wiki/OutOfTreeModules)
1 import numpy
2 from gnuradio import gr
3
4 class square3_ff(gr.sync_block):
5 " Squaring block "
6
18 matches
Mail list logo
