Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

On 07/05/2016 11:45 PM, Pavan Yedavalli wrote: Yes, sorry - two of them are actually connected via MIMO cable, with the master connected to the Octoclock. Then the other two are directly connected to the Octoclock. I used the MIMO cable just because I had it, but hopefully that's not changing

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

Yes, sorry - two of them are actually connected via MIMO cable, with the master connected to the Octoclock. Then the other two are directly connected to the Octoclock. I used the MIMO cable just because I had it, but hopefully that's not changing the functionality. Yes, I added even more

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

On 07/05/2016 09:45 PM, Pavan Yedavalli wrote: According to the spectrum analyzer, there's nothing being transmitted in the 900 MHz band around me, so that is actually fine. The biggest unknown could be what you are saying about how they combine in the RSSI circuit (which I'm not sure how it

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

On 07/05/2016 09:45 PM, Pavan Yedavalli wrote: According to the spectrum analyzer, there's nothing being transmitted in the 900 MHz band around me, so that is actually fine. The biggest unknown could be what you are saying about how they combine in the RSSI circuit (which I'm not sure how it

[Discuss-gnuradio] GNU Radio v3.7.10 and v3.7.9.3 releases are available

Hi all, GNU Radio v3.7.10 and v3.7.9.3 are available for download along with an updated live DVD environment. v3.7.10 is the latest of the 3.7 API series and includes several new features as well as all bug fixes to date including those in v3.7.9.3. The news item is available from the GNU Radio

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

According to the spectrum analyzer, there's nothing being transmitted in the 900 MHz band around me, so that is actually fine. The biggest unknown could be what you are saying about how they combine in the RSSI circuit (which I'm not sure how it works). I am not gaining any more insight when

[Discuss-gnuradio] VOLK v1.3 and v1.2.3 released

Hi all, This past weekend I released VOLK v1.3 and v1.2.3. I started using signed releases and a detached signature for release tarballs are available. For a record of releases and downloads see http://libvolk.org/releases.html For released notes on these releases see the tags in the git repo

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

On 07/05/2016 08:20 PM, Pavan Yedavalli wrote: I see, but the offset in phase between the two radios will affect the amplitude, right? That was the assumption I was using, since it gives out an amplitude reading, but the phase clearly will affect that reading, I presumed. Unfortunately, I

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

I see, but the offset in phase between the two radios will affect the amplitude, right? That was the assumption I was using, since it gives out an amplitude reading, but the phase clearly will affect that reading, I presumed. Unfortunately, I don't have any documentation on the RSSI circuit apart

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

On 07/05/2016 07:28 PM, Pavan Yedavalli wrote: The way I'm doing it is the following (please correct me if there is a fundamental error in assumptions): I am actually using an RSSI circuit that is receiving the power from the USRPs/antennas, and I'm determining whether the phase offset is the

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

The way I'm doing it is the following (please correct me if there is a fundamental error in assumptions): I am actually using an RSSI circuit that is receiving the power from the USRPs/antennas, and I'm determining whether the phase offset is the same based on that RSSI value. For example, I run

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

