Changed to null source, the rate is still around twice the sample rate (390.625k) for throttle block.
******* MESSAGE DEBUG PRINT ******** (((rate_now . 781360) (rate_avg . 786529))) ************************************ When the throttle block is bypassed, the rate jumps up to around 11.3MS/s. ******* MESSAGE DEBUG PRINT ******** (((rate_now . 1.16071e+07) (rate_avg . 1.12848e+07))) ************************************ The rate is similar to using file source, 0.78MS/s with throttle and 11.3MS/s when throttle bypassed. Rui On Wed, Aug 2, 2017 at 10:37 AM, Marcus Müller <muel...@kit.edu> wrote: > Ok, there's something fishy here. That rate (without the USRP Sink) is > ridiculously low. Can you replace the file_source with a null_source? That > way, we can rule out storage as the bottleneck. > > The probe_rate does nothing but just count how many items fly by, and then > send a message at its output port every update period. The message_debug > just prints messages. > > If it's not storage: are you perhaps running in a powersaver mode? Even > so, the rate would be too low. I really don't know what's going wrong here. > Run your flow graph, run "top" in a terminal, check that the python process > and its spawned child threads really consume most of the CPU. If that's not > the case, you've got something else eating away on your CPU. > > Best regards, > > Marcus > > On 08/02/2017 04:22 PM, Rui ZOU wrote: > > Not sure if the debug setup is the expected since it's the first time I > use the 'Probe Rate' and 'Message Debug' blocks whose functions are not > very clear to me now just after reading the contents under the document > tag. If there are other ways to learn about new blocks, please advise. > > The rates I get when the USRP Sink disabled is around 0.78MS/s I guess > from the debug output, shown below. > > ******* MESSAGE DEBUG PRINT ******** > (((rate_now . 782916) (rate_avg . 784937))) > ************************************ > > After enabling the USRP Sink, I got lots of 'L's and 2.4MS/s, shown below. > > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL > LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL******* > MESSAGE DEBUG PRINT ******** > (((rate_now . 2.36319e+06) (rate_avg . 2.36319e+06))) > ************************************ > > GRC and python files are attached. > > Rui > > On Wed, Aug 2, 2017 at 3:57 AM, Marcus Müller <muel...@kit.edu> wrote: > >> Huh, I really don't know what's happening there :/ I sadly don't have the >> USRP to test this live with me right now, but there's absolutely no timed >> commands involved¹ >> >> So, trying to weed out bugs: >> >> * I've replaced the USRP sink with a "Probe Rate" block, connected to a >> "Message Debug"'s print port. I saw samples fly by with more than 7 MS/s, >> so there really shouldn't be a bottleneck here – can you try to do the same >> and see whether your system can get similar rates? 7MS/s is still far too >> little for my taste, but that is FM-Modulation-limited² >> * Can you delete your subdev spec? in a 2-channel case, that should be >> the implicit one, anyways. >> >> Best regards, >> >> Marcus >> >> ¹ "timed commands" are a USRP feature that allows certain things to >> happen at well-defined times. You get an L when a timed command reaches the >> USRP after the specified time has already passed. In your flow graph, all >> that could happen is that a sample packet reaches the USRP after it should >> – but that's unlikely, you'd get a "U" instead. >> >> ² at least on my machine, most of the time is spent in the FM modulator. >> Which is kind of annoying, because looking into that, what costs most time >> is the "keeping the phase within 0;2pi" floating point modulo operation. I >> might get the urge to fix that. >> >> >> >> On 08/01/2017 08:31 PM, Rui ZOU wrote: >> >> Hi Marcus, >> >> I have fixed the two parallel SISO by removing packeting encoding, using >> QT GUI instead of WX. But the 'L' indicator still comes on, even sooner >> than previous version. The GRC and generated python files are attached. >> >> Rui >> >> On Tue, Aug 1, 2017 at 12:04 PM, Marcus Müller <muel...@kit.edu> wrote: >> >>> Ah, cool, but then I wouldn't start by packetizing data. >>> >>> Simply send your file GMSK-Modulated; drop the packet encoding; think >>> about it: the MIMO coding (usually) happens *after* the data has been >>> formed to logical data units. >>> >>> A few notes on your flowgraphs: Don't use the WX GUI elements in new >>> flowgraphs. We have deprecated them, since no-one can maintain them, and >>> the Qt GUI sinks have shown to be both more stable and efficient. As far as >>> I can foresee your application's needs, Qt has replacements for all the WX >>> visualizations you'd need. >>> >>> For the receiver, I'd guess you'd first simply start by just recording >>> from to channels, and then experimenting with things like >>> cross-correlation, and estimating the channel matrix based on your known >>> transmit signal. I wouldn't be surprised if the channel is rather boring in >>> your setup – I blindly assume you're doing this indoors, and that limits >>> the path difference and the amount of change (and hence, the delay spread >>> and the doppler spread) your signals are subject to, especially since your >>> bandwidth is so low. Of course, having a flat channel is nice :) but it >>> also means that it might be quite hard to get any actual MIMO gain, because >>> the two RX antennas might be very correlated. If in doubt, increase >>> bandwidth. Be agressive with roll-off / Bandwidth factors of your GMSK. >>> Cheers, >>> Marcus >>> >>> >>> On 08/01/2017 05:51 PM, Rui ZOU wrote: >>> >>> Hi Marcus, >>> >>> My goal is to first build a 2-by-2 space multiplexing MIMO using two >>> X310s and GNU Radio. As I'm new to all this stuff, I'm starting from >>> building 2 parallel SISOs. If there are some good kick-start materials or >>> any resources, they will be very valuable. Thanks. >>> >>> Rui >>> >>> On Tue, Aug 1, 2017 at 11:37 AM, Marcus Müller <muel...@kit.edu> wrote: >>> >>>> Hi Rui, >>>> >>>> sorry, I might simply have missed those, and didn't find your first >>>> email when I saw your recent one! I apologize. >>>> >>>> So, hm, interestingly, we have a severe bug in the packet_encoder block >>>> (its design is pretty bad, and that triggers an unexpected behaviour >>>> underneath). That might mean the packet_encoder is just consuming items as >>>> fast as it can, without actually producing packets. In other words, >>>> packet_encoder is broken; you can't use it right now. >>>> >>>> The more appropriate way of dealing with data might be in the example >>>> flowgraphs that you'd find under /usr/[local/]share/doc/gnuradi >>>> o/examples/digital/packet_loopback_hier.grc ; it's a lot more >>>> complicated, though, and you'd have to write a message / PDU source that >>>> gives you the data you want to transmit, rather than the Random PDU block! >>>> >>>> I don't really know if that is the way to go. What is it, that you want >>>> to build? Maybe the mailing list can advise? >>>> >>>> Best regards, >>>> >>>> Marcus >>>> >>>> On 08/01/2017 05:26 PM, Rui ZOU wrote: >>>> >>>> Here are the two flowgraphs I have used. I have tried to attach the two >>>> files in my first email. Probably failed in doing that. If still not seen, >>>> please let me know so I will try again. Thanks for your help. >>>> >>>> Running the first flow graph will cause GRC stop responding instantly, >>>> while the second one can run for a little while and produce lots of 'L' >>>> before going not responsive. >>>> >>>> Rui >>>> >>>> On Tue, Aug 1, 2017 at 11:09 AM, Marcus Müller <muel...@kit.edu> wrote: >>>> >>>>> Hi Rui, >>>>> >>>>> don't know, to me, it looks like replying didn't work out great, since >>>>> my mail client showed your mail in a new thread. Really, replying to a >>>>> mailing list mail should be nothing more than hitting the "reply" or >>>>> "reply >>>>> all" button. >>>>> >>>>> Anyway, even the slowest PC/laptop/Raspberry Pi/… I could think of >>>>> would be able to deal with these rates, so there's very, very likely >>>>> something wrong with the GNU Radio flowgraph you're using. Maybe you'd >>>>> want >>>>> to share that! >>>>> >>>>> Best regards, >>>>> >>>>> Marcus >>>>> >>>>> On 08/01/2017 04:59 PM, Rui ZOU wrote: >>>>> >>>>> Hi Marcus, >>>>> >>>>> Sorry for leaving the title empty, that's the first time to post to a >>>>> mailing list. This is also the first time to reply, no sure if I replied >>>>> correctly. >>>>> >>>>> I use 390.625k as the sampling rate because this is the lowest I can >>>>> get using the Ettus X310 without giving me a warning saying that the >>>>> sampling rate cannot be provided by the hardware. The application is just >>>>> transmitting a file using GMSK modulation on the two daughter boards of >>>>> X310. >>>>> >>>>> Rui >>>>> >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing >>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio