[Discuss-gnuradio] Newbie Q: Prototyping digital data over an audio path
Hi, I'm hoping that somebody can give me some pointers and advice on something I would like to do. My end goal: Using the audio output of my Livescribe Pulse smartpen, transmit data at a rate of 10 to 100 kbps, to be received by an iPhone and/or Android phone. What I have so far: 600 bps FSK using speaker/mic combo. Great proof of concept, but 20 seconds of screeching noise to transfer a short handwritten note is...less than optimal. What I'm thinking of doing: Using a cable between the devices, and QAM modulation. Is QAM16 or 64 a good modulation type for a cabled audio link? Is there something that would be more appropriate? The audio generation side is *extremely* resource constrained right now - j2me. How I'm thinking of getting there: 1. Use GNURadio to do an internal audio loopback test of some modulation schemes 2. Do the same thing using a physical loopback cable 3. Feed my computer's audio into an iPhone with an audio recording app, then feed the recorded sound file into GNURadio 4. Same thing, with my pen as the source 5. Write some J2ME code to generate the audio on the fly 6. Write a server-based iPhone app that feeds the audio into a remote GNURadio instance for decoding 7. Write an optimized iPhone native version. (Maybe? Is it possible? Is it even worth it? I get unlimited data on my cell plan...) Am I on the right path? My knowledge of signal processing is, sadly, somewhat rudimentary. I've written an FSK decoder using an FFT library in Python, and I can read a constellation diagram, so I have *some* knowledge, just not a lot. Looking at the QAM blocks in GNURadio, I see the comments: # NOT READY TO BE USED YET -- ENABLE AT YOUR OWN RISK While I am interested in learning, I don't feel that I am ready to spend 6 months getting up to speed on signal processing theory before I can even get a prototype working. Learning how to use GNURadio has been on my to-do list for quite awhile, but what I don't want to end up doing is spending a few months and then learning that I am not skilled enough to build what I need - it's hard from the outside to figure out what types of systems are easy to build and what require very detailed knowledge. Thanks for any advice, gopi. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] new hardware procurement
i am a student of telecommunications. we are undertaking a project regarding cooperative relaying using usrp. i have gone through some reports and blogs and that has made me confused about the selection of the daughter boards. there are problems such as strong line of site (which is bad for relaying diversity experiments) associated with 2.4G board with a low transmission power. on the other hand the flex400 has a lesser line of site issue but the transmission power is high. are there any hardware issues regarding these boards? what would be a good buy? flex400`s or the RFX2400`s. thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] glue blocks using C++ instead of Python
Blocks in Flowgraphs for transmission and receiving are are connected using python. (examples: benchmark_rx.py & benchmark_tx.py) Has someone glued those blocks (for TX & RX) using C++? I cannot find examples with C++. BR, Tom -- View this message in context: http://old.nabble.com/glue-blocks-using-C%2B%2B-instead-of-Python-tp27198638p27198638.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error regarding....WXgui
Hi, I have an error regarding wxgui. I am trying to use USRP board, it is detected successfully, benchmark.py file is running fine. When i try to use usrp_wbfm_rcv.py it gives an error. Traceback (most recent call last): File "/home/ali/Desktop/usrp_wfm_rcv.py", line 28, in from gnuradio.wxgui import slider, powermate ImportError: No module named wxgui I have installed all packages written on this link * http://gnuradio.org/redmine/wiki/gnuradio/GettingStarted * Please help me for resolving this issue. Thanks Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] glue blocks using C++ instead of Python
tom_unaff wrote: Blocks in Flowgraphs for transmission and receiving are are connected using python. (examples: benchmark_rx.py & benchmark_tx.py) Has someone glued those blocks (for TX & RX) using C++? I cannot find examples with C++. There is an example of this. See http://gnuradio.org/cgit/jcorgan.git/commit/?h=patches/mkjellss/bert-c%2b%2b&id=1bdb29911ac03428152b11ee81918c0a72e1319a But I'm quting Jonathan Corgan on this one: "However, we can't merge this into the mainline tree until we work out a method for integrating the C++ examples into our conditional build system. That's planned soon." Another place to look is http://gnuradio.org/doc/doxygen/index.html Thats where I looked while doing the rewrite. Cheers, and happy hacking =;OP //Mattias Kjellsson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error regarding....WXgui
When you build gnuradio, what was the output of ./configure ? Was gr-wxgui one of the configured components? If not, you may be missing dependencies. -Josh On 01/17/2010 05:13 AM, Muhammad Ali Khan wrote: Hi, I have an error regarding wxgui. I am trying to use USRP board, it is detected successfully, benchmark.py file is running fine. When i try to use usrp_wbfm_rcv.py it gives an error. Traceback (most recent call last): File "/home/ali/Desktop/usrp_wfm_rcv.py", line 28, in from gnuradio.wxgui import slider, powermate ImportError: No module named wxgui I have installed all packages written on this link * http://gnuradio.org/redmine/wiki/gnuradio/GettingStarted * Please help me for resolving this issue. Thanks Ali ___ 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] Error regarding....WXgui
hi, Thanks Josh for the reply that error is removed, now there is another error by compiling the same file *usrp_wfm_rcv.py *that is Traceback (most recent call last): File "/home/ali/Desktop/usrp_wfm_rcv.py", line 26, in from gnuradio import blks2 File "/usr/local/lib/python2.6/site-packages/gnuradio/blks2/__init__.py", line 37, in exec "from gnuradio.blks2impl.%s import *" % (f,) File "", line 1, in File "/usr/local/lib/python2.6/site-packages/gnuradio/blks2impl/cvsd.py", line 24, in from gnuradio.vocoder import cvsd_vocoder File "/usr/local/lib/python2.6/site-packages/gnuradio/vocoder/cvsd_vocoder.py", line 6, in import _cvsd_vocoder ImportError: libgnuradio-cvsd-vocoder.so.0: cannot open shared object file: No such file or directory help me with this one. Thanks Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Test tarballs for 3.3git
Test tarball distribution files have been created for the current 3.3git release under development: http://gnuradio.org/releases/gnuradio/gnuradio-3.3git-594-g02616cf8.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3git-594-g02616cf8.tar.gz These distribution files should compile and install using the same configure, make, make install process as the current 3.2.2 release files do. The purpose of providing these is to test the distribution tarball creation process, which can fail in ways that wouldn't affect building from a repository checkout. The full set of features for 3.3 release is not in them, nor are there release notes. However, the resulting build should be identical to what you would get if you were to build from our current git master. A word on naming--pre-release tarballs will have 3.3git, followed by the number of revisions since the last tag in the repository, followed by the shortened git commit id they are based on. In this case, we put in a 3.3git tag in the repo when we did the conversion from Subversion, so there have been 594 commits along the master branch since then. (This naming is derived from the output of 'git describe'). For USRP2 users, the associated image files for the firmware and FPGA, respectively, are: http://gnuradio.org/releases/usrp2-bin/trunk/txrx_edk10.1_3.3git-594-g02616cf8.bin http://gnuradio.org/releases/usrp2-bin/trunk/u2_rev3_ise10.1sp3_3.3git-594-g02616cf8.bin Remember, this is not a stable release, but a snapshot of our current development for 3.3. If this turns out to be useful (as measured by feedback on the list or the wiki), we may automate this. Finally, pending further testing, binary packages for Ubuntu 9.10 for this version will be created; those tracking 'unstable' in their package manager will get these automatically when they are ready. Thank you, Johnathan Corgan Corgan Enterprises LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USB connectivity under gnuradio/cygwin
I am trying to communicate with an external board (not the usrp) using usb. I have a driver installed under Windows that works fine with a standalone application. I have a gnuradio block for the same board, but am unable to get the usb driver recognized under cygwin. If someone has experience with this, I would appreciate some insight into whether there is something special that needs to be done to find the usb driver/port in cygwin to connect to the external board. As an alternative can someone point me to the gnuradio code that handles the usb connections for other boards so that I can use this as a model for moving forward. Thanks, -CAS ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] GRC: Serial Port to Block Diagram Interface
Thanks for the pointer, Josh! It surely did help... But now I'm stuck up somewhere else.. I managed to hack up the grc_gnuradio/blks2/probe.py to make the source block I require. But before that, let me make clear my intention is to mainly use the Graphical Sinks / Operators in GRC, to be able to wire up blocks for processing and displaying the signals I acquire from my serial interface. Right now, I'm using the python random number generator to shove me samples (in a similar callback function ref:probe.py). I wired up the blocks in this fashion in GRC: [ My Block ] -> [ Throttle ] -> [ Variable Sink ] and kept a Variable Text Box also in the window, referring to the ID in Variable Sink. Now I'm able to see the samples from the random number generator in the Variable Text Box.This works since Variable Sink is basically just a Message Sink with Callback. I could also use Operator Blocks like Multiply, Add on the incoming sample stream (placed after the Throttle block), whose output I'm able to see clearly on the Variable Text Box. Now to the issue - when I replace the Variable Sink block with any of the typical Graphical Sink blocks [Scope, Number, Histo] or even File sink, nothing seems to come out in the Sink. I suspect this due to the format of data expected by these traditional Sink blocks to be different from what is coming out from the Message Queue. This is the portion of the code I am using (from probe.py) to insert messages into the queue: arr = numpy.array(random.random(), numpy.float32) return gr.message_from_string(arr.tostring(), 0, gr.sizeof_float, 1) self._msgq.insert_tail(msg) I'm not entirely clear about the argument structure for gr.message_from_string() function, for which I couldn't find much documentation. I could understand the second argument represents message type (0 for all data messages, 1 for End-Of-Message). I've no idea what the third and fourth argument actually conveys. I do understand that message queues were not exactly built for this purpose. But I'm sure the mechanism to make the data acceptable to the traditional Sink blocks would have some good use, let alone this poor chap's ;) Or am I in the wrong direction using message queues ? Still Cheering, John > Date: Thu, 14 Jan 2010 14:46:12 -0800 > From: j...@joshknows.com > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] GRC: Serial Port to Block Diagram Interface > > You should make a hier2 block that has a gr.message_source inside of it. > You can put data you read from the serial port into a message queue. > (internally) The message sink will pop items off of the queue and into a > gnuradio stream. > > Take a look in grc/grc_gnuradio/blks2/* for example. Several of the > blocks in there make use of these message blocks and message queues. > Then, to get the block in grc, you can make an xml file modeled off of > one of the blocks in grc/blocks/*.xml > > Hope that points your in the right direction. > -Josh > > On 01/14/2010 02:17 PM, John Bonn wrote: > > > > Hello friends.. > > > > I'm trying to setup some experiments to utilize the GRC environment. As a > > part of it, I'm reading samples off an ADC connected to a microcontroller > > connected to PC via UART/RS232 Serial, using PySerial module. > > > > I have been trying to write a Source block for GR, where a listening > > thread > > would read the ADC samples from the Serial port into a global variable, and > > then, another thread wud "probably" pass the data into a gr.vector_source > > (like?) block within a hier2 block. > > > > Well, that was just the idea. But I guess the system doesn't work this way. > > I'm not sure whether I'm entering the message-blocks domain, which is > > expected to support such packetised(?) data. I read in the GRC Wiki - "add > > custom blocks" section that it might be possible to make such "special" > > functionality encapsulated in a block-diagram-safe block. Any suitable > > examples ? > > > > Conflicting again is the thought that ultimately samples from USRP and Audio > > sources are also probably caught in chunks and assembled into streams. But > > the sources for them look too complex and spread out for me to look into > > right now. > > > > I hope someone will make it clear for me and point me in a direction I can > > look for a quick hack. > > > > Cheers, > > > > John > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Keep your friends updated—even when you’re not signed in. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010___ Discuss-gnuradio mailing list Discus
Re: [Discuss-gnuradio] GRC: Serial Port to Block Diagram Interface
This is the portion of the code I am using (from probe.py) to insert messages into the queue: arr = numpy.array(random.random(), numpy.float32) return gr.message_from_string(arr.tostring(), 0, gr.sizeof_float, 1) self._msgq.insert_tail(msg) From the doxygen: gr_message_sptr gr_make_message_from_string (const std::string s, long type, double arg1, double arg2) A message is just a string of bytes, and them some arguments. The arguments are implementation dependent. In the grc code, those arguments are not even used, probably copy-pasted from some other code. Basically, you put binary data into a message, which goes into a message queue, and then its up to whoever reads from the queue to cast this data into the correct form. As a side note: Some of that grc/message passing kludgery needs to be revisited. But I would hesitate to do so because that PMT work may come to fruition... I'm not entirely clear about the argument structure for gr.message_from_string() function, for which I couldn't find much documentation. I could understand the second argument represents message type (0 for all data messages, 1 for End-Of-Message). I've no idea what the third and fourth argument actually conveys. I do understand that message queues were not exactly built for this purpose. But I'm sure the mechanism to make the data acceptable to the traditional Sink blocks would have some good use, let alone this poor chap's ;) Or am I in the wrong direction using message queues ? Message source and sinks are designed to get data in and out of gnuradio streams. Message queues and messages are how you interface with a message source or sink; by putting or taking messages in and out of a queue. Internally in the gr-wxgui stuff, all the blocks actually use message sinks to take streaming data out of gnuradio and get it into python for plotting. If you are having issues with the plotters, make sure that the samples rates match up, that can cause issues because the plotters try to decimate to achieve frame rate. Also be aware that the gr runtime passes around bit chunks of memory at a time, not single numbers, so you may be seeing an artifact of that. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2
Thanks for the reply Patrik, I managed to identify parameter values that make OFDM decoding work. It seems that low decimation/interpolation rates don't work (a bunch of "S"s at the receiver), nor do higher modulation schemes. The performance is very sensitive to the fft_length/occupied_tones. As a side note, the OFDM example from gnuradio-3.2.2/gnuradio-examples/python/ofdm works with BPSK but doesn't deliver any correct packets with the other modulations. The example I made in GRC though, works fine with both BPSK, QPSK and 8PSK. However, the packet error rate is quite high, I still haven't identified a case in which the error rate would be less than %40. cheers, Veljko 2010/1/15 Patrik Eliardsson : > Hi, > > I've tried the OFDM example on the USRP2 with minor changes and I didn't > encounter any problems. Be sure that you have the same FFT-length, number of > occupied tones, interpolation/decimation on both the receiver and > transmitter. Have you tried to increase the distance between the transmitter > and the receiver? Depending on your surrounding environment you may have to > tweak the length of the CP. > > I have the same configuration as you, but I have the RFX2400 instead of the > XCVR2450. > > Regards, > Patrik Eliardsson > >> -Original Message- >> From: >> discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org >> [mailto:discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu. >> org] On Behalf Of Veljko Pejovic >> Sent: Wednesday, January 13, 2010 10:22 PM >> To: discuss-gnuradio@gnu.org >> Subject: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2 >> >> Hi, >> >> I'm using Ubuntu 9.10, gnuradio version 3.2.2 and two USRP2 >> boards with XCVR2450 daughter boards. The boards are about a >> meter apart from each other. >> >> I'm trying to get OFDM working over USRP2 boards and for that >> I'm using GRC. I created a simple local loop (without USRPs): >> signal_source->modulation->channel_model->demodulation->scope_ >> sink. In this case OFDM modulation/demodulation works fine. >> However, when I split the loop into a sender >> signal_source->modulation->usrp2_sink and a receiver: >> usrp2_src->demodulation->scope_sink the decoding does not >> work, i.e. I don't get any output on the scope_sink. >> Although, FFT of the usrp2_src output looks exactly like what >> OFDM should look like. >> I'm pretty sure that the error is connected to OFDM as I got >> this transmitter/receiver pair working with GMSK, for example. >> >> I also tried the examples in >> gnuradio-3.2.2/gnuradio-examples/python/ofdm which I had to >> tweak a bit in order to get them using USRP2, but I got the >> same results: >> there is an OFDM-like signal in the air, but it's not getting decoded. >> >> Did anyone got OFDM demodulation working on USRP2? If so, any >> hints are highly appreciated. >> >> Thanks, >> >> >> Veljko >> >> >> ___ >> 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] OFDM modulation/demodulation over USRP2
Alright, I tuned a few more parameters (packet size, tx and rx gain) and got to a point where BPSK successfully receives almost all of the packets sent, and even QAM256 works, albeit very poorly. In my experiments changing the cyclic prefix didn't seem to have any impact. cheers, veljko 2010/1/17 Veljko Pejovic : > Thanks for the reply Patrik, > > I managed to identify parameter values that make OFDM decoding work. > It seems that low decimation/interpolation rates don't work (a bunch > of "S"s at the receiver), nor do higher modulation schemes. The > performance is very sensitive to the fft_length/occupied_tones. > > As a side note, the OFDM example from > gnuradio-3.2.2/gnuradio-examples/python/ofdm works with BPSK but > doesn't deliver any correct packets with the other modulations. The > example I made in GRC though, works fine with both BPSK, QPSK and > 8PSK. However, the packet error rate is quite high, I still haven't > identified a case in which the error rate would be less than %40. > > > cheers, > > Veljko > > 2010/1/15 Patrik Eliardsson : >> Hi, >> >> I've tried the OFDM example on the USRP2 with minor changes and I didn't >> encounter any problems. Be sure that you have the same FFT-length, number of >> occupied tones, interpolation/decimation on both the receiver and >> transmitter. Have you tried to increase the distance between the transmitter >> and the receiver? Depending on your surrounding environment you may have to >> tweak the length of the CP. >> >> I have the same configuration as you, but I have the RFX2400 instead of the >> XCVR2450. >> >> Regards, >> Patrik Eliardsson >> >>> -Original Message- >>> From: >>> discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu.org >>> [mailto:discuss-gnuradio-bounces+patrik.eliardsson=foi...@gnu. >>> org] On Behalf Of Veljko Pejovic >>> Sent: Wednesday, January 13, 2010 10:22 PM >>> To: discuss-gnuradio@gnu.org >>> Subject: [Discuss-gnuradio] OFDM modulation/demodulation over USRP2 >>> >>> Hi, >>> >>> I'm using Ubuntu 9.10, gnuradio version 3.2.2 and two USRP2 >>> boards with XCVR2450 daughter boards. The boards are about a >>> meter apart from each other. >>> >>> I'm trying to get OFDM working over USRP2 boards and for that >>> I'm using GRC. I created a simple local loop (without USRPs): >>> signal_source->modulation->channel_model->demodulation->scope_ >>> sink. In this case OFDM modulation/demodulation works fine. >>> However, when I split the loop into a sender >>> signal_source->modulation->usrp2_sink and a receiver: >>> usrp2_src->demodulation->scope_sink the decoding does not >>> work, i.e. I don't get any output on the scope_sink. >>> Although, FFT of the usrp2_src output looks exactly like what >>> OFDM should look like. >>> I'm pretty sure that the error is connected to OFDM as I got >>> this transmitter/receiver pair working with GMSK, for example. >>> >>> I also tried the examples in >>> gnuradio-3.2.2/gnuradio-examples/python/ofdm which I had to >>> tweak a bit in order to get them using USRP2, but I got the >>> same results: >>> there is an OFDM-like signal in the air, but it's not getting decoded. >>> >>> Did anyone got OFDM demodulation working on USRP2? If so, any >>> hints are highly appreciated. >>> >>> Thanks, >>> >>> >>> Veljko >>> >>> >>> ___ >>> 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] DAC configuration of gr-sounder
Hi Johnathan, I'm trying to understand the project gr-sounder and have some questions on that. 1. What's the configuration of AD9862 for the transmitter in gr-sounder. I didn't any code setting the register of AD9862 in the python code of gr-sounder project. 2. I used an oscilloscope to watch the signal the gr-sounder transmitter sends from the antenna A, but the waveform is like eye diagram and contains lots of noise. The frequency of the waveform is not the one which I set when run the project. Is there any problem on the method I did the test of the project? Thanks in advance. Yan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Minimum external clock for FPGA?
> It is my understanding that the current FPGA image used for OpenBTS will > fail on the transmit side if the FPGA clock is slower than the USB clock. > The USB clock is 48 MHz. > If you (or anyone else involved) can provide the details of what the issue is here, I may have some time to dive in and potentially come up with a fix. Let me know if interested. > > Also, the GSM symbol clock is derived from 13 MHz, so if you use a > multiple-of-13 clock, you can simplify a lot of the decimation. > > These two facts together led us to choose 52 MHz for the current OpenBTS > USRP clock. > Gotcha. Thanks for the quick response David. Anyone else know of any other issues that would prevent the FPGA from being clocked at lower speeds? > On Jan 16, 2010, at 4:33 PM, John Orlando wrote: > > Hi all, > I've seen posts about folks providing an external clock of 44 MHz to the > USRP, and with a few software tweaks, getting it to work. I'm wondering if > there is a floor as to how low this clock be reduced without causing > problems. I know some A/D converters have minimum sample rates, but the > AD9862 datasheet doesn't seem to indicate that it does. Is there any reason > I couldn't run my USRP with an external reference at 26 MHz? How 'bout 10 > MHz? > > The only datapoint I could find was a reference to the fact that the > current openBTS FPGA image doesn't run (?) at 26 MHz due to a "firmware fix" > that is needed, though I'm guessing that is referencing the FPGA code: > > http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg21130.html > > I'll probably make the USRP hardware modification on Monday to try these > out with an external sig gen, but I figured I'd throw the question to the > list prior to that to see if I could get a definitive answer. > > Thanks much... > > -- > Regards, > John Orlando > CEO/System Architect > Epiq Solutions > www.epiq-solutions.com > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > David A. Burgess > Kestrel Signal Processing, Inc. > > > > > -- Regards, John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Minimum external clock for FPGA?
On 01/17/2010 07:01 PM, John Orlando wrote: It is my understanding that the current FPGA image used for OpenBTS will fail on the transmit side if the FPGA clock is slower than the USB clock. The USB clock is 48 MHz. If you (or anyone else involved) can provide the details of what the issue is here, I may have some time to dive in and potentially come up with a fix. Let me know if interested. Also, the GSM symbol clock is derived from 13 MHz, so if you use a multiple-of-13 clock, you can simplify a lot of the decimation. These two facts together led us to choose 52 MHz for the current OpenBTS USRP clock. Gotcha. Thanks for the quick response David. Anyone else know of any other issues that would prevent the FPGA from being clocked at lower speeds? The 9862 is only spec'ed down to 10 MHz. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to Confirm OFDM constellation with USRP and GRC
Hi- all I’m now trying Transmission of the OFDM system with USRP and GRC I use OFDM mod/demod block in GRC I confirmed received spectrum by USRP receiver But I want to confirm constellation of receive block In my opinion, I have to spilt ofdm.py file before FFT. Am I correct? Do you have another method such as benchmark_ofdm? except using ofdm mod/demod Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Start_rx_streaming_at patch problems
On Tue, Jan 12, 2010 at 05:07, Tim Pearce wrote: > I've been using the latest git version of gnuradio and trying to get Doug's > start_rx_streaming_at patch (now merged with the git version) to work. [...] > When I do this everything compiles and I can start a flowgraph, > unfortunately no samples ever seem to be outputted from the block. There was a bug discovered in the merged patch that resulted in symptoms similar to what you are describing. It has been fixed as of git 165f4bc5. Please let me know if this corrects your problem. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: Discuss-gnuradio Digest, Vol 86, Issue 16
Hi : I am trying to add a new block wanet to gnuradio ,and after i writing the .h .cc and .i files, the following commands ./bootstrap ./configure -prefix=.. ./make ./make check ./make install all went well but when i try to use the newly added block in a testing code , the terminal said >>No module named _wanet can anyone give me some suggesstions to solve the problem! thanks! tuyang _ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TL&swm=1___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
