RE: [Discuss-gnuradio] Zynq-7000
I was speaking to my local Xilinx FAE in Australia today, he seems to think actual parts are something like 18 months out. > -Original Message- > From: discuss-gnuradio-bounces+dr=drelectro@gnu.org > [mailto:discuss-gnuradio-bounces+dr=drelectro@gnu.org] On Behalf Of > Philip Balister > Sent: Wednesday, 2 March 2011 1:18 PM > To: Jordan Hayes > Cc: gnuradio > Subject: Re: [Discuss-gnuradio] Zynq-7000 > > On 03/01/2011 08:27 PM, Jordan Hayes wrote: > > Just saw that Xilinx has announced the Zynq-7000 family -- chips that > > combine a dual-core ARM Cortex-A9 processor and peripherals with > > programmable logic cells (i.e., FPGA fabric). Seems like this could > make > > a pretty good base for an embedded gnuradio platform. Anyone looked > at > > this yet? > > > > Details at > > http://www.xilinx.com/publications/prod_mktg/zynq7000/Product- > Brief.pdf > > Yes, this is an exciting product. Xilinx announced this last April > during an Embedded Conference. They are slowly releasing technical > details, but what I haven't seen in the announcements is a solid time > frame for getting silicon and dev boards :( > > Philip > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNUradio DVB-S/S2
Hi there Just a quick question related to GNUradio. Is it possible to use USRP2 + WBX + Gnuradio to send DVB-S or S2 signals to a satellite set top box (using a cable) I am trying to emulate an OTA update on a box I have which tunes to a specific Freq/Transponder to "download" its OS. Please let me know Regards Dino ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Save all the samples of a packet (all complex values) and demodulate at once. (Is it possible?)
Dear all, We're using benchmark_tx(rx) apps to implement a simple cellular-like network. In the benchmark_rx example, the demodulator demodulates some amount of symbols at a time and the correlator and the framer, which followed the demodulator, read the demodulated bits and packetize them into a frame. But, for some reasons, we want to change the way the receiver decodes a packet. That is, we are trying save all the samples of a packet (all complex values) and demodulate at once in a function at a receiver. However, we haven't implemented or seen this kind of receiver structure in gnuradio. If you have seen or any experience with similar examples, please let us know. Any comment on it would be very appreciated. Thanks in advance. PS. we're using USRP1 / gnuradio 3.3.0 / Ubuntu 10.04 -- Minsuk ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] nature of gr_vector data
Hi! I have a general question related to the data-type model. I looked through much of the API documentation but it doesn't seem to glue together to something what I would describe as a complete picture. I want to know how the GNUradio framework actually converts the signal into a digital data-type like a vector. I'd be satisfied to get a very broad description because I can research details on my own. What I'm interested is the way how the gr_vector stuff interacts with the various streams and what "Slicing and Dicing Streams" (group__slicedice__blk) means. This is important for me in order to know the data representation and to interpret the results. Best, Marius ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] nature of gr_vector data
On 02-03-11 14:11, Marius wrote: I'd be satisfied to get a very broad description because I can research details on my own. What I'm interested is the way how the gr_vector stuff interacts with the various streams and what "Slicing and Dicing Streams" (group__slicedice__blk) means. This is important for me in order to know the data representation and to interpret the results. It all depends on what you want to do i guess. I've learned a lot about gnuradio by playing with the gnuradio-companion 'grc'. It makes it really easy to drag and drop a SDR solution together. And if things are not clear, i grep the sources for the specific method name. Gr. Sim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Save all the samples of a packet (all complex values) and demodulate at once. (Is it possible?)
On Wed, Mar 2, 2011 at 6:00 AM, Minsuk Kang wrote: > Dear all, > We're using benchmark_tx(rx) apps to implement a simple cellular-like > network. > In the benchmark_rx example, the demodulator demodulates some amount of > symbols at a time and the correlator and the framer, which followed the > demodulator, read the demodulated bits and packetize them into a frame. > But, for some reasons, we want to change the way the receiver decodes a > packet. > That is, we are trying save all the samples of a packet (all complex > values) and demodulate at once in a function at a receiver. > However, we haven't implemented or seen this kind of receiver structure in > gnuradio. > If you have seen or any experience with similar examples, please let us > know. > Any comment on it would be very appreciated. > Thanks in advance. > PS. we're using USRP1 / gnuradio 3.3.0 / Ubuntu 10.04 The main issue with this is "what is a packet". In the benchmark scripts there is a defined start and end of the packet, namely, correlation sequence at the beginning, and the n_bytes field. To save the demodulated samples into packets would not do you any good, as you have no idea where packets begin and end. You could just save fixed size blocks using the packetizer, but then your real packets would be split between your saved blocks at random. If what you are trying to do is really the best way to go about it, you would still need to demodulate at least /some/ of the bits (probably just the header) so you would know when to a packet starts, then packetize the raw stream starting at that point. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] nature of gr_vector data
Hi Marius, a lot of the confusion understanding GR stuff (in particular, data types) comes from using Simulink, where vector- or samplebased processing actually is different. There's a lot of Simulinkers around here, so I've explained this a couple of times :) In GNU Radio, the scheduler simply moves binary data from one block to another. It doesn't matter whether it's samples, vectors of samples or even pink fluffy teddybears (rather, binary representations thereof) as long as they have a *fixed size*. One binary object of this fixed size is called an 'item'. What an item is is up to you to define. The most common item in GNU Radio is the complex value. Every item usually has 64 bits (depends on the architecture, but that's the most common value) and stores one complex value. All the scheduler cares about here is the item size. It will reserve a buffer for each edge in the flow graph to store 'enough' items. How much 'enough' is depends on a couple of things, e.g. how many items does my block need to produce one output item. So say you have fixed vector length of 10 complex samples. The scheduler couldn't care less. All it knows is that you now have an item size of 640 bytes. One important slicer is the vector_to_stream block. This block is much simpler than you might imagine (judging from what you asked). It takes two parameters: The vector length (N), and the size (in bytes) of every item (M). All it pretty much does is copy the input buffer to the output buffer, but redefines the item size on the output buffer to M, whereas it was M*N on the input buffer. The scheduler, which handles the inter-block-buffers, thus know how many items are stored in the buffer (it's a ring buffer, to be precise) and how large they are. Now say you have a signal source which outputs vectors of 10 samples, and you want to run them through an FIR filter, which operates on individual samples. This is your flow graph: SRC > Vec2Stream -> Filter. Now let's pretend this is the scheduler order: 1) SRC produces 1 item (vector). It is copied to the first buffer. 2) Vec2Stream copies the vector to its output buffer. The SRC output buffer is now empty (because 1 item was copied into it, then was consumed by Vec2Stream). The Vec2Stream output buffer contains 10 items. 3) Filter is called and because it's a weird filter, uses 7 input items. The Vec2Stream output buffer thus now has 3 items left. 4) SRC and Vec2Stream are called with one item each. This produces 10 more items in the Vec2Stream output buffer, which now has 13 items. And so on. I've been deliberately inaccurate in two respects: - The GR scheduler does a lot more stuff, and - there's another way to pass data (messages). I hope this was helpful. Cheers, MB On Wed, Mar 02, 2011 at 02:11:38PM +0100, Marius wrote: > Hi! > > I have a general question related to the data-type model. > > I looked through much of the API documentation but it doesn't seem to > glue together to something what I would describe as a complete > picture. I want to know how the GNUradio framework actually converts > the signal into a digital data-type like a vector. > I'd be satisfied to get a very broad description because I can > research details on my own. What I'm interested is the way how the > gr_vector stuff interacts with the various streams and what "Slicing > and Dicing Streams" (group__slicedice__blk) means. This is important > for me in order to know the data representation and to interpret the > results. -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpwU8Lpc8Jwb.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, As predicted, changing from "RECV_MODE_FULL_BUFF" to "RECV_MODE_ONE_PACKET" and then "RECV_MODE_FULL_BUFF" reduced the latency significantly. My ping RTT time was >17ms in average, now it is 10.5ms. This is GREAT:-) Nonetheless, 10.5ms still includes quite some overhead because the communication time for my ping message is less than 3.9 ms in total. Above 6ms delay still exists somewhere. In your description below, "for the source, the work function waits for the entire RX buffer" (now it is one UDP packet of samples first and then the entire RX buffer), do you mean the buffer size determined by "noutput_items"? Likewise, is the entire TX buffer at the sink determined by "ninput_items"? One UDP packet of samples is only 1472/4= 368 samples and 1472/4/2/8 = 23 B of user data (given BPSK and 2 SPS). For a ping ICMP message ( 42B, which is tiny), plus 19B of frame overhead, it still must wait for "waits for the entire RX buffer" which may be possibly 10s of thousands of samples. Is there some way that we can further optimize the behavior? For example, can we limit the size of noutput_items? Is this purely GNU Radio scheduler's job? One previous question I had is this: why *recv_buff_size* is needed for benchmark_tx.py which involves only gr_uhd_usrp_sink.cc? I thought only *send_buff_siz* is needed. Andrew On 03/01/2011 08:20 PM, Josh Blum wrote: On 03/01/2011 04:39 PM, Feng Andrew Ge wrote: Josh, Your explanation makes sense. Is there a quick fix for me to bypass this problem temporarily while you are working on the modification. http://gnuradio.org/cgit/jblum.git/commit/?id=75538e12300cb0d593792a986841ba2df9997c54 :-) Further, following your current bandwidth optimization implementation, is the code trying to fill the buffer in both uhd_single_usrp_sink (sending buffer) and uhd_single_usrp_source (receiving buffer)? For the source, the work function waits for the entire RX buffer to be filled with samples. I strongly believe this is the cause of the latency. For the sink, the work function sends the entire buffer. This is correct behavior for optimum latency and bandwidth. When I started uhd_benchmark_tx.py, it also asked for specification of *recv_buff_size, where is it used? * http://www.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers -Josh On 03/01/2011 07:01 PM, Josh Blum wrote: On 03/01/2011 03:25 PM, Feng Andrew Ge wrote: Josh, Everything is in the attachment, look for python-based UHD_* code. The performance before and after Feb.25 was both poor. At one point before Feb. 25, the latency was even worse, up to>30ms. But I forgot the time. In terms of GNU Radio, for running UHD I checked out next from GNU Radio git. However, for raw Ethernet, I only ran GNU Radio 3.3.0. I haven't found time to check GNU Radio changes yet, what might cause such huge performance drop. Andrew, Here is an idea that may explain your problem: When the raw ethernet source calls into work(), it does not attempt to fill the entire buffer (noutput_items). Rather, it waits at least one packet to become available and then copies only the data that is available immediately into the buffer. In contrast, the UHD work function is bandwidth optimized and tries to fill the entire buffer. At your sample rate (500ksps), this will impose serious delays for very large noutput_items (10s of thousands). I hope that explains the issue you see. I am going to attempt a modification to the work function, where we recv a single packet with timeout, and then anything else that is available without waiting. I will let you know when I post a branch with changes. -Josh Andrew On 03/01/2011 06:13 PM, Josh Blum wrote: On 03/01/2011 02:21 PM, Feng Andrew Ge wrote: Josh, First of all, I am aware of what you pointed out and I did use the code latency_test.cpp for measuring latency between USRP2 and a host. The latency is negligible. Ok, i see. You were measuring the ping time over the tunnel. :-) Can you tell me: Is this a new problem with UHD since the " February 25rd 2011" announcement. That is, was it working properly for you previously? I think I was not clear enough in my previous email. My setting is this: host_1--USRP2_1 talks to host_2--USRP2_2. The latency I measured is based on GNU Radio-created wireless network interface, e.g., gr0. I started tunnel.py and created a digital link between host_1 and host_2; then I compared ping RTT time performance between using the UHD code and using the Raw_Ethernet code base. UHD introduced 9 ms of overhead and I am really puzzled about this. Since I am puzzled as well. 9ms sounds pretty bad. Is this a port of tunnel.py to UHD, can you share it? USRP2 sends samples immediately out and the latency between the host and USRP2 is negligible, the likely place I can think of is the interface between UHD and GNU Radio, for example, can UDP packet sending be preempted by other threads? Each time how many
[Discuss-gnuradio] problems using USRP as transmitter
Hello All, I've got a simple setup in GRC whereby I record a basic ASK signal directly to a file from a USRP source. After recording the signal I can sucessfully play it back to a USRP sink. The problem occurs whenever I attempt to to skip the first step and playback a pre-recorded signal - theres no transmission from the USRP. Can anybody explain why this is? Is there some init done by the USRP source instance that isnt performed when the USRP sink is created in isolation? Thanks. Simon Denvir.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Save all the samples of a packet (all complex values) and demodulate at once. (Is it possible?)
On Wed, Mar 02, 2011 at 09:00:36PM +0900, Minsuk Kang wrote: > > That is, we are trying save all the samples of a packet (all complex > values) and demodulate at once in a function at a receiver. We do something somewhat like this in gr-bluetooth. See bluetooth_multi_block.cc and its subclasses in the git repo here: http://sourceforge.net/projects/gr-bluetooth/develop We originally tried to string together separate blocks (squelch, ddc, demodulator, clock recovery, binary slicer), but the resulting symbol stream lost too much information about the relative timing between packets. For our application we needed precise packet interval information (like counting the number of samples between packets), but, even without the squelch block, the demodulator produced a stream of symbols that varied too much with respect to the sample timing. Instead we use the history mechanism to ensure that we are always working with a chunk of samples long enough to encompass an entire packet, and we have reimplemented (mostly by copy and paste) all the things mentioned above (that would traditionally be done in separate blocks) in a single block. Then we use the demodulated symbol stream to detect packets, and we construct a packet data structure from the complete set of symbols all at once. At that point we could also store the raw samples of the entire packet, but we haven't had a need to do so. Frankly, I think it is ugly, but it does what I think you want to do. For years I have had in mind a rewrite using something like the new stream tags mechanism to do all this in separate blocks that pass time stamps along with the data streams. mossmann ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Is data communication between UHD_USRP_SOURCE and USRP2 "polling" or "pushing"
Josh, Once I start uhd_benmark_rx.py, USRP2 continuously sends data to the host. The data rate is the sample rate times 4 (bytes per sample). This happens even when no transmitter is around. Therefore, I assume that the ADC just converts noise into samples and USRP2 sends those samples at the rate specified by the sample rate when uhd_usrp_source is initialized. I have one question, is data communication between USRP2 and uhd_usrp_source "polling" or "pushing"? I thought it is "polling" because only UDP socket client exists in uhd_usrp_source. In this case, data RECV is triggered by the scheduler's work function. Usually the noutput_items varies from time to time. If so, how can USRP2 send samples at a constant rate of the specified samp_rate (as I observed)? If it is "pushing" (which means that USRP2's firmware initiates the data sending to the host), it looks like that USRP2 even sends samples of noise at a constant speed. But if so, would the such samples fill the kernel socket buffer (whose size is determined by "sudo sysctl -w net.core.rmem_max=")? Newer packets will get dropped. On 03/01/2011 06:13 PM, Josh Blum wrote: Nothing gets buffered in the UHD in the usrp2/n210 implementation. However, there is a kernel socket buffer on receive that has enough buffering for a second of samples. Once this buffer fills, newer packets are dropped. I also believe that this is the same on the raw ethernet driver. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
On 03/02/2011 07:37 AM, Feng Andrew Ge wrote: > Josh, > > As predicted, changing from "RECV_MODE_FULL_BUFF" to > "RECV_MODE_ONE_PACKET" and then "RECV_MODE_FULL_BUFF" reduced the > latency significantly. My ping RTT time was >17ms in average, now it is > 10.5ms. This is GREAT:-) > glad to hear improvement! > Nonetheless, 10.5ms still includes quite some overhead because the > communication time for my ping message is less than 3.9 ms in total. > Above 6ms delay still exists somewhere. > True. Can you run the tunnel application on the same gnuradio install with the raw ethernet driver? That way we can isolate the problem. It would be good to know if there was a regression in the scheduler, or that the issue is inside gr-uhd. > In your description below, "for the source, the work function waits for > the entire RX buffer" (now it is one UDP packet of samples first and > then the entire RX buffer), So, its not the entire rx buffer on the "gr_uhd_source_latency_work" branch. The second call to recv() is non blocking, so it only handles data that is already available without delay. It should return less than noutput_items. You can confirm this by printing (num_samps < noutput_items) before work() returns. do you mean the buffer size determined by > "noutput_items"? Likewise, is the entire TX buffer at the sink > determined by "ninput_items"? > yes (although its still called noutput_items thanks to copy/paste) > One UDP packet of samples is only 1472/4= 368 samples and 1472/4/2/8 = > 23 B of user data (given BPSK and 2 SPS). For a ping ICMP message ( 42B, > which is tiny), plus 19B of frame overhead, it still must wait for > "waits for the entire RX buffer" which may be possibly 10s of thousands > of samples. > > Is there some way that we can further optimize the behavior? For > example, can we limit the size of noutput_items? Is this purely GNU > Radio scheduler's job? > We can return less than noutput_items but not zero. Which is what the changes on that branch attempt to do. > One previous question I had is this: why *recv_buff_size* is needed for > benchmark_tx.py which involves only gr_uhd_usrp_sink.cc? I thought only > *send_buff_siz* is needed. > It is not needed; and whoever made that application should not have put those options in. UHD will choose the best settings automatically. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
Josh, Before I test it with the raw ethernet driver, would you tell me what's the difference in gr_uhd_usrp_sink between blocking send and non-blocking send? Since the sending data is already in the buffer and it is UDP sending, I don't see any difference. But perhaps you might point out any difference from a time delay perspective. Andrew On 03/02/2011 02:11 PM, Josh Blum wrote: True. Can you run the tunnel application on the same gnuradio install with the raw ethernet driver? That way we can isolate the problem. It would be good to know if there was a regression in the scheduler, or that the issue is inside gr-uhd. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] smart pointer problem
On 03/01/2011 11:36 PM, johan kuijpers wrote: > Hi, > > I'm fighting a bit with a smart pointer. I want to apply a filter in my > block. Hence I construct a filter as shown below: > > gr_fir_filter_fff_sptr hi_pass = gr_make_fir_filter_fff(1, > gr_firdes::high_pass (1.0, > 64000, > 5000, > 1000, > gr_firdes::WIN_HAMMING, > 6.76 > )); > > as soon as I dereference the smart pointer in order to use the filter I > get an assertion error: const [with T = gr_block_detail]: Assertion `px > != 0' failed. > > hi_pass->general_work(noutput_items, ninput_items, input_items, > output_items); > > this means the smart pointer doesn't have a pointer (any longer?) to the > filter. Does anyone see what I'm doing wrong. I've been trying quite > hard to find the mistake but I simply don't get it. > It looks like you are using the shared pointer correctly, but perhaps there is something else that the scheduler sets-up that you are missing by using the block in a stand-alone fashion. Only the gurus know. You may want to use the vector source -> block -> vector sink paradigm that all the qa code uses; to process a single chunk of samples. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How is "UU" generated
Another question is how "UUU" gets generated---I still got many of them? Further, "UUU" makes sense when GNU Radio works with an audio device; however, I am not sure about its use when GNU Radio sends non-continuous data to USRP. When this "UUU" happens, will it be possible that some samples get held somewhere or even get dropped? I assume not, but like to get your confirmation. Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new feature work: qtgui support in grc
Hi Josh, I had a few moments to try it out. It worked very well and I think it will be useful. I got a little confused when I cloned the repository because it said there was no HEAD (or something like that) and the directory was empty, but I could still checkout to the wip/qtgui/grc branch. I hope I got the right thing. You mention engineering notation for the widget. I believe for the text entry it is quite straightforward (xml attached - I just copied the code from the gr-qtgui example). I will do more tests during the coming days. Alex On Wed, Mar 2, 2011 at 2:52 AM, Josh Blum wrote: > Hey list, > > I have been working on supporting PyQt widgets and the qtgui sinks in > the Gnuradio Companion. Get the code on my wip/qtgui/grc branch on > jblum.git http://gnuradio.org/cgit/jblum.git/log/?h=wip/qtgui/grc > > Available widgets: > * qtgui plotter (dft, scope, etc) > * tabbed panel > * slider > * combo box > * radio buttons > * text entry > * label > > 1) The slider adds a new requirement of PyQwt (python Qwt bindings). Qwt > should already be installed for the qtgui sinks themselves. > > 2) The qtgui and wxgui widgets are distinctly separated. Previously, the > "variable slider" was a wx slider form. Now, there is a WX GUI Slider > and a QT GUI Slider. And the generate options now have a QT GUI option. > You cannot mix and match widgets from different graphics libraries. > > 3) No attempt was made to make the existence of different graphics > toolkits transparent to the user. That would have been a huge pain on my > part and I couldn't try new things. If this Qt thing catches on, I am > considering a migration script from wx->qt. > > 4) The Qt widgets in grc do not have a python wrapper/forms library like > they do in gnuradio. All the generated code uses the PyQt API directly. > This is in-part possible because Qwt supplies its own set of useful > wrappers around Qt widgets. Examples: http://qwt.sourceforge.net/sliders.png > > 5) Each widget block in grc has a gui hint parameter. This parameter is > a combination of the grid parameter and notebook parameter seen in the > wx widget blocks. It also allowed the implementation code to be a lot > more generic. > > Whats missing? > I feel that the widgets still need a bit of polishing. Engineering > notation would be nice. I'd like to see features in the wx scope sink > brought to the qtgui scope such as trigger modes and multiple channels. > I think the qt equivalent of the numbersink would be nice too (and that > could use some of those real fancy qwt widets): > http://read.pudn.com/downloads186/sourcecode/embed/872381/qwt/doc/images/dials2.png > > Why qtgui stuff? > The WX stuff in gnuradio is fairly polished in comparison; and when it > works, it works. But we have seen many issues with wx outside of the > linux+x86 world, not to mention opengl issues on the x86. I hope that > the qt stuff is a viable, cross platform option for live gnuradio > plotting and graphical applications. > > Please try it out. Feedback is welcome! > -Josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > QT GUI Entry variable_qtgui_entry QT GUI Widgets from PyQt4 import Qt self.$(id) = $(id) = $value #set $win = 'self._%s_tool_bar'%$id $win = Qt.QToolBar(self) #if not $label() #set $label = '"%s"'%$id #end if $(win).addWidget(Qt.QLabel($label+" ", None)) self._$(id)_line_edit = Qt.QLineEdit(str(self.$id)) self._$(id)_tool_bar.addWidget(self._$(id)_line_edit) self._$(id)_line_edit.returnPressed.connect( lambda: self.set_$(id)(eng_notation.str_to_num(self._$(id)_line_edit.text().toAscii( $(gui_hint()($win)) self.set_$(id)($value) self._$(id)_line_edit.setText(eng_notation.num_to_str($id)) Label label string #if $label() then 'none' else 'part'# Type type int enum part Floatrealconv:float Integerintconv:int Stringstringconv:str Booleanboolconv:bool Anyrawconv:eval Default Value value 0 $type GUI Hint gui_hint gui_hint part This block creates a variable with a text entry box. \ Leave the label blank to use the variable id as the label. The GUI hint can be used to position the widget within the application. \ The hint is of the form [tab_id@tab_index]: [row, col, row_span, col_span]. \ Both the tab specification and the grid position are optional. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] questions related to msgq_insert
Dear all, I'm using the message_source to generate the source, connecting it with a multiply_const block to configure the amplitude for the signal. The message_source is created by the following: data = gr.message_source(sizeof_char, 2) msgq = data.msgq() When the msg is inserted as a tail of the msgq while the flow graph is running, the msg is inserted using insert_tail(msg). If my understanding serves me right, if only insert the msg once, it suppose to be send once. In my case, however, the msg is sent 10 times. (the set_amp is defined in the tb block to change the amplitude of the signal while tb is running) Could anyone help me to see what causes the problem? The code related msgq_insert in main thread is as followed: try: while 1: i = 1 tb.set_amplitude(5000) msg_13bit = gr.message_from_string(payload_13bit) tb._ls.msgq.insert_tail(msg_13bit) tb.set_amplitude(0) while(i < 50) msg_stop = gr.message_from_string(payload_stop) tb._ls.msgq.insert_tail(msg_stop) i += 1 Really appreciate any of your help! Thanks, Yan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new feature work: qtgui support in grc
On 03/02/2011 04:11 PM, Alexandru Csete wrote: > Hi Josh, > > I had a few moments to try it out. It worked very well and I think it > will be useful. > > I got a little confused when I cloned the repository because it said > there was no HEAD (or something like that) and the directory was > empty, but I could still checkout to the wip/qtgui/grc branch. I hope > I got the right thing. > Ah, I dont have a master branch. Most people just git remote add my repo to an existing gnuradio repo. > You mention engineering notation for the widget. I believe for the > text entry it is quite straightforward (xml attached - I just copied > the code from the gr-qtgui example). > Excellent, I will try to get this in the block as an option for float/real numbers. My goal is to have engineering notation for the text box in the qwt slider. I think that involves making a custom qwt text/engine object. It seems like something qwt should support or would not be hard to implement. Not sure. http://pyqwt.sourceforge.net/doc5/reference.html Thanks! -Josh > I will do more tests during the coming days. > > Alex > > > On Wed, Mar 2, 2011 at 2:52 AM, Josh Blum wrote: >> Hey list, >> >> I have been working on supporting PyQt widgets and the qtgui sinks in >> the Gnuradio Companion. Get the code on my wip/qtgui/grc branch on >> jblum.git http://gnuradio.org/cgit/jblum.git/log/?h=wip/qtgui/grc >> >> Available widgets: >> * qtgui plotter (dft, scope, etc) >> * tabbed panel >> * slider >> * combo box >> * radio buttons >> * text entry >> * label >> >> 1) The slider adds a new requirement of PyQwt (python Qwt bindings). Qwt >> should already be installed for the qtgui sinks themselves. >> >> 2) The qtgui and wxgui widgets are distinctly separated. Previously, the >> "variable slider" was a wx slider form. Now, there is a WX GUI Slider >> and a QT GUI Slider. And the generate options now have a QT GUI option. >> You cannot mix and match widgets from different graphics libraries. >> >> 3) No attempt was made to make the existence of different graphics >> toolkits transparent to the user. That would have been a huge pain on my >> part and I couldn't try new things. If this Qt thing catches on, I am >> considering a migration script from wx->qt. >> >> 4) The Qt widgets in grc do not have a python wrapper/forms library like >> they do in gnuradio. All the generated code uses the PyQt API directly. >> This is in-part possible because Qwt supplies its own set of useful >> wrappers around Qt widgets. Examples: http://qwt.sourceforge.net/sliders.png >> >> 5) Each widget block in grc has a gui hint parameter. This parameter is >> a combination of the grid parameter and notebook parameter seen in the >> wx widget blocks. It also allowed the implementation code to be a lot >> more generic. >> >> Whats missing? >> I feel that the widgets still need a bit of polishing. Engineering >> notation would be nice. I'd like to see features in the wx scope sink >> brought to the qtgui scope such as trigger modes and multiple channels. >> I think the qt equivalent of the numbersink would be nice too (and that >> could use some of those real fancy qwt widets): >> http://read.pudn.com/downloads186/sourcecode/embed/872381/qwt/doc/images/dials2.png >> >> Why qtgui stuff? >> The WX stuff in gnuradio is fairly polished in comparison; and when it >> works, it works. But we have seen many issues with wx outside of the >> linux+x86 world, not to mention opengl issues on the x86. I hope that >> the qt stuff is a viable, cross platform option for live gnuradio >> plotting and graphical applications. >> >> Please try it out. Feedback is welcome! >> -Josh >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with output of inverse FFT
Hi @all, on my long way to send multiple 802.11g frames i found another problem… During the process the data is converted from frequency domain to time domain by inverse fft. The fft length is 64, and the input is the OFDM symbol with carrier tones (vector of 64 * gr_complex) The frame consists of 3 ofdm symbols and i want to convert two identical frames. So there are 6 elements with a size of 64* gr_complex. (6*64 *8Byte = 3072 Byte) When I compare the result of the first frame (Bytes 0 – 0x5FF) with the result of the second frame (0x600 – 0xBFF) in a hex editor the frames are NOT the same. They differ from each other, starting at Byte 0x800 to 0x200 in the fist frame. (0x800 = 2048dec!?) I’m able to reproduce the problem in GRC, using a file source –>throttle->inverse fft(size 64) -> file sink flowgraph., my input file is attached. Is there a problem with the precession of the ifft? (gnuradio 3.2.2, ubuntu 10.04) Has anybody an idea how to fix this? http://old.nabble.com/file/p31056403/input.dat input.dat http://old.nabble.com/file/p31056403/output.dat output.dat -Hans -- View this message in context: http://old.nabble.com/Problem-with-output-of-inverse-FFT-tp31056403p31056403.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] libgnuradio-core-3.3.0.so
Hello everyone, I have setuped the gnuradio3.3.0. Then I tryed to test whether it can work or not. I tryed to run "./dial_tone". However, I got an Error: "ImportError: libgnuradio-core-3.3.0.so.0: cannot open shared object file: No such file or directory". And could you help me to solve this problem? Alex___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
