I like to call an external programmed python function inside of GRC
decoding a slow byte stream.
Therefore I made a simple experiment:
See
http://elho02.fbe.hs-bremen.de/~hartje/GRC/func_versuch.grc
Signalsource with samp_rate 3200
Throttle 3200
VariableSink V2
Variable Text BOX V2 (showing the
Hi,I've got another question. I implemented an OFDM-transmission eviroment and now I additionally added channel coding. It works fine, but when using trellis modulator and viterbi decoder, the packeterrorrate increases.I realized the blockbuilding, using a message_queue counting the incomming
Hi everyone,
I want to test something with usrp running continously under normal
environment.
Can someone tell me the real data of how long usrp is capable of running
continously.
Thanks.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
On 09/09/2010 08:41 AM, Matteo Carucci wrote:
Hi,
I just want to ask a very simple question.
The i q samples on the fpga design that come out of dsp_core_rx are
in 2's complement or in sign magnitude notation?
Everything we do is 2's comp
___
The UHD branch includes all the work from the VRT branch, and the old
VRT branch has been removed. UHD is where everything is happening.
Matt
On 09/09/2010 02:31 AM, Zohair M. Abu-Shaban wrote:
Thanks Matt for the information.
Actually, I meant to ask a wider question about the difference
As far as I can tell, EVENT_CODE_SUCCESS (Defined as success: a packet was
successfully transmitted) events never seem to happen. That's okay with me and
I'd worry about the bandwidth they'd take if I were transmitting and receiving
at the same time. Are they just not implemented, yet?
I need
I envisioned a way to send a burst with a request to ACK. If you enabled
the ACK, you would expect a async message to come back either one of the
errors or a success. This is not implemented.
-Josh
On 09/09/2010 09:54 AM, Marc Epard wrote:
As far as I can tell, EVENT_CODE_SUCCESS (Defined as
On 09/09/2010 11:42 AM, Anil Sharma wrote:
Hi everyone,
I want to test something with usrp running continously under
normal environment.
Can someone tell me the real data of how long usrp is capable of
running continously.
Thanks.
___
D
If you're interested in taking the DSP approach on the Beagleboard my favorite
guide to setting up and installing the proper environment is
http://ossie.wireless.vt.edu/trac/wiki/BeagleBoard
I've heard that the steps are a little outdated but if you stick with the
toolset versions indicated
Hallo,
I guess I explained to less. I'm using hard symbol coding. As I read in
the documentation, I can use the trellis modulated Symbols how ever I
want to. So on the transmitter side, I do not forward the trellis
modulated symbols to a QAM modulator or something. I convert the
generated
On Thu, Sep 9, 2010 at 11:26 PM, Alexandru Csete oz9...@gmail.com wrote:
...
(4) Not sure about the Qt stuff... In the source tree I tried to execute
the pyqt_example.py script and got:
Traceback (most recent call last):
File pyqt_example.py, line 4, in module
from gnuradio.qtgui
On 09/09/2010 06:19 PM, Kieran Brownlees wrote:
We have seen the same behaviour when trying to run overnight on the
USRP1, the flowgraph was just doing FM mod (LFRX in LFTX out) and it
had a graphical sink. Have the flowgraphs you used been made in GRC
(ie could this be a wx issue?).
Kieran
Thank you, Alexandru, for the report. I'm glad the basics work for you; they
do for me as well. Everything seems to work except for the QtGUI. I've found
in my install that the QtGUI doesn't work yet either, in exactly the same way
that yours fails. I know where the problem lies, and I'll
Hi,
I stumbled on this blockset on the Matlab website:
http://www.mathworks.com/help/toolbox/commblks/ref/usrp2receiver.html
I've been making do with the old firmware and fpga, but when I saw this link, I
became really excited - especially because it implies I can decrease the
decimation on my
On Fri, Sep 10, 2010 at 10:19:05AM +1200, Kieran Brownlees wrote:
We have seen the same behaviour when trying to run overnight on the USRP1,
the flowgraph was just doing FM mod (LFRX in LFTX out) and it had a
graphical sink. Have the flowgraphs you used been made in GRC (ie could this
be a wx
On 09/09/2010 10:32 PM, Eric Blossom wrote:
Marcus,
It would be useful it you could provide a gdb stack trace of all
threads when you see the wedged condition.
If it's a python program, run gdb against /usr/bin/python and use the
gdb attach command to attached to the wedged process.
Then
Thanks for the link Matthias.
Is this part of the UHD code considered stable? Or are there major changes
expected in the future? I saw a post that the UHD is pre-alpha as of 6
months ago.
To give reason why I am interested, I am planning to do some FPGA
development for the USRP1, which will
On 09/09/2010 08:54 PM, Colby Boyer wrote:
Thanks for the link Matthias.
Is this part of the UHD code considered stable? Or are there major changes
expected in the future? I saw a post that the UHD is pre-alpha as of 6
months ago.
I would call it more stable. Certain parts of the API
18 matches
Mail list logo
