Re: [Discuss-gnuradio] Ettus E310 & MIMO -- data rate?
Hi Marcus and Johannes, Thanks for your replies!! I fear that I'll have to change platform then -- I was targeting 2 x 9.1428MHz, but this is clearly going to be impossible :( Thanks again and have a nice day! Rob On Tue, 26 Feb 2019 at 16:35, Müller, Marcus (CEL) wrote: > Hi Johannes, Hi Rob, > On Tue, 2019-02-26 at 15:00 +, Johannes Demel wrote: > > Hi Rob, > > > > > (1) I cannot set an arbitrary sampling rate (for instance 9.1428M), > but > > > I am required to set e.g. 4M. > > > > USRPs, like every hardware, is constraint in terms of available sampling > > rates. You should stick with power of 2 divides of the master clock > > rate. Otherwise, the CIC filters on the USRP will corrupt your signal. > > > > While that's true, it's omitting the important point, maybe: The E310 > has a very flexible master clock rate. So, from the top of my head, > 9.1428 MHz could be possible, but only if you set the MCR to a multiple > of that first. > > > > (2) even with small sampling rates (like 2M), and despite a 10MB > buffer > > > in between the USRP source and the ZMQ sink, the system keeps > overflowin > > > > That's not very surprising. The Zynq's architecture makes it very hard > to keep both the USRP sample interface and the network interface afloat > at the same time. > > All in all, the E310 has not a great CPU, and what needs to be done > should be done on the E310 until the data rate is really low. > > This might imply that multi-MHz bandwidth applications need FPGA > design. > > Best regards, > Marcus > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] creating a embedded python-block with multiple output types
And incidentally, WX has has been depreciated. Does any know what the the WX GUI Scope Sink is equivalent to? -- Cinaed On 2/26/19 8:37 PM, Cinaed Simson wrote: > There's problem with the grc file - it doesn't load into grc. > > The embedded python code is using "" instead of ">" - at least that > was my guess. > > So I replaced them. I haven't tested it yet - I don't have a HackRF with me. > > As for your question, do you mean select a waveform in the signal source > block? > > Unfortunately, I can't help you. > > -- Cinaed > > > On 2/25/19 12:24 PM, Kristoff wrote: >> Hi, >> >> >> Last weekend, I've been playing around with python-blocks in python, one >> of the projects was to create a morsecode encoder block. >> (0.0.1 alpha-code here: https://github.com/on1arf/gr-morsecode-enc) >> The output-type of that block is complex64. >> >> Small question. >> How can I create a GNU Radio python-block that allows the user to select >> the output-type of the block, like -say- the signal-source block? >> >> >> >> Kristoff >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] creating a embedded python-block with multiple output types
There's problem with the grc file - it doesn't load into grc. The embedded python code is using "" instead of ">" - at least that was my guess. So I replaced them. I haven't tested it yet - I don't have a HackRF with me. As for your question, do you mean select a waveform in the signal source block? Unfortunately, I can't help you. -- Cinaed On 2/25/19 12:24 PM, Kristoff wrote: > Hi, > > > Last weekend, I've been playing around with python-blocks in python, one > of the projects was to create a morsecode encoder block. > (0.0.1 alpha-code here: https://github.com/on1arf/gr-morsecode-enc) > The output-type of that block is complex64. > > Small question. > How can I create a GNU Radio python-block that allows the user to select > the output-type of the block, like -say- the signal-source block? > > > > Kristoff > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distance Measurement by Correlation
>Make sure both your radios are locked to the same clock source. Any fsignificant requency offset between the two is going to ruin your correlation peaks very quickly. When the same clock source is not possible due to the distance between them, the carrier frequency offset can also be estimated and corrected at the initiating USRP and then the correlation can be applied. In this scenario, the quality of the result will depend on how good the CFO estimate is. Cheers, Qasim Message: 4 > Date: Tue, 26 Feb 2019 10:07:51 +0100 > From: Sylvain Munaut <246...@gmail.com> > To: Jonathan Preheim > Cc: GNURadio Discussion List > Subject: Re: [Discuss-gnuradio] Distance Measurement by Correlation > Message-ID: > uo2tdw...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > > Any ideas about how we can troubleshoot this more effectively? Or better > model the channel? > > Make sure both your radios are locked to the same clock source. > Any fsignificant requency offset between the two is going to ruin your > correlation peaks very quickly. > > Frequency offset is going to end up as a progressive phase shift along > your PN sequence. If that phase shift is a non-negligibe part of the > unit circle during the time of your PN sequence, they won't 'add up' > to a peak anymore. > > Cheers, > >Sylvain > > > > -- > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FPGA image build incorect size
I have been following the instruction for Getting Started with RFNOC Development. I have made it to the point of generating a custom FPGA image with the following command ./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 --fill-with-fifos with the following status on completion [00:37:14] Process terminated. Status: Success Warnings: 969 Critical Warnings: 37 Errors: 0 make[1]: Leaving directory '/home/mpntarx/rfnoc/src/uhd-fpga/usrp3/top/x300' Exporting bitstream files... Generating LVBITX... Exporting build report... Build DONE ... X310_RFNOC_HG I then ran the uhd_usrp_probe command with the successful output [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.15.0.git-13-g52138314 [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 1472 bytes. [INFO] [X300] Radio 1x clock: 200 MHz .. |/ | | | RFNoC blocks on this device: | | | | | | * DmaFIFO_0 | | | * Radio_0 | | | * Radio_1 | | | * DDC_0 | | | * DDC_1 | | | * DUC_0 | | | * DUC_1 I then attempted to load the generated FPGA image file uhd_image_loader --args "type=x300,addr=192.168.10.2" --fpga-path ~/rfnoc/src/uhd-fpga/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HG.bit [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.15.0.git-13-g52138314 Error: RuntimeError: The specified FPGA image is too large: 15878034 vs. 15878032 The FPGA size is reported as 2 bits too large. I have replicated this 2x now, with different image build specifics, with different modules to include. Is this a UHD problem? or something else. I installed UHD via PyBombs following the instructions in the Getting Started Guide. John Sent with [ProtonMail](https://protonmail.com) Secure Email.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus E310 & MIMO -- data rate?
Hi Johannes, Hi Rob, On Tue, 2019-02-26 at 15:00 +, Johannes Demel wrote: > Hi Rob, > > > (1) I cannot set an arbitrary sampling rate (for instance 9.1428M), but > > I am required to set e.g. 4M. > > USRPs, like every hardware, is constraint in terms of available sampling > rates. You should stick with power of 2 divides of the master clock > rate. Otherwise, the CIC filters on the USRP will corrupt your signal. > While that's true, it's omitting the important point, maybe: The E310 has a very flexible master clock rate. So, from the top of my head, 9.1428 MHz could be possible, but only if you set the MCR to a multiple of that first. > > (2) even with small sampling rates (like 2M), and despite a 10MB buffer > > in between the USRP source and the ZMQ sink, the system keeps overflowin > > That's not very surprising. The Zynq's architecture makes it very hard to keep both the USRP sample interface and the network interface afloat at the same time. All in all, the E310 has not a great CPU, and what needs to be done should be done on the E310 until the data rate is really low. This might imply that multi-MHz bandwidth applications need FPGA design. Best regards, Marcus smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus E310 & MIMO -- data rate?
Hi Rob, Am 26.02.19 um 15:51 schrieb Rob Heig: > Hi, > > I've bought an Ettus E310 board and I am trying to use it for a MIMO > project, but I am encountering several issues. > > In particular, I have created a GNU Radio design, compiled it as Python > script (as illustrated on the page > https://kb.ettus.com/Streaming_processed_data_from_the_E31x_with_GNU_Radio_and_ZMQ), > > modified it (because it was complaining due to a > TypeError: push_sink_make() takes at most 5 arguments (6 given) > error with the ZMQ sink) and scp'd to the board. > > What I've found is > (1) I cannot set an arbitrary sampling rate (for instance 9.1428M), but > I am required to set e.g. 4M. USRPs, like every hardware, is constraint in terms of available sampling rates. You should stick with power of 2 divides of the master clock rate. Otherwise, the CIC filters on the USRP will corrupt your signal. > (2) even with small sampling rates (like 2M), and despite a 10MB buffer > in between the USRP source and the ZMQ sink, the system keeps overflowin > > The design I'm using is depicted here: https://ibb.co/GVJxwcm > > - Am I doing anything wrong? > - What is the sampling rate I am supposed to achieve? > > Thanks a lot in advance! > Best, > Rob > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ettus E310 & MIMO -- data rate?
Hi, I've bought an Ettus E310 board and I am trying to use it for a MIMO project, but I am encountering several issues. In particular, I have created a GNU Radio design, compiled it as Python script (as illustrated on the page https://kb.ettus.com/Streaming_processed_data_from_the_E31x_with_GNU_Radio_and_ZMQ), modified it (because it was complaining due to a TypeError: push_sink_make() takes at most 5 arguments (6 given) error with the ZMQ sink) and scp'd to the board. What I've found is (1) I cannot set an arbitrary sampling rate (for instance 9.1428M), but I am required to set e.g. 4M. (2) even with small sampling rates (like 2M), and despite a 10MB buffer in between the USRP source and the ZMQ sink, the system keeps overflowing. The design I'm using is depicted here: https://ibb.co/GVJxwcm - Am I doing anything wrong? - What is the sampling rate I am supposed to achieve? Thanks a lot in advance! Best, Rob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio
Hi Johannes: On Tue, 2019-02-26 at 11:05 +, Johannes Demel wrote: > Hi Andy, > > thanks for your answer and help. That's the pointer I was looking > for. > > Just for clarification, I' refering to this schematic: > https://files.ettus.com/schematics/ubx/ubx.pdf > > The 'SKyWorks SKY13350-385LF' switch is this SPDT component in the > TXPA > block? Yes, on Sheet 1. It is also depicted on Sheet 11, Grid C-2, designated U32. > I expect a configuration with separate antennas for TX and RX. But > since > isolation between TX and RX chains is limited by the switch, this is > the > component I need to worry about? In my opinion, yes. It seems kind of funny that Ettus would make a board that can blast out 20 dBm on Tx, can only tolerate -15 dBm max on Rx, and then have only a single device that provides only 17-20 dB isolation between the Tx and Rx. If all the specifications from the UBX-160 page are to be believed, you always have to have the UBX Tx gain turned down by at least 15 dB to not damage your UBX board. > Otherwise I'd just separate my TX and RX antennas spatially. But > that > doesn't make sense in my case since the critical component is this > switch in my case. Right. Although antenna separation needs to happen as well, so you have at least 35 dB loss over the air. Keep in mind that equations derived from far field approximations don't necessarily hold in the near field. > I aim at working in the 3.7GHz band. Thus, I assume that my receive > signal goes through the VMMK-3603 LNA in the RXLNA block in the > schematic. I wonder how that component right after the RX2 SMA works? > I > assume this is a Skyworks AS236-321LF as shown on page 11 of the > schematic. > https://store.skyworksinc.com/Products/Detail/AS236321LF-Skyworks-Solutions-Inc/88944/ Take a look at the SPDT switch in Figure 1 here: http://www.skyworksinc.com/uploads/documents/PB_RFSwitches_PB121_15B.pdf It's not too hard to imagine what a DPDT switch looks like from there. > Are there in fact 2 switches concatenated? Would it be appropriate > to > just add up their isolation values? Ah, yes. As long as the USRP switches this one over to RX2, (and that sounds like your configuration,) it looks like you get an additional 13-15 dB of isolation. Still not enough to cover the whole 35 dB, but you're up to a worst case minimum 30 dB isolation. If all of the specifications are to be believed, and you know you'll receive negligible energy on the RX2 port antenna, you only need set Tx output gain to 5 dB of attenuation, and make sure you are using RX2 for Rx. > Another thought, would it be possible to configure a USRP in GR such > that it does continuously receive on TX/RX and then switch for the > duration of a transmit burst and switch back afterwards? Of course, > preferably this happens automagically. I'm pretty sure this already is handled automatically by the USRP/libuhd, but it would take a bit of searching through code to verify. In the case of telling the USRP you're using the TX/RX port for both Tx and Rx, you may not get that Skyworks AS236-321LF switch switched into the position to get the additional isolation. You'll have to check the code or check with Ettus. > This thread [0] suggests that there is some kind of control. But so > far, > I didn't find a definite way to tell if this covers my case with GNU > Radio. Also, in [1] it sounds like switching is done automagically. In GNURadio you should be able to set a USRP Sink to "TX/RX" and a USRP Source to "TX/RX", and libuhd should take care of the switching automatically, if I recall correctly. Again, you might not get the isolation of the second Rx switch using this configuration. > Though, I wonder if I can just use 'UHD: USRP Sink' and 'Source' or > if I > need to use the Async Sink? I have no idea. Never used it. Regards, Andy > Cheers > Johannes > > [0] > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-October/050112.html > [1] > https://stackoverflow.com/questions/39321262/switching-usrp-from-rx-to-tx-using-gnuradio > > Am 25.02.19 um 20:30 schrieb Andy Walls: > > > > > Date: Mon, 25 Feb 2019 10:29:56 + > > > From: Johannes Demel > > > To: "discuss-gnuradio@gnu.org" > > > Subject: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio > > > > > > Hi all, > > > > > > I plan to implement a TDD system with GNU Radio and X310s w > > > UBX160s. > > > My > > > lab setup is as follows: > > > - multiple USRPs (start with 2, extend to more) > > > - each USRP shall use 1 TX and one RX port. Preferably on one > > > daughterboard in order to extend it to MIMO later on. > > > > > > At the moment the receiver runs continuously. While TX bursts > > > happen > > > occasionally. I'd like to turn up TX power as much as possible. > > > But > > > I'm > > > concerned that this will damage the RX frontend. Especially if > > > the > > > RX > > > gain is set to some high value too. Should I be concerned about >
Re: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio
Hi Andy, thanks for your answer and help. That's the pointer I was looking for. Just for clarification, I' refering to this schematic: https://files.ettus.com/schematics/ubx/ubx.pdf The 'SKyWorks SKY13350-385LF' switch is this SPDT component in the TXPA block? I expect a configuration with separate antennas for TX and RX. But since isolation between TX and RX chains is limited by the switch, this is the component I need to worry about? Otherwise I'd just separate my TX and RX antennas spatially. But that doesn't make sense in my case since the critical component is this switch in my case. I aim at working in the 3.7GHz band. Thus, I assume that my receive signal goes through the VMMK-3603 LNA in the RXLNA block in the schematic. I wonder how that component right after the RX2 SMA works? I assume this is a Skyworks AS236-321LF as shown on page 11 of the schematic. https://store.skyworksinc.com/Products/Detail/AS236321LF-Skyworks-Solutions-Inc/88944/ Are there in fact 2 switches concatenated? Would it be appropriate to just add up their isolation values? Another thought, would it be possible to configure a USRP in GR such that it does continuously receive on TX/RX and then switch for the duration of a transmit burst and switch back afterwards? Of course, preferably this happens automagically. This thread [0] suggests that there is some kind of control. But so far, I didn't find a definite way to tell if this covers my case with GNU Radio. Also, in [1] it sounds like switching is done automagically. Though, I wonder if I can just use 'UHD: USRP Sink' and 'Source' or if I need to use the Async Sink? Cheers Johannes [0] http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-October/050112.html [1] https://stackoverflow.com/questions/39321262/switching-usrp-from-rx-to-tx-using-gnuradio Am 25.02.19 um 20:30 schrieb Andy Walls: > >> Date: Mon, 25 Feb 2019 10:29:56 + >> From: Johannes Demel >> To: "discuss-gnuradio@gnu.org" >> Subject: [Discuss-gnuradio] TDD mode with USRPs in GNU Radio >> >> Hi all, >> >> I plan to implement a TDD system with GNU Radio and X310s w UBX160s. >> My >> lab setup is as follows: >> - multiple USRPs (start with 2, extend to more) >> - each USRP shall use 1 TX and one RX port. Preferably on one >> daughterboard in order to extend it to MIMO later on. >> >> At the moment the receiver runs continuously. While TX bursts happen >> occasionally. I'd like to turn up TX power as much as possible. But >> I'm >> concerned that this will damage the RX frontend. Especially if the >> RX >> gain is set to some high value too. Should I be concerned about that? > > Yes. > > https://kb.ettus.com/UBX > > "TX Power (Max) > > 10 MHz - 3 GHz: 20 dBm > 3 - 6 GHz: 8 - 20 dBm" > > "Input Power Levels > > The maximum input power for the UBX is -15 dBm." > > > The TX chain is isolated from the Rx chain by a SKyWorks SKY13350-385LF > switch. > https://files.ettus.com/schematics/ubx/ubx.pdf > http://www.skyworksinc.com/Product/712/SKY13350-385LF > > which claims typical isolation of 25 dB at 3 GHz on the webpage, but > the datasheet indicates 20 dB is actually typical and 17 dB is minimum. > UBX-160 board design, if not done right, can degrade that. > > 17 dB of isolation is does not cover the 35 dB difference between max > TX power and max Rx input power. > > >> Or >> does the USRP take care of that automatically? e.g. turn down RX >> gain >> during transmission? > > I don't think so. > > >> Even if a transmission is received at the same receiver, I'd expect >> my >> RX DSP chain to just demodulate that burst and later on this packet >> would be discarded. > > That's my experience with WBX-120 boards installed in a working > system: the radio can hear itself. > > >> Also, I'd envision a block that 'blanks' my RX >> samples whenever TX is expected. > > It's easy enough to throw away these packets at the MAC layer. > Receiving them is also a rudimentary check for a continuous built in > test to detect if the transmitter has completely failed. > > >> All in all the questions are: >> - do I need to implement some logic in GR to turn down RX gain (or >> shut >> off RX) during a TX burst? > > Given the numbers above, I would think you need to keep the gain down. > > >> - does UHD take care of that? > > I don't think so. > > >> - If I need to take care of that, how did you guys handle that >> problem? > > Don't run the RX chain at full gain. > > Put an LNA and limiter out in front of the USRP's Rx port. > > And if you're using one antenna for both Tx and Rx, on the TX/RX and > RX2 ports respectively, you'll need a PIN diode RF T/R switch out in > front of the USRP as well. > > Regards, > Andy > >> Cheers >> Johannes >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distance Measurement by Correlation
> Any ideas about how we can troubleshoot this more effectively? Or better > model the channel? Make sure both your radios are locked to the same clock source. Any fsignificant requency offset between the two is going to ruin your correlation peaks very quickly. Frequency offset is going to end up as a progressive phase shift along your PN sequence. If that phase shift is a non-negligibe part of the unit circle during the time of your PN sequence, they won't 'add up' to a peak anymore. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
