On Fri, Jul 08, 2011 at 05:57:17AM +, Höin Michael (hoim) wrote:
> Hi all
>
> I have a simulation problem with my time interleaving block. If I simulate my
> block the most time all tests get passed, but in average every 7th simulation
> the tests don't pass and I get the message:
>
> Trace
Hi Martin
This was the solution. Many thanks!
I don't realize that in simulations I had also to use the throttles.
Gruss aus der Schweiz :-)
Michael
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/disc
On Fri, Jul 08, 2011 at 10:26:57AM +0200, Michael Höin wrote:
> Hi Martin
>
> This was the solution. Many thanks!
> I don't realize that in simulations I had also to use the throttles.
Hi Michael,
you shouldn't *have* to use throttles--I believe there's a bug somewhere
in the scheduling or memor
On 07/06/2011 07:33 PM, Morgan Redfield wrote:
> I'm still working on my MAC, and there's a lot of room for
> improvement. At the moment, I get throughput of about 1kbps. What kind
> of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using
On 07/06/2011 07:33 PM, Morgan Redfield wrote:
> I'm still working on my MAC, and there's a lot of room for
> improvement. At the moment, I get throughput of about 1kbps. What kind
> of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using
On 07/06/2011 07:33 PM, Morgan Redfield wrote:
> I'm still working on my MAC, and there's a lot of room for
> improvement. At the moment, I get throughput of about 1kbps. What kind
> of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using
Hi Martin
Here the python-testcode:
https://home.zhaw.ch/~hoim/qa_howto.py
(Without the throttle sometimes the test fails)
Here the whole C++ -entity-code:
https://home.zhaw.ch/~hoim/howto_time_interleaving_vff.cc
Have fun :-)
Michael
-
Zuric
Hey guys,
I am implementing a probe block that stores several values to a member
struct so they can be read from pyhton via accessor method
(get_probe_values() const {return probe_struct;}).
Now my question is: Is it necessary to use some kind of thread locking
mechanism to prevent gnuradio from ch
On 08/07/2011 9:39 AM, Drury, Ian wrote:
Hello Marcus,
I have just done an install using your script and it worked fine in that
it all the required software seemed to be installed and the build seemed
to run& complete OK for both UHD& GNU Radio.
I tried running gr-uhd/uhd_fft.py and got an er
Hello Marcus,
I have just done an install using your script and it worked fine in that
it all the required software seemed to be installed and the build seemed
to run & complete OK for both UHD & GNU Radio.
I tried running gr-uhd/uhd_fft.py and got an error:
[root@LinuxPC apps]# python uhd_fft.p
On Fri, Jul 8, 2011 at 05:45, Johannes Schmitz wrote:
> I am implementing a probe block that stores several values to a member
> struct so they can be read from pyhton via accessor method
> (get_probe_values() const {return probe_struct;}).
> Now my question is: Is it necessary to use some kind
Hello, I'm trying to use a recently purchased DBSRX2 + USRP1 combination.
Although the board shows some signs of life, it's difficult to make sense of
the fft spectrum. In investigating, I found that the daughterboard id does
not seem to be correct. In particular, the gnuradio software reports dbid
On 08/07/2011 1:57 PM, Prachi Parihar wrote:
Hello, I'm trying to use a recently purchased DBSRX2 + USRP1
combination. Although the board shows some signs of life, it's
difficult to make sense of the fft spectrum. In investigating, I found
that the daughterboard id does not seem to be correct.
Thanks for your answer.
> Yes, this is not only possible but likely to happen. You will need to
> acquire a mutex in your work function just prior to updating the probe data,
> and release it afterward. The accessor function also needs to do the same,
> copy the probe data locally, then release
I changed my code to use boost::mutex now. Therefore I included
#include
Then I did something like this, which made my program go into a deadlock :(
in header:
boost::mutex d_metric_mutex;
in .cc
d_metric_mutex.lock();
d_metric.x = 1
d_metric.y = 2
d_metric_mutex.unlock();
and accessor:
metri
Dear all,
I installed GNURadio+UHD on USRP E200 in Ubuntu 10.10 system by using the
build-gnuradio script Marcus offered. After installation successfully
completely, using uhd_find_devices gave the result:
--
-- UHD Device 0
---
On Fri, 2011-07-08 at 17:00 -0400, Yan Nie wrote:
> Dear all,
>
> I installed GNURadio+UHD on USRP E200 in Ubuntu 10.10 system by using the
> build-gnuradio script Marcus offered. After installation successfully
> completely, using uhd_find_devices gave the result:
>
Hi All,
Do all blocks pass stream tags by default? Or do certain ones drop a stream
tag? I have an application where a downstream block searches for a tag added
by an up stream one, but it never finds the tag. =\
--Colby
___
Discuss-gnuradio mailing lis
Derp.
Nevermind, I'm stupid.
--Colby
On Fri, Jul 8, 2011 at 3:18 PM, Colby Boyer wrote:
> Hi All,
>
> Do all blocks pass stream tags by default? Or do certain ones drop a stream
> tag? I have an application where a downstream block searches for a tag added
> by an up stream one, but it never f
19 matches
Mail list logo
