Re: Sending a signal to a USRP N200

On 2021-09-06 5:33 p.m., isaac mario tupac davila wrote: Hi I've probed A:A, A:B, A:AB, A:BA and had the same behavior. Doesn't change. regards Isaac T Could you confirm your signal power?  The Basic_RX has NO RF GAIN--which means the peak input power would be around +7dBm approximately.  

Re: Sending a signal to a USRP N200

On 2021-09-06 3:24 p.m., isaac mario tupac davila wrote: Hi. -- The daughterboard is the BasicRX Daughterboard. -- I put the address of  my USRP as 192.168.10.1 ** soporte@i28:~$ ping 192.168.10.1

Re: UHD function to determine USB version?

On 2021-08-27 5:39 p.m., Jeff Long wrote: uhd_usrp_probe reports it doesn't it? Only as a side-effect of the driver opening the device. It doesn't do anything explicit that I can see. On Fri, Aug 27, 2021, 17:35 Marcus D. Leech <mailto:patchvonbr...@gmail.com>> wrote: On 202

Re: UHD function to determine USB version?

On 2021-08-27 2:49 p.m., Mike wrote: Hello, I apologize if I missed it in the documentation, but is there a UHD function that will return the USB version (e.g. USB 2 or USB 3) that the USRP is using? I'm using a B200 in a custom C++ program and would like to programmatically verify the USB

Re: 回复: [USRP-users] Is there a "trigger" in GNURadio with USRP?

he answer. I've cross-posted to discuss-gnuradio because there may be an audience there who have already done something similar to what you want and may ask more clarifying questions. *发件人:*Marcus D Leech *发送时间:*2021年8月3日3:52 *收件人:*ZHOU Yuxuan *抄送:*usrp-us...@lists.ettus.com *主题:*Re: [USRP

Re: GRC port type assignment in Python Block

On 07/26/2021 07:32 AM, Josh Morman wrote: Hi Jerrid, Your attempt at using structures to map to a complex type is sensible, but it appears that GRC doesn't parse this very well for at least the embedded python blocks. The UHD blocks are c++ based which just uses the io_signature object in

Re: Using an E310 in place of a B200

On 07/20/2021 03:52 PM, Mike wrote: Hello, We are working with the srsRAN software package (www.srslte.com). Our hardware configuration is a laptop running the srsRAN application under Ubuntu, connected via USB to a USRP. It runs well with B200s, however we do not have access to B200s at

Re: Error attempting to use AirSpy with osmocom source block

On 07/17/2021 05:28 PM, Ellie White wrote: Hi Jeff, Thank you so much for this advice and for taking the time to investigate this -- I just tried removing the spaces as you suggested and it worked great. Really appreciate your help on this! Enjoy the rest of your weekend :) Cheers, Ellie

Re: Overrun using GRC Python block and USRP

ndations >> on how to get you closer to what you need. >> >> Best regards, >> >> Marcus >> >> On 09.07.21 18:33, Huang Wei wrote: >> > Thank you for the quick reply, so if I write the block in C++ or C, it may >> > work at a >&g

Re: Overrun using GRC Python block and USRP

On 07/09/2021 12:05 PM, Huang Wei wrote: Sorry, I mean it's the underrun problem Huang Wei mailto:weizar...@gmail.com>> 于2021年7 月9日周五 下午5:02写道： Hello everyone, I am using the embedded python block in GRC to realize some simple functions. All works fine in the GRC local set-up.

Re: N310 phase sync issue with antenna array

On 06/29/2021 04:51 PM, Larry wrote: Hello everyone, I am having an issue with achieving a phase-synchronous RF configuration using an N310 with an Octoclock and a linear antenna array. What I believe should be the expected results of this setup is that each AD9371 should receive synchronous

Re: USRP - N300 RunTimeError

>>> Done (return code 1) > > Note that I found out that GNU Radio executed UHD_3.15.0.0 instead of > UHD_4.0.0.0. > I did update GNU radio, maybe the UHD of GNU radio is out of date? > >> On Tue, 29 Jun 2021 at 16:01, Marcus D Leech wrote: >> What was the exact d

