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> wrote:
> USRP sink > > On Wed, Aug 2, 2017 at 11:08 AM, Rui ZOU <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> 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> 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