On 07/05/2016 06:47 PM, Pavan Yedavalli wrote: Hi Marcus, Thanks for the background. That helps greatly. Having said that, I am unclear which commands specifically tune the radios, so I did the following around the frequency tuning (after all of the time source, gain, and antenna setting

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

Hi Marcus, Thanks for the background. That helps greatly. Having said that, I am unclear which commands specifically tune the radios, so I did the following around the frequency tuning (after all of the time source, gain, and antenna setting code): addr_string =

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

That is precisely what I'm saying, and precisely what timed-commands for tuning were invented. On certain hardware, after the tune is complete, a phase-reset pulse is sent by the FPGA. The only way for THAT to have the desired effect is to make sure that the phase-reset pulse happens at the same

Re: [Discuss-gnuradio] new user

Hi Darin - If you want to use SDRplay, you -can- do that using MacPorts via the gr-osmosdr port: with a patch that I can provide. The SDRplay folks, at least in the recent past: (1) provide only pre-combined binaries, not source code, which need to be tweaked to work for most OS X installs

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

I am using USRP N210 with SBX daughterboards. All devices are connected to the octoclock ref and octoclock PPS. It would be nice to get phase alignment, but mere coherence-with-an-offset is sufficient if that offset stays constant across different runs of the file/flowgraph. Are you saying that

Re: [Discuss-gnuradio] new user

Thank you all. I will try again tonight. Initially I was trying to get SDRplay to work so followed the flow suggested in various sites for that but they didn't work and I may have messed something around that prevented a clean install of GNU Radio. > On Jul 5, 2016, at 1:33 PM, Michael

Re: [Discuss-gnuradio] random phase offset constantly changing with octoclock setup

WHat specific hardware line-up do you have? You have to use set_time_unknown_pps(), but also, if you want phase alignment (as opposed to mere coherence-with-an-offset), you need to use timed tuning commands across your systems. This will result in zero relative phase offset between boards, if

[Discuss-gnuradio] random phase offset constantly changing with octoclock setup

Hi, Despite all of my boards being connected via the Octoclock (ref and pps), I am constantly getting different phase offsets every time I run a gnuradio flowgraph (or python file). I am not sure why this is happening, but I do know that I need to call one of the functions, set_time_now() and/or

Re: [Discuss-gnuradio] new user

I think if you follow the install guide for Mac OS X, GR will work almost out of the box. As stated, there are cases where some dependencies fail to build or the like; just "clean" the failed dependency, try to install it directly, and it usually works. Most dependencies are a binary download now;

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

The installer that you used to install GNU RADIO *includes* UHD. You now have newer UHD interspersed with the version that came bundled with your GnuRadio install. On 2016-07-05 11:33, Sanat Kumar Mishra wrote: > UHD 3.9.36 is the latestv version of USRP Hardware Driver available. If I >

Re: [Discuss-gnuradio] new user

On 07/04/2016 07:52 AM, Darin Decker wrote: > Good morning, I have been trying to get Gnuradio up and and running all > weekend on either a Macbook Pro or a System 76 Ubuntu 12.04 machine but have > not had any success. If I understand correctly, Ubuntu 12.04 is not > supported so I have not

Re: [Discuss-gnuradio] new user

I installed GNURadio using brew (http://brew.sh). Its as simples as: brew install gnuradio I recommend trying it as a ‘package manager’ instead of MacPorts. Best regards, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org

Re: [Discuss-gnuradio] SWIG Errors

Sylvain, That sounds exactly like what was happening to me! Thank you :D -Dave On Tue, Jul 5, 2016 at 9:20 AM, Sylvain Munaut <246...@gmail.com> wrote: > See the thread : > > "The AttributeError problem now that I have modified a working OOT" > > My guess is that you encountered

Re: [Discuss-gnuradio] Dynamic custom bloc parameter

Note that it's generally possible to just implement a setter function and define a in the GRC XML, but then you would have to care about thread safety yourself... And having an asynchronous message passing interface is nice, anyway :) Best regards Marcus Am 5. Juli 2016 15:57:04 MESZ,

Re: [Discuss-gnuradio] UHD FW Issue for NI USRP 2943R

The windows installer from that site seems to have been linked against UHD 3.9.3, which is why the mismatch. There was no reason to have separately installed UHD, since UHD is listed as a package that is bundled into the installer. I would remove the 3.9.4 UHD you have if you plan to use Gnu

Re: [Discuss-gnuradio] new user

Hi Darin: Just chiming in. I use MacPorts, it works really well. There is the occasional build error if the MacPorts folks are behind gnuradio developments a bit, but generally there are no problems. I use Ubuntu for my main gnuradio machine. The RTL dongles are good and quite versatile.

Re: [Discuss-gnuradio] Dynamic custom bloc parameter

On 2016-07-05 14:42, Marcus Müller wrote: Hi, I'd generally recommend that you add a message handler to your block, which can be connected via message passing to other blocks. That way, you'll have something that is thread-safe (which is necessary, because Great ! thanks a lot Marcus :) I saw

Re: [Discuss-gnuradio] SWIG Errors

See the thread : "The AttributeError problem now that I have modified a working OOT" My guess is that you encountered something similar. So the SWIG process went fine and without any error, but if the .so that was generated from your C++ code can't be loaded because of undefined symbols, then

Re: [Discuss-gnuradio] SWIG Errors

Well poop. I can't remember what was causing the issues (it was about a month ago). If I run across it again I'll copy off the code before fixing it so that I can show it here. On Sun, Jul 3, 2016 at 5:59 PM, Dave NotTelling wrote: > Sylvain, > > I'll attempt to gin

Re: [Discuss-gnuradio] Dynamic custom bloc parameter

Hi, I'd generally recommend that you add a message handler to your block, which can be connected via message passing to other blocks. That way, you'll have something that is thread-safe (which is necessary, because your xmlrpc server will run in another thread than your block's 'work' method).

Re: [Discuss-gnuradio] new user

Much appreciated Mark. Yeah, I've seen screen prints and videos and agree it looks amazing. I'll follow the MacPorts path as you suggest. Eighth now it is getting stuck with the xterm comment and then saying no osmosdr so will work on resolving those first. > On Jul 4, 2016, at 7:51 PM,

[Discuss-gnuradio] Dynamic custom bloc parameter

Hi everybody, I would like to know how a parameter can be updated during the execution of a custom C++ block (I have some data to change during the execution of the flowgraph with XMLRPC). Do someone already did it ? :) Thanks in advance ! Best regards, -JM