[Discuss-gnuradio] simple signal processing with python function call?
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 values) (decimationrate=1) Constant source V2 * 3 Scope Sink I planed to exchange the V2 * 3 to an external python function to obtain a simple signal processing routine in python The update rate of the constant source is very slow. Is there any better way to get a simple python extension for signal processing in GRC? What else can be done for higher update rate of the variable in GRC? -- mit freundlichen Grüßen M. Hartje -- Prof. Dr.-Ing. Michael Hartje Labor Hochspannungstechnik / Labor elektrische Messtechnik Neustadtswall 30; D-28199 Bremen Tel +49 421 5905-3444FAX +49 421 5905-3476 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Viterbi--OFDM
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 items and when reached a certain limit, push it into an message source.To realize the defined initial and final state, I added zeros at the end of each block using the python --struct-- module. These data blocks are converted to chunks and handed over to the trellis_modulator.The outcoming chunks are, depending on there number of bits packt to shorts to transmit it using the ofdm_mod block.Obn the receiver side the recieved block is unpackt using the inverse operation of the block after the trellis_mod und the tcm output symbols are handed over to the combined_viterbi afterwards packt to the original data stream. This stream is catched by a message queue as well and packets of the original length are reconstructed.So my question is, what did I do wrong, to get an packet error rate, that is worse than the uncoded transmission. It seems to me, that some times in the transmission the viterbi works fine and corrects all the errors, but sometimes, it doesn't output any correct data.Is there a solution to this problem?Thanks alot for your help.TobiasNeu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help : how long usrp can run continously in normal environment.
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 http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ADC clarification in verilog of usrp2
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] references: USRP2, GNURadio, UHD and VRT
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 between the UHD branch and VRT branch. In other words, what's new Regards, Zohair -- From: Matt Ettus m...@ettus.com Sent: Thursday, September 09, 2010 12:08 AM To: Zohair M. Abu Shaban zohair...@hotmail.com Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] references: USRP2, GNURadio, UHD and VRT On 09/08/2010 11:33 AM, Zohair M. Abu Shaban wrote: 2- I used UHD but slightly dealt with VRT. And, I cannot make a clear comparison between them, any brief about this, please? VRT is a protocol, which is the data packet format which we send over ethernet. UHD is the driver which sends data via VRT and also does all of the control of the hardware as well. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] recv_async_msg questions
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 to start and stop transmitting, do some work, and go around again. I think I'm seeing residual events after I end a burst. Should I use the metadata's timestamp to filter them out or is there a way to flush the queue of events? -Marc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] recv_async_msg questions
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 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 to start and stop transmitting, do some work, and go around again. I think I'm seeing residual events after I end a burst. Should I use the metadata's timestamp to filter them out or is there a way to flush the queue of events? -Marc ___ 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
Re: [Discuss-gnuradio] help : how long usrp can run continously in normal environment.
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 Three years ago, I used to run my USRP1-based radio astronomy software for months at a time with no issue. In the last year or so, I've been unable to maintain those kinds of uptimes with either USRP1 or USRP2, which I ascribe to fundamental changes in Gnu Radio, but I haven't been able to put my finger on exactly which flow-graphs will wedge after a few days, and which ones will keep going and going. I have one flow-graph that uses the USRP2 at low bandwidths (400Ksps or so) that seems to be able to run forever. Another, similar flowgraph, will tend to wedge after a few days. I also have a flow-graph that uses an ALSA source and sink, and it can only run for a few days before wedging. I think the USRP *hardware and drivers* are perfectly capable of running forever, but the current Gnu Radio seems to have issues that I haven't been able to pin-point with long-running applications. -- 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] gnuradio on beagleboard?
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 on the webpage you should be fine. I've managed to target the DSP from GNU Radio to do filtering mostly. I plan on making my code available but I've been too busy lately trying to meet some project deadlines so it might take me a while to do so. But basically you can connect to the DSP from GNU Radio if tell the TI tools to generate libraries instead of excutable for your application and then you can follow the How to write a Custom GNU Radio tutorials to add them as custom blocks. al fayez -Original Message- From: Philip Balister phi...@balister.org To: Thunder87 thunderbolt...@mail.ru Cc: Discuss-gnuradio@gnu.org Sent: Mon, Sep 6, 2010 3:44 pm Subject: Re: [Discuss-gnuradio] gnuradio on beagleboard? On 09/06/2010 03:06 PM, Thunder87 wrote: Am I correct, thinking that gnuradio should work on any platform, as long as it's on ubuntu? GNU Radio will run on Linux, OSX, and possibly windows etc. As noted, Ubuntu is just one flavour of Linux Will I be able to run it on http://beagleboard.org/ Beagleboard with http://elinux.org/BeagleBoardUbuntu Ubuntu ? GNU Radio runs on the Beagleboard already. Only the FIR fff filter has been optimized for NEON SIMD though. There are some guys at Virginia Tech looking at the using the DSP with GNU Radio also. They might have some more suggestions. Philip ___ 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
Re: [Discuss-gnuradio] Viterbi--OFDM
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 fsm symbols let's say with 2 Bits per Byte with a unpacked_to_packed block back into a byte with all symbols use. So I have 4 trellis coded symbols in each byte. And the so coded bytes I forward to the ofdm_mod to transmit it. On the receiver side, I take the packet handed over by the ofdm_demodulator complete usual ofdm demodulation. So if no error occured i should get back bytes with 4 fsm hard symbols each. I take these bytes and make a pack_to_unpack and get back the 4 bytes with one 2bit fsm symbol each. this steam of chunks is than decoded by a hard_symbol viterbi. The principle is the same like in one of the trellis examples with an outer coding. it should in an error free case be the same as taking the symbols generated by a tcm into a viterbi. the scheme is: input(packet with leading and ending zeros to force defined states)---pack_to_unpack--tcm(hard_symbol)--unpack_to_pack--ofdm_mod--CHANNEL--ofdm_demod--pack_to_unpack--combined_viterbi(hard_symbol)--unpack_to_pack--- And I don't know why I doesn't work all the time. Is there an error in my idea? Cheers, Tobias Am 09.09.2010 21:57, schrieb Veljko Pejovic: Hi Tobias, I'm trying to implement coded OFDM as well. I think we are following the same approach when it comes to the transmission, but I'm afraid I do not understand your receiver. When exactly do you do OFDM demodulation? combined_viterbi does demodulation of the BPSK, QAM, etc signal based on the given constellation. However, OFDM decoding has to happen before that. The tricky part is that the OFDM blocks in gnuradio don't allow you to easily plug the combined_viterbi module. Are you putting it between ofdm_recv and ofdm_demod in the ofdm_demod class? If so, what about the control signal that tells you where the frame starts, which flows on the other ofdm_recv port? Cheers, Veljko On Thu, Sep 9, 2010 at 7:10 AM, Tobias Schmid tobiasschmid22...@web.de mailto:tobiasschmid22...@web.de wrote: 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 items and when reached a certain limit, push it into an message source. To realize the defined initial and final state, I added zeros at the end of each block using the python --struct-- module. These data blocks are converted to chunks and handed over to the trellis_modulator. The outcoming chunks are, depending on there number of bits packt to shorts to transmit it using the ofdm_mod block. Obn the receiver side the recieved block is unpackt using the inverse operation of the block after the trellis_mod und the tcm output symbols are handed over to the combined_viterbi afterwards packt to the original data stream. This stream is catched by a message queue as well and packets of the original length are reconstructed. So my question is, what did I do wrong, to get an packet error rate, that is worse than the uncoded transmission. It seems to me, that some times in the transmission the viterbi works fine and corrects all the errors, but sometimes, it doesn't output any correct data. Is there a solution to this problem? Thanks alot for your help. Tobias Neu: WEB.DE http://WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org mailto: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
Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated
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 import qtgui
File /opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py,
line 24, in module
_qtgui = swig_import_helper()
File /opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py,
line 20, in swig_import_helper
_mod = imp.load_module('_qtgui', fp, pathname, description)
ImportError:
dlopen(/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/_qtgui.so, 2):
Library not loaded: libqwtplot3d.0.dylib
Referenced from:
/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/_qtgui.so
Reason: image not found
I found the libqwtplot3d.0.dylib in /opt/local/lib but I get the same error
even after adding it to LD_LIBRARY_PATH in the .profile file
I learned that on OSX it is dyld and not ld; however, changing it to
DYLD_LIBRARY_PATH gave another error:
Traceback (most recent call last):
File ./pyqt_example.py, line 4, in module
from gnuradio.qtgui import qtgui
File /opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py,
line 24, in module
_qtgui = swig_import_helper()
File /opt/local/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py,
line 20, in swig_import_helper
_mod = imp.load_module('_qtgui', fp, pathname, description)
ImportError:
dlopen(/opt/local/lib/python2.6/site-packages/gnuradio/qtgui/_qtgui.so, 2):
Library not loaded:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
Referenced from:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
Reason: Incompatible library version: vecLib requires version 1.0.0 or
later, but libLAPACK.dylib provides version 0.0.0
I tried to google this and found some forum discussions suggesting that this
is problem with the port package and that using DYLD_LIBRARY_PATH is not
recommended - instead DYLD_FALLBACK_LIBRARY_PATH can be used. Tried that and
got a different error:
Traceback (most recent call last):
File ./pyqt_example.py, line 5, in module
from PyQt4 import QtGui, QtCore
ImportError:
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyQt4/QtCore.so,
2): Symbol not found: __PyByteArray_empty_string
Referenced from:
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyQt4/QtCore.so
Expected in: flat namespace
in
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/PyQt4/QtCore.so
Alex
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help : how long usrp can run continously in normal environment.
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 I have a mixture of flow-graphs that use GUI bits and ones that don't. Doesn't seem to make any difference. In fact, my longest-running one uses an FFT and Stripchart/scope sink. -- 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] GNU Radio via MacPorts Updated
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 be working on patches hopefully get them in place tomorrow. I'll post another email to the list once it works for me. - MLD ps1 You shouldn't set the DYLD_LIBRARY_PATH to find libraries; OSX's dyld is smart enough to find them -- but only if it knows where to look, which is the issue in this case (no path, just the library name). ps2 On OSX, you do not need to set up udevs or anything; the USRP just works :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 UHD Matlab Receiver Communications Blockset
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 USRP2 to 1 - perhaps by requesting real, single precision values instead of complex doubles. Is there an open source version of that blockset? Alternatively, despite poking around the UHD API, it wasn't immediately obvious how I could change the type of data, or set a decimation of 1, from the uhd::usrp::simple_usrp class. I suspect it may have something to do with the uhd::io_type_t class, but, again, I'm not too sure. Has anyone had a chance to play around with this blockset, or know how it works? It looks _really_ neat, and appears to work with wbx boards. Vincent W ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help : how long usrp can run continously in normal environment.
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 issue?). I've recently seen crashes (assert failures) directly related to wx, gtk and opengl. From looking at the stack traces on those, it didn't appear to be our problem. These were not running under GRC. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help : how long usrp can run continously in normal environment.
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 issue thread apply all bt to generate the stack traces and send them to me. Eric Will do. Last time I did that, the rather large mass of information on each of the many, many, threads was quite daunting for me to analyse myself. -- 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] Location of the latest base USRP1 FPGA code
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 require a decent amount of change (to make space on the board + features). I would like to keep what I do in line with UHD. Thanks, Colby On Thu, Sep 9, 2010 at 1:16 AM, Matthias Wilhelm wilh...@informatik.uni-kl.de wrote: Hi, the repository for the UHD driver (fpga, firmware and host) can be found under http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki The last change for the USRP1 FPGA code is from 5 months ago, but I think the latest code should be there. Matthias Am 09.09.2010 um 07:44 schrieb Colby Boyer: Hi all, I searched through the mailing lists and there is not much of a consensus on the location of the latest base FPGA code. The repo I found was git:// ettus.sourcerepo.com/ettus/fpga.git Is this the FPGA code used in the new UHD drivers? If not, can someone be kind enough to point me in the right direction. Thanks, Colby ___ 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
Re: [Discuss-gnuradio] Location of the latest base USRP1 FPGA code
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 require polishing. But if you were to start coding to it, your code changes would be minor. To give reason why I am interested, I am planning to do some FPGA development for the USRP1, which will require a decent amount of change (to make space on the board + features). I would like to keep what I do in line with UHD. The USRP1 FPGA code is not going to change (unless someone contributes new features like timestamps). Thanks, Colby On Thu, Sep 9, 2010 at 1:16 AM, Matthias Wilhelm wilh...@informatik.uni-kl.de wrote: Hi, the repository for the UHD driver (fpga, firmware and host) can be found under http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/wiki The last change for the USRP1 FPGA code is from 5 months ago, but I think the latest code should be there. Matthias Am 09.09.2010 um 07:44 schrieb Colby Boyer: Hi all, I searched through the mailing lists and there is not much of a consensus on the location of the latest base FPGA code. The repo I found was git:// ettus.sourcerepo.com/ettus/fpga.git Is this the FPGA code used in the new UHD drivers? If not, can someone be kind enough to point me in the right direction. Thanks, Colby ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
