[Discuss-gnuradio] Flowgraph timing with GPIO
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?
Your help is greatly appreciated.
--
Barry Duggan
options:
parameters:
author: Barry Duggan
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: Morse code generator
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: test0928
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: Test 0928
window_size: ''
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [16, 16.0]
rotation: 0
state: enabled
blocks:
- name: baud
id: variable
parameters:
comment: ''
value: speed/1.2
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [400, 20.0]
rotation: 0
state: enabled
- name: repeat
id: variable
parameters:
comment: ''
value: '1200'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [560, 20.0]
rotation: 0
state: true
- name: samp_rate
id: variable
parameters:
comment: ''
value: baud*repeat
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [688, 20.0]
rotation: 0
state: enabled
- name: speed
id: variable
parameters:
comment: ''
value: '12'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [288, 20.0]
rotation: 0
state: true
- name: analog_sig_source_x_0_0
id: analog_sig_source_x
parameters:
affinity: ''
alias: ''
amp: '0.5'
comment: ''
freq: '600'
maxoutbuf: '0'
minoutbuf: '0'
offset: '0'
phase: '0'
samp_rate: samp_rate
type: float
waveform: analog.GR_COS_WAVE
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [678, 454]
rotation: 0
state: enabled
- name: audio_sink_0
id: audio_sink
parameters:
affinity: ''
alias: ''
comment: ''
device_name: hw:CARD=Device,DEV=0
num_inputs: '1'
ok_to_block: 'True'
samp_rate: '48000'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1300, 494]
rotation: 0
state: enabled
- name: blocks_float_to_uchar_0
id: blocks_float_to_uchar
parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [945, 121]
rotation: 0
state: true
- name: blocks_multiply_xx_0
id: blocks_multiply_xx
parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
num_inputs: '2'
type: float
vlen: '1'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [936, 364]
rotation: 0
state: enabled
- name: blocks_repeat_0
id: blocks_repeat
parameters:
affinity: ''
alias: ''
comment: ''
interp: repeat
maxoutbuf: '0'
minoutbuf: '0'
type: byte
vlen: '1'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [483, 360]
rotation: 0
state: enabled
- name: blocks_uchar_to_float_0
id: blocks_uchar_to_float
parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [668, 364]
rotation: 0
state: enabled
- name: epy_block_0
id: epy_block
parameters:
_source_code: "\"\"\"\nMorse code vector source\n\"\"\"\n\n#
epy_block_0.py\n\
# revised 08/20/2019\n# revised 09/27/2019 to clear input line (code
from\
\ Volker Schroer dl1ksv)\n\nimport numpy as np\nfrom gnuradio import
gr\n\n\
import pmt\n\ntextboxValue = \"\"\n\nMorse = {\n\"A\":
\"1,0,1,1,1\",\n\
\\"B\": \"1,1,1,0,1,0,1,0,1\",\n\"C\":
\"1,1,1,0,1,0,1,1,1,0,1\",\n\
\\"D\": \"1,1,1,0,1,0,1\",\n\"E\": \"1\",\n\"F\":
\"1,0,1,0,1,1,1,0,1\"\
,\n\"G\": \"1,1,1,0,1,1,1,0,1\",\n\"H\": \"1,0,1,0,1,0,1\",\n
\"\
I\": \"1,0,1\",\n\"J\": \"1,0,1,1,1,0,1,1,1,0,1,1,1\",\n\"K\":
\"1,1,1,0,1,0,1,1,1\"\
,\n\"L\": \"1,0,1,1,1,0,1,0,1\",\n\"M\": \"1,1,1,0,1,1,1\",\n
\"\
N\": \"1,1,1,0,1\",\n\"O\": \"1,1,1,0,1,1,1,0,1,1,1\",\n\"P\":
\"1,0,1,1,1,0,1,1,1,0,1\"\
,\n\"Q\": \"1,1,1,0,1,1,1,0,1,0,1,1,1\",\n\"R\":
\"1,0,1,1,1
Re: [Discuss-gnuradio] Flowgraph
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 show us what you have tried and what problem > you are having with it. > https://wiki.gnuradio.org/index.php/ReportingErrors > > I see that you have no synchronization blocks in your flowgraphs, they > will be needed when using actual hardware. Are you able to correctly send > and receive a file when you are doing a pure simulation, no hardware? > > Regards, > Derek > > On Sat, May 19, 2018 at 6:17 AM, Dewan Arif wrote: > >> I hope you are doing great. I need your help for one of my project. I >> want to transmit data in wireless communication using gnuradio and usrp >> 2901. After that I want to calculate BER and plot BER vs SNR. >> >> First, you have to give me the Gnuradio Flowgraph. I want to transmit >> >> a. Text >> b. Picture >> c. Audio >> d. Video. >> >> and you have to save at .txt ; .png ; .wav and .avi format in the >> receiver end. >> >> you have to give two flow graph one for simulation and other for >> real-time transmission (each data type text, picture, audio, and video) >> >> you have to use two scheme one is DPSK and other is WIFI. >> >> The second part is you have to calculate the BER and plot the BER vs SNR >> curve in Matlab for each transmission (text, picture, audio, and video) >> >> >> It should not take much time if you are an expert. I have attached the >> picture as an example. >> >> List What I Want : >> >> 1) TransceiverFlowgraph.grc in Gnuradio ( data type: text, audio, video, >> picture) DPSK and WiFi Simulation >> >> 2) Transceiver Flowgraph.grc in Gnuradio ( data type: text, audio, video, >> picture) DPSK and WIFI Real-time transmission >> >> 3) Matlab code BER Calculation, plot BER vs SNR curve for simulation >> >> 4) Matlab code BER Calculation, plot BER vs SNR curve for real-time >> transmission. >> >> >> Please help me out >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Very Respectfully, Dan CaJacob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph
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/ReportingErrors I see that you have no synchronization blocks in your flowgraphs, they will be needed when using actual hardware. Are you able to correctly send and receive a file when you are doing a pure simulation, no hardware? Regards, Derek On Sat, May 19, 2018 at 6:17 AM, Dewan Arif wrote: > I hope you are doing great. I need your help for one of my project. I want > to transmit data in wireless communication using gnuradio and usrp 2901. > After that I want to calculate BER and plot BER vs SNR. > > First, you have to give me the Gnuradio Flowgraph. I want to transmit > > a. Text > b. Picture > c. Audio > d. Video. > > and you have to save at .txt ; .png ; .wav and .avi format in the receiver > end. > > you have to give two flow graph one for simulation and other for real-time > transmission (each data type text, picture, audio, and video) > > you have to use two scheme one is DPSK and other is WIFI. > > The second part is you have to calculate the BER and plot the BER vs SNR > curve in Matlab for each transmission (text, picture, audio, and video) > > > It should not take much time if you are an expert. I have attached the > picture as an example. > > List What I Want : > > 1) TransceiverFlowgraph.grc in Gnuradio ( data type: text, audio, video, > picture) DPSK and WiFi Simulation > > 2) Transceiver Flowgraph.grc in Gnuradio ( data type: text, audio, video, > picture) DPSK and WIFI Real-time transmission > > 3) Matlab code BER Calculation, plot BER vs SNR curve for simulation > > 4) Matlab code BER Calculation, plot BER vs SNR curve for real-time > transmission. > > > Please help me out > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph heartbeat pulse
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. Apologies. I have an automated system which starts the flowgraph at specific times, runs it for a few minutes (15-20mins) and shuts it down. So when there is no data at the output I believe that the flowgraph is launched but it either stalls or crashes (for whatever reason). The source of data is actually USRP so there is hardware involved in the system. I also know whether it is launched or it failed to launch and I monitor the CPU utilisation during this time. I havent received any alerts on the CPU but I agree I wouldnt discard the possibility that the computing power could be the issue. As a result it becomes a bit hard to know where it crashes (which by the way I am still not 100% certain that it actually does) so thats why I thought I should start with some vitals first. I am also thinking of doing the core dump somehow to check for any segfaults etc but not sure yet how useful that will be (unless I build the gnuradio in debug mode). Thank you all again. Best Regards Milos On 1 April 2018 at 13:27, Müller, Marcus (CEL) wrote: > 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 > need to transport many samples! > > Best regards, > Marcus > > On Sun, 2018-04-01 at 11:31 +, Gilad Beeri (ApolloShield) wrote: > > 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? > > > > On Sun, Apr 1, 2018 at 2:16 PM Müller, Marcus (CEL) > > wrote: > > > 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. > > > 4096 items, and then Throttle's work will be called with these 4096 > > > items. Throttle then calculates #input_items/sample_rate = 4096s > > > and > > > sleep, for more than an hour, then signal it's finished copying > > > thes > > > 4096 items to the output. This is everything but a usable watchdog! > > > > > > Frankly, I know (very, very well) that GNU Radio isn't bug-free. > > > But if your flow graph occasionally breaks, then you need to fix > > > that, > > > and not only try to figure out when that happens. This is > > > especially > > > hard in GNU Radio, since all blocks run in different threads, and a > > > disjunkt watchdog subgraph might just as well continue running > > > after > > > your main graph has ceased to function. > > > > > > I interpret your "sometimes values are missing" as "but then it > > > continues working normally afterwards". I'm certain that means your > > > flow graph is *not* crashing, because then it wouldn't continue > > > working > > > normally after. What might happen is that some step or external > > > factor > > > needs to much resources of your computer, and then the real time > > > processing of your input data (wherever that comes from!) can't be > > > sustained, leading to your external data source (SDR device?) > > > having to > > > drop samples. But then you'll need to debug your computation and > > > computational system to make it sufficienly reliable at not > > > consuming > > > more time to do whatever you do to the signal than it takes to > > > produce > > > the signal! > > > > > > Vitals are still a good idea, but sadly, I don't have a standard > > > way of > > > doing them. > > > > > > Best regards, > > > Marcus > > > > > > On Sun, 2018-04-01 at 04:20 +, Gilad Beeri (ApolloShield) > > > wrote: > > > > 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 > > > > > > v...@spire.com> wrote: > > > > > 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 parameter
Re: [Discuss-gnuradio] Flowgraph heartbeat pulse
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 need to transport many samples! Best regards, Marcus On Sun, 2018-04-01 at 11:31 +, Gilad Beeri (ApolloShield) wrote: > 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? > > On Sun, Apr 1, 2018 at 2:16 PM Müller, Marcus (CEL) > wrote: > > 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. > > 4096 items, and then Throttle's work will be called with these 4096 > > items. Throttle then calculates #input_items/sample_rate = 4096s > > and > > sleep, for more than an hour, then signal it's finished copying > > thes > > 4096 items to the output. This is everything but a usable watchdog! > > > > Frankly, I know (very, very well) that GNU Radio isn't bug-free. > > But if your flow graph occasionally breaks, then you need to fix > > that, > > and not only try to figure out when that happens. This is > > especially > > hard in GNU Radio, since all blocks run in different threads, and a > > disjunkt watchdog subgraph might just as well continue running > > after > > your main graph has ceased to function. > > > > I interpret your "sometimes values are missing" as "but then it > > continues working normally afterwards". I'm certain that means your > > flow graph is *not* crashing, because then it wouldn't continue > > working > > normally after. What might happen is that some step or external > > factor > > needs to much resources of your computer, and then the real time > > processing of your input data (wherever that comes from!) can't be > > sustained, leading to your external data source (SDR device?) > > having to > > drop samples. But then you'll need to debug your computation and > > computational system to make it sufficienly reliable at not > > consuming > > more time to do whatever you do to the signal than it takes to > > produce > > the signal! > > > > Vitals are still a good idea, but sadly, I don't have a standard > > way of > > doing them. > > > > Best regards, > > Marcus > > > > On Sun, 2018-04-01 at 04:20 +, Gilad Beeri (ApolloShield) > > wrote: > > > 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 > > > > v...@spire.com> wrote: > > > > 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 regularly and saved to a database. > > > > > > > > However, sometimes it is either meta missing or data or both. I > > am > > > > convinced that the flowgraph either stalls or crashes. I need > > to > > > > capture it where exactly but first I want to develop a tool to > > > > monitor the flowgraph to now when it crashed or hanged. > > > > > > > > So I want to add a hearbeat somewhere which I can monitor and > > know > > > > exactly that it is not running anymore. Does anybody have any > > ideas > > > > of what would be the best way to do it? Can I use something > > from > > > > the library for this? > > > > > > > > Any suggestions will be appreciated. > > > > > > > > Many thanks, > > > > Milos > > > > > > > > ___ > > > > Discuss-gnuradio mailing list > > > > Discuss-gnuradio@gnu.org > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph heartbeat pulse
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? On Sun, Apr 1, 2018 at 2:16 PM Müller, Marcus (CEL) wrote: > 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. > 4096 items, and then Throttle's work will be called with these 4096 > items. Throttle then calculates #input_items/sample_rate = 4096s and > sleep, for more than an hour, then signal it's finished copying thes > 4096 items to the output. This is everything but a usable watchdog! > > Frankly, I know (very, very well) that GNU Radio isn't bug-free. > But if your flow graph occasionally breaks, then you need to fix that, > and not only try to figure out when that happens. This is especially > hard in GNU Radio, since all blocks run in different threads, and a > disjunkt watchdog subgraph might just as well continue running after > your main graph has ceased to function. > > I interpret your "sometimes values are missing" as "but then it > continues working normally afterwards". I'm certain that means your > flow graph is *not* crashing, because then it wouldn't continue working > normally after. What might happen is that some step or external factor > needs to much resources of your computer, and then the real time > processing of your input data (wherever that comes from!) can't be > sustained, leading to your external data source (SDR device?) having to > drop samples. But then you'll need to debug your computation and > computational system to make it sufficienly reliable at not consuming > more time to do whatever you do to the signal than it takes to produce > the signal! > > Vitals are still a good idea, but sadly, I don't have a standard way of > doing them. > > Best regards, > Marcus > > On Sun, 2018-04-01 at 04:20 +, Gilad Beeri (ApolloShield) wrote: > > 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 > v...@spire.com> wrote: > > > 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 regularly and saved to a database. > > > > > > However, sometimes it is either meta missing or data or both. I am > > > convinced that the flowgraph either stalls or crashes. I need to > > > capture it where exactly but first I want to develop a tool to > > > monitor the flowgraph to now when it crashed or hanged. > > > > > > So I want to add a hearbeat somewhere which I can monitor and know > > > exactly that it is not running anymore. Does anybody have any ideas > > > of what would be the best way to do it? Can I use something from > > > the library for this? > > > > > > Any suggestions will be appreciated. > > > > > > Many thanks, > > > Milos > > > > > > ___ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph heartbeat pulse
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. 4096 items, and then Throttle's work will be called with these 4096 items. Throttle then calculates #input_items/sample_rate = 4096s and sleep, for more than an hour, then signal it's finished copying thes 4096 items to the output. This is everything but a usable watchdog! Frankly, I know (very, very well) that GNU Radio isn't bug-free. But if your flow graph occasionally breaks, then you need to fix that, and not only try to figure out when that happens. This is especially hard in GNU Radio, since all blocks run in different threads, and a disjunkt watchdog subgraph might just as well continue running after your main graph has ceased to function. I interpret your "sometimes values are missing" as "but then it continues working normally afterwards". I'm certain that means your flow graph is *not* crashing, because then it wouldn't continue working normally after. What might happen is that some step or external factor needs to much resources of your computer, and then the real time processing of your input data (wherever that comes from!) can't be sustained, leading to your external data source (SDR device?) having to drop samples. But then you'll need to debug your computation and computational system to make it sufficienly reliable at not consuming more time to do whatever you do to the signal than it takes to produce the signal! Vitals are still a good idea, but sadly, I don't have a standard way of doing them. Best regards, Marcus On Sun, 2018-04-01 at 04:20 +, Gilad Beeri (ApolloShield) wrote: > 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 v...@spire.com> wrote: > > 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 regularly and saved to a database. > > > > However, sometimes it is either meta missing or data or both. I am > > convinced that the flowgraph either stalls or crashes. I need to > > capture it where exactly but first I want to develop a tool to > > monitor the flowgraph to now when it crashed or hanged. > > > > So I want to add a hearbeat somewhere which I can monitor and know > > exactly that it is not running anymore. Does anybody have any ideas > > of what would be the best way to do it? Can I use something from > > the library for this? > > > > Any suggestions will be appreciated. > > > > Many thanks, > > Milos > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph heartbeat pulse
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...@spire.com> wrote: > 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 regularly and > saved to a database. > > However, sometimes it is either meta missing or data or both. I am > convinced that the flowgraph either stalls or crashes. I need to capture it > where exactly but first I want to develop a tool to monitor the flowgraph > to now when it crashed or hanged. > > So I want to add a hearbeat somewhere which I can monitor and know exactly > that it is not running anymore. Does anybody have any ideas of what would > be the best way to do it? Can I use something from the library for this? > > Any suggestions will be appreciated. > > Many thanks, > Milos > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph heartbeat pulse
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 regularly and saved to a database. However, sometimes it is either meta missing or data or both. I am convinced that the flowgraph either stalls or crashes. I need to capture it where exactly but first I want to develop a tool to monitor the flowgraph to now when it crashed or hanged. So I want to add a hearbeat somewhere which I can monitor and know exactly that it is not running anymore. Does anybody have any ideas of what would be the best way to do it? Can I use something from the library for this? Any suggestions will be appreciated. Many thanks, Milos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph with loops
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 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 train ride some time > ago, and in theory, with the Thread-Per-Block (TPB) scheduler, it *would* > work. However, of course, you're running into causality problems if none of > the blocks in the feedback path creates items out of thin air, and the > block where feedback and forward items "merge" needs an item on every input. > > So, realizing that this refusal to work is a result of GNU Radio > originally being written only with the single-threaded scheduler (STS) in > mind, and is a remnant of us never really having codified or formalized the > boundaries between blocks, block execution, scheduling, and flowgraph > initialization, I kinda stopped there, and never wrote the unit and > integration tests, wrote docs or figured out a way to test whether such a > flow graph could work before actually letting it start to run. > > It just seemed wiser to *first* tackle the fact that we don't really have > a formal description of how the scheduler should behave before changing > what it refuses to do (and, possibly, for good reasons that I didn't have > in mind). Now, fast forward a while, what a surprise!, that plan of > formalizing what GR is supposed to do never saw execution; it's not really > a weekend project. > > But: this whole thing has gotten traction over the last couple of weeks, > so maybe we'll come up with something. > > Cheers, > Marcus (the second) > > On 16.05.2017 22:39, Marcus D. Leech wrote: > > 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 build a recursive > filter on the same principle? > Thanks > Thomas > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > Loops are strictly forbidden by the buffer-management model. > > However, you can loop *internally* within a block. > > > > > ___ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph with loops
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 train ride some time ago, and in theory, with the Thread-Per-Block (TPB) scheduler, it *would* work. However, of course, you're running into causality problems if none of the blocks in the feedback path creates items out of thin air, and the block where feedback and forward items "merge" needs an item on every input. So, realizing that this refusal to work is a result of GNU Radio originally being written only with the single-threaded scheduler (STS) in mind, and is a remnant of us never really having codified or formalized the boundaries between blocks, block execution, scheduling, and flowgraph initialization, I kinda stopped there, and never wrote the unit and integration tests, wrote docs or figured out a way to test whether such a flow graph could work before actually letting it start to run. It just seemed wiser to /first/ tackle the fact that we don't really have a formal description of how the scheduler should behave before changing what it refuses to do (and, possibly, for good reasons that I didn't have in mind). Now, fast forward a while, what a surprise!, that plan of formalizing what GR is supposed to do never saw execution; it's not really a weekend project. But: this whole thing has gotten traction over the last couple of weeks, so maybe we'll come up with something. Cheers, Marcus (the second) On 16.05.2017 22:39, Marcus D. Leech wrote: > 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 >> build a recursive filter on the same principle? >> Thanks >> Thomas >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > Loops are strictly forbidden by the buffer-management model. > > However, you can loop *internally* within a block. > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph with loops
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 build a recursive filter on the same principle? Thanks Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Loops are strictly forbidden by the buffer-management model. However, you can loop *internally* within a block. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph with loops
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 principle? Thanks Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph with BER Block freezing
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 stopped. If I disable the BER block and the Virtual Source and Number Sink, and instead enable the Tag Debug, the flowgraph keeps running indefinitely. I attached bertest.grc to this message. bertest.grc Description: application/gnuradio-grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph branching statements and transceiver
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 the TX and RX side of this working already, but its only a one way system, the TX can only talk to the RX. I'd like to have it so they can both talk and listen to each other. I know in the Chat_app example user input is accepted and then sent out, but it is embedded into an OOT block. Is there anyway to implement user input and branching statements within the top_block or something like that? I really appreciate your help, Logan Washbourne Electrical Engineering Graduate Student (Electromagnetics) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph Control
-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 its tiny size. I hope that's fine with everyone. Some parts may be done differently at first glance. But those files still accumulate quite a lot of trial and error with some lengthy simulations. I hope it helps. Cheers Johannes On 23.10.2015 18:44, Richard Bell wrote: > 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 understand the non-GUI related matters better. > > Appreciated, Rich > > On Fri, Oct 23, 2015 at 2:44 AM, Johannes Demel > wrote: > > 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 simulation > infrastructure. I fixed some problems in the block 'ber_bf' to shut > down the flowgraph correctly when that limit is exceeded. And not > shut down before any errors occured. After your flowgraph is done, > just get the number of bit errors with > tb..total_errors(). I know it'll break > encapsulation. tb..nitems_read(0) will return > the number of bytes. Be careful with the bit vs. byte issue. But > that also depends on your input data. My flowgraphs are capped by > the FEC decoder, all the other blocks mostly wait for it. So I just > spawn a couple of them in parallel and delete a flowgraph once it > finished and I got all the results. My assumption is that flowgraph > instantiation is really fast compared to the simulation. Worst case > setup time < 2s and simulation time may exceed 1000s. Also, you > don't have to worry about incomplete resets for your flowgraph. > > I hope I could show a different approach here. > > Also, I use 'no GUI' flowgraphs. > > Cheers Johannes > > > [1] http://imgur.com/wDOPqHL > > On 22.10.2015 23:26, Richard Bell wrote: 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 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(), so the next iteration can start? > > Rich > > On Thu, Oct 22, 2015 at 1:21 PM, West, Nathan > > wrote: > >> >> >> 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() tb.stop() >>> >>> tb3 = my_flowgraph( paramter_set_3 ) tb.start() >>> tb.wait() tb.stop() >>> >>> etc.. >>> >> >> That's what I would do, except create a list of your >> parameter values and loop over the list. >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> ___ Discuss-gnuradio >> mailing list Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWLfeCAAoJEO7fmkDsqywMhhUP/3tSylqbQmLRBa8Al2PiaIYq z2yaeqbW729dW0IbIub1Q3eY+gYNG1o7W+7aCDPwfCt1JKOtyPiW63ikPrNuh5h+ Yzq6VuxRG3lJBJqxvEzTIBlBgMDNF5oWVhoeNW5dpXvJHwI3zmdFh0vuhuIbQ1t2 Lo1q7G0Rz0UJZUD4RQXJsxX2FacohZoh0fzWhulVfIHxZIEOs/t9xn9BdflIA9n3 rbK3ohDcrpDGGPFfKQZWheUARbhdJRpA3Qp43JnN95OCkT3Y3QTgLxJWD/Db8Wgl EaeoxbF7n5VSGq4OzMj7Dr/8SkEqwGZrCq2vXK1jWqFfgt/F6LXYeYD/61t9qKF0 W1z6+9zUEzCoycmtI0o8NiSUpS4ztD4zlgI6LiY0SNV7unTvYu7YkDF5QJ7i7Wqw LkJfOGw2qdJWjjW3Oecuj/Mx4jd1bLSGY5p5riywRcDv4ch1QxXnCTgPnzYC35xM q2rPK2eKDRQd47uOyui9ichY45bY5xY4377tOy/K+yrNWE8p6xLVLc7GNutmK4Dh QSi8yaQTdfVhoqdySGOWQ7QWruG89LfhWArEECxL65xwWrcMnQAqVOXME5rzzhLx podXXeQTg+WsF9hXB2ScRRFqVr/2ONqQ9bwF9XgUm+CDS5ZbzFMd7D7mhzeDOmJh oOpQeeh4aT7MMkJoOfx2 =P7DP -END PGP SIGNATURE- simulation_example.tar.gz Description: application/gzip simulation_example.tar.gz.sig Description: PGP signature ___ Discuss-gn
Re: [Discuss-gnuradio] Flowgraph Control
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 understand the non-GUI related matters better. Appreciated, Rich On Fri, Oct 23, 2015 at 2:44 AM, Johannes Demel wrote: > -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 simulation infrastructure. > I fixed some problems in the block 'ber_bf' to shut down the flowgraph > correctly when that limit is exceeded. And not shut down before any > errors occured. > After your flowgraph is done, just get the number of bit errors with > tb..total_errors(). I know it'll break encapsulation. > tb..nitems_read(0) will return the number of bytes. > Be careful with the bit vs. byte issue. But that also depends on your > input data. > My flowgraphs are capped by the FEC decoder, all the other blocks > mostly wait for it. So I just spawn a couple of them in parallel and > delete a flowgraph once it finished and I got all the results. > My assumption is that flowgraph instantiation is really fast compared > to the simulation. Worst case setup time < 2s and simulation time may > exceed 1000s. Also, you don't have to worry about incomplete resets > for your flowgraph. > > I hope I could show a different approach here. > > Also, I use 'no GUI' flowgraphs. > > Cheers > Johannes > > > [1] http://imgur.com/wDOPqHL > > On 22.10.2015 23:26, Richard Bell wrote: > > 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 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(), so the next > >> iteration can start? > >> > >> Rich > >> > >> On Thu, Oct 22, 2015 at 1:21 PM, West, Nathan > >> >>> wrote: > >> > >>> > >>> > >>> 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() > tb.stop() > > tb3 = my_flowgraph( paramter_set_3 ) tb.start() tb.wait() > tb.stop() > > etc.. > > >>> > >>> That's what I would do, except create a list of your parameter > >>> values and loop over the list. > >>> > >>> > >> > > > > > > > > ___ Discuss-gnuradio > > mailing list Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBAgAGBQJWKgF8AAoJEO7fmkDsqywMTOsQAJZ8IjGtMDkwWAlF4MjOM4AS > 35bhaekAVcym3l02mV04aaAVdfBMeifrbAGuCKFVWnYNFLlZZhNGNi8scC+fkhWZ > 3QR3ZC+yA1FgurL7fheCdQru8Z5oF3nb0/6LzbSEd69z4w/tfNBD5fdwV91S6YNm > qJv+cOs/oJSxBWEjT2xY96DeMpKABXeI0KnadLtts9P7v8Kk940orS6OQtMk0TbR > x603stUh52LJhAJdGOi/KG8BgioL/4Vr2KcqHprIs0IJ2iF382nPgl9cc+ybh3w9 > yZEAWpg6Y2zD3k0g75zeuviN5sZnaKvqUEvOq4/yoTwbh635sYyqVFJtP8rtijOj > EOnlTjlA89ugUzDoBkrL8jJaqDicUpzNIFoYbN+NVhd4n/9UuaVSi9P6Qa25dTgB > fWEcY19J5DDvMfJw5l60RYj2Oh4y816olTDF25t/jjHGOmPBwuCUtL1oi9j82eL1 > bi8sREOXtNn63nDq7pyv5dYf1D5+6aHPsxajwGb4rdUI5AVHC6aQiBMQemaGG/5V > ooNckXruFBDzR/CiveRkAvLeHr7Gs5L89ge7xgVTXq+evbr+bid6CYcOqcwfrX65 > u1uaEXlEpmWOjPHhKUVFG1Zd3EPIwyeOx34DQaEXIHNFmNj1xCErlQ2SuFGFDH3n > HSRDwtl2iSixOROI3r7f > =ez4I > -END PGP SIGNATURE- > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph Control
-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 simulation infrastructure. I fixed some problems in the block 'ber_bf' to shut down the flowgraph correctly when that limit is exceeded. And not shut down before any errors occured. After your flowgraph is done, just get the number of bit errors with tb..total_errors(). I know it'll break encapsulation. tb..nitems_read(0) will return the number of bytes. Be careful with the bit vs. byte issue. But that also depends on your input data. My flowgraphs are capped by the FEC decoder, all the other blocks mostly wait for it. So I just spawn a couple of them in parallel and delete a flowgraph once it finished and I got all the results. My assumption is that flowgraph instantiation is really fast compared to the simulation. Worst case setup time < 2s and simulation time may exceed 1000s. Also, you don't have to worry about incomplete resets for your flowgraph. I hope I could show a different approach here. Also, I use 'no GUI' flowgraphs. Cheers Johannes [1] http://imgur.com/wDOPqHL On 22.10.2015 23:26, Richard Bell wrote: > 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 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(), so the next >> iteration can start? >> >> Rich >> >> On Thu, Oct 22, 2015 at 1:21 PM, West, Nathan >> >> wrote: >> >>> >>> >>> 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() tb.stop() tb3 = my_flowgraph( paramter_set_3 ) tb.start() tb.wait() tb.stop() etc.. >>> >>> That's what I would do, except create a list of your parameter >>> values and loop over the list. >>> >>> >> > > > > ___ Discuss-gnuradio > mailing list Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWKgF8AAoJEO7fmkDsqywMTOsQAJZ8IjGtMDkwWAlF4MjOM4AS 35bhaekAVcym3l02mV04aaAVdfBMeifrbAGuCKFVWnYNFLlZZhNGNi8scC+fkhWZ 3QR3ZC+yA1FgurL7fheCdQru8Z5oF3nb0/6LzbSEd69z4w/tfNBD5fdwV91S6YNm qJv+cOs/oJSxBWEjT2xY96DeMpKABXeI0KnadLtts9P7v8Kk940orS6OQtMk0TbR x603stUh52LJhAJdGOi/KG8BgioL/4Vr2KcqHprIs0IJ2iF382nPgl9cc+ybh3w9 yZEAWpg6Y2zD3k0g75zeuviN5sZnaKvqUEvOq4/yoTwbh635sYyqVFJtP8rtijOj EOnlTjlA89ugUzDoBkrL8jJaqDicUpzNIFoYbN+NVhd4n/9UuaVSi9P6Qa25dTgB fWEcY19J5DDvMfJw5l60RYj2Oh4y816olTDF25t/jjHGOmPBwuCUtL1oi9j82eL1 bi8sREOXtNn63nDq7pyv5dYf1D5+6aHPsxajwGb4rdUI5AVHC6aQiBMQemaGG/5V ooNckXruFBDzR/CiveRkAvLeHr7Gs5L89ge7xgVTXq+evbr+bid6CYcOqcwfrX65 u1uaEXlEpmWOjPHhKUVFG1Zd3EPIwyeOx34DQaEXIHNFmNj1xCErlQ2SuFGFDH3n HSRDwtl2iSixOROI3r7f =ez4I -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph Control
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 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(), so > the next iteration can start? > > Rich > > On Thu, Oct 22, 2015 at 1:21 PM, West, Nathan > wrote: > >> >> >> 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() >>> tb.stop() >>> >>> tb3 = my_flowgraph( paramter_set_3 ) >>> tb.start() >>> tb.wait() >>> tb.stop() >>> >>> etc.. >>> >> >> That's what I would do, except create a list of your parameter values and >> loop over the list. >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph Control
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(), so the next iteration can start? Rich On Thu, Oct 22, 2015 at 1:21 PM, West, Nathan wrote: > > > 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() >> tb.stop() >> >> tb3 = my_flowgraph( paramter_set_3 ) >> tb.start() >> tb.wait() >> tb.stop() >> >> etc.. >> > > That's what I would do, except create a list of your parameter values and > loop over the list. > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph Control
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() > tb.stop() > > tb3 = my_flowgraph( paramter_set_3 ) > tb.start() > tb.wait() > tb.stop() > > etc.. > That's what I would do, except create a list of your parameter values and loop over the list. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph Control
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() tb.stop() etc.. On Thu, Oct 22, 2015 at 11:36 AM, Richard Bell wrote: > 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 the flow > graph until I generate enough errors. At that point, I want to reset all > the memory elements to default state and change the noise added and run > until I generate enough errors again. I keep doing this N times. > > In my reading, it seems that start() and stop() are more meant for > situations where you are disconnecting/connecting blocks. Is this true or > should I consider calling start and stop between each run? > > If start and stop is in fact not the way to go, how do I make sure the > simulation is put back in the default state. I don't want the control loops > of the synchronizers to have any memory of the previous run. > > Is there example code that implements something similar to this already? > > Thanks, > Rich > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph Control
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 the flow graph until I generate enough errors. At that point, I want to reset all the memory elements to default state and change the noise added and run until I generate enough errors again. I keep doing this N times. In my reading, it seems that start() and stop() are more meant for situations where you are disconnecting/connecting blocks. Is this true or should I consider calling start and stop between each run? If start and stop is in fact not the way to go, how do I make sure the simulation is put back in the default state. I don't want the control loops of the synchronizers to have any memory of the previous run. Is there example code that implements something similar to this already? Thanks, Rich ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
Yes, that’s a workaround. My point is that this issue is not obvious to somebody who isn’t familiar with how the scheduler works. When using null sources, it makes sense to just use two of them. But what if you’re supplying a data stream and need to inject a synchronization sequence in the middle, as GSM does? In this case, my workaround is using a Deinterleave block to split a burst of data into two branches fed to the first and third ports of a Stream Mux, and a Vector Source with the sync sequence fed to the second Mux port. This works fine for me. I still wonder if there’s a way 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 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 third port waiting for items. Use two distinct null sources and I think it will run fine. Sent from my iPhone On Jul 8, 2015, at 7:26 PM, Nowlan, Sean mailto:sean.now...@gtri.gatech.edu>> wrote: 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 problems? I know there are other ways to do what I’ve shown here, but locking up seems like a bug. Thanks, Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
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 third port waiting for items. Use two distinct null sources and I think it will run fine. Sent from my iPhone > On Jul 8, 2015, at 7:26 PM, Nowlan, Sean wrote: > > 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 problems? > > I know there are other ways to do what I’ve shown here, but locking up seems > like a bug. > > Thanks, > Sean > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
Oh I didnt know it.
Thanks for correcting it
Regards
Jeon
2015. 7. 9. 오전 11:51에 "Nowlan, Sean" 님이 작성:
> Null source just sets all outputs to zero, so it’s equivalent to a
> constant source with the scalar=0.
>
>
>
> …
>
> for(size_t n = 0; n < input_items.size(); n++) {
>
> optr = (void*)output_items[n];
>
> memset(optr, 0, noutput_items *
> output_signature()->sizeof_stream_item(n));
>
> }
>
> …
>
>
>
> I think this is some subtle issue with Stream Mux’s forecast function and
> how it interacts with the scheduler knowing when to advance read pointers
> from the upstream block. This is just a wild guess, though. Also, I’ve seen
> an upstream block connect to two inputs of a Multiply block to create a
> squaring device, and that seems to work just fine. But in 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:* Wednesday, 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 given number of samples and
> it takes forever
>
> Regards
> Jeon
>
> 2015. 7. 9. 오전 11:27에 "Nowlan, Sean" 님이 작성:
>
> 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
> problems?
>
>
>
> I know there are other ways to do what I’ve shown here, but locking up
> seems like a bug.
>
>
>
> Thanks,
>
> Sean
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph locking up with Stream Mux
Null source just sets all outputs to zero, so it’s equivalent to a constant
source with the scalar=0.
…
for(size_t n = 0; n < input_items.size(); n++) {
optr = (void*)output_items[n];
memset(optr, 0, noutput_items *
output_signature()->sizeof_stream_item(n));
}
…
I think this is some subtle issue with Stream Mux’s forecast function and how
it interacts with the scheduler knowing when to advance read pointers from the
upstream block. This is just a wild guess, though. Also, I’ve seen an upstream
block connect to two inputs of a Multiply block to create a squaring device,
and that seems to work just fine. But in 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: Wednesday, 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 given number of samples and it
takes forever
Regards
Jeon
2015. 7. 9. 오전 11:27에 "Nowlan, Sean"
mailto:sean.now...@gtri.gatech.edu>>님이 작성:
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 problems?
I know there are other ways to do what I’ve shown here, but locking up seems
like a bug.
Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 given number of samples and it takes forever Regards Jeon 2015. 7. 9. 오전 11:27에 "Nowlan, Sean" 님이 작성: > 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 > problems? > > > > I know there are other ways to do what I’ve shown here, but locking up > seems like a bug. > > > > Thanks, > > Sean > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph locking up with Stream Mux
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 problems? I know there are other ways to do what I've shown here, but locking up seems like a bug. Thanks, Sean stream_mux_bug_test.grc Description: stream_mux_bug_test.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph reading keystrokes during execution
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 the user keystrokes from the flowgraph at PC#1 ? >> >> I am building the flowgraphs using GRC (Companion). >> I guess I need to use something similar to WX GUI Slider, that get the >> user keystrokes instead of the slider position, into the flowgraph, >> during its execution. > > Sure, you can add another widget to do that. You probably want to catch > an event from QT and turn that into a message, then post that > asynchronously. > > M > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph reading keystrokes during execution
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 flowgraphs using GRC (Companion). > I guess I need to use something similar to WX GUI Slider, that get the > user keystrokes instead of the slider position, into the flowgraph, > during its execution. Sure, you can add another widget to do that. You probably want to catch an event from QT and turn that into a message, then post that asynchronously. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] flowgraph reading keystrokes during execution
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 something similar to WX GUI Slider, that get the user keystrokes instead of the slider position, into the flowgraph, during its execution. Thanks in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()
Any block can return "DONE" to indicate the scheduler that it finished its processing. Then the scheduler tells downstream blocks that they are DONE too. However, it's possible that you want downstream blocks to finish operating on samples that are "in flight" after the upstream block is marked DONE, rather than terminating everything before those buffers have been flushed/processed. Wouldn't it make sense to have the scheduler let these buffers flush before notifying those blocks that they are DONE? (Or does the scheduler already do something like this, and I've just not noticed?) From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org [discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] on behalf of Tom Rondeau [t...@trondeau.com] Sent: Thursday, September 12, 2013 9:45 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 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 > problem is, tpb_detail::notify_neighbours only notifies blocks that that > have input or output buffers (which as far as I can tell, blocks with only > message inputs or outputs don't), so blocks like message_debug will block on > tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and can > never be notified (as it has no input buffers, so notify downstream does > nothing). > > Johnathan contacted me r.e. this and I sent him a patch which fixed the > problem for me (attached to this message), but I don't think he has had time > to look at it yet. The gist of it is that it uses pmt::PMT_EOF to indicate > that message blocks should transition to done and notify neighbours. > > Please feel free to correct me on any of what I said above, this was my > first foray into the scheduler so I could have it completely wrong. > > Thanks, > Mark Yeah, ok, I see the problem. I think I remember now someone else talking about this potential issue. I'll discuss your patch with Johnathan sometime soon. I see where you're going with it, but I'm hoping that there's a solution that's a bit simpler (or just fewer changes). Thanks, -- Tom Visit us at GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 > On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau wrote: >> >> 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 >> > appears to be hanging on the call to top_block.wait(). >> > >> > The flow graph for the test is as follows: >> > non-repeating file source -> my block -> message_debug >> > >> > is hanging the expected behaviour? I can work around it by counting the >> > number of items written by the file source, but it would be nice to have >> > it >> > terminate of its own accord. >> > >> > Thanks, >> > Mark >> >> >> Mark, >> >> No, that's not expected behavior. When the file sink finishes, it >> should set the DONE stage in the scheduler that should indicated to >> every down stream block that they are also done. >> >> Make sure that there isn't something happening where your block isn't >> getting stuck in 'work' at this point. >> >> -- >> Tom >> Visit us at GRCon13 Oct. 1 - 4 >> http://www.trondeau.com/grcon13 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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 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 > problem is, tpb_detail::notify_neighbours only notifies blocks that that > have input or output buffers (which as far as I can tell, blocks with only > message inputs or outputs don't), so blocks like message_debug will block on > tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and can > never be notified (as it has no input buffers, so notify downstream does > nothing). > > Johnathan contacted me r.e. this and I sent him a patch which fixed the > problem for me (attached to this message), but I don't think he has had time > to look at it yet. The gist of it is that it uses pmt::PMT_EOF to indicate > that message blocks should transition to done and notify neighbours. > > Please feel free to correct me on any of what I said above, this was my > first foray into the scheduler so I could have it completely wrong. > > Thanks, > Mark Yeah, ok, I see the problem. I think I remember now someone else talking about this potential issue. I'll discuss your patch with Johnathan sometime soon. I see where you're going with it, but I'm hoping that there's a solution that's a bit simpler (or just fewer changes). Thanks, -- Tom Visit us at GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 > On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau wrote: >> >> 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 >> > appears to be hanging on the call to top_block.wait(). >> > >> > The flow graph for the test is as follows: >> > non-repeating file source -> my block -> message_debug >> > >> > is hanging the expected behaviour? I can work around it by counting the >> > number of items written by the file source, but it would be nice to have >> > it >> > terminate of its own accord. >> > >> > Thanks, >> > Mark >> >> >> Mark, >> >> No, that's not expected behavior. When the file sink finishes, it >> should set the DONE stage in the scheduler that should indicated to >> every down stream block that they are also done. >> >> Make sure that there isn't something happening where your block isn't >> getting stuck in 'work' at this point. >> >> -- >> Tom >> Visit us at GRCon13 Oct. 1 - 4 >> http://www.trondeau.com/grcon13 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()
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 problem is, tpb_detail::notify_neighbours only notifies blocks that that have input or output buffers (which as far as I can tell, blocks with only message inputs or outputs don't), so blocks like message_debug will block on tpb_detail::input_cond forever (on line 110 of tpb_thread_body.cc) and can never be notified (as it has no input buffers, so notify downstream does nothing). Johnathan contacted me r.e. this and I sent him a patch which fixed the problem for me (attached to this message), but I don't think he has had time to look at it yet. The gist of it is that it uses pmt::PMT_EOF to indicate that message blocks should transition to done and notify neighbours. Please feel free to correct me on any of what I said above, this was my first foray into the scheduler so I could have it completely wrong. Thanks, Mark On Thu, Sep 12, 2013 at 3:56 AM, Tom Rondeau wrote: > 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 > > appears to be hanging on the call to top_block.wait(). > > > > The flow graph for the test is as follows: > > non-repeating file source -> my block -> message_debug > > > > is hanging the expected behaviour? I can work around it by counting the > > number of items written by the file source, but it would be nice to have > it > > terminate of its own accord. > > > > Thanks, > > Mark > > > Mark, > > No, that's not expected behavior. When the file sink finishes, it > should set the DONE stage in the scheduler that should indicated to > every down stream block that they are also done. > > Make sure that there isn't something happening where your block isn't > getting stuck in 'work' at this point. > > -- > Tom > Visit us at GRCon13 Oct. 1 - 4 > http://www.trondeau.com/grcon13 > -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- async_message_stopping3.patch Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()
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 > appears to be hanging on the call to top_block.wait(). > > The flow graph for the test is as follows: > non-repeating file source -> my block -> message_debug > > is hanging the expected behaviour? I can work around it by counting the > number of items written by the file source, but it would be nice to have it > terminate of its own accord. > > Thanks, > Mark Mark, No, that's not expected behavior. When the file sink finishes, it should set the DONE stage in the scheduler that should indicated to every down stream block that they are also done. Make sure that there isn't something happening where your block isn't getting stuck in 'work' at this point. -- Tom Visit us at GRCon13 Oct. 1 - 4 http://www.trondeau.com/grcon13 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] flowgraph with async messaging hangs on calling wait()
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 graph for the test is as follows: non-repeating file source -> my block -> message_debug is hanging the expected behaviour? I can work around it by counting the number of items written by the file source, but it would be nice to have it terminate of its own accord. Thanks, Mark -- -- This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph latency with UHD and continuous stream
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 the USRP
(this is possible because the USRP packet size is fixed). The number of
produced output samples are limited such that there are only N samples (50 ms)
between my source and the USRP's DUC.
On Apr 23, 2013, at 4:37 PM, Phelps Williams wrote:
> 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_source_0 = uhd.amsg_source("addr=192.168.102.1",
> self.async_msgq)
> self.async_rcv = gru.msgq_runner(self.async_msgq, self.async_callback)
>
> def async_callback(self, msg):
> md = self.uhd_amsg_source_0.msg_to_async_metadata_t(msg)
> print "Channel: %i Time: %f Event: %i" % (md.channel,
> md.time_spec.get_real_secs(), md.event_code)
>
> In josh's example he sets the user_payload field with presumably a buffer
> occupancy value. I'm getting lost in the swiggyness here and can't figure
> out how to print a value of type 0x9894188> any suggestions there?
>
> I'm guessing what you are doing is writing a block which handles messages and
> in the event the occupancy drops below a certain amount, you write more
> source data out.
>
>
>
> On Tue, Apr 23, 2013 at 2:17 PM, Jordan Otomo wrote:
> 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 as opposed to per-block. I've been able to limit my latency
> to about 50 ms, but you can probably do better depending on how much
> processing you're doing. Hope this works for you!
>
> Jordan
>
>
> On Apr 22, 2013, at 10:59 PM, Phelps Williams wrote:
>
>> 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. This flowgraph ends with a UHD USRP sink.
>>
>> I am consistently observing latency through my flow graph of around 2 -
>> 2.5sec. The total latency doesn't appear to be dependent on the sample rate
>> (I've tested 1Msps and 2Msps). When intentionally underruning the flow
>> graph by setting set_max_noutput_items to less than 10msec of samples, the
>> latency through the graph is between 80msec and 200msec. Intentionally
>> underrunning UHD isn't an option for my application as an intermittent
>> modulated signal from the USRP causes issues.
>>
>> I am attempting to use the global (via gr.top_block.start()) and block
>> specific max_noutput_items settings to limit the total amount of latency in
>> my flow graph but this doesn't appear to be the primary source of latency.
>>
>> My suspicion is that UHD or the USRP has a transmit buffer which is the
>> source of my problem. I tried messing with the send_buff_size and
>> recv_buff_size specified here:
>> http://files.ettus.com/uhd_docs/manual/html/transport.html but these didn't
>> seem to make any impact.
>>
>> I played with setting set_max_noutput_items on the source block to the exact
>> value expected during the 10msec select timeout in my custom source block.
>> This works for a while but occasionally underruns. Also as udp traffic
>> moves through the block, the total amount of latency slowly increases. It
>> also seems wrong to throttle the flowgraph at both the source and the sink.
>> Much like it is problematic to use a throttle with a UHD source or sink
>> block. set_max_noutput_items doesn't seem like the right solution for this
>> problem.
>>
>> Decreasing GR_FIXED_BUFFER_SIZE in gr_flat_flowgraph makes a significant
>> improvement but it isn't a viable option for my application because it is a
>> universal setting for all gnuradio based radios running on my system. Some
>> of which require the default buffer size to operate efficiently.
>>
>> There has been a little discussion of this topic on the mailing list in the
>> past but I haven't found examples that include UHD / USRP with a flowgraph
>> that isn't intentionally underrunning (ie with a typical UDP source block).
>>
>> I have messed with the maximum socket buffer sizes allowed by linux. The
>> uhd recommended config and much smaller variations don't appear to make an
>> impact to this latency.
>> $ s
Re: [Discuss-gnuradio] Flowgraph latency with UHD and continuous stream
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_source_0 = uhd.amsg_source("addr=192.168.102.1",
self.async_msgq)
self.async_rcv = gru.msgq_runner(self.async_msgq, self.async_callback)
def async_callback(self, msg):
md = self.uhd_amsg_source_0.msg_to_async_metadata_t(msg)
print "Channel: %i Time: %f Event: %i" % (md.channel,
md.time_spec.get_real_secs(), md.event_code)
In josh's example he sets the user_payload field with presumably a buffer
occupancy value. I'm getting lost in the swiggyness here and can't figure
out how to print a value of type any suggestions there?
I'm guessing what you are doing is writing a block which handles messages
and in the event the occupancy drops below a certain amount, you write more
source data out.
On Tue, Apr 23, 2013 at 2:17 PM, Jordan Otomo wrote:
> 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 as opposed to per-block. I've been able to limit my
> latency to about 50 ms, but you can probably do better depending on how
> much processing you're doing. Hope this works for you!
>
> Jordan
>
>
> On Apr 22, 2013, at 10:59 PM, Phelps Williams wrote:
>
> 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. This flowgraph ends with a UHD USRP sink.
>
> I am consistently observing latency through my flow graph of around 2 -
> 2.5sec. The total latency doesn't appear to be dependent on the sample
> rate (I've tested 1Msps and 2Msps). When intentionally underruning the
> flow graph by setting set_max_noutput_items to less than 10msec of samples,
> the latency through the graph is between 80msec and 200msec.
> Intentionally underrunning UHD isn't an option for my application as an
> intermittent modulated signal from the USRP causes issues.
>
> I am attempting to use the global (via gr.top_block.start()) and block
> specific max_noutput_items settings to limit the total amount of latency in
> my flow graph but this doesn't appear to be the primary source of latency.
>
> My suspicion is that UHD or the USRP has a transmit buffer which is the
> source of my problem. I tried messing with the send_buff_size and
> recv_buff_size specified here:
> http://files.ettus.com/uhd_docs/manual/html/transport.html but these
> didn't seem to make any impact.
>
> I played with setting set_max_noutput_items on the source block to the
> exact value expected during the 10msec select timeout in my custom source
> block. This works for a while but occasionally underruns. Also as udp
> traffic moves through the block, the total amount of latency slowly
> increases. It also seems wrong to throttle the flowgraph at both the
> source and the sink. Much like it is problematic to use a throttle with a
> UHD source or sink block. set_max_noutput_items doesn't seem like the
> right solution for this problem.
>
> Decreasing GR_FIXED_BUFFER_SIZE in gr_flat_flowgraph makes a significant
> improvement but it isn't a viable option for my application because it is a
> universal setting for all gnuradio based radios running on my system. Some
> of which require the default buffer size to operate efficiently.
>
> There has been a little discussion of this topic on the mailing list in
> the past but I haven't found examples that include UHD / USRP with a
> flowgraph that isn't intentionally underrunning (ie with a typical UDP
> source block).
>
> I have messed with the maximum socket buffer sizes allowed by linux. The
> uhd recommended config and much smaller variations don't appear to make an
> impact to this latency.
> $ sudo sysctl net.core.rmem_max
> net.core.rmem_max = 5000
> $ sudo sysctl net.core.wmem_max
> net.core.wmem_max = 1048576
>
> For reference I am running:
> UHD 003.005.002
> Gnuradio 3.6.4.1
>
> *tl;dr*
> My expectation is that there is a buffer UHD is attempting to maintain,
> when this buffer gets low, it triggers upstream work operations in the
> flowgraph to refill this buffer. Is this not the case? How can I
> manipulate the size of this buffer? Is there any way to confirm the size
> of this buffer?
>
> Thanks!
>
> -Phelps
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
Re: [Discuss-gnuradio] Flowgraph latency with UHD and continuous stream
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 as opposed to per-block. I've been able to limit my latency to about 50 ms, but you can probably do better depending on how much processing you're doing. Hope this works for you! Jordan On Apr 22, 2013, at 10:59 PM, Phelps Williams wrote: > 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. > This flowgraph ends with a UHD USRP sink. > > I am consistently observing latency through my flow graph of around 2 - > 2.5sec. The total latency doesn't appear to be dependent on the sample rate > (I've tested 1Msps and 2Msps). When intentionally underruning the flow graph > by setting set_max_noutput_items to less than 10msec of samples, the latency > through the graph is between 80msec and 200msec. Intentionally underrunning > UHD isn't an option for my application as an intermittent modulated signal > from the USRP causes issues. > > I am attempting to use the global (via gr.top_block.start()) and block > specific max_noutput_items settings to limit the total amount of latency in > my flow graph but this doesn't appear to be the primary source of latency. > > My suspicion is that UHD or the USRP has a transmit buffer which is the > source of my problem. I tried messing with the send_buff_size and > recv_buff_size specified here: > http://files.ettus.com/uhd_docs/manual/html/transport.html but these didn't > seem to make any impact. > > I played with setting set_max_noutput_items on the source block to the exact > value expected during the 10msec select timeout in my custom source block. > This works for a while but occasionally underruns. Also as udp traffic moves > through the block, the total amount of latency slowly increases. It also > seems wrong to throttle the flowgraph at both the source and the sink. Much > like it is problematic to use a throttle with a UHD source or sink block. > set_max_noutput_items doesn't seem like the right solution for this problem. > > Decreasing GR_FIXED_BUFFER_SIZE in gr_flat_flowgraph makes a significant > improvement but it isn't a viable option for my application because it is a > universal setting for all gnuradio based radios running on my system. Some > of which require the default buffer size to operate efficiently. > > There has been a little discussion of this topic on the mailing list in the > past but I haven't found examples that include UHD / USRP with a flowgraph > that isn't intentionally underrunning (ie with a typical UDP source block). > > I have messed with the maximum socket buffer sizes allowed by linux. The uhd > recommended config and much smaller variations don't appear to make an impact > to this latency. > $ sudo sysctl net.core.rmem_max > net.core.rmem_max = 5000 > $ sudo sysctl net.core.wmem_max > net.core.wmem_max = 1048576 > > For reference I am running: > UHD 003.005.002 > Gnuradio 3.6.4.1 > > tl;dr > My expectation is that there is a buffer UHD is attempting to maintain, when > this buffer gets low, it triggers upstream work operations in the flowgraph > to refill this buffer. Is this not the case? How can I manipulate the size > of this buffer? Is there any way to confirm the size of this buffer? > > Thanks! > > -Phelps > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph latency with UHD and continuous stream
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. This flowgraph ends with a UHD USRP sink. I am consistently observing latency through my flow graph of around 2 - 2.5sec. The total latency doesn't appear to be dependent on the sample rate (I've tested 1Msps and 2Msps). When intentionally underruning the flow graph by setting set_max_noutput_items to less than 10msec of samples, the latency through the graph is between 80msec and 200msec. Intentionally underrunning UHD isn't an option for my application as an intermittent modulated signal from the USRP causes issues. I am attempting to use the global (via gr.top_block.start()) and block specific max_noutput_items settings to limit the total amount of latency in my flow graph but this doesn't appear to be the primary source of latency. My suspicion is that UHD or the USRP has a transmit buffer which is the source of my problem. I tried messing with the send_buff_size and recv_buff_size specified here: http://files.ettus.com/uhd_docs/manual/html/transport.html but these didn't seem to make any impact. I played with setting set_max_noutput_items on the source block to the exact value expected during the 10msec select timeout in my custom source block. This works for a while but occasionally underruns. Also as udp traffic moves through the block, the total amount of latency slowly increases. It also seems wrong to throttle the flowgraph at both the source and the sink. Much like it is problematic to use a throttle with a UHD source or sink block. set_max_noutput_items doesn't seem like the right solution for this problem. Decreasing GR_FIXED_BUFFER_SIZE in gr_flat_flowgraph makes a significant improvement but it isn't a viable option for my application because it is a universal setting for all gnuradio based radios running on my system. Some of which require the default buffer size to operate efficiently. There has been a little discussion of this topic on the mailing list in the past but I haven't found examples that include UHD / USRP with a flowgraph that isn't intentionally underrunning (ie with a typical UDP source block). I have messed with the maximum socket buffer sizes allowed by linux. The uhd recommended config and much smaller variations don't appear to make an impact to this latency. $ sudo sysctl net.core.rmem_max net.core.rmem_max = 5000 $ sudo sysctl net.core.wmem_max net.core.wmem_max = 1048576 For reference I am running: UHD 003.005.002 Gnuradio 3.6.4.1 *tl;dr* My expectation is that there is a buffer UHD is attempting to maintain, when this buffer gets low, it triggers upstream work operations in the flowgraph to refill this buffer. Is this not the case? How can I manipulate the size of this buffer? Is there any way to confirm the size of this buffer? Thanks! -Phelps ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph stopped after few minutes
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 Castelldefels, Barcelona (Spain) Tel: +34 93 396 71 70 Ext: 2177 Fax. +34 93 645 29 01 www.cttc.es El 30/07/2012 13:39, Tom Rondeau escribió: > 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 nor forecast. D block (2 inputs 1 output) has >> set_output_multiple to 40+80 and its forecast is in0=(nouput/(40+80))*40 >> and in1=(noutput/(40+80))*80. All consumes are adjusted as their >> respective forecasts. >> All these blocks are encapsulated by a hier_block2 and then connected to >> a null_sink (for testing). >> >> Thanks for your help. >> >> Pol Henarejos > > Pol, > > I wouldn't use set_output_multiple for this, especially since you're > already using forecast. For block D, you might want to not use > forecast and instead keep track of what's coming in from both inputs > between calls to work. That should help keep things moving. > > Tom > > >> El 29/07/2012 16:01, Tom Rondeau escribió: >>> 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 respectively. B and C produce packets (header and payload) from the input coming from A. D packets header and payload. The latency is different since B and C produce different sizes. A produces one sample per packet (it is a kind of signaling). All blocks are gr_block. So, A produces a sample. It is delivered to B and C. Both produce header and payload using the sample produced by A. Finally, D joins together both inputs. I studied the delay between both branches and, since B is faster than C, the delay is increasing. After few minutes the flowgraph hangs and the difference of delaying is around 8000 packets. The flowgraph is in fact running. No stop is called but there are not any sample flowing. I use gnuradio master branch. Could you give me some hint for solving it? Thank you. -- Pol Henarejos >>> >>> >>> Pol, >>> >>> It's difficult to diagnose these problems. Are all blocks (A, B, C, >>> and D) that you discuss your own blocks or are some of them in GNU >>> Radio already? If you've made your own blocks to do this, have to done >>> anything with the forecast method that might be requiring samples from >>> both inputs? With B and C producing samples at different rates, you >>> can't be guaranteed that they will have enough samples to enter the >>> work function. You have to make sure that your block that takes in >>> both streams knows what to do if it's given fewer samples than >>> required (save state for reentry, basically). >>> >>> Tom >>> >> signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph stopped after few minutes
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 nor forecast. D block (2 inputs 1 output) has > set_output_multiple to 40+80 and its forecast is in0=(nouput/(40+80))*40 > and in1=(noutput/(40+80))*80. All consumes are adjusted as their > respective forecasts. > All these blocks are encapsulated by a hier_block2 and then connected to > a null_sink (for testing). > > Thanks for your help. > > Pol Henarejos Pol, I wouldn't use set_output_multiple for this, especially since you're already using forecast. For block D, you might want to not use forecast and instead keep track of what's coming in from both inputs between calls to work. That should help keep things moving. Tom > El 29/07/2012 16:01, Tom Rondeau escribió: >> 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 respectively. B and C produce packets (header and payload) from >>> the input coming from A. D packets header and payload. The latency is >>> different since B and C produce different sizes. A produces one sample >>> per packet (it is a kind of signaling). All blocks are gr_block. >>> >>> So, A produces a sample. It is delivered to B and C. Both produce header >>> and payload using the sample produced by A. Finally, D joins together >>> both inputs. >>> >>> I studied the delay between both branches and, since B is faster than C, >>> the delay is increasing. After few minutes the flowgraph hangs and the >>> difference of delaying is around 8000 packets. The flowgraph is in fact >>> running. No stop is called but there are not any sample flowing. >>> >>> I use gnuradio master branch. >>> >>> Could you give me some hint for solving it? >>> >>> Thank you. >>> >>> -- >>> >>> Pol Henarejos >> >> >> Pol, >> >> It's difficult to diagnose these problems. Are all blocks (A, B, C, >> and D) that you discuss your own blocks or are some of them in GNU >> Radio already? If you've made your own blocks to do this, have to done >> anything with the forecast method that might be requiring samples from >> both inputs? With B and C producing samples at different rates, you >> can't be guaranteed that they will have enough samples to enter the >> work function. You have to make sure that your block that takes in >> both streams knows what to do if it's given fewer samples than >> required (save state for reentry, basically). >> >> Tom >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph stopped after few minutes
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 to 40+80 and its forecast is in0=(nouput/(40+80))*40 and in1=(noutput/(40+80))*80. All consumes are adjusted as their respective forecasts. All these blocks are encapsulated by a hier_block2 and then connected to a null_sink (for testing). Thanks for your help. 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 Castelldefels, Barcelona (Spain) Tel: +34 93 396 71 70 Ext: 2177 Fax. +34 93 645 29 01 www.cttc.es El 29/07/2012 16:01, Tom Rondeau escribió: > 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 respectively. B and C produce packets (header and payload) from >> the input coming from A. D packets header and payload. The latency is >> different since B and C produce different sizes. A produces one sample >> per packet (it is a kind of signaling). All blocks are gr_block. >> >> So, A produces a sample. It is delivered to B and C. Both produce header >> and payload using the sample produced by A. Finally, D joins together >> both inputs. >> >> I studied the delay between both branches and, since B is faster than C, >> the delay is increasing. After few minutes the flowgraph hangs and the >> difference of delaying is around 8000 packets. The flowgraph is in fact >> running. No stop is called but there are not any sample flowing. >> >> I use gnuradio master branch. >> >> Could you give me some hint for solving it? >> >> Thank you. >> >> -- >> >> Pol Henarejos > > > Pol, > > It's difficult to diagnose these problems. Are all blocks (A, B, C, > and D) that you discuss your own blocks or are some of them in GNU > Radio already? If you've made your own blocks to do this, have to done > anything with the forecast method that might be requiring samples from > both inputs? With B and C producing samples at different rates, you > can't be guaranteed that they will have enough samples to enter the > work function. You have to make sure that your block that takes in > both streams knows what to do if it's given fewer samples than > required (save state for reentry, basically). > > Tom > signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph stopped after few minutes
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 respectively. B and C produce packets (header and payload) from > the input coming from A. D packets header and payload. The latency is > different since B and C produce different sizes. A produces one sample > per packet (it is a kind of signaling). All blocks are gr_block. > > So, A produces a sample. It is delivered to B and C. Both produce header > and payload using the sample produced by A. Finally, D joins together > both inputs. > > I studied the delay between both branches and, since B is faster than C, > the delay is increasing. After few minutes the flowgraph hangs and the > difference of delaying is around 8000 packets. The flowgraph is in fact > running. No stop is called but there are not any sample flowing. > > I use gnuradio master branch. > > Could you give me some hint for solving it? > > Thank you. > > -- > > Pol Henarejos Pol, It's difficult to diagnose these problems. Are all blocks (A, B, C, and D) that you discuss your own blocks or are some of them in GNU Radio already? If you've made your own blocks to do this, have to done anything with the forecast method that might be requiring samples from both inputs? With B and C producing samples at different rates, you can't be guaranteed that they will have enough samples to enter the work function. You have to make sure that your block that takes in both streams knows what to do if it's given fewer samples than required (save state for reentry, basically). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph stopped after few minutes
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 input coming from A. D packets header and payload. The latency is different since B and C produce different sizes. A produces one sample per packet (it is a kind of signaling). All blocks are gr_block. So, A produces a sample. It is delivered to B and C. Both produce header and payload using the sample produced by A. Finally, D joins together both inputs. I studied the delay between both branches and, since B is faster than C, the delay is increasing. After few minutes the flowgraph hangs and the difference of delaying is around 8000 packets. The flowgraph is in fact running. No stop is called but there are not any sample flowing. I use gnuradio master branch. Could you give me some hint for solving it? Thank you. -- 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 Castelldefels, Barcelona (Spain) Tel: +34 93 396 71 70 Ext: 2177 Fax. +34 93 645 29 01 www.cttc.es signature.asc Description: OpenPGP digital signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph for commercial FM radio TX/RX
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 > located? I am in Boston, Massachusetts, USA. In Europe it's not; there's only a minimum spacing between adjacent transmitters in the same geographical area. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpqzL3RDB7L5.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph time, or getting number of samples since start of flowgraph
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 Signal Source connected to a USRP2 Sink in order > to generate a tone. Is there any way to query the Signal Source for how many > samples it has created since the flowgraph started? > > Thanks a lot. > > Steve McMahon Time would indicate that there is a concept of a sample rate, which isn't always true and not every block is told what the sample rate is, anyways, even if the items are clocked. However, the next branch does now keep track of the number of items read and written for each input/output of each block. You can get these by calling the nitems_read and nitems_written. It returns a 64-bit number of the item count since the start of the flow graph. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] flowgraph time, or getting number of samples since start of flowgraph
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. Is there any way to query the Signal Source for how many samples it has created since the flowgraph started? Thanks a lot. Steve McMahon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph stop execution when changing sample rate of uhd_single_usrp_source
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 rates using
>> uhd_single_usrp_source the flowgraph will suspend execution and CPU
>> load drops to 0.
>> The flowgraph is still alive in the sense that it is responsive to UI
>> commands and sometimes even resumes execution for 5-10 seconds then
>> stops again. No error message appears in the terminal.
>>
>> The previous versions I have installed don't have this problem:
>> UHD_0001.20101124180824.2568efd
>> v3.3.1git-227-gb245c628
>>
>> I also tried the combination UHD_0001.20101124180824.2568efd +
>> v3.3.1git-322-ge92f2cb6 and it also has this problem which lead me to
>> suspect gr-uhd rather than uhd.
>>
>
> There was a change to the uhd single usrp source to support the tags. It
> might be getting into a condition that gets stuck in the work function.
>
> size_t total_samps = 0;
> while(total_samps + 362 < (size_t)noutput_items) {
> size_t num_samps = _dev->get_device()->recv(
> output_items, noutput_items, metadata,
> //_type, uhd::device::RECV_MODE_FULL_BUFF
> _type, uhd::device::RECV_MODE_ONE_PACKET
> );
>
> This code looks really wrong. It will loop and the output_items pointer
> doesnt increase. There is also some magic constant in there. Tom?
>
> -Josh
Yeah, there is something wrong there. We threw this together WAY too
quickly the other week. I'll look into this tomorrow. My N210 isn't
responding to network updates of the new images and I can't spend any
more time on this tonight.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph stop execution when changing sample rate of uhd_single_usrp_source
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 execution and CPU
> load drops to 0.
> The flowgraph is still alive in the sense that it is responsive to UI
> commands and sometimes even resumes execution for 5-10 seconds then
> stops again. No error message appears in the terminal.
>
> The previous versions I have installed don't have this problem:
> UHD_0001.20101124180824.2568efd
> v3.3.1git-227-gb245c628
>
> I also tried the combination UHD_0001.20101124180824.2568efd +
> v3.3.1git-322-ge92f2cb6 and it also has this problem which lead me to
> suspect gr-uhd rather than uhd.
>
There was a change to the uhd single usrp source to support the tags. It
might be getting into a condition that gets stuck in the work function.
size_t total_samps = 0;
while(total_samps + 362 < (size_t)noutput_items) {
size_t num_samps = _dev->get_device()->recv(
output_items, noutput_items, metadata,
//_type, uhd::device::RECV_MODE_FULL_BUFF
_type, uhd::device::RECV_MODE_ONE_PACKET
);
This code looks really wrong. It will loop and the output_items pointer
doesnt increase. There is also some magic constant in there. Tom?
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph stop execution when changing sample rate of uhd_single_usrp_source
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 in the sense that it is responsive to UI commands and sometimes even resumes execution for 5-10 seconds then stops again. No error message appears in the terminal. The previous versions I have installed don't have this problem: UHD_0001.20101124180824.2568efd v3.3.1git-227-gb245c628 I also tried the combination UHD_0001.20101124180824.2568efd + v3.3.1git-322-ge92f2cb6 and it also has this problem which lead me to suspect gr-uhd rather than uhd. I am using USRP1 and this happens with both WBX and RFX2400. My application is written in Python and Qt, though I don't think that makes any difference because I can reproduce it even with the simplest GRC flowgraph (attached). The major difference is that my application uses gr.top_block.lock() and unlock() when changing sample rate and doing some other reconfiguration, and this is probably why the flowgraph sometimes resumes execution for a few seconds. Let me know if any other info or testing is needed. Alex uhd_test.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph for commercial FM radio TX/RX
Hello Bernardo Gonçalves: No, I have not yet obtained any other materials/flowgraphs other than what Markus Heller posted on this mail list. However, I do not have time to look into the FM radio TX/RX right now as I am very busy trying to finish something else. I will start working on it again in about one week. Let's talk again at that time. Have you found any other materials? I would be interested in collaborating with you on this. Are you trying to do the same thing that I'm trying to do (create a flowgraph for TX and/or RX of commercial FM radio)? You also asked about other non-FM-radio flowgraphs. I do have some other flowgraphs that I would be happy to share with you. What are you looking for? 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 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 Mcmahon" Date: Wednesday, December 1, 2010, 1:59 PM Hello Steve, I have read your email a long ago and since I am working on similar stuff (only for simulation purposes), I would like to know if you got some other materials with other flowgraphs. I know that Markus Heller answered your email with his website, but I am looking for more. Do you have any other flowgraph (not only FM ones)? Thanks! Regards,Bernardo On Tue, Nov 9, 2010 at 11:33 PM, Steve Mcmahon wrote: 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 band, to be received by a standard FM radio. In the receive case, I would like to capture and demodulate commercial FM radio and save the raw PCM audio data to a file for playback. This is for academic, proof-of-concept, very low-power purposes. I am not using it to operate a pirate FM radio station. I appreciate your help. Thanks. Steve McMahon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph slows down and hangs when using benchmark_tx with a custom block
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 dbpsk.py and upon doing so the flowgraph slows down incredibly. What can I do to speed up the process? DiffEnc --> Custom Block --> Chunks2Symbols ( n ouputs) --> (n * 1000 outputs) --> (n *1000 outputs) Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowgraph for commercial FM radio TX/RX
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://www.snowymtn.ca/GNURadio/GNURAdioDoc-7.pdf http://www.linuxjournal.com/article/7505 For a nice receiver there's this neat little Python program from Michel Barbeau: http://people.scs.carleton.ca/~barbeau/SDR/Python/radio.py ...which you might download right away with "wget". BR Markus DL8RDS Am Dienstag, den 09.11.2010, 17:33 -0800 schrieb Steve Mcmahon: > 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 band, to be received by a > standard FM radio. > > In the receive case, I would like to capture and demodulate commercial FM > radio and save the raw PCM audio data to a file for playback. > > This is for academic, proof-of-concept, very low-power purposes. I am not > using it to operate a pirate FM radio station. > > I appreciate your help. > Thanks. > > Steve McMahon > > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] flowgraph for commercial FM radio TX/RX
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 band, to be received by a standard FM radio. In the receive case, I would like to capture and demodulate commercial FM radio and save the raw PCM audio data to a file for playback. This is for academic, proof-of-concept, very low-power purposes. I am not using it to operate a pirate FM radio station. I appreciate your help. Thanks. Steve McMahon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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. If we can define enough > need, then we can talk more about finding the right way about it. > > Eric's suggestion is a good start. Tell it how many items you want and > then run the loop based off that number or the noutput_items, > whichever is smaller. If this works well for you, we might want to > find a way of integrating that concept as part of the > scheduler/basic_block. > > Well, like I said, we can think this through more clearly if you come > up with positive results with that hack. > > Tom > > I hacked in a hard-coded value as a temporary test that amounts to 100msec worth of "super symbols" (the actual symbols are di-bits, at a nominal 4800symbol/sec rate, but I send 1200 packed bytes/second over the FIFO) from my external source. Looking at the debug logging setup by the scheduler, the scheduler has asked for 32767 noutput_items on the gr.file_source() in my flow-graph, and I'm returning 100msec worth (which is 120 items in my case). The result is a flow-graph that runs with much less apparent latency, depending on what blocks I pick. If I put in an interpolator block as the last item in the graph before the FFT display, it becomes "chunky" again, so I put in a rational resampler to resample up to the final channel bandwidth (mininum 500KHz for a USRP2, if I've done my math correctly :-) ). But the result is quite a bit more CPU hungry than the previous "fits and starts" version of the flow-graph. So this little hack is instructive, but not in and of itself any kind of path forward. It seems like some kind of global approach to the latency issue for narrow-bandwidth/low-event-rate applications is definitely worth discussing. Likely much careful treading required :-) -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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 rate and >> > that should clean things up. >> > >> > Tom >> > >> > >> I also noted in the reply to Eric that I observe the same behaviour with >> an external source that is producing 4800 symbols/second--so >> it's not the throttle *per se*, but rather the way that work "chunks" >> get scheduled in Gnu Radio. With a "fast" source, you dont find yourself >> in a situation where there aren't enough "chunks" to keep things busy. >> >> But a very reasonable example would be something like a cross-band >> digital repeater application, where bits/symbols would be arriving >> at the "channel rate", and need to leave the Tx in something at least >> approaching real time--you certainly need to have a bit of >> elastic buffering to compensate for clock-skew between the two sides, >> but several-tens-of-seconds of latency isn't likely to be very >> useful in the real world. >> >> Note that I'm not criticizing anybody or anything. I'm making >> observations, and I *do* understand *why* it is the way it is. >> My little test flow-graph failed the "least astonishment test", which >> is why I felt I needed to comment. >> >> Would it be reasonable to open a discussion about this class of >> flow-graph? I think they can be characterized as flow-graphs with >> a low symbol rate, and high interpolation (which I think is where the >> buffer-multiplier effect may be coming into play). In such flow-graphs, >> would it be reasonable to be able to "tweak" the scheduler to deal >> with this type of situation? I have little insight into how the scheduler >> works in detail, but I think I understand the "fits and starts" that I >> was observing. >> >> So, is this a reasonable discussion topic? Are other folks working on >> "stuff" that will run into part of the performance diagram I ran >> into yesterday? Or is everyone else working on high-event-rate type >> signal chains? > > Marcus, > > This is certainly a reasonable discussion topic. > I suggest before wading in that you first enable the scheduler logging > that I mentioned in a prior post and take a look at that. > > Feel free to send me the logs too. > > What we're looking for is which block is forcing the large chunk size. > If you were reading from a file using for example gr.file_source, it > won't return until until it's completely filled up the downstream > buffer given to it. That's just how it's written. > > A trivial change would be to have it loop until it it read > min(N_USER_SPECIFIED_ITEMS, noutput_items) items. > > Eric 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. If we can define enough need, then we can talk more about finding the right way about it. Eric's suggestion is a good start. Tell it how many items you want and then run the loop based off that number or the noutput_items, whichever is smaller. If this works well for you, we might want to find a way of integrating that concept as part of the scheduler/basic_block. Well, like I said, we can think this through more clearly if you come up with positive results with that hack. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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 > > > > > I also noted in the reply to Eric that I observe the same behaviour with > an external source that is producing 4800 symbols/second--so > it's not the throttle *per se*, but rather the way that work "chunks" > get scheduled in Gnu Radio. With a "fast" source, you dont find yourself > in a situation where there aren't enough "chunks" to keep things busy. > > But a very reasonable example would be something like a cross-band > digital repeater application, where bits/symbols would be arriving > at the "channel rate", and need to leave the Tx in something at least > approaching real time--you certainly need to have a bit of > elastic buffering to compensate for clock-skew between the two sides, > but several-tens-of-seconds of latency isn't likely to be very > useful in the real world. > > Note that I'm not criticizing anybody or anything. I'm making > observations, and I *do* understand *why* it is the way it is. > My little test flow-graph failed the "least astonishment test", which > is why I felt I needed to comment. > > Would it be reasonable to open a discussion about this class of > flow-graph? I think they can be characterized as flow-graphs with > a low symbol rate, and high interpolation (which I think is where the > buffer-multiplier effect may be coming into play). In such flow-graphs, > would it be reasonable to be able to "tweak" the scheduler to deal > with this type of situation? I have little insight into how the scheduler > works in detail, but I think I understand the "fits and starts" that I > was observing. > > So, is this a reasonable discussion topic? Are other folks working on > "stuff" that will run into part of the performance diagram I ran > into yesterday? Or is everyone else working on high-event-rate type > signal chains? Marcus, This is certainly a reasonable discussion topic. I suggest before wading in that you first enable the scheduler logging that I mentioned in a prior post and take a look at that. Feel free to send me the logs too. What we're looking for is which block is forcing the large chunk size. If you were reading from a file using for example gr.file_source, it won't return until until it's completely filled up the downstream buffer given to it. That's just how it's written. A trivial change would be to have it loop until it it read min(N_USER_SPECIFIED_ITEMS, noutput_items) items. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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 external source that is producing 4800 symbols/second--so it's not the throttle *per se*, but rather the way that work "chunks" get scheduled in Gnu Radio. With a "fast" source, you dont find yourself in a situation where there aren't enough "chunks" to keep things busy. But a very reasonable example would be something like a cross-band digital repeater application, where bits/symbols would be arriving at the "channel rate", and need to leave the Tx in something at least approaching real time--you certainly need to have a bit of elastic buffering to compensate for clock-skew between the two sides, but several-tens-of-seconds of latency isn't likely to be very useful in the real world. Note that I'm not criticizing anybody or anything. I'm making observations, and I *do* understand *why* it is the way it is. My little test flow-graph failed the "least astonishment test", which is why I felt I needed to comment. Would it be reasonable to open a discussion about this class of flow-graph? I think they can be characterized as flow-graphs with a low symbol rate, and high interpolation (which I think is where the buffer-multiplier effect may be coming into play). In such flow-graphs, would it be reasonable to be able to "tweak" the scheduler to deal with this type of situation? I have little insight into how the scheduler works in detail, but I think I understand the "fits and starts" that I was observing. So, is this a reasonable discussion topic? Are other folks working on "stuff" that will run into part of the performance diagram I ran into yesterday? Or is everyone else working on high-event-rate type signal chains? Cheers -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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 while with > zero bytes in it, then really a lot of bytes, then no more bytes for > quite some time, then > another lump of bytes, etc. I confirmred that the "producer" end of > the FIFO was producing > bytes at the correct rate. > > So when I'm sending "real" data to an actual USRP (f'rexample), the > symbols will get clocked out at the right rate, provided > that I issue those bits in sufficiently large lumps to prevent the > USRP from underrun on transmit. > > But what about situations where you might have a source of bits that's > running in "real time" (like my little test case with the > external FIFO), and you'd like the resulting symbols to be "clocked > out" at something resembling "real time"? My test case > was just a test case, but I can certainly imagine situations where it > actually matters. Remember that GNU Radio runs stuff through each signal processing block in "chunks." These chunk sizes can be around 100 to 32000 items in size, more when there is time to spare and less when the system is trying to operate quickly. When you're running with a sample rate of 4800, that's going to pass 4800 samples each second. At this rate, the GNU Radio scheduler is likely using very large block sizes (you could print out the value of noutput_items in one of the work functions to see for sure). Let's say that, generally, each block is given an noutput_items=8192. That's almost 2 seconds worth of data. I just created a simple flowgraph in GRC with a noise source, throttle, and scope sink. With varying rates on the throttle, you can get see this happening. With such a simple flowgraph, the noutput_items is always either 4095 or 4096, so it's pretty regular. With a rate of 4800, you get a scope update about every second. I've seen something like what you were observing with more complicated flowgraphs with very small sample rates; when the scheduler doesn't produce the same number of items each time through, it runs in "fits and starts" as you said. Conversely, when running with a source like the USRP, the USRP source is being run at a minimum of 250 ksps, so the flow graph has to work to keep up with that and therefore runs data through the whole graph "faster" but only because the sinks are being updated with new data more quickly. Like Eric said, remove the throttle or at least change the rate and that should clean things up. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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. Think about it: what > definitely of time to you use? Over what period of time do you > average, etc, etc. > > I understand that. See below. > > It will do the right thing, assuming that all blocks "do the right > thing" and compute as much output as they are asked to. > > > You don't send it at the right rate, you let the sink (or source) > handle the timing issues. > > > Note that NONE of GNU Radio has any idea of the actual sample rate. > > There are some places where sample rates are used (e.g., > gr.sig_source), but they are there as a convenience so that people > don't have to continually puzzle over normalized frequencies. > However, this may give the impression that "sample_rate" actually > means something in the real world, and it doesn't --- with the exception > of i/o devices connected to a sample clock. > > Yes, I "get" that. > The display may appear to run in "fits and starts" because the > internal decimation rate of the sink may be too high for the throttled > data rate that you're sending. It may take a long time to get enough > data for the FFT sink to display anything. Or there could be bugs in > the sink... > > E.g., the GL fft sink has at least a bug or two related to the > mis-specification of python's '/' operator. If you use integers, > 1/3 == 0, but 1.0/3 = . The bug I'm thinking of shows up as a divide > by zero in the persistence code when the ftt sink is invoked with its > default parameters (sample_rate = 1, fft_rate = 15). There may also > be problems with mapping the user provided fft_rate into the > decimation factor of the keep_one_in_n block. Not sure about that > one, but this is a place where it's possible to ask for ill-specified > behavior. E.g., if I say that the fft_rate is 15, and my sample rate > is 1, do I expect interpolation by 15??? > > > See Python PEP-238 for background on the divide issue and the use of > > from __future__ import division > > to debork the behavior of '/', and possibly help fix the sinks. > > 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 while with zero bytes in it, then really a lot of bytes, then no more bytes for quite some time, then another lump of bytes, etc. I confirmred that the "producer" end of the FIFO was producing bytes at the correct rate. So when I'm sending "real" data to an actual USRP (f'rexample), the symbols will get clocked out at the right rate, provided that I issue those bits in sufficiently large lumps to prevent the USRP from underrun on transmit. But what about situations where you might have a source of bits that's running in "real time" (like my little test case with the external FIFO), and you'd like the resulting symbols to be "clocked out" at something resembling "real time"? My test case was just a test case, but I can certainly imagine situations where it actually matters. > If you want to see the details of what the scheduler is doing, > change > > #define ENABLE_LOGGING 0 > > to > > #define ENABLE_LOGGING 1 > > at the top of gr_block_executor.cc It will then create a separate ASCII > log file for each block. They're named "sst-NNN.log". The first line > of each log identifies the block. > > Hope this helps! > > Eric > > > -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph running in "fits and starts"
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 throttled to the byte rate required to produce the correct > number of symbols/second (4800). 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. Think about it: what definitely of time to you use? Over what period of time do you average, etc, etc. /*! * \brief throttle flow of samples such that the average rate does not exceed samples_per_sec. * \ingroup misc_blk * * input: one stream of itemsize; output: one stream of itemsize * * N.B. this should only be used in GUI apps where there is no other * rate limiting block. It is not intended nor effective at precisely * controlling the rate of samples. That should be controlled by a * source or sink tied to sample clock. E.g., a USRP or audio card. */ > What I've noticed is that this graph only runs in "fits and starts", > rather than continuously. I assume this has something to > do with the Gnu Radio buffering and internal scheduler. > In the case of a "real" flow-graph, taking real data in at > 4800symbols/second, going to a real USRP transmitter, will it still > run in "fits and starts" or will it "do the right thing"?? It will do the right thing, assuming that all blocks "do the right thing" and compute as much output as they are asked to. > I realize that buffering is an important part of Gnu Radio, but how do > you actually send low-rate data in something approaching > correct real-time? You don't send it at the right rate, you let the sink (or source) handle the timing issues. Note that NONE of GNU Radio has any idea of the actual sample rate. There are some places where sample rates are used (e.g., gr.sig_source), but they are there as a convenience so that people don't have to continually puzzle over normalized frequencies. However, this may give the impression that "sample_rate" actually means something in the real world, and it doesn't --- with the exception of i/o devices connected to a sample clock. > I at first thought this was due to the throttle block, so I replaced it > with an external (via a FIFO) source that produced random bytes > at a 1200-bytes/second rate (2 bits/symbol), and it behaves exactly > the same as a a throttled random source--the graph seems to run in > "fits and starts". The display may appear to run in "fits and starts" because the internal decimation rate of the sink may be too high for the throttled data rate that you're sending. It may take a long time to get enough data for the FFT sink to display anything. Or there could be bugs in the sink... E.g., the GL fft sink has at least a bug or two related to the mis-specification of python's '/' operator. If you use integers, 1/3 == 0, but 1.0/3 = . The bug I'm thinking of shows up as a divide by zero in the persistence code when the ftt sink is invoked with its default parameters (sample_rate = 1, fft_rate = 15). There may also be problems with mapping the user provided fft_rate into the decimation factor of the keep_one_in_n block. Not sure about that one, but this is a place where it's possible to ask for ill-specified behavior. E.g., if I say that the fft_rate is 15, and my sample rate is 1, do I expect interpolation by 15??? See Python PEP-238 for background on the divide issue and the use of from __future__ import division to debork the behavior of '/', and possibly help fix the sinks. If you want to see the details of what the scheduler is doing, change #define ENABLE_LOGGING 0 to #define ENABLE_LOGGING 1 at the top of gr_block_executor.cc It will then create a separate ASCII log file for each block. They're named "sst-NNN.log". The first line of each log identifies the block. Hope this helps! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph running in "fits and starts"
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 (4800). What I've noticed is that this graph only runs in "fits and starts", rather than continuously. I assume this has something to do with the Gnu Radio buffering and internal scheduler. In the case of a "real" flow-graph, taking real data in at 4800symbols/second, going to a real USRP transmitter, will it still run in "fits and starts" or will it "do the right thing"?? I realize that buffering is an important part of Gnu Radio, but how do you actually send low-rate data in something approaching correct real-time? I at first thought this was due to the throttle block, so I replaced it with an external (via a FIFO) source that produced random bytes at a 1200-bytes/second rate (2 bits/symbol), and it behaves exactly the same as a a throttled random source--the graph seems to run in "fits and starts". -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph generates output even when the input exhausts
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 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 input_02 > > exhausts output is still generated even though I see no problem with my > C++ > > code. Its a simple operation in which for each input in Input_02 line the > > block outputs 'N' items from Input_01. Once, the data source (in this > case > > is a file_source in non-repeat mode) for Input_02 exhausts i.e. the file > is > > read completely the output should stop being generated as there is > nothing > > coming on Input_02. I expect the previous data stored in the buffer for > > Input_02 is flushed by the scheduler after one work() cycle. > > > > Any help would be appreciated. > > Thanks, > > Mir > > GNU Radio does work the way you described. You can confirm this by > doing something like: > > src1 = gr.vector_source_f((1,2,3,4,5,6), False) > src2 = gr.vector_source_f((10,11,12,13,14,15), True) > op = gr.add_ff() > dst = gr.vector_sink_f() > > tb.connect(src1, (op, 0)) > tb.connect(src2, (op, 1)) > tb.connect(op, dst) > > tb.run() > > This will halt. > > There is most likely a problem in your block. If you're subclassing > gr_block, are you calling consume or consume_each? > > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flowgraph generates output even when the input exhausts
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 the > input lines. I see in my flowgraph that even when the data on input_02 > exhausts output is still generated even though I see no problem with my C++ > code. Its a simple operation in which for each input in Input_02 line the > block outputs 'N' items from Input_01. Once, the data source (in this case > is a file_source in non-repeat mode) for Input_02 exhausts i.e. the file is > read completely the output should stop being generated as there is nothing > coming on Input_02. I expect the previous data stored in the buffer for > Input_02 is flushed by the scheduler after one work() cycle. > > Any help would be appreciated. > Thanks, > Mir GNU Radio does work the way you described. You can confirm this by doing something like: src1 = gr.vector_source_f((1,2,3,4,5,6), False) src2 = gr.vector_source_f((10,11,12,13,14,15), True) op = gr.add_ff() dst = gr.vector_sink_f() tb.connect(src1, (op, 0)) tb.connect(src2, (op, 1)) tb.connect(op, dst) tb.run() This will halt. There is most likely a problem in your block. If you're subclassing gr_block, are you calling consume or consume_each? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flowgraph generates output even when the input exhausts
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 input_02 exhausts output is still generated even though I see no problem with my C++ code. Its a simple operation in which for each input in Input_02 line the block outputs 'N' items from Input_01. Once, the data source (in this case is a file_source in non-repeat mode) for Input_02 exhausts i.e. the file is read completely the output should stop being generated as there is nothing coming on Input_02. I expect the previous data stored in the buffer for Input_02 is flushed by the scheduler after one work() cycle. Any help would be appreciated. Thanks, Mir ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