Re: USRP - N300 RunTimeError

What was the exact device argument you used in the GR case? Sent from my iPhone > On Jun 29, 2021, at 9:36 AM, Niels van Etten wrote: > >  > Dear all, > I'm trying to run the Ettus N300 on GNU radio. > When I'm running GNU radio via: pybombs run gnuradio-companion, I get the > following

Re: [USRP-users] LibUHD - Python API problem (RFNoC not found)

t; -- Could NOT find UDEV (missing: UDEV_INCLUDE_DIR_UDEV_LIBS) > … > # > # UHD Disabled components > # > * LibUHD – Python API > * LIBERIO > * GSPD > * E300 &

Re: [USRP-users] LibUHD - Python API problem (RFNoC not found)

Could you share the log from CMake? That might tell us why. Sent from my iPhone > On Jun 25, 2021, at 1:56 AM, COURANT Frederique - Contractor via USRP-users > wrote: > >  > Hello users, > > When I try to install UHD 3.14.0.0 on RedHat 7.5 system, I can’t enabled > components LibUHD –

Re: USRP source starts to receive after certain samples

Latency is pretty normal in digital systems. There’s buffering in Gnu Rsdio, in the kernel network and USB layers, and there are packetizing delays. There’s buffer in the radio and the DUC and DDC filters inherently ads group delay. Picoseconds? Really? EM waves in a vacuum propagate at

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

. *From:* Marcus D. Leech *Sent:* Tuesday, June 15, 2021 6:34 PM *To:* Skyvalakis Konstantinos *Cc:* Discuss-gnuradio@gnu.org *Subject:* Re: Phase Synchronize 2 USRP N200 w/ SBX cards On 06/15/2021 09:34 AM, Skyvalakis Konstantinos wrote: I just thought, that the time difference I

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

