Hi List,
from my understanding of the code, this caveat still exists. And I have the
same problem with this block as Achilleas.
Johnathan: As you wrote in the cited post that you would be working on that
after 3.7.0, could you please give an update on the state of work?
How can we support?
Mit
Hi,
Yes, this looks like a pretty big issue to me too. 100% CPU spinning
is just not acceptable, ever.
To me it look like all it's missing is a
basic_block::delete_head_blocking with a timeout. Then the
pdu_to_tagged_stream_impl::calculate_output_stream_length could just
use that with a reasona
Hi,
When I add an xmlrpc server block in GnuRadio 3.7.5, I'm not able to stop
the flow graph pressing Enter any more. I have to manually add the shutdown
call to the server in the generated script (see below). Am I doing
something wrong, is it expected or is this a bug?
...
raw_input('Press E
No chance, I do not get any stable audio performance, I assume the Kubuntu
sound system is defective somehow. It is not about sampling rates, the pitch
is correct, just choppy. When calling the dial tone script repeatedly,
sometimes it works, sometimes it causes garbled sounds, then again it works,
Just a warning:
pdu_to_tagged_stream saw significant change in the middle of last
december; so make sure you're all talking about the same version :)
Greetings,
Marcus
On 01/14/2015 11:29 PM, Achilleas Anastasopoulos wrote:
> Hi all,
>
> I have the following problem that is been bugging me for qu
> Just a warning:
> pdu_to_tagged_stream saw significant change in the middle of last december;
> so make sure you're all talking about the same version :)
Just tried with the last version and the issue is definitely there.
I'm not entirely sure what motivated the fact of making it a TSB
source,
Stupid question:
at least in the old version of the code, the current message was popped
from the queue using delete_head_nowait().
Why don't we just delete_head_blocking() and -- block?
Greetings,
Marcus
On 01/15/2015 01:59 PM, Sylvain Munaut wrote:
>> Just a warning:
>> pdu_to_tagged_stream saw
On Thu, Jan 15, 2015 at 2:01 PM, Marcus Müller wrote:
> Stupid question:
> at least in the old version of the code, the current message was popped
> from the queue using delete_head_nowait().
> Why don't we just delete_head_blocking() and -- block?
I think this would prevent the flow graph from s
Hi,
On 01/15/2015 02:26 PM, Sylvain Munaut wrote:
> >Why don't we just delete_head_blocking() and -- block?
> I think this would prevent the flow graph from stopping because it
> would block there indefinitely.
Yes, a friendly cohabitant of this lab just told me to rtfm and also
consider it; I do a
Some background: It was made a TSB block because TSB source blocks
weren't possible until recently, and that's an example use-case. Doesn't
solve the spinning issue.
On 01/15/2015 02:26 PM, Sylvain Munaut wrote:
> On Thu, Jan 15, 2015 at 2:01 PM, Marcus Müller
> wrote:
>> Stupid question:
>> at
Ok. First instruction that I do not know how to execute is the import variable
block that says "import coma.cdma_parameters as cp". What exactly am I supposed
to be replacing in this section.
On Wednesday, January 14, 2015 7:08 PM, Frank Pinto
wrote:
Ok. First instruction that I do
On 01/15/2015 12:59 AM, Sylvain Munaut wrote:
> To me it look like all it's missing is a
> basic_block::delete_head_blocking with a timeout. Then the
> pdu_to_tagged_stream_impl::calculate_output_stream_length could just
> use that with a reasonably small timeout (like 100ms or so) so that it
> wa
There is no such instruction to be executed!
Please read the README.md file and let us know which one of the detailed
instructions mentioned there you don't know how to execute.
Achilles
On Thu, Jan 15, 2015 at 10:52 AM, Frank Pinto
wrote:
> Ok. First instruction that I do not know how to exec
Frank,
you have to follow the procedure in README by compiling ONE file at a time,
and RELOADING the blocks as you go on, ie,
Load the hier block "amp_var_est_hier.grc",
Compile it (this little button on GRC that looks like a pyramid, a sphere
and an arrow)
Reload it (this little circle button on
<<< text/html; charset=us-ascii: Unrecognized >>>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi all,
I've been slowly working to understand/isolate an issue with a strange voltage
pulse at all freqs and on USRP N210 with 50 Ohm load.
I posted about it on StackExchange here, and there are more details at this
link:
http://stackoverflow.com/questions/27968237/semi-consistent-voltage-pul
On 01/15/2015 12:26 PM, Anderson, Douglas J. wrote:
Hi all,
I've been slowly working to understand/isolate an issue with a strange
voltage pulse at all freqs and on USRP N210 with 50 Ohm load.
I posted about it on StackExchange here, and there are more details at
this link:
http://stackover
In general you cannot use the first few samples of output from an
acquisition. There are a couple of reasons:
First, if you begin collecting data immediately (rather than using UHD to
schedule a collection at a given time) and you are using a daughterboard
with a downconverter (anything but BasicR
Okay, this makes sense.
What about the version I posted on StackExchange where I am using GNU Radio's
scheduler to request the samples?
What does GNU Radio do when running a constant flowgraph (like uhd_fft) that it
doesn't to when running topblock.run() for each collection, as far as
discardi
Nothing. The timing might be a little different -- if it's tuning effects
you're seeing, there's effectively a race condition between tuning and
sample collection. Gnuradio will never discard samples off the front unless
you use a Skip Head block, which you should probably be doing as evidently
you
On 01/15/2015 12:40 PM, Nick Foster wrote:
Second, there are digital halfband and CIC filters in the USRP, and
they are not reset between acquisitions. This means that the first
samples will have some junk left over from the last acquisition.
If the filters were "reset", what would they be
I don't think it's tuning effects, if I'm understanding that correctly. You
mean that after you retune the USRP, the LO will take some time to settle?
In the script I posted, that shouldn't be a factor, as the UHD instance is
created and tuned when I import the file in the python interpreter, an
Hey guys,
dev call January starts soon, if you want to join, ping me in IRC.
Cheers,
M
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 01/15/2015 12:55 PM, Anderson, Douglas J. wrote:
I don't think it's tuning effects, if I'm understanding that
correctly. You mean that after you retune the USRP, the LO will take
some time to settle?
In the script I posted, that shouldn't be a factor, as the UHD
instance is created and tun
Marcus, thank you.. the "optimized for steady state streaming" comment confirms
some suspensions, although I'd love to understand more deeply why exactly this
happens consistently to acquisitions long after a retune.
I think the code snippet I posted to StackExchange might illustrate the
differ
Frank,
Please do the following and report to us what you get.
Open a python session and write
>>> from cdma import cdma_parameters as cp
What is the result of this?
Achilleas
On Thu, Jan 15, 2015 at 12:12 PM, Frank Pinto
wrote:
> Hello Sir, I just tried that and the first the hier block
>
The result is:Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/cdma/__init__.py", line 34, in
import cdma_parameters
File "/usr/local/lib/python2.7/dist-packages/cdma/cdma_parameters.py", line
124, in
payload_mod =
[digital.cons
Hi,
>> To me it look like all it's missing is a
>> basic_block::delete_head_blocking with a timeout. Then the
>> pdu_to_tagged_stream_impl::calculate_output_stream_length could just
>> use that with a reasonably small timeout (like 100ms or so) so that it
>> waits on a message but if none comes,
On 01/15/2015 01:11 PM, Anderson, Douglas J. wrote:
Marcus, thank you.. the "optimized for steady state streaming" comment
confirms some suspensions, although I'd love to understand more deeply
why exactly this happens consistently to acquisitions long after a retune.
I think the code snippet
I guess in my mind, once the usrp_source device and flowgraph instances were
created and connected, run() would just be pulling samples through the blocks.
I read through a presentation on the GNU Radio flowgraph yesterday on
gnuradio.squarespace.com (can't find the exact link ATM) but failed to
On Thu, Jan 15, 2015 at 1:41 PM, Salman Dinani wrote:
> Hi to all,
>
> Thanks very much to all of you for your valuable suggestions.In accordance
> with your suggestions, I experimented with my designed DQPSK system and got
> few problems which I am listing down.All the referenced figures are
> at
Hi,
For reading your data from file, you need to have a binary data file. Libre
office file has a header and after that your text " ", in which "1"
or "0' is a char not a bit!
GNURadio bit generation sources assume "0" is a byte of bits "" and
"1" is a byte of bits "1000". So y
OK, great.
This is due to the fact a recent pull request has not yet been merged into
gnuradio.
SO the constellation module does not have yet the
"constellation_8psk_natural"
constellation.
There is a simple fix to that:
please go to your gr-cdma/python directory
and edit the file
cdma_parameter
Hi,
I had this same aU problem a few months ago on Linux Mint, but was able to
resolve it by editing the default ALSA settings in ~/.gnuradio/config.conf .
I will send detailed notes on the exact fix I made when I get home, but I
just found this page also describing the fix:
http://www.funwithele
Hi,
iam testing an UKW Radio Receiver GRC project (gr-rds) on bananapi. The
application starts. The tuned radio station sounds clicking. Changing
any parameter in the GUI is very difficult/slow.
top tells me a memory usage about 20 %. CPU usage is nearly 200 %
(bananapi has 2 CPUs). At any w
Post a screenshot of your flowgraph. Sounds like a sample rate mismatch.
On Fri, Jan 16, 2015 at 8:38 AM, Andreas Ladanyi
wrote:
> Hi,
>
> iam testing an UKW Radio Receiver GRC project (gr-rds) on bananapi. The
> application starts. The tuned radio station sounds clicking. Changing any
> paramete
I have applied the change, now the error reads: AttributeError: 'module' object
has no attribute 'constellation_16qam'
On Thursday, January 15, 2015 3:37 PM, Achilleas Anastasopoulos
wrote:
OK, great.
This is due to the fact a recent pull request has not yet been merged into
gnur
Hello Andreas,
you never need a throttle block when you have hardware that
limits/defines your real-world sampling rate; in your case, it's your RF
hardware and your sound card.
Aside from things like implicit resampling in the audio card driver
infrastructure, it's absolutely possible that your b
Hi Frank,
For the same reason, constellation_16qam is not in the current
constellation module yet. Unlike 8psk_natural which you have a replacement
constellation_8psk, no 16-ary constellation is available in current
constellation module.
You can try to modify the cdma_parameter.py by deleting the
Hello all,
I've used pybombs to install uhd+gnuradio on CentOS 6.6 x86_64.
I then executed ./pybombs env and sourced the generated file in my .bashrc.
After completely restarting my computer to make sure nothing funny was
going on, my terminal continues not to recognize gnuradio-companion as a
c
Ok, here are the contents of my ~/.gnuradio/config.conf:
[audio_alsa]
default_input_device = default
default_output_device = default
#period_time = 0.010 # in seconds (default)
period_time = 0.100 # in seconds
nperiods = 4 # total buffering
On 01/16/2015 12:58 AM, Marcus Müller wrote:
> Hello Andreas,
>
> you never need a throttle block when you have hardware that
> limits/defines your real-world sampling rate; in your case, it's your RF
> hardware and your sound card.
> Aside from things like implicit resampling in the audio card dr
On 01/16/2015 02:10 AM, Richard Bell wrote:
> I've used pybombs to install uhd+gnuradio on CentOS 6.6 x86_64.
>
> I then executed ./pybombs env and sourced the generated file in my .bashrc.
>
> After completely restarting my computer to make sure nothing funny was
> going on, my terminal continue
43 matches
Mail list logo
