Re: [Discuss-gnuradio] value error
Hi, I made the updating of the program, but the problem persists. PN sync doesn't have problem. You have an idea of thing I could do for resolving the problem. Thank you a lot for your help. Scrive Eric Blossom <[EMAIL PROTECTED]>: > On Tue, Mar 18, 2008 at 05:54:37PM +0100, Crespi Floriana wrote: > > Hi > > I have a problem with ofdm system. > > > > Each time I run benchmark_ofdm_rx.py I get; > > > > Traceback (most recent call last): > > File "benchmark_ofdm_rx.py", line 210, in > > main() > > File "benchmark_ofdm_rx.py", line 199, in main > > tb = my_top_block(rx_callback, options) > > File "benchmark_ofdm_rx.py", line 64, in __init__ > > self.rxpath = receive_path(callback, options) > > File "/home/crespi/Desktop/Workspace_flo/receive_path.py", line 52, in > > __init__ > > blks2.ofdm_demod(options, callback=self._rx_callback) > > File "/usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/ofdm.py", > line > > 209, in __init__ > > self.ofdm_recv = ofdm_receiver(self._fft_length, > > self._cp_length,self._occupied_tones, self._snr, preambles,options.log) > > File > > > "/usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/ofdm_receiver.py", > > line 107, in __init__ > > self.connect((self.ofdm_sync,1), (self.ofdm_frame_acq,1)) > > File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py", > line > > 70, in connect > > self._connect(points[i-1], points[i]) > > File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py", > line > > 76, in _connect > > dst_block.basic_block(), dst_port) > > File > > > "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", > > line 946, in connect > > return _gnuradio_swig_py_runtime.gr_hier_block2_sptr_connect(*args) > > ValueError: port number 1 exceeds max of 0 > > > > > > > > I use realese number 7324 and kubuntu 7.04 > > > > Do you have some idea of which the problem is??? > > > > Thanks a lot of > > Can you try updating to the current trunk version and see if the > problem still persists? > > Eric > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] value error
Crespi Floriana wrote: Hi, I made the updating of the program, but the problem persists. PN sync doesn't have problem. You have an idea of thing I could do for resolving the problem. Thank you a lot for your help. Are you saying the system works when you use the PN synchronization block ofdm_sync_pn.py but not if you switch out the PN version for, say, the ML version (ofdm_sync_ml.py)? If that's the problem, then there is no current (easy) solution. In order to fix some operational problems, I had to make changes to the way the systems interconnect and broke the other synchronization methods in the process. This isn't really a problem since the other sync methods don't work properly, anyway. I have plans to fix this, but I can't say when. Tom Scrive Eric Blossom <[EMAIL PROTECTED]>: On Tue, Mar 18, 2008 at 05:54:37PM +0100, Crespi Floriana wrote: Hi I have a problem with ofdm system. Each time I run benchmark_ofdm_rx.py I get; Traceback (most recent call last): File "benchmark_ofdm_rx.py", line 210, in main() File "benchmark_ofdm_rx.py", line 199, in main tb = my_top_block(rx_callback, options) File "benchmark_ofdm_rx.py", line 64, in __init__ self.rxpath = receive_path(callback, options) File "/home/crespi/Desktop/Workspace_flo/receive_path.py", line 52, in __init__ blks2.ofdm_demod(options, callback=self._rx_callback) File "/usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/ofdm.py", line 209, in __init__ self.ofdm_recv = ofdm_receiver(self._fft_length, self._cp_length,self._occupied_tones, self._snr, preambles,options.log) File "/usr/local/lib/python2.5/site-packages/gnuradio/blks2impl/ofdm_receiver.py", line 107, in __init__ self.connect((self.ofdm_sync,1), (self.ofdm_frame_acq,1)) File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py", line 70, in connect self._connect(points[i-1], points[i]) File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/hier_block2.py", line 76, in _connect dst_block.basic_block(), dst_port) File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 946, in connect return _gnuradio_swig_py_runtime.gr_hier_block2_sptr_connect(*args) ValueError: port number 1 exceeds max of 0 I use realese number 7324 and kubuntu 7.04 Do you have some idea of which the problem is??? Thanks a lot of ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Rick- > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter > > and see > > if the device can decode P25 as well. This may be a general IMBE and > > AMBE codec. > > > > I hope so. I looked at this a while back. What concerned me most was the > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > Compare the docs to another DVSI product - the VC55 - to see what I mean. If you're looking at low bitrate codecs for GNU radio, why use a hardware (dongle) dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps, and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG 4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mac OS X Build problem
Qi - It looks like you're mixing Python 2.3 and 2.4. That's not wise, since there have been significant differences between decimal releases of Python. Also, it's possible that Python 2.3 is too old. I think Python 2.5 is recommended, but 2.4 works for the most part. I would highly recommend you installing the 'python24' port and related 'py- YYY' ports, and see if those work for you. If you have install issues, email me off-list and I'll help as time allows. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
- Start Original Message - Sent: Wed, 19 Mar 2008 07:02:08 -0600 From: Jeff Brower <[EMAIL PROTECTED]> To: Rick Parrish <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > Rick- > > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame > > > converter and see > > > if the device can decode P25 as well. This may be a general IMBE and > > > AMBE codec. > > > > > > > I hope so. I looked at this a while back. What concerned me most was the > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > > Compare the docs to another DVSI product - the VC55 - to see what I mean. > > If you're looking at low bitrate codecs for GNU radio, why use a hardware > (dongle) > dependent solution? You might look at MELPe, which provides 600, 1200, and > 2400 bps, > and can be implemented as a software solution. MELPe is a US/NATO standard > (STANAG > 4591). Common applications are HF radio and L band satellite apps where > bandwidth is > very limited. > - End Original Message - Hello, That would be a good idea if I was doing digital voice from scratch but I am trying to decode IMBE and AMBE used in APCO P25 and a number of other systems like MA/COM ProVoice and some Inmarsat stuff. MELPe may be a great solution to get Ham Digital Voice away from IMBE and AMBE. It may be difficult to do in the case of VHF/UHF with older P25 radios being available surplus. IP issues can be a minefield as the Rembrandt Technologies suit about their ATSC patents shows. I heard that HDTV Grand Alliance made the mistake of not having a formal patent pool and there was an informal agreement. Rembrandt got the technology patents from AT&T which was part of the HDTV Grand Alliance and decided to play hardball and recover the costs of buying the patents plus make a profit. Having dealt with companies that only release information under NDA, I can appreciate that DVSI has their information available so a device like DV Dongle can be made. It is not a good clean open source solution but is like the MadWifi driver. I would like to play with ALE and STANAG protocols someday. Thanks for the information and I will look up more information on it. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio]Why I can't success run example : FM Receiver
Hi: I need someone help me, why I can't run example from this page: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html When I run example 1:Dial Tone Output. I get error message: Traceback (most recent call last): File "am.py", line 20, in fg = build_graph () File "am.py", line 10, in build_graph fg = gr.flow_graph () AttributeError: 'module' object has no attribute 'flow_graph' When I run example 2:A Complete FM Receiver I get error message: Traceback (most recent call last): File "test.py", line 5, in from gnuradio import mc4020 ImportError: cannot import name mc4020 Why? How can I do? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio]Why I can't success run example : FM Receiver
On Mar 19, 2008, at 11:47 AM, JackyYang wrote: I need someone help me, why I can’t run example from this page: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html When I run example 1:Dial Tone Output. I get error message: Traceback (most recent call last): File "am.py", line 20, in fg = build_graph () File "am.py", line 10, in build_graph fg = gr.flow_graph () AttributeError: 'module' object has no attribute 'flow_graph' This example will no longer work with the current SVN trunk (assuming that's what you're using), because the "flow_graph" code has been removed. Someone needs to update that page ;) ... or create a backwards compatible "flow_graph" interpretation layer. When I run example 2:A Complete FM Receiver I get error message: Traceback (most recent call last): File "test.py", line 5, in from gnuradio import mc4020 ImportError: cannot import name mc4020 Could be a number of problems: + The module "mc4020" is wasn't compiled / installed in the first place; + PYTHONPATH isn't correct to find it; + code is too old, and no longer works with the SVN trunk (or release tarball). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote: > Rick- > > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame > > > converter and see > > > if the device can decode P25 as well. This may be a general IMBE and > > > AMBE codec. > > > > > > > I hope so. I looked at this a while back. What concerned me most was the > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > > Compare the docs to another DVSI product - the VC55 - to see what I mean. > > If you're looking at low bitrate codecs for GNU radio, why use a hardware > (dongle) > dependent solution? You might look at MELPe, which provides 600, 1200, and > 2400 bps, > and can be implemented as a software solution. MELPe is a US/NATO standard > (STANAG > 4591). Common applications are HF radio and L band satellite apps where > bandwidth is > very limited. > > -Jeff Unless something has changed, MELP is also encumbered. How about a free codec, such as speex? http://www.speex.org/ Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio]Why I can't success run example : FM Receiver
JackyYang wrote: When I run example 1:Dial Tone Output. I get error message: Traceback (most recent call last): File "am.py", line 20, in fg = build_graph () File "am.py", line 10, in build_graph fg = gr.flow_graph () AttributeError: 'module' object has no attribute 'flow_graph' in the script, change: fg = gr.flow_graph() to: fg = gr.top_block() Then run again. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] DV Dongle - AMBE USB Device
speex is nice. I've used it as well as the AMBE2000/2020. I wasn't in love with the AMBE. We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 pair of DSPs work in our application. Specs were light and idiosyncrasies were numerous. j0j > Date: Wed, 19 Mar 2008 09:02:46 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > CC: discuss-gnuradio@gnu.org > > On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote: > > Rick- > > > > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame > > > > converter and see > > > > if the device can decode P25 as well. This may be a general IMBE and > > > > AMBE codec. > > > > > > > > > > I hope so. I looked at this a while back. What concerned me most was the > > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > > > Compare the docs to another DVSI product - the VC55 - to see what I mean. > > > > If you're looking at low bitrate codecs for GNU radio, why use a hardware > > (dongle) > > dependent solution? You might look at MELPe, which provides 600, 1200, and > > 2400 bps, > > and can be implemented as a software solution. MELPe is a US/NATO standard > > (STANAG > > 4591). Common applications are HF radio and L band satellite apps where > > bandwidth is > > very limited. > > > > -Jeff > > Unless something has changed, MELP is also encumbered. How about a > free codec, such as speex? http://www.speex.org/ > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Jared- > speex is nice. I've used it as well as the AMBE2000/2020. I wasn't in love > with > the AMBE. We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 > pair > of DSPs work in our application. Specs were light and idiosyncrasies were > numerous. What was the lowest bitrate you used with Speex? My understanding is that Speex's PESQ scores are below 3 for anything below 3000 bps. -Jeff > > Date: Wed, 19 Mar 2008 09:02:46 -0700 > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > > Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > > CC: discuss-gnuradio@gnu.org > > > > On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote: > > > Rick- > > > > > > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame > > > > > converter > and see > > > > > if the device can decode P25 as well. This may be a general IMBE and > > > > > AMBE codec. > > > > > > > > > > > > > I hope so. I looked at this a while back. What concerned me most was the > > > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. > > > > Compare the docs to another DVSI product - the VC55 - to see what I > > > > mean. > > > > > > If you're looking at low bitrate codecs for GNU radio, why use a hardware > (dongle) > > > dependent solution? You might look at MELPe, which provides 600, 1200, > > > and 2400 > bps, > > > and can be implemented as a software solution. MELPe is a US/NATO standard > (STANAG > > > 4591). Common applications are HF radio and L band satellite apps where > bandwidth is > > > very limited. > > > > > > -Jeff > > > > Unless something has changed, MELP is also encumbered. How about a > > free codec, such as speex? http://www.speex.org/ > > > > Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio]Why I can't success run example : FM Receiver
Could be a number of problems: + The module "mc4020" is wasn't compiled / installed in the first place; How could I install it?(My system is Ubnutu7.10, and I am step by step see this page http://www.gnuradio.org/trac/wiki/UbuntuInstall) + PYTHONPATH isn't correct to find it; I am sure I can run other gnuradio-example program.(Is that mean PYTHONPATH ok?) + code is too old, and no longer works with the SVN trunk (or release tarball).= That is too bad, has any way can I get example code to run FM receiver? Thank your answer!! >> I need someone help me, why I can't run example from this page: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html >> >> When I run example 1:Dial Tone Output. >> I get error message: >> Traceback (most recent call last): >> File "am.py", line 20, in >> fg = build_graph () >> File "am.py", line 10, in build_graph >> fg = gr.flow_graph () >> AttributeError: 'module' object has no attribute 'flow_graph' > >This example will no longer work with the current SVN trunk (assuming >that's what you're using), because the "flow_graph" code has been >removed. Someone needs to update that page ;) ... or create a >backwards compatible "flow_graph" interpretation layer. >> When I run example 2:A Complete FM Receiver >> I get error message: >> Traceback (most recent call last): >> File "test.py", line 5, in >> from gnuradio import mc4020 >> ImportError: cannot import name mc4020 >Could be a number of problems: >+ The module "mc4020" is wasn't compiled / installed in the first place; >+ PYTHONPATH isn't correct to find it; >+ code is too old, and no longer works with the SVN trunk (or release >tarball).= ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio]Why I can't success run example : FM Receiver
Dear sir: It is work!! Thank you very much. But, why I can't see graph? I have installed GNU Radio Companion, is it run on GRC? >JackyYang wrote: >> When I run example 1:Dial Tone Output. >> > >I get error message: >> >>Traceback (most recent call last): >> >> File "am.py", line 20, in >> >> fg = build_graph () >> >> File "am.py", line 10, in build_graph >> >> fg = gr.flow_graph () >> >> AttributeError: 'module' object has no attribute 'flow_graph' >> >in the script, change: >fg = gr.flow_graph() >to: >fg = gr.top_block() > >Then run again. > >- George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to insert a matlab file into GNURadio in python
Hello, I've made a code in matlab for GNURadio but I don't know how to insert this code in the files programmed in python in GNURadio. Can anyone tell me how to do it?I've seen there are some files done in matlab but I couldn't figure out how they have been inserted. Thank you very much! _ Tecnología, moda, motor, viajes,…suscríbete a nuestros boletines para estar siempre a la última http://newsletters.msn.com/hm/maintenanceeses.asp?L=ES&C=ES&P=WCMaintenance&Brand=WL&RU=http%3a%2f%2fmail.live.com___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to insert a matlab file into GNURadio in python
On Wed, Mar 19, 2008 at 06:50:22PM +0100, Jose Emilio Gervilla Rega wrote: > > Hello, > > I've made a code in matlab for GNURadio but I don't know how to > insert this code in the files programmed in python in GNURadio. Can > anyone tell me how to do it?I've seen there are some files done in > matlab but I couldn't figure out how they have been inserted. GNU Radio doesn't run Matlab or Octave code. The code in the tree is typically used for displaying the output of log files. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to insert a matlab file into GNURadio in python
Jose Emilio Gervilla Rega wrote: Hello, I've made a code in matlab for GNURadio but I don't know how to insert this code in the files programmed in python in GNURadio. Can anyone tell me how to do it?I've seen there are some files done in matlab but I couldn't figure out how they have been inserted. Thank you very much! Hi, The octave scripts, found in here: http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/utils ... are not actually inserted into a GNU Radio flowgraph or anything. They are simply used to post-process data from GNU Radio. I think some people have managed to integrate GNU Radio and matlab in the past, I don't know how though. But, those files I think you're speaking of are for post-processing. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] better docs for GRC
Hey, I am interesting in creating some kind of auto-generated docs for grc. Currently, each block has a custom description or a description copy/pasted from the html doxygen stuff. While some custom descriptions are necessary, it would be nice to be able to grab this other information about blocks and block parameters from the doxygen docs. It seems doxygen can create an xml output file with "all" the information. I would like to take a look at this doxygen-xml output. Do we currently generate it when this: http://gnuradio.org/doc/doxygen/ is made? Available for download? If not, where is the doxygen config file located so I can modify it and generate this output myself? Assuming this doxygen xml file is what I think it is: GRC could get a hold of it in 2 ways: 1) if a user wants their grc to have docs, they have to --enable-doxygen or 2) the grc setup script could download said xml file from gnuradio.org and install it in a known location. I prefer #2. Any thoughts on this approach? Alternative ideas? -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] better docs for GRC
On Wed, Mar 19, 2008 at 03:03:46PM -0400, Josh Blum wrote: > Hey, > > I am interesting in creating some kind of auto-generated docs for grc. Sounds like a great idea. > Currently, each block has a custom description or a description copy/pasted > from the html doxygen stuff. > > While some custom descriptions are necessary, it would be nice to be able > to grab this other information about blocks and block parameters from the > doxygen docs. > > It seems doxygen can create an xml output file with "all" the information. > I would like to take a look at this doxygen-xml output. Do we currently > generate it when this: http://gnuradio.org/doc/doxygen/ is made? Available > for download? If not, where is the doxygen config file located so I can > modify it and generate this output myself? It's currently disabled, but we could turn it back on. See gnuradio-core/doc/Doxygen.in # If the GENERATE_XML tag is set to YES Doxygen will # generate an XML file that captures the structure of # the code including all documentation. GENERATE_XML = NO > Assuming this doxygen xml file is what I think it is: GRC could get a hold > of it in 2 ways: 1) if a user wants their grc to have docs, they have to > --enable-doxygen or 2) the grc setup script could download said xml file > from gnuradio.org and install it in a known location. > > I prefer #2. Any thoughts on this approach? Alternative ideas? I think #2's problematic since the XML would always be out of date, and might not match the version of GR that the user has installed. However, if you want to generate the XML and store it somewhere on gnuradio.org, we can arrange that. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mac OS X Build problem
Here's another data point. I am using OS X 10.4.10 on a PPC Mac with Python 2.3.5, the one that comes with OS X 10.4. I have built GNU Radio from trunk recently with no problems. In order to avoid difficulties I have heard about on this list and elsewhere, I have not installed another Python. Because I am still using the old Python, I can't use MacPorts for any packages that have Python dependencies (otherwise MacPorts will install the new Python). In March 2007 I installed NumPy 1.0.1 from the source tarball at http://www.scipy.org/Download I see the current version is 1.0.4, but 1.0.1 is still available from sourceforge (linked from the scipy page). In 2005 I installed wxPython 2.6.1.0 from wxPython2.6-osx-ansi-2.6.1.0-macosx10.3-py2.3.dmg available at http://www.wxpython.org/download.php#binaries. I see it's still there. These work for me. Jon Jacky ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about Benchmark_rx.py file code
Hi I'm trying to troubleshoot a piece of code that was handed to me.? The basic
application uses GNU radio and a USRP in transmitting digital signals and the
application uses the following file provided in GNU radio "benchmark_rx.py"
which can be found in the following directory
"gnuradio/trunk/gnuradio-examples/python/digital/benchmark_rx.py".
The application occasionally crashes on line 66 in the benchmark file, the line
is "(pktno,) = struct.unpack('!H', payload[0:2])".? The error I get is that
struct.unpack should be passed a string of at least size 2
When looking at the code it seems that it should have 'H' versus '!H' if the
intend was to convert the object to a C unsigned short object.? And if the
intention is to pass !H then it should be passed as "!H" using double ?
quotes.? when I changed the code to either 'H' or "!H" the code works without
any runtime errors.
My question is, is the '!H' a bug in the GNU radio code?? Thanks.
Al Fayez
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Benchmark_rx.py file code
On Wed, Mar 19, 2008 at 06:02:17PM -0400, [EMAIL PROTECTED] wrote:
> Hi I'm trying to troubleshoot a piece of code that was handed to
> me.? The basic application uses GNU radio and a USRP in transmitting
> digital signals and the application uses the following file provided
> in GNU radio "benchmark_rx.py" which can be found in the following
> directory
> "gnuradio/trunk/gnuradio-examples/python/digital/benchmark_rx.py".
> The application occasionally crashes on line 66 in the benchmark
> file, the line is "(pktno,) = struct.unpack('!H', payload[0:2])".?
> The error I get is that struct.unpack should be passed a string of
> at least size 2
That means that the code is being handed a string of length < 2 bytes.
> When looking at the code it seems that it should have 'H' versus
> '!H' if the intend was to convert the object to a C unsigned short
> object.? And if the intention is to pass !H then it should be passed
> as "!H" using double ? quotes.? when I changed the code to either
> 'H' or "!H" the code works without any runtime errors.
If you'll take a look at the python documentation for struct.unpack,
you'll see that the "!" forces network endian order. That's what we
want. If you look at the python documentation you'll discover the
differences between 'foo' and "foo" -- nothing.
> My question is, is the '!H' a bug in the GNU radio code?? Thanks.
Nope.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] APCO Project 25 CAI
Hello, After looking at this document it appears that writing a APCO P25 CAI decoder is a good way to learn error correcting codes because it uses many varieties of different types. http://www.p25.com/resources/P25TrainingGuide.pdf I just hope the Vocoder Error Correcting Code description on Page 48 is describing a FEC mode that the Vocoder supports. Otherwise it may take awhile to code something that can decode vocoder frames. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about Benchmark_rx.py file code
Eric Blossom wrote:
On Wed, Mar 19, 2008 at 06:02:17PM -0400, [EMAIL PROTECTED] wrote:
The application occasionally crashes on line 66 in the benchmark
file, the line is "(pktno,) = struct.unpack('!H', payload[0:2])".?
The error I get is that struct.unpack should be passed a string of
at least size 2
That means that the code is being handed a string of length < 2 bytes.
Not getting the bug after your changes was probably coincidental. I've
seen this happen on occasion when a packet is receive erroneously and
the header is corrupted. The framer state machine looks for the repeated
packet length after correlating with the access code. What's probably
happening is the header is being read in as double 0's, so it passes on
a packet of length zero. When unpacking, Python is throwing an exception.
The right thing to do here is catch the exception and mark it as a
missed packet.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Jeff Brower wrote: If you're looking at low bitrate codecs for GNU radio, why use a hardware (dongle)dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps,and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. My interest is what is actually being used - which in the case of public safety communications is the P25 variant of IMBE. FWIW, a closed source PC hosted IMBE vocoder exists now. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick Parrish wrote: > Jeff Brower wrote: > >If you're looking at low bitrate codecs for GNU radio, why use a > >hardware (dongle)dependent solution? You might look at MELPe, which > >provides 600, 1200, and 2400 bps,and can be implemented as a software > >solution. MELPe is a US/NATO standard (STANAG4591). Common > >applications are HF radio and L band satellite apps where bandwidth is > >very limited. > My interest is what is actually being used - which in the case of public > safety communications is the P25 variant of IMBE. FWIW, a closed source > PC hosted IMBE vocoder exists now. Is this a DVSI licensed and publically available closed source module or something "unofficial" or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues... and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don't see this as in their interest). -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] D-Star (was Re: DV Dongle - AMBE USB Device)
Hi All, I spent some time looking at the D-Star spec, which is supposedly "open". Unfortunately, the published DOC (yes, singular) out there are far from complete. Fortunately, Moe, Pieter and Robin did some work analyzing D-Star and posted their results... Doing D-Star with the USRP looks easily done and most stuff is there such as GMSK, inter-leaving, Trellis, etc. I think that what is missing is a scrambling and of course a framer. While I'm not sure that D-Star has much advantage over other protocols available in amateur radio, it seems to be taking off. Networks are being built. D-Star can transport data, such as short-messages and most importantly Ethernet frames. AMBE could be replaced by Speex. Dave On Tue, Mar 18, 2008 at 10:53 AM, Eric A. Cottrell <[EMAIL PROTECTED]> wrote: > > One of the "problems" with DStar and some other digital voice systems is > the Patent and other IP considerations. DStar uses the AMBE codec which > is owned by DVSI. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re:audio source/sink sample rate
> On Tue, Mar 18, 2008 at 10:00:32AM +0530, vsrk sarma wrote: > > Is it possible to change default sample rate for audio files? > > Most examples in gnuradio examples seemto set sample rate at 32000. > > Also default audio source/sink is from gr-audio-alsa despite > configure,make > > & install with --enable-audio-oss. > > alsa in my system is accepting only 48000. > > Is it possible to change setting somewhere to make them compatible? > > I have gnuradio-3.1.1(tarball version) on Ubuntu 7.10 on a 64 bit > > laptop(HP/Compaq nx6115) > > > > -- > > vsrk sarma > > You can set the default audio driver by creating a ~/.gnuradio/config.conf > with this content: > > [audio] > verbose = True > #audio_module = audio_oss > audio_module = audio_alsa > > Try specifying -I plughw:0,0 or -O plughw:0,0 on the command line if > you're using ALSA. plughw implements a resampler. FWIW, we find that ALSA > generally works better than OSS. > > Eric > Python examples I am running are outting directly to alsa. Can you specify where I can you these arguments? I am running my examples from terminal command line using commands like :python am_rcv.py [args] arguments given above are not accepted. I tried setting up config.conf in ./gnuradio folder (in the parent directory of gnuradio-3.1.1 without improvement. Is this the correct place or should it be in location such as /usr/local/lib/... vsrk sarma +91 98498 64184 +91 40 6545 8642 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
David I. Emery wrote: Is this a DVSI licensed and publically available closed source module or something "unofficial" or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues... and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don't see this as in their interest). Reverse engineering - at least for two common IMBE variants (P25 and MA/COM's ProVoice) - isn't necessary. Both algorithms are published by DVSI through the TIA. One of WinRadio's more recent offerings includes a software codec option for P25. It's a $99 download - probably DRM'd to your radio's serial number. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
