Re: [Discuss-gnuradio] UHF monitoring
On Mon, Apr 12, 2010 at 09:05, schuler101 schuler...@gmail.com wrote: Thanks for reply. I had one more question, if I was just monitoring the usage of channel (it is being used or not at any moment), do I still need to write complex gnuradio scripts? My guess would be that it should be easy to write corresponding scripts since I am not trying to decipher received signal as such. You have two choices: 1) Use an existing utility like usrp_fft.py to visualize the sample stream coming from the USRP in the time or frequency domains. 2) Write your own GNU Radio application to process the sample stream to extract the information you desire. It all depends upon what you mean by just monitoring the usage of channel. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reuse c++ modules in c++ code
On Mon, Apr 12, 2010 at 17:31, Kyle Zhou kyle...@gmail.com wrote: I am writing a new c++ signal processing block and wondering if I can use existing gnuradio modules in this new module. I know reuse c++ modules in python is easy via swig. When it comes to reusing in c++, what is the best way? I can think of inheritance. But what if I want to use multiple existing modules? It is possible to write hierarchical blocks in C++, which compose existing blocks into an internal flowgraph: http://gnuradio.org/redmine/repositories/browse/gnuradio/gnuradio-core/src/lib/hier You do not need to call the work() function of the internal blocks; the runtime figures all this out for you. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
On Mon, Apr 12, 2010 at 22:11, Ian Holland ian.holl...@rlmgroup.com.au wrote: I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. The digital-bert example uses a self-synchronizing scrambler to generate a bit sequence that occupies the full baseband bandwidth of the channel. The scrambler/descrambler pair is insensitive to the phase ambiguity; however, this comes at the price of generating extra bit errors on the descrambled sequence for every bit error in the channel. Secondly, I came across another post in which it was mentioned the Costas loop should only operate on a single sample per symbol. However, as I read the source code, it seems as though it is actually passed sps samples per symbol, where sps 1. Have I misread something here? Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
Thanks Jonathon This clears things up a bit. By the way, the post I was referring to can be found at http://osdir.com/ml/discuss-gnuradio-gnu/2010-02/msg00098.html Maybe I misread the reply from Jason, but said reply seemed to suggest to me that a single sample per symbol should be used. Anyway, your response has cleared things up for me. Best Regards Ian. -Original Message- From: Johnathan Corgan [mailto:jcor...@corganenterprises.com] Sent: Tuesday, 13 April 2010 4:36 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert... On Mon, Apr 12, 2010 at 22:11, Ian Holland ian.holl...@rlmgroup.com.au wrote: I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. The digital-bert example uses a self-synchronizing scrambler to generate a bit sequence that occupies the full baseband bandwidth of the channel. The scrambler/descrambler pair is insensitive to the phase ambiguity; however, this comes at the price of generating extra bit errors on the descrambled sequence for every bit error in the channel. Secondly, I came across another post in which it was mentioned the Costas loop should only operate on a single sample per symbol. However, as I read the source code, it seems as though it is actually passed sps samples per symbol, where sps 1. Have I misread something here? Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] XML Editing Tools
Hi. What are the tools used to create the following Gnu Radio documents: a) exploring-gnuradio.xml b) usrp_guide.xml c) gr-trellis.xml Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to get the content of EEPROM on mother board (boot issue)
Hi All I am now developing a board like USRP, also using gnuradio, but add some surroundings. The issue now is as below. I have changed the VID and PID in EEPROM on mother board to FFFE/0002, which is the same as usrp. And in the instrument manager, I can see the my device and the ID is FFFE/0002, which is right. I think the PC should drive my device the same as USRP, but my device still can not boot. the system can't find USRP device. Do you guys know why? I doubt that because the configuration of my rom is wrong. (Or is there some posibility else?) So I would like to check the content of EEPROM. Is there the EEProm data file in the gnuradio package (I think it should be .iic format?)? or how I can read from the EEPROM without taking it off? Thank you very much! BR Xin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Strange indentation space in python script
Hi,all, I just found a strange probelm in python scripts. For example, if I look at the usrp2_fft.py file from the website listed as below. The indent of line 57 and line 59 has one indentation space smaller than other lines. http://vps.gnuradio.org/redmine/repositories/entry/gnuradio/gr-utils/src/python/usrp2_fft.py?rev=a549bd11646f60d425a74d530b8f3ddfc4774202 However, if I down it into my laptop and open this file with IDLE or other editer, the line 57 and line 59 have two indentation space bigger than other lines. In my opinion, there should not be any extra indentation space for both line 57 and line 59. Since the indentation is part of the python grammar, it confused me a lot. Regards Andy long -- View this message in context: http://old.nabble.com/Strange-indentation-space-in-python-script-tp28229298p28229298.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
Re: [Discuss-gnuradio] How to get the content of EEPROM on mother board (boot issue)
2010/4/13 Liang Xin 梁昕 liangxin...@gmail.com: Hi All I am now developing a board like USRP, also using gnuradio, but add some surroundings. The issue now is as below. I have changed the VID and PID in EEPROM on mother board to FFFE/0002, which is the same as usrp. And in the instrument manager, I can see the my device and the ID is FFFE/0002, which is right. I think the PC should drive my device the same as USRP, but my device still can not boot. the system can't find USRP device. Do you guys know why? I doubt that because the configuration of my rom is wrong. (Or is there some posibility else?) So I would like to check the content of EEPROM. Is there the EEProm data file in the gnuradio package (I think it should be .iic format?)? or how I can read from the EEPROM without taking it off? Thank you very much! BR Xin There is significantly more to USB than simple VID/PID. You need to have specific endpoints set and control words are used which are specific to the device. Additionally, any driver that you are using will talk to the device in a specific way, your computer is talking to your new board as if it were a USRP, and it is not responding because you didn't program it to. From your previous emails (to which I will address the reply here), it seems as though you want to make a new output device for gnuradio to compete with the USRP in terms of price. I think there is a market for this, so good luck. With that said, I think that you are getting ahead of yourself. Unless you want to specifically clone the USRP using different chips, which would seem kind of pointless because you would be unable to add any functionality, you would need to use a different PID/VID and register your board as a separate device. The second step is to write a source and sink block for this new device and work. Your approach is not wholly wrong, when making a new IO device for gnuradio the USRP is a good place to start, it's an existing codebase that documents the appropriate way to talk to gnuradio. However you will not be able to simply copy the code, because your device will be different in several way, mostly the method you use to transfer data to it. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange indentation space in python script
It seems to display correctly on that link for me. Checking it on my copy here it looks like the script is playing the dangerous game of mixing tabs + spaces so the actual indentation you see on your text editor depends on how it treats tabs. Whether it works or not then depends on how python chooses to treat the tabs. Looks like tabs are used on some other lines as well. Cheers, Tim On Tue, Apr 13, 2010 at 1:24 PM, Andy_Long luckshiw...@yahoo.com.cn wrote: Hi,all, I just found a strange probelm in python scripts. For example, if I look at the usrp2_fft.py file from the website listed as below. The indent of line 57 and line 59 has one indentation space smaller than other lines. http://vps.gnuradio.org/redmine/repositories/entry/gnuradio/gr-utils/src/python/usrp2_fft.py?rev=a549bd11646f60d425a74d530b8f3ddfc4774202 However, if I down it into my laptop and open this file with IDLE or other editer, the line 57 and line 59 have two indentation space bigger than other lines. In my opinion, there should not be any extra indentation space for both line 57 and line 59. Since the indentation is part of the python grammar, it confused me a lot. Regards Andy long -- View this message in context: http://old.nabble.com/Strange-indentation-space-in-python-script-tp28229298p28229298.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FFT beamforming
I have a potential application for an FFT beamformer. 5 or 7 antennas, 5 or 7 USRP2. The actual application is fairly narrowband--less than 250KHz wide. If I lock all the USRP2 to a common source (GPSDO probably) is that likely to be good enough for an FFT beamformer? The computational burden will be quite modest of course, since the bandwidth will be 250KHz or less, but what of the required phase coherence? Anyone had any related experience? Cheers -- 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] XML Editing Tools
I am afraid that the files look hand-written. You can misuse doxygen to make manuals by feeding it hand written xml. At least I think thats the case. I am interested to have a wiki-based markup, where the wiki code could be rendered into doxygen xml by a small python script (or just strait to html, it doesnt need to integrate with doxygen). Its easier to write wiki code than xml, and its easier to maintain documentation code checked into the git repo (and keep it version specific). What do you think about a wiki-based solution to extending gnuradio documentation? -Josh On 04/12/2010 11:50 PM, Firas Abbas wrote: Hi. What are the tools used to create the following Gnu Radio documents: a) exploring-gnuradio.xml b) usrp_guide.xml c) gr-trellis.xml Best Regards, Firas ___ 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] xcvr2450
Dear Matt and All, I can see in the data-sheet of the MAX2829 that there is some form of calibration mode. I don't really understand what it does. Is it used ? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Interpolation before USRP sink
On Tue, Apr 13, 2010 at 10:52 AM, Alberto Trentadue albtrenta...@tiscali.it wrote: Hello to the list I am trying to build a simple SSB transmitter using GRC - GR-3.2.2. I use the 32Khz sampled audio source and bandpass it to reduce bandwidth to minimum. In order to match USRP usable interpolation, I have to set an interpolation by 10 to the bandpass, so that 32K * 10 * 400 = 128MSPS. I've actually managed to get the RF signal out of the USRP, but it isn't really satisfactory. The 10-interpolated spectrum contains my baseband signal's spectral replicas spaced by 32kHz, as it always is the case when interpolate. My problem is that if I put a lowpass filter between the bandpass and USRP sink, working at 320kHz, the CPU cannot keep up and I get uUuUaOaO like raining. If you use the gr.interp_fir_filter_XXX properly, you should not get the spectral replicas. Make the taps as: taps = gr.firdes.low_pass_2(1, 32e3*10, 32e3, 5e3, 80) Those last three numbers are the bandwidth, transition band, and out of band attenuation, so use whatever numbers you want. When you use these taps in the interpolation filter, it should produce a cleanly interpolated signal for you. I use an AMD-3X Phenom with 3x2.3GHz cores and Ubuntu 9.04. Actually I see that 1 of the cores jumps to full 2.3G speed and gets stuck at 100% usage. That should be a powerful enough processor to run a filter at 320 kHz. What version of GNU Radio are you running? It almost sounds like you're using the single threaded scheduler instead of the thread per block. Regardless, you can get rid of the second filter if you use the interpolating filter correctly. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gr-trellis ; convolutional code and convolutionnal interleaver.
Gr-trellis ; convolutional code and convolutionnal interleaver. Hi, I'm trying to design an error correction flow graph that would use a convolutional encoder and a convolutional interleaver. I searched in gr-trellis for the appropriate blocks, but I have a bunch of questions about how to use them. About the convolutional interleaver. Trellis.interleaver needs a specification file. Where can I find an example of this specification file? The best would be a file specifying a convolutional interleaving. About Viterbi decoder I wrote the following python file that should encode a stream of bits and decode it using Viterbi algorithm. Unfortunately, my inputs and outputs are different. What did I do wrong? Thanks Axel class top(gr.top_block): def __init__(self): gr.top_block.__init__(self) constel= (2,[0, 0, 0, 1, 1, 0, 1, 1]) f=trellis.fsm(/home/Axel/Desktop/Testgnuradio/FSM_Codeur2.fsm) self.src_data = (0,0,1,0,0,1,1,0,1,0,1,1,1,0,1,0,1,1,0,0,1,0,0,1,1,0,1,1,0,1,1,0,1,0,0,1,1,0,0,0,1,1,1,0,1,0,1,1,0,0,1,0,0,1,1,0,1,1,0,1,1,0,1,0,0,1,1,0,0,0,1,1,1,0,1,0,1,1,0,0,1,0,0,1,1,0,1,1,0,1,1,0,1,0,0,1,1,0,0,0,1,1,1,0,1,0,1,1,0,0,1,0,0,1,1,0,1,1,0,1,1,0,1,0,0,1,1,0,0,0,1,1,1,0,1,0,1,1,0,0,1,0,0,1,1,0,1,1,0,1,1,0,1,0,0,1,1,0,0,0,1,1,1,0,1,0,1,1,0,0,1,0,0,1,1,0,1,1,0,1,) self.in_data = gr.vector_source_s (self.src_data) self.enc = trellis.encoder_ss(f,0) # initial state = 0 #self.mod = gr.chunks_to_symbols_sf(constel[1],constel[0]) self.metrics = trellis.metrics_s(f.O(),1,[0,1,2,3],trellis.TRELLIS_HARD_SYMBOL) self.va = trellis.viterbi_s(f,2,0,-1) # Put -1 if the Initial/Final states are not set. #self.va =trellis.viterbi_combined_s(f,K+L,0,0,dimensionality,tot_constellation,trellis.TRELLIS_EUCLIDEAN) self.sink1= gr.vector_sink_s() self.sink2= gr.vector_sink_s() self.connect (self.in_data,self.enc,self.metrics,self.va,self.sink2)#,self.metrics,self.va) self.connect (self.in_data,self.sink1) def print_out(self): print in,self.sink1.data() print out,self.sink2.data() if __name__ == '__main__': try: tb = top() tb.run() tb.print_out() except KeyboardInterrupt: pass (FSM_codeur2.fsm = ) 2 4 4 0 2 0 2 1 3 1 3 0 3 3 0 1 2 2 1 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git macports OSX 10.6 x86_64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, El mar 21, 2010, a las 1:21 a.m., Michael Dickens escribió: Hi Christian - On Mar 20, 2010, at 2:41 PM, Christian Kendi wrote: the git has the problem: configure: creating ./config.status config.status: error: cannot find input file: `gruel/Makefile.in' With or without CFLAGS/CXXFLAGS=-arch i386 doesnt matter. yes, been bootstrapping before. The 'Makefile.in' are created by bootstrap. So, if one is missing either it was removed after bootstrap or bootstrap failed. In order to bootstrap on OSX, you need to modify the script to use 'glibtoolize' instead of 'libtoolize' -- assuming you installed GNU's libtool using MacPorts or Fink or whatever, since they prepend a 'g' to the installed executables in order to distinguish between Apple's libtool and GNU's libtool executables (similar, yet very different). thanks for the response. in the meantime i was able to compile it with glibtoolize. The macports gnuradio works ALMOST fine. I had to custom build the wxPython and wxWidgets for 64 bit. Yeah; on 64-bit OSX I expect gnuradio-wxgui will error out since it requires wxPython which doesn't compile as 64-bit yet. Would you be willing to share your patches to get wxWidgets wxPython to be 64-bit? Or, are you using the latest SVN version (2.9.0.X)? i was using the SVN and both were compiling fine. The problem right now is that the FFT sinks stuck. Just when i move the cursor to a textfield where the cursor is blinking there is an update of the display. Obviously the refresh of the cursor is linked somehow. If im enabling GL sinks the display stucks totally! I tested other GL and normal wx apps with python and they work fine, so i guess my x64 builds are fine. No idea where to direct you; could be GNU Radio's WX programming or WX itself, or something in between. Maybe others know better. - MLD this is still an issue even updating to the latest SVN. Greets Chris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFLxJHqp+9ff145KVIRAhnnAKCoTW6WkYU/nBrlgUSOCaW+ULY8QQCfV6s/ NVy4j9ifpyb5KWbxXHZKylw= =TZKz -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] git macports OSX 10.6 x86_64
Hi Chris - I'm glad to hear you have at least some parts of GNU Radio working as 64-bit on OSX 10.6. I don't have 10.6 installed (yet) for further testing, but I'm heading that way one of these days. I've been holding out for the release of wxPython 2.9.0, which will officially support 64-bit on OSX; there are patches out for 2.8.9 and 2.8.10 series to support 64-bit, but none are truly stable yet (nor is the 2.9 trunk). The MacPorts folks are evaluating both the 2.8 series patches as well as helping out with the 2.9 series, to try to speed its release -- but who know when it'll be out. For now, a 32-bit install should work if you want to go that route. I'd choose to (re)install as universal everything that you can, but then make py26- wxPython and gnuradio-wxgui just 32-bit; should be doable without too much fuss. You could then upgrade to 64-bit when the dependencies are met. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] xcvr2450
On 04/13/2010 08:10 AM, Per Zetterberg wrote: Dear Matt and All, I can see in the data-sheet of the MAX2829 that there is some form of calibration mode. I don't really understand what it does. Is it used ? It is used to calibrate out DC offsets and IQ balance. We do not currently use this mode, but with a little bit of driver work and some flowgraphs we could. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gr-trellis ; convolutional code and, convolutionnal interleaver.
Axel, First, there is no such thing in gr-trellis as a convolutional interleaver. There is only a generic interleaver, ie a permutation which is defined through the different constructors provided in interleaver.h (through a file, random, etc). If you do not want to have super control over it i suggest you start with just a random interleaver and see how it works. Second, I see a minor problem in your code: the viterbi block should specify the block size as its 2nd parameter so instead of self.va = trellis.viterbi_s(f,2,0,-1) you should put something like self.va = trellis.viterbi_s(f,len(self.src_data),0,-1) I tried this modification and works fine with me. Let me know if you have any problems, Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On Mon, Apr 12, 2010 at 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Mon, 12 Apr 2010 16:02:43 +0800 From: =?GB2312?B?TGlhbmcgWGluIMG66r8=?= liangxin...@gmail.com Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface in USRP To: discuss-gnuradio@gnu.org Message-ID: o2o2579940b1004120102j64b217c0pf2ff8431da1ca...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi All I am developing a board with gnuradio which is like USRP. It is also use FX2LP(CY7C68013a) and AD9862, and I add some surroundings. I hope that my board can work well with gnuradio, but it seems like it can only support USRP now. So could you please give me some help, if I want to run gnuradio on my board. How should I do with it? ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility for its product. I have been working on this project for a few months. We're interested in feedback on the approach we took. Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board looks like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. We chose to have it show up as a USRP rev 5 to distinguish it from a real USRP, of which I believe the latest revision is 4. Is this likely to conflict any time soon? One of our goals was to minimize the changes required to the GNU Radio source tree, to make deployment and maintenance easier and to increase the chances of changes being integrated upstream. Catalin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On 04/13/2010 03:32 PM, Catalin Patulea wrote: ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility for its product. I have been working on this project for a few months. We're interested in feedback on the approach we took. Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board looks like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. We chose to have it show up as a USRP rev 5 to distinguish it from a real USRP, of which I believe the latest revision is 4. Is this likely to conflict any time soon? I would have used a higher version number, in order to give Ettus more headroom for new versions of their hardware, as an item of courtesy. In fact, Matts a great guy, you should perhaps just work this out between you, so that no tripping over each other happens, and the marketplace doesn't end up with down-the-road grief. I'm all in favour of standardizing the wire protocols used by both the USRP1 and USRP2, actually. One of our goals was to minimize the changes required to the GNU Radio source tree, to make deployment and maintenance easier and to increase the chances of changes being integrated upstream. A laudable goal, and I encourage cooperation, and the development of wire standards in this area. Full-disclosure: I used to be a protocol standards expert for my previous employer, Nortel. So I'm biased :-) -- 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] Re: About EEPROM and FX2(68013a) USB interfacein USRP
Catalin- On Mon, Apr 12, 2010 at 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Mon, 12 Apr 2010 16:02:43 +0800 From: Liang Xin Áºê¿ liangxin...@gmail.com Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface in USRP To: discuss-gnuradio@gnu.org Message-ID: o2o2579940b1004120102j64b217c0pf2ff8431da1ca...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi All I am developing a board with gnuradio which is like USRP. It is also use FX2LP(CY7C68013a) and AD9862, and I add some surroundings. I hope that my board can work well with gnuradio, but it seems like it can only support USRP now. So could you please give me some help, if I want to run gnuradio on my board. How should I do with it? ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility for its product. I have been working on this project for a few months. We're interested in feedback on the approach we took. Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board looks like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. We chose to have it show up as a USRP rev 5 to distinguish it from a real USRP, of which I believe the latest revision is 4. Is this likely to conflict any time soon? My suggestion would be to use 4.x and work out with Matt what the x should be... for example you might use 4.6 if Matt says that he's likely to jump a major rev number before he moves the minors to 4.5 This would give the advantage of marking your board with a more-or-less accurate time-frame and capabilities range. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On Tue, Apr 13, 2010 at 03:32:49PM -0400, Catalin Patulea wrote: On Mon, Apr 12, 2010 at 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Mon, 12 Apr 2010 16:02:43 +0800 From: =?GB2312?B?TGlhbmcgWGluIMG66r8=?= liangxin...@gmail.com Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface in USRP To: discuss-gnuradio@gnu.org Message-ID: o2o2579940b1004120102j64b217c0pf2ff8431da1ca...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi All I am developing a board with gnuradio which is like USRP. It is also use FX2LP(CY7C68013a) and AD9862, and I add some surroundings. I hope that my board can work well with gnuradio, but it seems like it can only support USRP now. So could you please give me some help, if I want to run gnuradio on my board. How should I do with it? ThinkRF (www.thinkrf.com) is also developing GNU Radio compatibility for its product. I have been working on this project for a few months. We're interested in feedback on the approach we took. Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board looks like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. I suggest (following Cypress's lead) that you have your device come up as something other than an unconfigured Cypress FX2. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp2_fft.py and changing the gain
On Tue, Apr 13, 2010 at 1:54 AM, Johnathan Corgan jcor...@corganenterprises.com wrote: On Mon, Apr 12, 2010 at 15:27, John Orlando j...@epiq-solutions.com wrote: However, as soon as I try to change the gain via the usrp2_fft.py GUI, I get an 'O' character spit out on the USRP2's serial port, and the GUI completely freezes. I then have to do a manual exit from the GUI window to get back to a cmd prompt, and can re-launch things from there. What you are seeing is a known bug with the current design of the USRP2 firmware. The internal gain calculations for the DBSRX by the microcontroller take too long for the polling loop to keep up with the state machine transitions. When this happens, I find that I can usually change the frequency via the GUI and the receive stream will start again. The solution to this is to go either go to a fully interrupt driven firmware design, and/or to move the daughterboard code back out of the firmware and onto the host like USRP1. I believe both of these things are happening in the Ettus Research UHD driver design, but I am not certain. Thanks for the insight Jonathon. I was doing some testing with our BURX board as well, and got the same GUI freezing result. The gain calculations for our board is trivial, so I wouldn't think that it is a matter of time being consumed doing these calculations. However, both the DBSRX and the BURX board use an I2C interface to communicate from the host to the daughterboard. So I wonder if it is really just a matter of the aeMB getting held up doing the I2C transaction. But if this were the case, I'd think _any_ I2C communication would cause the freeze (such as changing the center frequency, which also happens over I2C). And changing the center frequency works just fine on both boards. Hmm...may not be worth much investigating with UHD coming soon, assuming this fixes this. I guess it'll just be a head-scratcher for now. Thanks again... -- 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] usrp2_fft.py and changing the gain
On Tue, Apr 13, 2010 at 14:09, John Orlando j...@epiq-solutions.com wrote: Thanks for the insight Jonathon. I was doing some testing with our BURX board as well, and got the same GUI freezing result. The gain calculations for our board is trivial, so I wouldn't think that it is a matter of time being consumed doing these calculations. However, both the DBSRX and the BURX board use an I2C interface to communicate from the host to the daughterboard. So I wonder if it is really just a matter of the aeMB getting held up doing the I2C transaction. This may very well be the case as my recall is a little hazy (this was a year or two ago that it came up.) It could be that there need to be several I2C writes and it works if there is just one, but not if there are several. Anyway, there doesn't seem much chance of a solution until the UHD comes out. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On Tue, Apr 13, 2010 at 4:06 PM, Eric Blossom e...@comsec.com wrote: On Tue, Apr 13, 2010 at 03:32:49PM -0400, Catalin Patulea wrote: On Mon, Apr 12, 2010 at 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote: Date: Mon, 12 Apr 2010 16:02:43 +0800 From: =?GB2312?B?TGlhbmcgWGluIMG66r8=?= liangxin...@gmail.com Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface in USRP To: discuss-gnuradio@gnu.org Our board is also an unconfigured Cypress FX2 on power-up, so we will have a proprietary utility that changes the personality of the board. Once that is done, the board looks like a USRP, presenting the corresponding VID/PID and responding to the USRP USB protocol. This seems like it can only cause problems down the line. Wouldn't it be better from a development point of view to keep your device as a separate VID/PID that is unique to you and simply abstract/link the existing USRP functions into your source/sink pair? This way, at a minimum, if the USRP code were changed someway that broke your fpga implementation, the graph would fail gracefully, as opposed to the host just happily sending samples along while your device does nothing. Not to mention this would give you the ability to extend the functionality of the source/sink pair to take advantage of anything your board happens to do better than the USRP. From your website it seems that you support a wider bandwidth and frequency range than the USRP, why limit your board? Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
On 04/12/2010 05:22 PM, Vikram Ragukumar wrote: Matt, In our effort to distill the gemac core and related logic, we have pulled out the following module under u2_core SERDES, Dsp core, UART, external RAM interface and the buffer pool The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: which is instantiated in u2_core. Most of the buffering happens in simple_gemac_wrapper in the fifo_2clock_cascade files. (a) Is any buffering for the gemac done using buffers in the buffer pool or is it ok to eliminate that module all together ? Yes, it does buffering. You can get rid of it, but then you'll need to create a module which holds the FIFO contents until there is a complete packet. Otherwise, the ethernet will start sending the packet before you have a complete packet there. (b) The synthesis report currently shows that 24 BRAM's are being used by the design. Does this sound about right ? Are there modules unrelated to gemac or aeMB that we can pull out, to reduce BRAM usage ? You're going to need to do your own exploration. ISE has a feature to tell you which modules are using block rams. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: About EEPROM and FX2(68013a) USB interface in USRP
On 04/13/2010 07:09 PM, Jason Uher wrote:
This seems like it can only cause problems down the line. Wouldn't it
be better from a development point of view to keep your device as a
separate VID/PID that is unique to you and simply abstract/link the
existing USRP functions into your source/sink pair?
A couple of comments. Yup, a separate VID/PID (although doesn't Ettus use
a VID assigned to the FSF, in order to avoid large fees paid to the USB
consortium or something? ) would be a good idea.
If the device really does, more, or less, look like a USRP, then the
right thing
to do is to have a table in the USRP code (there probably already is) that
looks for the various VID/PID that could be a USRP-type device, and
do the right thing (configuring itself for vendor-a whizzy feature,
etc).
What I'd like to see is cooperation on these sorts of things from the
various
vendors in the new eco-system that Matt has unwittingly created here.
Creating some kind of cooperative standard for how the USB and GiGE
interfaces
work (with provision for vendor-specific-whizzy-stuff) will make
everybodies lives
easier. It will be an ecosystem, rather than a bunch of independent
bunkered
silos.
This way, at a minimum, if the USRP code were changed someway that
broke your fpga implementation, the graph would fail gracefully, as
opposed to the host just happily sending samples along while your
device does nothing. Not to mention this would give you the ability
to extend the functionality of the source/sink pair to take advantage
of anything your board happens to do better than the USRP. From your
website it seems that you support a wider bandwidth and frequency
range than the USRP, why limit your board?
I haven't looked at the wire protocol for either the USB or 1GiGE side
of things,
but it wouldn't surprise me if the wire protocols were fairly agnostic
about
things like bandwidth. I mean the protocols already have to support
notions
of capabilities with all the new daughter-cards out there.
Which brings up an interesting question. Is the capabilities database
on the cards,
or in the driver code, or in the FPGA code, or what? Is it rather a mix?
I like this to other classes of USB devices, like USB Audio, where
there is a base
protocol and expected device behaviour, and custom variants for
operating outside
the base functionality.
No reason not to do something similar here, both for USB and 1GiGE, and
whatever else
comes along in the future.
Despite that fact that (full disclosure) I derive a small part of my
income through Ettus, I'm thrilled
to see a USRP{1,2}-based ecosystem developing out there. It's
healthy for everybody. Not
just in the traditional competition is good business sense, but
because it causes better, more
mature growth. Applications can run on different hardware without
being re-written, new hardware
can instantly take advantage of existing applications. It's just a
Good Thing(tm).
These are exciting times in the SDR world, I believe.
--
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
[Discuss-gnuradio] Why no phase ambiguity in digital-bert...
I notice in the digital-bert example (benchmark_rx.py and receive_path.py), the Costas loop actually occurs prior to the MM sampler, without being wrapped inside the mpsk_receiver: (lines 104-105 of http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-examples/python/digi tal-bert/receive_path.py) self.connect(self, self._agc, self._rrc, self._costas, self._mm, self._c2r, self._slicer, self._descrambler, self._ber) Are these operations generally interchangeable? Thanks Ian. My explanation pertained to the benchmark_rx; but Johnathan already said it doesnt matter in his first reply ;) Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
Thanks, I wasn't 100% clear if there were some conditions for interchangability after Jonathon's reply, but it sounds like not. Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Jason Uher Sent: Wednesday, 14 April 2010 12:19 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Why no phase ambiguity in digital-bert... I notice in the digital-bert example (benchmark_rx.py and receive_path.py), the Costas loop actually occurs prior to the MM sampler, without being wrapped inside the mpsk_receiver: (lines 104-105 of http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-examples/python/digi tal-bert/receive_path.py) self.connect(self, self._agc, self._rrc, self._costas, self._mm, self._c2r, self._slicer, self._descrambler, self._ber) Are these operations generally interchangeable? Thanks Ian. My explanation pertained to the benchmark_rx; but Johnathan already said it doesnt matter in his first reply ;) Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. ___ 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] XML Editing Tools
Thank you Josh and Eric for the Responses From: Josh Blum j...@joshknows.com I am afraid that the files look hand-written. You can misuse doxygen to make manuals by feeding it hand written xml. At least I think thats the case. Whats I'm looking for is a new approach to generate both html and PDF documentation from the same source. I saw that writing an XML document is the best way since converting from xml to html and pdf is trivial. Example: 1) To convert usrp_guide.xml to html file: $ xmlto html-nochunks usrp_guide.xml 2) To convert the same file to PDF file: $ xmlto --with-fop pdf usrp_guide.xml Of course , we need the following dependencies: - xmlto - xmltex - fop I am interested to have a wiki-based markup, where the wiki code could be rendered into doxygen xml by a small python script (or just strait to html, it doesnt need to integrate with doxygen). Its easier to write wiki code than xml, and its easier to maintain documentation code checked into the git repo (and keep it version specific). What do you think about a wiki-based solution to extending gnuradio documentation? Josh It is a good idea. If you decided to write such code, please keep in mined to use redmine wiki markup. P.S: I want to warn you that I failed to convert doxygen xml files to PDF files. They seems not to be a standard docbook xml files. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] XML Editing Tools
I feel wiki markup is the best way to go. Its friendly on the writer and makes for readable diffs. I dont like the idea of checking in generated docbook xml. We could use restructured text http://en.wikipedia.org/wiki/ReStructuredText and docutils to convert it to xml, html, etc. -josh 1) To convert usrp_guide.xml to html file: $ xmlto html-nochunks usrp_guide.xml 2) To convert the same file to PDF file: $ xmlto --with-fop pdf usrp_guide.xml Of course , we need the following dependencies: - xmlto - xmltex - fop I am interested to have a wiki-based markup, where the wiki code could be rendered into doxygen xml by a small python script (or just strait to html, it doesnt need to integrate with doxygen). Its easier to write wiki code than xml, and its easier to maintain documentation code checked into the git repo (and keep it version specific). What do you think about a wiki-based solution to extending gnuradio documentation? Josh It is a good idea. If you decided to write such code, please keep in mined to use redmine wiki markup. P.S: I want to warn you that I failed to convert doxygen xml files to PDF files. They seems not to be a standard docbook xml files. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
