Re: Phase Synchronize 2 USRP N200 w/ SBX cards
I repeated the experiments once again today and I got once again the same results. I still keep on randomly getting these 4 cases I attached on a previous message. I observed that cases 1.png and 3.png have a phase difference of +/- 180 degrees and cases 2.png and 4.png also have a phase difference 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 Konstantinos Sent: Friday, June 11, 2021 12:39 AM To: Marcus D. Leech Cc: Discuss-gnuradio@gnu.org Subject: Re: Phase Synchronize 2 USRP N200 w/ SBX cards Exactly my thoughts as well, I mean regarding the phase ambiguity of the WBX daughterboards, from what I've read on the Ettus website. I am 100% sure the daughterboards are SBX. On Jun 11, 2021 00:26, "Marcus D. Leech" wrote: 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 recurring phase offsets (Blue = RX2 of SBX1, Red = RX2 of SBX2). I am attaching the 4 screenshots I captured. Thank you so much for your help. I feel like we're getting there. You're sure that you have SBX cards and not WBX cards? Sorry for the apparently-stupid question, but the WBX uses almost the same hardware as the SBX, but uses a 2XLO mixer that has fixed phase ambiguity--which would look like what you have here.
Re: Phase Synchronize 2 USRP N200 w/ SBX cards
I have a query in to Ettus R&D about possible causes. But you might need, for now to do an initial phase Calibration when you start up. Sent from my iPhone > On Jun 11, 2021, at 3:39 AM, Skyvalakis Konstantinos > wrote: > > > I repeated the experiments once again today and I got once again the same > results. I still keep on randomly getting these 4 cases I attached on a > previous message. > > > > I observed that cases 1.png and 3.png have a phase difference of +/- 180 > degrees > > and cases 2.png and 4.png also have a phase difference 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 Konstantinos > Sent: Friday, June 11, 2021 12:39 AM > To: Marcus D. Leech > Cc: Discuss-gnuradio@gnu.org > Subject: Re: Phase Synchronize 2 USRP N200 w/ SBX cards > > Exactly my thoughts as well, I mean regarding the phase ambiguity of the WBX > daughterboards, from what I've read on the Ettus website. > > I am 100% sure the daughterboards are SBX. > > > On Jun 11, 2021 00:26, "Marcus D. Leech" wrote: > 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 recurring phase offsets > (Blue = RX2 of SBX1, Red = RX2 of SBX2). > > > > I am attaching the 4 screenshots I captured. > > > > Thank you so much for your help. I feel like we're getting there. > > > > > You're sure that you have SBX cards and not WBX cards? Sorry for the > apparently-stupid question, but the WBX uses almost the > same hardware as the SBX, but uses a 2XLO mixer that has fixed phase > ambiguity--which would look like what you have here. > > >
Mac Layer
Hi, so I have been wondering what people do to implement mac layer type things with GNURadio? (for example automatic detection/handshaking type protocols before transmitting digital data packets.) >From my perspective gnuradio is good for physical layer development, but less so for state machine type work of mac layer... Thanks, Nick
Re: GSoC'21 - View Only Mode
Hello everyone! I have now published the first blog post for my GSoC work on the GRC View-Only Mode. This week I have mainly worked at saving evaluated values of parameters in the grc-file. You can read about it here: https://oscekh.github.io/ I will be posting an update on the blog each Friday, with a corresponding announcement on this list. Best regards, Oscar Ekholm On Mon, May 24, 2021 at 11:19 AM Oscar Ekholm wrote: > Hello, > > I've been accepted to work with GnuRadio for this year's Google Summer of > Code. I will be working on implementing a GRC View-Only Mode, which is a > security feature disabling execution of block parameters in untrusted > flowgraphs. > > I will be posting weekly progress updates on my blog: > https://oscekh.github.io/ > > If you are interested in reading more about the View-Only mode it is > described further in my project proposal: > > https://docs.google.com/document/d/1dL6PziJSopcY3O7gJ6CXiedTSdbhrHVFhR-UJRTmsng/edit?usp=sharing > > Please reach out if you have any questions, advice or thoughts you want to > share. > > Best regards, > Oscar Ekholm >
Re: Mac Layer
Hi Nick, On 11.06.21 16:58, Nicholas Long wrote: > Hi, so I have been wondering what people do to implement mac layer type > things with GNURadio? > (for example automatic detection/handshaking type protocols before > transmitting digital > data packets.) Well, "we" (as in the community) have Basti Bloessl's gr-ieee802-11 project as an example on how to approach that. > From my perspective gnuradio is good for physical layer development, but less > so for state > machine type work of mac layer... Well, yes. Kind of. GNU Radio definitely is a physical layer thing. It doesn't give you any tools to develop MA controllers. But: MACs are different. Pretty different, in fact. As you say, the common denominator is "there's one or more state machines"; from there up, it's pretty variable. Now, what GNU Radio *does* give you is a flexible architecture to implement your physical receiver and transmitter, and a mechanism with which you can interchange messages with a controller. I think (and I'm not alone with that, there's work ongoing on new concepts in that space!) that we could do a bit better on the usefulness of that messaging system, but it does work. I think GNU Radio Companion as the visible front of the whole GNU Radio idea establishes the impression that GNU Radio is a generator for stand-alone *applications*; it's not. GNU Radio is a library, and the things you can create with it are *meant* to be used as the signal processing side of other applications. Look at the success gqrx has: It uses GNU Radio underneath, but none of its visualization blocks; satellite ground stations, video transceivers, radiosonde receivers, emergency beacons and a myriad of other very real-world applications are underpinned by GNU Radio. DARPA's spectrum challenge gave teams a development kit based on GNU Radio as a starting point, and its whole point was to demonstrate the ability to react to sudden interference and user constellation changes. All these things use different approaches, clearly. There's good reason to assume the project "should" have a goto MAC demo – but we don't. Too much to fiddle, probably. Best regards, Marcus
Re: Mac Layer
Hi Nick, You can take a look at the https://gitlab.com/marmote/gr-marmote3 repo as well. That has a custom waveform and custom MAC but it is a full fledged solution. The bare essentials (real time part) are kept in gnuradio, the rest is controlled from python using protocol buffers. Low latency buffer management is hard, but not impossible. Best, Miklos On Fri, Jun 11, 2021 at 10:42 PM Marcus Müller wrote: > Hi Nick, > > On 11.06.21 16:58, Nicholas Long wrote: > > Hi, so I have been wondering what people do to implement mac layer type > things with GNURadio? > > (for example automatic detection/handshaking type protocols before > transmitting digital > > data packets.) > > Well, "we" (as in the community) have Basti Bloessl's gr-ieee802-11 > project as an example > on how to approach that. > > > From my perspective gnuradio is good for physical layer development, but > less so for state > > machine type work of mac layer... > > Well, yes. Kind of. > GNU Radio definitely is a physical layer thing. It doesn't give you any > tools to develop > MA controllers. > But: MACs are different. Pretty different, in fact. As you say, the common > denominator is > "there's one or more state machines"; from there up, it's pretty variable. > > Now, what GNU Radio *does* give you is a flexible architecture to > implement your physical > receiver and transmitter, and a mechanism with which you can interchange > messages with a > controller. I think (and I'm not alone with that, there's work ongoing on > new concepts in > that space!) that we could do a bit better on the usefulness of that > messaging system, but > it does work. > > I think GNU Radio Companion as the visible front of the whole GNU Radio > idea establishes > the impression that GNU Radio is a generator for stand-alone > *applications*; it's not. GNU > Radio is a library, and the things you can create with it are *meant* to > be used as the > signal processing side of other applications. Look at the success gqrx > has: It uses GNU > Radio underneath, but none of its visualization blocks; satellite ground > stations, video > transceivers, radiosonde receivers, emergency beacons and a myriad of > other very > real-world applications are underpinned by GNU Radio. DARPA's spectrum > challenge gave > teams a development kit based on GNU Radio as a starting point, and its > whole point was to > demonstrate the ability to react to sudden interference and user > constellation changes. > > All these things use different approaches, clearly. There's good reason to > assume the > project "should" have a goto MAC demo – but we don't. Too much to fiddle, > probably. > > Best regards, > Marcus > >
