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 t
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 attenuati
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 wo
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 wo
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 w
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 using
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 or
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 don
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
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 s
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
th
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 code
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 = "addr0=192.168.10.3,addr1=
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 i
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 includi
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
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 Dickens
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 you
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
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;
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
> unin
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 pu
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
https://lists.gnu.org/m
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 something
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, schrieb
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 Radi
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.
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
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 th
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 something up tomorrow.
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).
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, Mark
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
33 matches
Mail list logo