4:19 PM *To:* Marcus D Leech *Cc:* Discuss-gnuradio@gnu.org *Subject:* Re: Phase Synchronize 2 USRP N200 w/ SBX cards Hi again I would like to ask you the following and I am also attaching the code for clarity: self.sink = uhd.usrp_sink( ",".join(("addr0=192

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

On 06/15/2021 09:19 AM, Skyvalakis Konstantinos wrote: t1 = self.sink.get_time_now(0) t2 = self.sink.get_time_now(1) t3 = self.source.get_time_now(0) t4 = self.source.get_time_now(1) print(uhd.time_spec_t.get_real_secs(t1)) print(uhd.time_spec_t.get_real_secs(t2))

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

s just the first one that popped up in a Google search: https://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf On Jun 13, 2021 22:06, Marcus D Leech wrote: Phase *correction* is easy once you know what that c

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

ference of +/- 180 degrees. > > > > Do you reckon you could help me any further with my problem? I really need to > achieve this synchronization for my thesis. > > > > Thank you very much. > > From: Discuss-gnuradio > on behalf of > Skyvalakis Konstan

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

On 06/10/2021 01:00 PM, Skyvalakis Konstantinos wrote: In addition to my last message regarding the INTEGER_N tuning​, ​I repeated the experiment multiple times. I even restarted the USRPs and the signal generator multiple times. What I observed was, that there were only 4 different

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

On 06/10/2021 07:39 AM, Skyvalakis Konstantinos wrote: Yes, I know that about GNURadio and the timed commands. I just described the flowchart here. After I generated that flowchart in GNURadio I edited the timed commands in the generated python file, according to the code I included in my

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

till observe a > different phase offset at every experiment.​ > > > > I am using 3.7.12.0 version of GNURadio. > > > > Thanks for your help. > > From: Marcus D. Leech > Sent: Thursday, June 10, 2021 2:26 PM > To: Skyvalakis Konstantinos > Cc: Discuss

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

t even appear in later versions of GR. You'd have to modify the generated code to have it wrap the tuning requests in timed commands. *From:* Marcus D Leech *Sent:* Wednesday, June 9, 2021 10:53 PM *To:* Skyvalakis Konstantin

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

this, yes. You want to measure the phase offset that is dominated by the receivers and not external path length differences. > Thanks. > > > > From: Marcus D Leech > Sent: Wednesday, June 9, 2021 9:05 PM > To: Skyvalakis Konstantinos > Cc: Discuss-gnuradio@gnu.org > Subject: Re:

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

itting a tone @ 868MHz from an > RF generator and I'm receiving it from the 2 RX channels. > > Also could you elaborate more on the last thing you mentioned, the one about > the phase identical test tone.... > > On Jun 9, 2021 19:51, "Marcus D. Leech" wrote: >

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

On 06/09/2021 10:11 AM, Skyvalakis Konstantinos wrote: I have 2 USRP N200 devices, each one equipped with an SBX daughterboard. I am providing 10MHz ref clock and 1 PPS input on both devices with equal length cables, from an external signal generator. My application is DoA. Is it possible

Re: USRP N200

On 05/31/2021 06:23 AM, Skyvalakis Konstantinos wrote: Hi, I have 2 USRP N200 devices equipped with an SBX daughterboard each. I want to build a 1 Tx, 2 Rx system, where everything is synchronized. ​I have an external generator to provide 10MHz ref clock and PPS input for both USRP

Re: Phase Synchronize 2 USRP N200 w/ SBX cards

So you are presumably using timed commands for tuning, and making sure both devices are set to exactly the same time on the PPS pulse? What is the magnitude of the phase difference that you’re seeing! Sent from my iPhone > On May 28, 2021, at 6:30 AM, Skyvalakis Konstantinos > wrote: > > 

Re: Sample Rate and audio underflow ....

The RTL-SDR supports nothing below 250Ksps and rates between 250Ksps and 900ksps are “spotty” Sent from my iPhone > On May 13, 2021, at 4:33 PM, Rob Roschewsk wrote: > >  > Hi all! > > I'm working on a "Hello, World!" flow in GRC just a simple NBFM receiver > tuned to my local NOAA

Re: QT GUI Digital Number Control / inaccuracy

On 05/01/2021 10:37 AM, Tom Breyer wrote: Dear team, when I use "QT GUI Digital Number Control" to display a frequency I see some "special effects". Below 128MHz, it works fine but above I get wrong display data: ok: Input 128.001.000Hz -> Display = 128.001.000 not ok: Input 138.001.000Hz ->

Re: USRP E310 based transceiver

Also—missed this the first time around. The AD9361 has only a single LO synthesizer in each duration. Meaning that both RX channels will be tuned to the same RF frequency. Sent from my iPhone > On Apr 26, 2021, at 7:58 PM, Marcus D Leech wrote: > > The RX gain range on the RF

Re: USRP E310 based transceiver

The RX gain range on the RF front end goes up to 72dB, so you’re about 40dB below maximum RX gain. Sent from my iPhone > On Apr 26, 2021, at 6:09 PM, Ivan Zahartchuk wrote: > >  > Hello. I want to make a transceiver based on USRP E310. That is, on one > channel, reception and on another

Re: Rust-lang

My feeling is that it would be Herculean to take a framework 17 years in the making, and move to an entirely new language. Inevitably, there’s be *years* of crossover time with people using both environments in the field. There’s be pressure for back-ports and a general support headache.

Re: Receive amplitude consistency

usrp-users mailing list, where this discussion is probably more appropriate. On 4/21/2021 10:42 AM, Marcus D Leech wrote: What is the magnitude of the inconsistency? If you replace the signal generator with a 50 ohm terminator and increase the gain to near maximum, do you still see the inc

Re: Receive amplitude consistency

What is the magnitude of the inconsistency? If you replace the signal generator with a 50 ohm terminator and increase the gain to near maximum, do you still see the inconsistency? What power level are you injecting from the signal generator. Sent from my iPhone > On Apr 21, 2021, at 12:27

Re: E310, RFNoC OFDM Sync block error

This is the wrong mailing list for discussions of USRP hardware. But yes, the FPGA in the E310 is not as big as on other USRP devices. This discussion should be continued on the usrp-users mailing list. Sent from my iPhone > On Apr 16, 2021, at 8:26 AM, Louis Jung wrote: > > Dear all, >

Re: USRP E310 limited sample rate

ote: > > Thank you for your answer! > > Then, if I want to run some OOT modules (i.e., gr-csitool) on E310, I need to > change it to use RFNOC blocks, is it right? > > Is there any reference or guide to port from gnuradio blocks to RFNOC blocks? > > Best, > >> 20

Re: USRP E310 limited sample rate

The Zynq CPU cannot possibly sustain sample rates of 10s of MSPS. The E3xx series have larger FPGAs that support the RFNOc framework that support high sample rate signal flows within the FPGA. Sent from my iPhone > On Apr 12, 2021, at 10:55 PM, Louis Jung wrote: > > Hi all, > > I’m

Re: B200 clock and pulse timing

expect there to be more delay in the sampling path than > the PPS path, but is there a way to characterize those different delays? > > Thanks! > > > > On 4/6/2021 9:34 PM, Marcus D. Leech wrote: >> On 04/06/2021 07:14 PM, Mike wrote: >>> Hello, >>&

Re: B200 clock and pulse timing

On 04/06/2021 07:14 PM, Mike wrote: Hello, I’d like to better understand the clock in the B200/B210. First, what is the actual resolution of the clock?Is it any more precise than the 100 nanoseconds a 10 MHz external reference provides?When the USRP timing is set to external, does the 10

Re: Transport stream source

On 04/04/2021 12:22 PM, Ralf Gorholt wrote: Hello Steven, when I look at your flow graph, that is exactly what I have tried to do (use a UDP source and UDP sink) but it did not work. Could it be because I had not put a throttle between source and sink? I will try to reproduce what you have

Re: Transport stream source

On 04/04/2021 03:53 AM, Ralf Gorholt wrote: Hi Marcus, as I have written, I have tried to use a UDP source (and to connect it to a UDP sink with a different IP address and port) but it does not seem to work. As I am quite new to GNU radio, I have certainly made a mistake somewhere. If I only

Re: Transport stream source

If you want VLC to produce a stream and Gnu Radio to consume it, you need a UDP *source* rather than a *sink*. Sent from my iPhone > On Apr 3, 2021, at 3:48 PM, Ralf Gorholt wrote: > > Dear all, > > instead of using a file source, I would like to get data from a video > stream into GNU

Re: FM Radio Reception Issue on VMWare

USB performance in VMs is often poor. That’s probably the main contributor. Sent from my iPhone > On Apr 2, 2021, at 5:13 PM, James Hayek wrote: > >  > Hello all, I am unsure if this is an issue with my flowgraph or something > specific to my VMWare machine. I am running Windows 10 along

Re: This flow graph is radiating negative Tx power

I’ve suggested this to you before. Start with a pure some way at your target frequency—what does your spectrum analyzer say about power. Now Modulate it to produce a bandwidth of 1khz—what does your spectrum analyzer say about the power in each bin? Now what about with 10khz of modulation

Re: Problem gnuradio.uhd attribute

lock.params[key].get_evaluated() > KeyError: ‘catch_exceptions’ > > Do you have any idea how can I resolve this problem ? > > I don’t think it is a problem with my flow graph because this is the same > result with example flow graph in gnuradio examples. > > Thanks

Re: Problem gnuradio.uhd attribute

Your message is confusing. Do you mean that your created the graph under gnuradio-3.9 but are trying to execute it under Gnuradio 3.8? Sent from my iPhone > On Mar 15, 2021, at 4:47 AM, COURANT Frederique - Contractor > wrote: > >  > Hello, > > I try to test the flow graph that I have

Re: direction finder USRP E310

hing similar but did not find anything with the participation of > E310 > > ср, 10 мар. 2021 г. в 01:56, Marcus D Leech : >> Balint Seeber did work on this many years ago using GnuRadio. I suggest >> tracking down his work. >> >> Sent from my iPhone >> >

Re: USRP N210 Synchronization

On 03/10/2021 07:26 AM, Martin Braun wrote: USRPs typically operate with a 25% duty cycle PPS (i.e., 250 ms on, 750 ms off). But they will work with pretty much any duty cycle. Check the levels are within limits (I don't have them off the top of my head). I would suggest you connect your

Re: direction finder USRP E310

Balint Seeber did work on this many years ago using GnuRadio. I suggest tracking down his work. Sent from my iPhone > On Mar 9, 2021, at 6:38 PM, Ivan Zahartchuk wrote: > >  > Hello, I am trying to create a layout for a USRP E310 based direction finder > in gnuradio. I need to read data

Re: Is there a way to change the number of taps of the FIR filter in GNURadio while running?

This type of problem showed up in 3.9 due to pybind11 issues for setter functions. But this seems like a separate issue. Sent from my iPhone > On Mar 3, 2021, at 11:44 PM, Nick Foster wrote: > >  > It looks like the GRC convenience blocks for the filter tap generation don't > have

Re: Is there a way to change the number of taps of the FIR filter in GNURadio while running?

On 03/03/2021 10:10 PM, Jay Patel wrote: Hi all, I am using |GNURadio| example |Filter Introduction| flow graph which shows basic introduction of |filtering|. I want to change the |no. of taps| while running the program. I tried to put the |qt gui range| but it looks like |GNURadio|

Re: Suggestion for an SDR computer

There is essentially no way on gods little green planet that you will process 2Gsps on the CPU. You will really need to pre-process within your FPGA framework. Sent from my iPhone > On Feb 20, 2021, at 4:29 PM, Moses Browne Mwakyanjala > wrote: > >  > Hi everyone, > I will be acquiring a

Re: How to use 2 N310 for TX and RX

What happens if you just use a single N310 for both TX and RX? Just trying to figure out where the problem might be. Also please share a minimal flow graph that shows the problem. Sent from my iPhone > On Feb 10, 2021, at 1:25 PM, Johannes Demel wrote: > > Hi all, > > I have a flowgraph

Re: N310 TX with external LO

On 01/26/2021 06:26 AM, Damon qiu wrote: Dear Madam/Sir, Recently, I had encountered a problem that was the synchronization of signal between the four channels of USRP N310. For sloving this problem, I used to the mode of external local oscillator (LO) of N310. As this article says

Re: Cross compile gnuradio in E312 error

On 01/25/2021 01:00 AM, --- via "GNU Radio, the Free & Open-Source Toolkit for Software Radio" wrote: Dear friends: I'm installing rfnoc on E312, when I cross compile gnu radio, I execute this command：cmake -Wno-dev

Re: Performing a USRP Packet Loopback

On 01/20/2021 12:12 AM, Jada Mariano Berenguer wrote: Hi, I realized that in my packet loopback example, I didn't connect any of the QT GUI sinks after the USRP source. The updated flow graph is attached in screenshot0. After I connected them, I ran the packet loopback example on my MacBook

Re: Performing a USRP Packet Loopback

Keep in mind that the Pi 3b isn’t that powerful. So running a modulate+demodulator loopback flow may be too much for it, even at low rates. Also for a loopback flow at low rates you may need to alter the internal buffer sizes in you flow-graph to prevent TX starving for samples because the RX

Re: stop making unneeded improvements

On 01/16/2021 09:00 PM, Glen Langston wrote: Dear Marcus and all, Thanks for all your efforts. I really to appreciate all you’ve done. Best regards, Glen We know you do, Glen. Sometimes when you haven't been "inside the sausage factory" it can be a bit hard to understand why things are

Re: Stop making unneeded improvements

On 01/12/2021 02:51 PM, Lamar Owen wrote: I'm trying to debug and patch the UHD stack for USRP1 with DBS-RX daughterboard; it just quit working, and while I've reported to the UHD list no action has been taken to fix the regression. I was able to reproduce the regression issue with DBS-RX

Re: Stop making unneeded improvements

On 01/08/2021 12:38 AM, p...@dbnut.com wrote: [Apologies for the lack of paragraph breaks in that last - taken by surprise after using a crude editor] Thank you, Marcus, for taking so much trouble to respond so comprehensively. And with such good grace! Your detailed section on dependencies

Re: Stop making unneeded improvements

On 01/07/2021 03:32 PM, p...@dbnut.com wrote: Prompted to write by Glen Langston's post, I'm an old man resurrecting an old moan, and in a minority that (I believe) is just not catered for: * Windows user * Non-programmer (of any great consequence) It was NEVER a goal of GR to make it easy for

Re: Stop making unneeded improvements

On 01/05/2021 09:24 AM, Johannes Demel wrote: Hi Glen, I fully understand your frustration to make things work long term and constant breakage. There are, however, reasons why breaking changes are unavoidable. Some examples are: 1. GRC used Cheetah with XML for block definitions BUT:

Re: Accuracy of rx_time in UHD API stream receive command?

On 01/05/2021 12:27 AM, Mike wrote: Hello, I apologize if this is covered in a document somewhere, but from exactly where is the rx_time value in the UHD API stream receive command derived? I'd like to determine how close that value is to the actual arrival time of the signal at the antenna

Re: Stop making unneeded improvements

On 12/22/2020 08:21 PM, Glen Langston wrote: Hello GNuradio Superheros, I have to say, after 5 years with gnu radio, I’m either tool old or something has to change. I’ve been trying to produce some tools for High School teacher to do radio astronomy. and for that gnuradio 3.7 was perfectly

Re: GNURADIO doesn't find USRP B205

Also you have two UHD versions on your system. 3.15 for your uhd_usrp_probe and 3.13 is what Gnu Radio is linked against. Sent from my iPhone > On Nov 30, 2020, at 12:37 PM, jean-michel.fri...@femto-st.fr wrote: > > you forgot to highlight in your message the answers given by libuhd: > >>

Re: [USRP-users] Poor Data Rates with the USRP E312

The E31x series really are intended for applications where all the high sample rate stuff happens in the FPGA. The ARM cpu is only dual core and runs at under 1Ghz. The scenario you describe is a lot like what we used to call “network mode” for the E31x, and it was never recommended for that

Re: [USRP-users] daughter board coherency on N310

rchitectural reasons, there is a timstamp clock for each RF chain in th device--those clocks need to b synchronized, so a "set_time_next_pps" will take care of that. On Fri, Nov 20, 2020 at 12:43 PM Marcus D. Leech mailto:patchvonbr...@gmail.com>> wrote: On 11/20/2020 11:49 AM

Re: [USRP-users] Overrun on chan error 0 USRP e310 RFNoC

. в 05:12, Marcus D Leech <mailto:patchvonbr...@gmail.com>>: There’s no way the fpga to ARM channel can support those data rates. Lower your sample rate to 5msps and try again. Sent from my iPhone > On Nov 20, 2020, at 10:02 PM, Ivan Zahartchuk via USRP-users ma

Re: How to import custom script to GRC?

On 11/21/2020 09:26 AM, Fabian Schwartau wrote: Hi everyone, I would like to built some flow graphs with GRC, but I need to write a few custom python functions which I want to use in the flow graph. For example I need to generate some filter coefficient and things like that. I thought I just

Re: [USRP-users] Overrun on chan error 0 USRP e310 RFNoC

There’s no way the fpga to ARM channel can support those data rates. Lower your sample rate to 5msps and try again. Sent from my iPhone > On Nov 20, 2020, at 10:02 PM, Ivan Zahartchuk via USRP-users > wrote: > >  > Hello, I want to launch two channels for receiving in parallel with usrp

Re: [USRP-users] daughter board coherency on N310

On 11/20/2020 11:49 AM, Rob Kossler wrote: Hi Cameron, Yes, this is possible. I'm not too familiar with gnuradio but in the end you need to use a "timed start" to the receive streams. Rob On Fri, Nov 20, 2020 at 7:34 AM Cameron Matson via USRP-users mailto:usrp-us...@lists.ettus.com>>

Re: [USRP-users] Direction finding based on USRP E310 board

The two channels on an E310 are already time synchronized and phase coherent. You’d only have to callibrate and remove external phase effects. Sent from my iPhone > On Nov 16, 2020, at 6:15 PM, Ivan Zahartchuk via USRP-users > wrote: > >  > Hello. I am interested in the possibility of

Re: Measuring transmission power from USRP B210

o-ow...@gnu.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Discuss-gnuradio digest..." >> >> >> Today's Topics: >> >>1. Re: Measuring transmission power from USRP B210 (Marcus D. Leech)

Re: Ettus Research B205 + Raspberry Pi 4B + GNURADIO

On 11/07/2020 07:43 PM, Jens Hoffmann wrote: Hi, it's my intention to use an Ettus B205mini connected to a Raspberry Pi 4 B (latest model with 8GB RAM) with GNURADIO running on it. During the first try with the current RASPBIAN OS the complete installation seems to be successful but the

Re: Maximum Number of Bins

I think you are fine. If you're not, get a faster PC, honestly! Best regards, Marcus M (the younger Marcus) On 29.10.20 23:53, Marcus D. Leech wrote: On 10/29/2020 06:03 PM, Criss Swaim wrote: we are running version 3.7.9.2 I constructed a simple flow-graph in GR 3.7.13.5 osmosdr_source--->

Re: Maximum Number of Bins

shouldn't necessarily Seg Fault, it's not a terribly efficient way of doing things. Criss Swaim csw...@tpginc.net cell: 505.301.5701 On 10/29/2020 11:37 AM, Marcus D. Leech wrote: On 10/29/2020 01:17 PM, Criss Swaim wrote: I have attached a png of the flow graph and the error msgs from

Re: Maximum Number of Bins

On 10/29/2020 01:17 PM, Criss Swaim wrote: I have attached a png of the flow graph and the error msgs from the system log are below. These error messages are the only messages. Oct 29 10:45:26 tf abrt-hook-ccpp[378]: /var/spool/abrt is 23611049718 bytes (more than 1279MiB), deleting

Re: Maximum Number of Bins

Sharing your flow-graph. The exact error messages and more context would be good Presumably you’re talking about FFT bins but it’s not clear. Also why are your samples being conveyed as strings ? That’s wildly inefficient. Sent from my iPhone > On Oct 28, 2020, at 7:24 PM, Criss Swaim

Re: Underruns causing USRP to stop transmitting and receiving

On 10/21/2020 03:57 PM, Marcus Müller wrote: But: I fully agree with you, the ability to write signal processing in Python that performs somewhat well is a great boon! And I do recommend that to most beginners, too: Start in Python (unless you already are really more comfortable with C++) and

Re: Underruns causing USRP to stop transmitting and receiving

On 10/21/2020 03:13 PM, Marcus Müller wrote: Hi Jerrid, * A function probe is really a kludge in GNU Radio and probably shouldn't be used. You've got very many of these – and that kind of hints at architectural problems, e.g. you trying to replace message passing with polling. My wild guess

chat.gnuradio.org down?

Seems like chat.gnuradio.org has been misbehaving for the last couple of hours.

Re: phase difference between Tx/Rx1 Tx/Rx2

On 10/12/2020 11:32 PM, Xiang Ma wrote: Think about this. The signal transmitted at USRP TX is image.png Then after transmission, received at USRP RX is image.png Here, ignore the Doppler shift, and just consider the phase change due to the transmission distance, I know due to the wavelength,

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

Thanks again Sent from my iPhone > On Oct 8, 2020, at 1:22 AM, Ron Economos wrote: > > I've submitted another PR. > > https://github.com/gnuradio/gnuradio/pull/3819 > > Ron > >> On 10/7/20 19:57, Marcus D. Leech wrote: >>> On 10/07/2020 06:01 AM

XMLRPC in GRC 3.9

I've noticed that the XMLRPC implementation in GRC 3.9 is lacking the "logging" option in the block so there's no way to turn off the very-chatty logging that is normally done. In GRC 3.7 there was a"logging" parameter that you could turn off, and it was OFF by default.

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

On 10/07/2020 06:01 AM, Ron Economos wrote: Here's the PR. https://github.com/gnuradio/gnuradio/pull/3818 Here's the updated file if you want to do a quick test. http://www.w6rz.net/multiply_const_v_python.cc It goes in gnuradio/gr-blocks/python/blocks/bindings Ron So thanks tremendously

Re: phase difference between Tx/Rx1 Tx/Rx2

On 10/07/2020 07:13 PM, Xiang Ma wrote: Should the TX be the signal before it been received and after it been transmitted? Thx The phase of the TX signal, as seen at the RX will be some function of the propagation delay between the two, and the initial phase at the TX. That's basic

Re: phase difference between Tx/Rx1 Tx/Rx2

On 10/07/2020 06:49 PM, Xiang Ma wrote: Thank you. I have read this, it only shows the phase difference between two RX, how about the phase difference between TX and RX? Thank you. Well, given that the only "view" you have of TX is after it has been received, and before it has been

Re: phase difference between Tx/Rx1 Tx/Rx2

Google is your friend. https://www.egr.msu.edu/classes/ece480/capstone/spring14/group02/docs/Application%20Note%20-%20Phase%20George%20Godby%20Team%202.pdf Sent from my iPhone > On Oct 7, 2020, at 6:19 PM, Xiang Ma wrote: > >  > Does anyone help with this? > > Great thx. > >> On Tue, Oct

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

cc > > It goes in gnuradio/gr-blocks/python/blocks/bindings > > Ron > >> On 10/6/20 23:04, Ron Economos wrote: >> It's only in 3.9. It was merged on June 19, 2020. >> >> Ron >> >>> On 10/6/20 22:49, Marcus D. Leech wrote: >>>

YAML conversion from 3.7 GRC files

The YAML converter in GRC loses its lunch slightly on command-line parameters that are tagged in XML as type "string" whereas the converter seems to want them to be "str". I experimentally edited a GR 3.7 xml file and replaced "string" with "str", and the YAML converter inside GRC seems

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

unning some of my code on a 3.9 system, at the ATA/HCRO] On 10/6/20 22:34, Marcus D Leech wrote: The system I’m trying this on Is Python 3.8. I get no warnings at all, no exceptions. Nothing. It just silently screws the pooch. Sent from my iPhone On Oct 7, 2020, at 1:21 AM, Ron Economos

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

val = > self.blocks_multiply_const_vxx_0.set_k([1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1]) > AttributeError: 'gnuradio.blocks.blocks_python.multiply_const_vcc' object has > no attribute 'set_k' > > Ron > >> On 10/6/20 21:59, Marcus D Leech wrote: >> A vector is what I want and this

Re: multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

> > Ron > >> On 10/6/20 21:08, Marcus D. Leech wrote: >> This is an apparent problem in 3.9.0.0-git >> >> In grc, create a multiply_const with a vector size > 1 >> >> Have a function_probe block that sets the constant on a regular >> basis--p

multiply_vxx_const.set_k() in GR3.9 seems to be busticated?

This is an apparent problem in 3.9.0.0-git In grc, create a multiply_const with a vector size > 1 Have a function_probe block that sets the constant on a regular basis--perhaps from a variable, or a function call or the like. The constant will never be updated, even thought the

Re: USB communication

On 10/04/2020 01:06 PM, David Winter wrote: Hey, in case you were referring to the "Universal Serial Bus": The short answer: As far as I know, there is no _direct_ way of using "USB communication in gnuradio". Just as there is no direct way of, I dunno, manipulating the wires in a SCSI or

Older .grc files (3.7) at GRC 3.9

I've found a problem when pulling 3.7 grc files into GRC on 3.9. Command-line parameters of type "string" get converted into type "None", and thus don't end up as actual command-line parameters. Is there a tool for doing smooth transition, other than manually pulling in to GRC, turning those

Re: comparing scalar vs vector items

On 09/23/2020 04:09 AM, Ali G. Dezfuli wrote: Hi all, I'd like to compare two GR blocks in terms of performance (especially throughput) 1- using scalar items together with "set_output_multiple (int

<    1   2   3   4   5   6   7   8   9   10   >