Hi,
In the attached flowgraph the timing is correct in both of the time
sinks and the audio output. However, I have been unable to get the
output to the GPIO pin synchronized with the rest of it. It seems to
consume all of the data without waiting for the other output. Any ideas
on what to do
I'll do all the work for 1 x 10^-5 BERCoin.
On Sat, May 26, 2018 at 9:59 AM Derek Kozel wrote:
> Hello Dewan,
>
> I'm glad that you are using GNU Radio, but no one here is going to do your
> entire project for you. We are happy to help with specific questions or
> problems, but not until you sho
Hello Dewan,
I'm glad that you are using GNU Radio, but no one here is going to do your
entire project for you. We are happy to help with specific questions or
problems, but not until you show us what you have tried and what problem
you are having with it.
https://wiki.gnuradio.org/index.php/Repor
Thank you all every much on the ideas. I appreciate it. I have initially
thought about using UDP in the similar manner you suggested and I guess I
will start with that one first and probably try other methods if that
doesnt work.
By the way, I was not clear about "continuous" mode of operation.
Ap
That sounds very feasible!
But, again, if all that happens is actually a hardware source
overflowing, and dropping a single let's say 200 sample packets, this
might be hard to detect externally if "Keep 1 in N" has an N > 200 or
so to reliably detect a single missed packet, and that might mean you
Thanks for the Throttle insights :)
If there's a hardware source in the flowgraph, maybe he can leverage the
source's clock, and use source -> Keep 1 in N -> sink?
Or write a custom UDP sink that connects directly to the source, and
implements some kind of "Send 1 for every N items" internally?
O
Be a bit careful there, Throttle doesn't work like that!
Throttle will sleep for as long as it takes to pass the number of input
items it sees.
For example, if you connected
Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
Then, on start of the flow graph, "constant source" will produce e.g.
Might work for you:
Any kind of source, throttled to 1/HEARTBIT_INTERVAL, to a UDP sink.
Example:
Constant Source(1) -> Throttle (1 S/s) -> UDP Sink
will write the number 1 to the designated UDP sink, once every second.
On Sun, Apr 1, 2018 at 12:22 AM Milos Milosavljevic <
milos.milosavlje...@spi
Hi All,
I was wondering if someone can give me some hints on the below please.
I have a flowgraph running continuously demodulating some off air signals
and spitting out meta data about the parameters, calculated SNRs, BER, freq
offset estimations, etc. That meta and output data is parsed regular
Ok thank you Marcus and Marcus for your answers.
GNURadio is really awesome and this feature will be great in my opinion.
Marcus (the first) said:
"However, you can loop *internally* within a block."
How can i do that?
Thx
Thomas
Le 17 mai 2017 10:56, "Marcus Müller" a écrit :
> Adding to tha
Adding to that, because it comes up every couple of years:
Marcus is right, GNU Radio's scheduler will just bark at you and refuse
to work if the flow graph has cycles.
I don't fully agree with the statement that it's due to buffer management:
I've patched away that refusal to work on a longish
On 05/16/2017 04:01 PM, Thom L wrote:
Hi,
For educational purposes I try to use gnuradio to realize simple
digital filters with delay, add and multiply blocks.
This is perfect for non-recursive filters but it does not seem
possible to make loops as in the example above and thus impossible to
b
Hi,
For educational purposes I try to use gnuradio to realize simple digital
filters with delay, add and multiply blocks.
This is perfect for non-recursive filters but it does not seem possible to
make loops as in the example above and thus impossible to build a recursive
filter on the same princip
I have been trying to incorporate BER measures in a more complex
flowgraph that includes OFDM.
I created a basic example to understand it better, but to my surprise
when I run it, it stops after 2 seconds approximately. The interface
is working, but the FFT Sink and BER Number Sink are stop
Hello all,
I am trying to figure out a way to allow for user input to dictate what
happens in my flowgraphs. Ideally I want to build a transceiver that will
constantly read in data until the user tries to send out a message. Once
the message has been sent then it goes back to reading data.
I have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Richard,
I cut out the more specific parts. Thus, now there's an example for a
dummy flowgraph. Dummy in terms of dummy encoder/decoder in GR. Now
there's an archive attached to this mail. I dared to attach it to this
mailing list post because of i
Thank Johannes. Would you be willing to share your python code so I could
learn from it?
I'm still trying to get the simulation working with GUIs. I've still got
issues getting the GUI window from one run to close properly, without
generating errors in terminal. But your approach will help me unde
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Richard,
I'm currently working on something quite similar. [1] shows an example
fur a dummy.
Basically what I do: I wrapped my flowgraph into another Python thread
which runs the flowgraph and generates statistics and everything else
I want for my
I removed the qt app.exec_() line and that seemed to fix it
On Thu, Oct 22, 2015 at 2:16 PM, Richard Bell
wrote:
> Thanks.
>
> I'm running into a problem getting tb.stop() to trigger. I tried putting a
> head block in the flow graph thinking it triggers WORK_DONE which I thought
> would lead to
Thanks.
I'm running into a problem getting tb.stop() to trigger. I tried putting a
head block in the flow graph thinking it triggers WORK_DONE which I thought
would lead to tb.stop(), but it doesn't. The flowgraph window just sits
there frozen. How do I get a running flow graph to trigger tb.stop(
On Thu, Oct 22, 2015 at 3:58 PM, Richard Bell
wrote:
> Or is this the correct stategy:
>
> if __name__ == '__main__':
>
> tb1 = my_flowgraph( paramter_set_1 )
> tb.start()
> tb.wait()
> tb.stop()
>
> tb2 = my_flowgraph( paramter_set_2 )
> tb.start()
> tb.wait()
> t
Or is this the correct stategy:
if __name__ == '__main__':
tb1 = my_flowgraph( paramter_set_1 )
tb.start()
tb.wait()
tb.stop()
tb2 = my_flowgraph( paramter_set_2 )
tb.start()
tb.wait()
tb.stop()
tb3 = my_flowgraph( paramter_set_3 )
tb.start()
tb.wait(
Hi all,
I'd like a recommendation on how to setup an experiment. I have a full
loopback transceiver simulation that I want to test. It contains forward
error correction and the full synchronization chain along with AGCs and the
like.
For the experiment, I want to set the noise to a value and run
to prevent people from stumbling into the issue
that’s causing the lock up.
Sean
From: Richard Bell [mailto:richard.be...@gmail.com]
Sent: Thursday, July 09, 2015 3:40 AM
To: Nowlan, Sean
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
I think
I think it's the fact that you are feeding two different ports of the mux by
one null source that is the issue. The first ports buffer fills before the
third ports buffer does. When the first is full, it prevents null source from
creating new outputs, which will cause the graph to stall on the t
Stream Mux’s
> case, it’s only copying from one input at a time.
>
>
>
> Sean
>
>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On
> Behalf Of *Jeon
> *Sent:* Wednesd
nesday, July 08, 2015 10:46 PM
To: Discuss GNU Radio mailing list
Subject: Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
whileni didnt look into null source block code,
but the basic behavior of null source block is,
it outputs nothing.
So stream mux waits until input blocks pass a
whileni didnt look into null source block code,
but the basic behavior of null source block is,
it outputs nothing.
So stream mux waits until input blocks pass a given number of samples and
it takes forever
Regards
Jeon
2015. 7. 9. 오전 11:27에 "Nowlan, Sean" 님이 작성:
> I’m somehow getting a simpl
I'm somehow getting a simple flowgraph to lock up GNU Radio. It locks up every
time I run it, after roughly the same amount of time. As you can see in the
attached image and GRC file, I'm feeding two inputs of a Stream Mux block from
the same upstream block. Do you imagine why that might cause p
Thank you.
On Wed, Mar 26, 2014 at 5:54 PM, Martin Braun wrote:
> On 03/26/2014 04:26 AM, Activecat wrote:
>> Dear Sir,
>>
>> I am thinking of building simple chat application using gnuradio.
>> PC#1 connecting to USRP#1, will send text message to PC#2 via USRP#2.
>> The question is, how to get t
On 03/26/2014 04:26 AM, Activecat wrote:
> Dear Sir,
>
> I am thinking of building simple chat application using gnuradio.
> PC#1 connecting to USRP#1, will send text message to PC#2 via USRP#2.
> The question is, how to get the user keystrokes from the flowgraph at PC#1 ?
>
> I am building the f
Dear Sir,
I am thinking of building simple chat application using gnuradio.
PC#1 connecting to USRP#1, will send text message to PC#2 via USRP#2.
The question is, how to get the user keystrokes from the flowgraph at PC#1 ?
I am building the flowgraphs using GRC (Companion).
I guess I need to use
5 AM
To: Mark Cottrell
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling
wait()
On Wed, Sep 11, 2013 at 5:08 PM, Mark Cottrell
wrote:
> Hi Tom,
>
> I spent a while playing around with this, including adding a bunch of debug
> output
On Wed, Sep 11, 2013 at 5:08 PM, Mark Cottrell
wrote:
> Hi Tom,
>
> I spent a while playing around with this, including adding a bunch of debug
> output to tpb_thread_body::tpb_thread_body, and found that when a block is
> done, the DONE state should propagate through the flow graph as
> tpb_detai
Hi Tom,
I spent a while playing around with this, including adding a bunch of debug
output to tpb_thread_body::tpb_thread_body, and found that when a block is
done, the DONE state should propagate through the flow graph as
tpb_detail::notify_neighbours is called (as I'm sure you're aware). The
pr
On Thu, Aug 22, 2013 at 10:44 PM, Mark Cottrell
wrote:
> Hello all,
>
> I have written a sync block that takes in samples and outputs messages
> (similar to tagged_stream_to_pdu), but when writing a test for the block I
> found that when I called top_block.run(), the test never finished, as it
> a
Hello all,
I have written a sync block that takes in samples and outputs messages
(similar to tagged_stream_to_pdu), but when writing a test for the block I
found that when I called top_block.run(), the test never finished, as it
appears to be hanging on the call to top_block.wait().
The flow gra
The payload field contains the sequence numbers of packets consumed by the
USRP's DUC. As a note, you may need to reorder the bytes (uhd::ntohx). I'm
handling the messages in C++, so I'm not too sure about the swig. My source
reads the messages and calculates the number of samples consumed by
Thanks Jordan, this is super helpful.
I made the uhd/gr-uhd changes that josh suggested and using the following
code snippet. I now can see EVENT_CODE_BURST_ACK (event code == 0)
messages coming back from UHD at approximately 30msec intervals.
self.async_msgq = gr.msg_queue(0)
self.uhd_amsg_sour
Hi Phelps,
I've been dealing with latency issues of my own, and this seems to be the best
solution so far (big thanks to Josh!):
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-04/msg00211.html
The nice thing about this method is that it allows you to manage buffering at a
system level
I created a block which in the work(), sits in select on a udp socket with
a timeout of 10msec. In the event it times out rather than getting a read
signal, a pattern of noutput_items is written. In the event it receives
data from the udp socket, the udp dgram is copied to the output items
vector
Dear Tom,
I will give it a try. I will keep you in touch.
Thanks for your answer.
Pol Henarejos
Research Engineer, MSc
pol.henare...@cttc.es
Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castellde
On Mon, Jul 30, 2012 at 4:18 AM, Pol Henarejos wrote:
> Dear Tom,
>
> All blocks are written by me. B and C produce 40 and 80 samples,
> respectively. They have set_output_multiple to 40 and 80. Both forecast
> have in0=noutput/40 and in0=noutput/80. A block does not have nor
> set_output_multiple
Dear Tom,
All blocks are written by me. B and C produce 40 and 80 samples,
respectively. They have set_output_multiple to 40 and 80. Both forecast
have in0=noutput/40 and in0=noutput/80. A block does not have nor
set_output_multiple nor forecast. D block (2 inputs 1 output) has
set_output_multiple
On Thu, Jul 19, 2012 at 4:54 AM, Pol Henarejos wrote:
> Dear list,
>
> I have a simple flowgraph with two branches, with different delays that
> are joined at the end. Imagine a topblock with A,B,C,D blocks. A is
> connected to B and C. B and C are connected to D. A and D are sink and
> source res
Dear list,
I have a simple flowgraph with two branches, with different delays that
are joined at the end. Imagine a topblock with A,B,C,D blocks. A is
connected to B and C. B and C are connected to D. A and D are sink and
source respectively. B and C produce packets (header and payload) from
the i
On Sun, Dec 05, 2010 at 12:13:39AM -0800, Steve Mcmahon wrote:
> By the way, in the USA, commercial FM is on odd frequencies (i.e., 94.5 MHz,
> 94.7 MHz, 94.9 MHz, etc.). In Europe and Japan, isn't commercial FM on even
> frequencies (i.e., 94.4 MHz, 94.6 MHz, 94.8 MHz, etc.)? Where are you
> lo
On Sun, Dec 5, 2010 at 11:24 PM, Steve Mcmahon
wrote:
> Hello:
>
> Does GNU Radio keep track of time, or sample count, or something similar as a
> flowgraph runs? How can I query the current "flowgraph time", from within my
> flowgraph, if such a thing exists?
>
> More specifically, I have a Sig
Hello:
Does GNU Radio keep track of time, or sample count, or something similar as a
flowgraph runs? How can I query the current "flowgraph time", from within my
flowgraph, if such a thing exists?
More specifically, I have a Signal Source connected to a USRP2 Sink in order to
generate a tone.
On Sun, Dec 5, 2010 at 12:22 PM, Josh Blum wrote:
>
>
> On 12/05/2010 08:17 AM, Alexandru Csete wrote:
>> Greetings,
>>
>> Yesterday I updated my gnuradio/next and UHD installations to:
>> UHD_0001.20101204162446.a51fb2e
>> v3.3.1git-322-ge92f2cb6
>>
>> I noticed that when changing USRP sample rat
On 12/05/2010 08:17 AM, Alexandru Csete wrote:
> Greetings,
>
> Yesterday I updated my gnuradio/next and UHD installations to:
> UHD_0001.20101204162446.a51fb2e
> v3.3.1git-322-ge92f2cb6
>
> I noticed that when changing USRP sample rates using
> uhd_single_usrp_source the flowgraph will suspend
Greetings,
Yesterday I updated my gnuradio/next and UHD installations to:
UHD_0001.20101204162446.a51fb2e
v3.3.1git-322-ge92f2cb6
I noticed that when changing USRP sample rates using
uhd_single_usrp_source the flowgraph will suspend execution and CPU
load drops to 0.
The flowgraph is still alive
ies (i.e., 94.4 MHz, 94.6 MHz, 94.8 MHz, etc.)? Where are you located?
I am in Boston, Massachusetts, USA.
Steve McMahon
--- On Wed, 12/1/10, Bernardo Gonçalves wrote:
From: Bernardo Gonçalves
Subject: Re: [Discuss-gnuradio] flowgraph for commercial FM radio TX/RX
To: "Steve Mcmah
Hi,
I have a modified dbpsk.py in which I use a custom block after the
self.diffenc (differential encoder block). This custom C++ block outputs
1000 output_items of size 'gr_sizeof_char' for each input_item of size
'gr_sizeof_char'. I then use benchmark_tx.py to test the functioning of the
modified
Hi Steve,
on my webpage I collected a number of receive and transmit flowgraphs
for all sorts of modulations, but also FM:
http://www.dl8rds.de/index.php/GNURadio_and_USRP2
I also own the USRP2 and the WBX board and I am testing them step by
step.
Please also consider these documents:
http://
Hello:
Does anyone have a flowgraph that could be run on a USRP2 with a WBX
daughterboard for either transmit or receive of commercial FM radio (88 MHz to
108 MHz U.S.)?
In the transmit case, I would like to read raw PCM audio from a file and
modulate it and transmit it in the commercial FM ba
On 09/06/2010 05:03 PM, Tom Rondeau wrote:
> On Sat, Sep 4, 2010 at 8:47 PM, Eric Blossom wrote:
> Marcus,
> Indeed, this could be something we want to talk more about. Kind of on
> the periphery of my vision, I can see a handful of applications where
> the large chunking issue could be a problem.
On Sat, Sep 4, 2010 at 8:47 PM, Eric Blossom wrote:
> On Sat, Sep 04, 2010 at 08:22:38PM -0400, Marcus D. Leech wrote:
>> On 09/04/2010 08:08 PM, Tom Rondeau wrote:
>> > On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech wrote
>> >
>> > Like Eric said, remove the throttle or at least change the rat
On Sat, Sep 04, 2010 at 08:22:38PM -0400, Marcus D. Leech wrote:
> On 09/04/2010 08:08 PM, Tom Rondeau wrote:
> > On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech wrote
> >
> > Like Eric said, remove the throttle or at least change the rate and
> > that should clean things up.
> >
> > Tom
> >
>
On 09/04/2010 08:08 PM, Tom Rondeau wrote:
> On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech wrote
>
> Like Eric said, remove the throttle or at least change the rate and
> that should clean things up.
>
> Tom
>
>
I also noted in the reply to Eric that I observe the same behaviour with
an e
On Sat, Sep 4, 2010 at 12:19 AM, Marcus D. Leech wrote:
> On 09/03/2010 11:52 PM, Eric Blossom wrote:
> Thought about that, as well. So replaced the graphical FFT sink with a
> file sink, and set the
> "unbuffered" flag. That file fills up in "fits and starts'--that is,
> it spends quite a whil
On 09/03/2010 11:52 PM, Eric Blossom wrote:
> The throttle block was written so that the GUI elements could be
> tested without an inherently rate limiting source being in the graph.
> It is not designed to precisely rate limit anything. For any use
> other than that, you're asking for trouble. T
On Fri, Sep 03, 2010 at 10:09:01PM -0400, Marcus D. Leech wrote:
> I've got a flow-graph with a throttled random byte source, which is a
> test input for a modulator:
>
> http://www.sbrac.org/files/fm4_test_modulator.grc
>
> http://www.sbrac.org/files/fm4_test_modulator.py
>
> The source is thro
I've got a flow-graph with a throttled random byte source, which is a
test input for a modulator:
http://www.sbrac.org/files/fm4_test_modulator.grc
http://www.sbrac.org/files/fm4_test_modulator.py
The source is throttled to the byte rate required to produce the correct
number of symbols/second (
There was a problem in my block. I fixed it. I am using gr_block and
cosume_each.
Thanks for the help
On Sat, Dec 5, 2009 at 8:54 AM, Eric Blossom wrote:
> On Thu, Dec 03, 2009 at 11:16:01AM -0600, Mir M. Ali wrote:
> > Hi,
> > I developed a gnuradio block that takes 2 inputs. Input_01 is comi
On Thu, Dec 03, 2009 at 11:16:01AM -0600, Mir M. Ali wrote:
> Hi,
> I developed a gnuradio block that takes 2 inputs. Input_01 is coming from a
> source that repeats and Input_02 is coming from a source that exhausts after
> a while. The output should only be generated when there is data on both th
Hi,
I developed a gnuradio block that takes 2 inputs. Input_01 is coming from a
source that repeats and Input_02 is coming from a source that exhausts after
a while. The output should only be generated when there is data on both the
input lines. I see in my flowgraph that even when the data on inpu
67 matches
Mail list logo
