From josh at joshknows.com  Mon Dec  7 01:30:27 2015
From: josh at joshknows.com (Josh Blum)
Date: Sun, 6 Dec 2015 17:30:27 -0800
Subject: gr-osmosdr fixes for soapy support, and msvc
Message-ID: <5664E133.7030704@joshknows.com>

Hey list,

It looks like due to some GRC changes, the throw in 
set_iq_balance_mode() is no longer caught. Its causing a problem for GRC 
users and I would like upstream the fix. See soapy_support:

http://cgit.osmocom.org/gr-osmosdr/log/?h=soapy_support

I am building GNURadio and gr-osmosdr as part of my PothosSDR installer: 
https://github.com/pothosware/PothosSDR/wiki/GNURadio

There were a few minor fixes to make for the MSVC compiler. The commits 
have explanatory messages, and I made sure that they were non-breaking.
I would also like to upstream these fixes as well. See msvc_fixes:

http://cgit.osmocom.org/gr-osmosdr/log/?h=msvc_fixes

Thanks for your consideration,
-josh


From horiz0n at gmx.net  Mon Dec  7 19:50:39 2015
From: horiz0n at gmx.net (Dimitri Stolnikov)
Date: Mon, 07 Dec 2015 20:50:39 +0100
Subject: gr-osmosdr fixes for soapy support, and msvc
In-Reply-To: <5664E133.7030704@joshknows.com>
References: <5664E133.7030704@joshknows.com>
Message-ID: <op.x9ahep2evay7ep@wopr.artelis.net>

Hi Josh,

merged all 3. Thanks!

Best regards,
Dimitri

On Mon, 07 Dec 2015 02:30:27 +0100, Josh Blum <josh at joshknows.com> wrote:

> Hey list,
>
> It looks like due to some GRC changes, the throw in  
> set_iq_balance_mode() is no longer caught. Its causing a problem for GRC  
> users and I would like upstream the fix. See soapy_support:
>
> http://cgit.osmocom.org/gr-osmosdr/log/?h=soapy_support
>
> I am building GNURadio and gr-osmosdr as part of my PothosSDR installer:  
> https://github.com/pothosware/PothosSDR/wiki/GNURadio
>
> There were a few minor fixes to make for the MSVC compiler. The commits  
> have explanatory messages, and I made sure that they were non-breaking.
> I would also like to upstream these fixes as well. See msvc_fixes:
>
> http://cgit.osmocom.org/gr-osmosdr/log/?h=msvc_fixes
>
> Thanks for your consideration,
> -josh


From jmaurin at jonis.com.br  Tue Dec 29 00:26:22 2015
From: jmaurin at jonis.com.br (jmaurin at jonis.com.br)
Date: Mon, 28 Dec 2015 22:26:22 -0200
Subject: Cmd structure for rtl_tcp
Message-ID: <ba958b6a23e3e047178ecc38d107efca@jonis.com.br>

Hi List!

I'm new here, so I hope I'm asking for help in the right place. I'm 
trying to build and application that read I/Q data from rtl_tcp using 
Delphi. For beginning, I'm trying to set some params for rtl_tcp using 
my remote app. I found the source code of rtl_tcp and I could identify 
some information about what is each command, like 0x01 (hex) is to set 
frequency, 0x02 to set sample, etc....
What I don't undertand is the structure of parameters. Each parameter is 
one byte? If not, how parameters are sent? Do I need to send char to end 
command, like end of line or carrier return? Is not, what's the correct 
structure for sending commands?

For example:
For setting gain, send one byte with 0x04 and another byte indicating 
the gain index.


Tks!
Jonis Maurin Cear?


From staticfloat at gmail.com  Thu Dec 31 23:30:35 2015
From: staticfloat at gmail.com (Elliot Saba)
Date: Thu, 31 Dec 2015 15:30:35 -0800
Subject: gr-osmosdr broken on OSX due to MSG_NOSIGNAL
Message-ID: <CAGGi21YxbgP1MHqNhhL4KDw39-iPNJCk2uux6aJsnzm8R-wkxg@mail.gmail.com>

It looks like the block to redefine MSG_NOSIGNAL as SO_NOSIGPIPE inside of
redpitaya_common.cc needs to be copied into redpitaya_sinc_c.cc as well.
-E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20151231/7600e812/attachment.htm>

From staticfloat at gmail.com  Thu Dec 10 05:47:57 2015
From: staticfloat at gmail.com (Elliot Saba)
Date: Thu, 10 Dec 2015 05:47:57 -0000
Subject: Fixing gr-fosphor compilation
Message-ID: <CAGGi21ao1jH2p9v4WGbXY9G9_Wjfiiw872OM8jmxL7FO7A8cLQ@mail.gmail.com>

After pulling gr-fosphor `master` today and compiling against the latest
GNURadio, I noticed that it failed when attempting to link against
libgnuradio, due to missing pmt symbols.  The attached one-line patch fixes
the issue, but I imagine would break compilation against older GNURadio
releases.

If there is a better way for me to submit this patch, please let me know.
I had previously emailed one of the gr-fosphor developers with a separate
issue regarding libpng issues out of ignorance of this mailing list.  I
don't want to disturb you developers any more than need be, so if there is
a better forum than this for patches/pull requests, I am more than happy to
use it.
-E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20151210/98248d67/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gr-fosphor-pmt.patch
Type: application/octet-stream
Size: 487 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20151210/98248d67/attachment.obj>

From hoofdeigenwijs at gmail.com  Tue Dec 29 16:05:46 2015
From: hoofdeigenwijs at gmail.com (Ben Z en de rest)
Date: Tue, 29 Dec 2015 16:05:46 -0000
Subject: osmocom_fft won't tune BladeRF lower than 300MHz
Message-ID: <CACbGgOsKm7TE3+SXd=w7S+FxUA8m1BaapT2sAdHGDpjOgC4Ohg@mail.gmail.com>

Hi. Today I installed latest gr-osmosdr. I want to run osmocom_fft and view
the recorded file in "inspectrum".

Osmocom_fft starts, runs, knows there is a BladeRF available and does work.
only thing is that it does not allow tuning lower then 300 MHz as if the
transverterboard is unknown to the osmocom_fft.

I tried to start osmocom_fft with -a balderf but that does not help.

If I set it to for example 145M it gives this message:

Failed to set out of bound frequency: 1.45e+08

libbladerf is updated last weekend.

Any ideas on this ?

Thanks,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-sdr/attachments/20151229/774e6ed3/attachment.htm>