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
