WAIT! Throttle? I didn't see that in either of the flow graphs you sent me first (twoparatx, onefile2tx)
Seriously?! Your GRC will even print a warning that you mustn't use Throttle together with hardware if you have both Throttle and a USRP sink. Remove the Throttle, and try again. On 08/02/2017 05:00 PM, Rui ZOU wrote: > 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 > <mailto: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. >> >> >> LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL******* >> 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 >> <mailto: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 <mailto: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 <mailto: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/gnuradio/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 <mailto: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 list >>>>>> Discuss-gnuradio@gnu.org >>>>>> <mailto:Discuss-gnuradio@gnu.org> >>>>>> >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> >>>>>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >>>>>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
