I'm really confused at this point. In no point in your testing should be Throttle involved. So, please, can you do a test with:
Null Source Probe Rate -> Message Debug No UHD USRP Sink No Throttle and tell me a) how fast you were and b) how much CPU you used ? Thanks! Marcus On 08/02/2017 05:18 PM, Rui ZOU wrote: > The screen capture of htop when running the python script, test.py, is > attached. > > On Wed, Aug 2, 2017 at 11:10 AM, Rui ZOU <zourui.mkithap...@gmail.com > <mailto:zourui.mkithap...@gmail.com>> wrote: > > Throttle block is NEVER in use when USRP Sink is used. > > On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU > <zourui.mkithap...@gmail.com <mailto:zourui.mkithap...@gmail.com>> > wrote: > > USRP sink > > On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU > <zourui.mkithap...@gmail.com > <mailto:zourui.mkithap...@gmail.com>> wrote: > > My previous email shows the rate WITHOUT > > On Wed, Aug 2, 2017 at 11:05 AM, Marcus Müller > <muel...@kit.edu <mailto:muel...@kit.edu>> wrote: > > 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
