Getting OOT's to run in GRC
Hello list, I have been unable to get any OOT module blocks to run in GRC. I initially was using a VirtualBox Manjaro (via Architect) with GNURadio 3.9 and with some finding missing packages (cmake, swig, boost, boost-libs maybe some others Ive forgotten) was able to get gr_modtool created blocks to compile and link and install with no error messages. The blocks pull in gr-fft and (for the lfsr stuff) gr-digital. There is a source block, a general block, and a couple noblock utility classes in the custom OOT module. But when I attempt to run a flowgraph containing these OOT blocks in GRC I get the "module attribute error module has no component block" (sic). I followed some hints I researched for adding a conf file to ld.so.d to add /usr/local/lib and did that and restarted my system to take effect then did ldconfig. But no change in result. Being unsure of all the things that may be misconfigured I decided to try a VirtualBox Ubuntu LTS with (aside from gcc make perl for the vbox guest additions) only the gnuradio ppa installed. My first attempt was with 3.9 via the master branch using the basic instructions (3 cli commands) at the top of https://wiki.gnuradio.org/index.php/UbuntuInstall then recreating my OOT module with gr_modtool. But gr_modtool couldn't do newmod because of some missing template or some such which seems to still be a problem. So I made a new Ubuntu LTS VM and tried to use the ppa for gnuradio 3.7 but discovered there are no sources in that ppa so it would not install. Finally I remembered Goldilocks and the Three Bears and tried yet another VM with the ppa for gnuradio 3.8 hoping it would be just right. With this I was able to use gr_modtool to set up the OOT module and add the blocks, copy my C++ code over, and do the compile, link, install, ldconfig. But on this system running a flowgraph in GRC containing blocks from the OOT I get the "no module named module" (sic) import error where it can't even find the entire OOT module. I found one suggested fix with some path variables which did seem useful (both the PYTHONPATH and LD_something_blah_blah paths were empty). But taking the steps to temporarily fix the paths did not remedy the error message. I don't understand a lot about python or the inner workings of the C++ cmake build system set up by gr_modtool. Way back in the day I managed to build gnuradio on some Fedora boxes using the build-gnuradio script and gnuradio 3.7.something and gr_modtool and with probably headaches I don't remember anymore managed to get custom OOT module blocks on those machines up and running pretty well. But I'm stumped now. My preference is to get this to work in Manjaro (current with linux 5.10.something), but if that can't be done then getting it to work in Ubuntu LTS (20.04 or if an older LTS version works better let me know) will have to do. Would someone give me some ideas to try? Many thanks, John
Re: Phase Synchronize 2 USRP N200 w/ SBX cards
Agreed. The compensation part is not the one I worry about. What worries me the most is the angle-in-radians part. Let's say that from the time sink plot I observe that I have pi/2 radians phase offset between channel 1 and channel 2. How do I know it's pi/2 radians and not -3pi/2? To be precise, I am also dumping the 2 channels complex data to 2 file sinks, which I then import on matlab for easier and faster experimentation. In other words, how can I precisely calculate the 4 discrete phase shifts I am observing in my application? Should I use cross correlation? Should I use Hilbert transform? I don't have a very noisy application, in case that plays a very crucial role. Thanks. On Jun 13, 2021 22:06, Marcus D Leech wrote: Phase *correction* is easy once you know what that correction should be. Just a complex multiply-const by Complex(math.cos(angle-in-radians),math.sin(angle-in-radians)) Or the equivalent in complex exponential notation. Sent from my iPhone On Jun 13, 2021, at 1:52 PM, Skyvalakis Konstantinos wrote: Understandable. However, if you eventually hear anything about it please let me know. Can I contact you again tomorrow for some questions I have about the phase correction block I need to make? (I mean through discuss-gnuradio) Thank you very much. On Jun 13, 2021 19:37, Marcus D Leech wrote: I haven’t heard fro R&D on it. Part of the problem is the N200 was designed over a decade ago, and the original engineering team have long since departed… Sent from my iPhone On Jun 13, 2021, at 6:25 AM, Skyvalakis Konstantinos wrote: Hi Marcus and sorry for bothering you again, but I'd like to ask if you have any news regarding my problem. Thank you. On Jun 11, 2021 16:15, Skyvalakis Konstantinos wrote: Yes it kind of helps, because if I manage to apply a phase shifting/correction technique, then all 4 scenarios could produce sensible data. I am trying to build a phase correction block now, that will compare the 2 received signals, to see which phase shift out of the possible 4, minimizes the absolute phase difference between the 2 channels. After I figure out which phase offset is the correct one, out of all 4, then I can run the rest of my DoA application. It is a bit of a pain in the a**, but it will have to do in case it never gets fixed. Let me know if you have any news from Ettus. Thanks again. From: Marcus D Leech Sent: Friday, June 11, 2021 4:05 PM To: Skyvalakis Konstantinos Subject: Re: Phase Synchronize 2 USRP N200 w/ SBX cards Also does knowing that there are only 4 possible phase relationships help in your application at all? Like only one of the 4 possible phase assumptions can produce “sensible” data? Just a thought. Sent from my iPhone On Jun 11, 2021, at 9:03 AM, Marcus D Leech wrote: I am an Ettus support contractor. I have a direct channel to R&D so I will relay any insights I receive here since any such feedback would be generally useful. Sent from my iPhone On Jun 11, 2021, at 8:15 AM, Skyvalakis Konstantinos wrote: I also tried contacting Ettus Support but they are not replying to my e-mails. I will try to implement the phase calibration for now. Thank you for your effort. From: Marcus D Leech Sent: Friday, June 11, 2021 2:23 PM To: Skyvalakis Konstantinos Cc: Discuss-gnuradio@gnu.org Subject: 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 o
Re: Phase Synchronize 2 USRP N200 w/ SBX cards
On 06/13/2021 04:02 PM, Skyvalakis Konstantinos wrote: Agreed. The compensation part is not the one I worry about. What worries me the most is the angle-in-radians part. Let's say that from the time sink plot I observe that I have pi/2 radians phase offset between channel 1 and channel 2. How do I know it's pi/2 radians and not -3pi/2? To be precise, I am also dumping the 2 channels complex data to 2 file sinks, which I then import on matlab for easier and faster experimentation. In other words, how can I precisely calculate the 4 discrete phase shifts I am observing in my application? Should I use cross correlation? Should I use Hilbert transform? I don't have a very noisy application, in case that plays a very crucial role. Thanks. If you consult the "uhd_fft" app within the gnuradio/gr-uhd source tree, you'll see that it has a mode where it will display the relative phases of two channels when you have a two-channel input. It also has a bunch of different synchronization options, so you can glean a lot of technique info from that. Also, there's a fair amount of "stuff" out there on phase measurements with Gnu Radio--this is 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 correction should be. Just a complex multiply-const by Complex(math.cos(angle-in-radians),math.sin(angle-in-radians)) Or the equivalent in complex exponential notation. Sent from my iPhone On Jun 13, 2021, at 1:52 PM, Skyvalakis Konstantinos wrote: Understandable. However, if you eventually hear anything about it please let me know. Can I contact you again tomorrow for some questions I have about the phase correction block I need to make? (I mean through discuss-gnuradio) Thank you very much. On Jun 13, 2021 19:37, Marcus D Leech wrote: I haven’t heard fro R&D on it. Part of the problem is the N200 was designed over a decade ago, and the original engineering team have long since departed… Sent from my iPhone On Jun 13, 2021, at 6:25 AM, Skyvalakis Konstantinos wrote: Hi Marcus and sorry for bothering you again, but I'd like to ask if you have any news regarding my problem. Thank you. On Jun 11, 2021 16:15, Skyvalakis Konstantinos wrote: Yes it kind of helps, because if I manage to apply a phase shifting/correction technique, then all 4 scenarios could produce sensible data. I am trying to build a phase correction block now, that will compare the 2 received signals, to see which phase shift out of the possible 4, minimizes the absolute phase difference between the 2 channels. After I figure out which phase offset is the correct one, out of all 4, then I can run the rest of my DoA application. It is a bit of a pain in the a**, but it will have to do in case it never gets fixed. Let me know if you have any news from Ettus. Thanks again. *From:* Marcus D Leech *Sent:* Friday, June 11, 2021 4:05 PM *To:* Skyvalakis Konstantinos *Subject:* Re: Phase Synchronize 2 USRP N200 w/ SBX cards Also does knowing that there are only 4 possible phase relationships help in your application at all? Like only one of the 4 possible phase assumptions can produce “sensible” data? Just a thought. Sent from my iPhone On Jun 11, 2021, at 9:03 AM, Marcus D Leech wrote: I am an Ettus support contractor. I have a direct channel to R&D so I will relay any insights I receive here since any such feedback would be generally useful. Sent from my iPhone On Jun 11, 2021, at 8:15 AM, Skyvalakis Konstantinos wrote: I also tried contacting Ettus Support but they are not replying to my e-mails. I will try to implement the phase calibration for now. Thank you for your effort. *From:* Marcus D Leech *Sent:* Friday, June 11, 2021 2:23 PM *To:* Skyvalakis Konstantinos *Cc:* Discu
Re: Phase Synchronize 2 USRP N200 w/ SBX cards
For what it is worth, slide 10 of https://archive.fosdem.org/2020/schedule/event/fsr_software_defined_radio_based_scientific_instrumentation/attachments/slides/3895/export/events/attachments/fsr_software_defined_radio_based_scientific_instrumentation/slides/3895/fosdem2020_instrumentation.pdf shows how phase between two inputs of a B210 is measured as the ratio of the FFT (Aexp(jwt+phi1)/Aexp(jwt+phi2)~exp(j(phi1-phi2) even if a LO offset w remains, here with respect to an exteral acousto-optical modulator oscillator) and I have hidden from that discussion the need to heterodyne digitally the signal using a Xlating FIR for weak signals as shown on slide 24 of http://jmfriedt.free.fr/ifcs2021_tutorial.pdf That would be most convenient for CW signals as illustrated on slide 17 of that same presentation, otherwise phase of the cross correlation indeed for broadband signals (slide 10 only shows the magnitude but replace Complex to Mag with Complex to Arg), JM > On 06/13/2021 04:02 PM, Skyvalakis Konstantinos wrote: > > Agreed. The compensation part is not the one I worry about. What > > worries me the most is the angle-in-radians part. > > > > Let's say that from the time sink plot I observe that I have pi/2 > > radians phase offset between channel 1 and channel 2. How do I know > > it's pi/2 radians and not -3pi/2? > > > > To be precise, I am also dumping the 2 channels complex data to 2 > > file sinks, which I then import on matlab for easier and faster > > experimentation. > > > > In other words, how can I precisely calculate the 4 discrete phase > > shifts I am observing in my application? > > > > Should I use cross correlation? > > > > Should I use Hilbert transform? > > > > I don't have a very noisy application, in case that plays a very > > crucial role. > > > > Thanks. > If you consult the "uhd_fft" app within the gnuradio/gr-uhd source > tree, you'll see that it has a mode where it will display the >relative phases of two channels when you have a two-channel input. > It also has a bunch of different synchronization options, >so you can glean a lot of technique info from that. > > Also, there's a fair amount of "stuff" out there on phase > measurements with Gnu Radio--this is 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 correction > > should be. Just a complex multiply-const by > > > > Complex(math.cos(angle-in-radians),math.sin(angle-in-radians)) > > > > Or the equivalent in complex exponential notation. > > > > > > > > Sent from my iPhone > > > > On Jun 13, 2021, at 1:52 PM, Skyvalakis Konstantinos > > wrote: > > > > > > Understandable. However, if you eventually hear anything > > about it please let me know. > > > > Can I contact you again tomorrow for some questions I have > > about the phase correction block I need to make? (I mean > > through discuss-gnuradio) > > > > Thank you very much. > > > > On Jun 13, 2021 19:37, Marcus D Leech > > wrote: > > I haven’t heard fro R&D on it. Part of the problem is the > > N200 was designed over a decade ago, and the original engineering > > team have long since departed… > > > > Sent from my iPhone > > > > On Jun 13, 2021, at 6:25 AM, Skyvalakis Konstantinos > > wrote: > > > > > > Hi Marcus and sorry for bothering you again, but I'd > > like to ask if you have any news regarding my problem. > > > > Thank you. > > > > On Jun 11, 2021 16:15, Skyvalakis Konstantinos > > wrote: > > > > Yes it kind of helps, because if I manage to apply a > > phase shifting/correction technique, then all 4 > > scenarios could produce sensible data. > > > > > > I am trying to build a phase correction block now, that > > will compare the 2 received signals, to see which phase > > shift out of the possible 4, minimizes the absolute > > phase difference between the 2 channels. > > > > > > After I figure out which phase offset is the correct > > one, out of all 4, then I can run the rest of my > > DoA application. It is a bit of a pain in the a**, but > > it will have to do in case it never gets fixed. > > > > > > Let me know if you have any news from Ettus. > > > > > > Thanks again. > > > > > > > > > > *From:* Marcus D Leech > > *Sent:* Friday, June 11, 2021 4:05 PM > > *To:* Skyvalakis Konstantinos > > *Subject:* Re: Phase Synchronize 2 USRP N2
