On Fri, May 03, 2013 at 11:04:40AM +1200, Mark Cottrell wrote:
> I am trying to create a block that detects sync patterns at baseband tagging
> the first sample of the pattern using stream tags, then using the tags down
That's the correct way to do it, if you ask me.
Just to clarify: Before you g
On Fri, May 03, 2013 at 09:08:34AM +0200, Martin Braun (CEL) wrote:
> > Currently I have an implementation of the block, but I am having trouble
> > understanding the relationship between ninput_items and noutput_items.
> > When I
> > feed the block from a file source consisting of 720 samples, I
I'm using UHD 003.005.002-47-g4a860d74
I'm working on narrowband/tunnel.py. I changed the usrp_source call to
create 4 channels, I added all necessary connections.
I made those changes with two channels using the default fpga image
and it worked well.
mle...@ripnet.com a écrit :
On 02 Ma
On Fri, May 3, 2013 at 4:37 AM, Marcus D. Leech wrote:
>
> Has anyone experienced any build failures in UHD on Ubuntu 13.04 using
> build-gnuradio?
>
> I haven't upgraded my Ubuntu system yet, and I have had one report of a
> UHD build failure on Ubuntu 13.04
> due to libboost1.49, but a manual
Hi Marcus,
Please find attached the txt file with the warnings.
Cheers,
Zo
Date: Thu, 2 May 2013 11:18:59 -0700
From: ml-node+s4n41109...@n7.nabble.com
To: xtmpcvs...@hotmail.com
Subject: Re: Error in Building UHD on Windows
If everything works fine: Ignore them.
The first one see
On 05/03/2013 08:59 AM, Sean Nowlan wrote:
On 05/02/2013 10:37 PM, Marcus D. Leech wrote:
Has anyone experienced any build failures in UHD on Ubuntu 13.04 using
build-gnuradio?
I haven't upgraded my Ubuntu system yet, and I have had one report of a
UHD build failure on Ubuntu 13.04
due to li
On 03 May 2013 09:00, Sean Nowlan wrote:
> On 05/03/2013 08:59 AM,
Sean Nowlan wrote:
>
>> On 05/02/2013 10:37 PM, Marcus D. Leech wrote:
>>
>>> Has anyone experienced any build failures in UHD on Ubuntu
13.04 using
>>> build-gnuradio?
>>>
>>> I haven't upgraded my Ubuntu
system yet, an
Looked at those code lines, since I wasn't used to the
compiler output of msvc; everything looks fine.
Cheers,
Marcus
Am 03.05.2013 13:12, schrieb Zooz Engineer:
Hi Marcus,
Please find attached the txt file with the warnings.
Cheers,
Zo
-
I updated the GNURadio Ubuntu install instructions for the 1.53 special
case. It's a known safe option, so it should generate less issues.
I'll update the wiki once Ubuntu updates the libboost-all-dev meta-package
to the newer version.
Cheers,
Ben
On Fri, May 3, 2013 at 7:14 AM, wrote:
> **
>
On 05/03/2013 06:12 AM, Zooz Engineer wrote:
> Hi Marcus,
>
> Please find attached the txt file with the warnings.
>
These are just implicit casts that cause default warnings in MSVC, but
not GCC. We generally fix these by just explicitly casting. There is
nothing to worry about.
I will add t
Adriana -
The GNURadio UDB source / sink blocks are just receiving / sending samples
via a UDP port.
You can use a block, or a C# application that just listens to the socket.
Look at the implementation of the UDP source if you are confused. It is
just using 'basic UDP sockets'.
http://gnuradio.
Hi Adriana,
there is something wrong with the involved terminology here, so
hopefully I understand your question correctly:
You use an USRP E110, on which you run an GNU Radio flowgraph that
you created in python.
You have another computer somewhere else, that has a C# runtime on it.
You want to
Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst,
"in_port_id") instead of tb.connect?
Cheers
Marcus
Am 03.05.2013 00:35, schrieb Sean Nowlan:
I'm trying to create a block that accepts messages and prints them out.
I created a block that extends gr_block and it has no strea
NaceurElOuni -
I think I'm having trouble understanding your question. I'm not sure what
you want to measure, or how you intend to measure it.
For starters, there isn't really a shared concept of 'time' between the
FPGA and the analog components. The FPGA operates in terms of clocks...
which don'
Hi Yingjie Chen -
If your schedule requires that the code work, then feel free to hack on it
and make it work! That's the beauty of open source. You could then
contribute your code back to the community, thus helping everyone that has
put effort into making GNURadio what it is, today =)
Cheers,
B
On 05/03/2013 01:26 PM, Marcus Müller wrote:
Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst,
"in_port_id") instead of tb.connect?
Cheers
Marcus
I'm trying to post a message to a port from top_block as opposed to
connecting the output port of one block to the input of "
On 05/03/2013 01:41 PM, Sean Nowlan wrote:
On 05/03/2013 01:26 PM, Marcus Müller wrote:
Hi Sean,
have you tried using tb.msg_connect(src, "out_port_id", dst,
"in_port_id") instead of tb.connect?
Cheers
Marcus
I'm trying to post a message to a port from top_block as opposed to
connecting th
Hint 1: If both 210s are on the same PPS and frequency reference and the FPGA
clocks are synchronized to the PPS, you can schedule the transmit and receive
to within one tick of the 100 MHz ADC clock.
Hint 2: Cross correlate the transmitted and received samples. The lag will be
independent of
O.k.
I managed to make it work by removing every file named *usrp* or
*gnuradio* and reinstalling gnuradio and uhd from the repository.
Now the examples seem to work on my usrp1.
But I am quite desperate at getting my old python code to work. I have
programmed a vector-network-analyzer.
I used
Nice to hear, that you have made progress Wolfgang.
GL with the rest
73s
Erik OZ4KK
O.k.
I managed to make it work by removing every file named *usrp* or
*gnuradio* and reinstalling gnuradio and uhd from the repository.
Now the examples seem to work on my usrp1.
But I am quite desperate at
Michael,
the update seems to work, I have built (using macports) the whole of
gnuradio and the osmosdr module. All seems to work with the osmo and rtl
sources and sink appearing in companion and being able to hook them
together.
I am having a problem getting a graph to execute however, (probabl
Hi there,
I have a USRP2 with WBX board which has been sitting around doing nothing.
I was wondering if it is possible to use this hardware to get a live DVB-T
signal and replay it back.
What I want to do is to intercept entitlement management messages and
modify/remove them on the fly.
Please l
Hi all GSoC applicants,
thanks for submitting so many fantastic GSoC proposals!
Just a quick status update: We have received 28 applications; we will
know about the number of slots next week Wednesday.
Realistically, I am expecting 2-4 slots for GNU Radio. Selecting
students will be hard, and I h
Thank you Marc,
* Ok I will try using a common clock ref and input PPS
* Scheduling the transmit and receive to within one tick of the 100 MHz
ADC clock: Can that be done into the host GNU radio code or am supposed to
move the code to the FPGA.
* Is that the samples count method to get accurate
Hi Ben,
Thanks for explanations,
I've been doing some theoretical calculations on the group delay estimation
and found that this part is giving negligible latency compared to the
Ethernet portion between USRP and host.
cheers.
2013/5/3 Naceur Amine El Ouni
> Thank you Marc,
>
> * Ok I wil
I had this issue once and if I remember correctly, connecting the block
to the flowgraph (i.e. connect any block to your message port, even if
that port will never send messages) will make your message handler react
to messages from your python code.
Hope this helps
Martin
Am 03.05.2013 19:4
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of
Martin Lülf [m...@mluelf.de]
Sent: Friday, May 03, 2013 7:59 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discu
Sir,
This is Gandhiraj R, from Amrita Vishwa Vidyapeetham, Coimbatore, Tamil Nadu,
India.
Currently many of our students working in GNURadio based projects.
Recently we can not access the GNURADIO.ORG web link.
Error message:
---
Access Denied
The owner o
28 matches
Mail list logo
