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
