Hi,
It is not as bad as it sounds, but almost 
With building the last “master” on a 32bit Kubuntu 12.04 none of my grc
files work. They are all with analog stuff, FM TX and RX stuff with
USRP1 as
transceiver, some RTL2832 receivers.
Is it possible that old grc files do not work, although the blocks are
shown? I had a simple TX transmitter, cosinus source, NBFM TX, USRP,
three
blocks, and the “old” grc file threw an error “module object has no
attribute channel_model” when running it. When I took the very same
blocks
from the blocks menu and assembled the same thing together once again,
it
transmitted a sine tone at 1.8GHz as it should.
Not so much luck I had with RTL2832 receivers, with WX GUI FFT and
waterfall
I assume I am doing smth. wrong, I can’t imagine that these problems are
normal
My last installation came from Marcus’ build script, throwing gr-baz,
grextras, gr-osmosdr and other stuff into my system. So after restoring
a
backup of the old functional system (with all the stuff) at the moment I
am
doing a clean uninstall of last gnuradio and the accompanying stuff,
then a
complete new build of latest master, to see what is happening. The build
will take about one hour, some time to drink coffee and wait…
Ralph.
On Tue, May 28, 2013 at 2:21 AM, Ralph A. Schmid, dk5ras
[email protected] wrote:
blocks, and the “old” grc file threw an error “module object has no
attribute channel_model” when running it. When I took the very same blocks
from the blocks menu and assembled the same thing together once again, it
transmitted a sine tone at 1.8GHz as it should.
Ralph,
Yes, we made the big move the other day towards the 3.7.0 release.
Basically, we made next into master, so master is tracking the 3.7 API
branch now. You should have noticed the ~1100 updates when you pulled
master.
All blocks and code that come with GNU Radio should work fine (we’re
bug testing, so reports on bugs in out blocks are welcome). So
anything you have that uses only GNU Radio blocks should update fine,
as long as updated any of the ‘old’ blocks with the newer ones.
Not so much luck I had with RTL2832 receivers, with WX GUI FFT and waterfall
I assume I am doing smth. wrong, I can’t imagine that these problems are
normal 
I just sent another message to the listserv about this. All external
GNU Radio projects must be updated to work with the 3.7 API. I’ve
already started this with gr-osmosdr, including the interface to
RTL-SDR. See the gr-next branch on this repo:
My last installation came from Marcus’ build script, throwing gr-baz,
grextras, gr-osmosdr and other stuff into my system. So after restoring a
backup of the old functional system (with all the stuff) at the moment I am
doing a clean uninstall of last gnuradio and the accompanying stuff, then a
complete new build of latest master, to see what is happening. The build
will take about one hour, some time to drink coffee and wait…
Ralph.
Why does it take an hour to build? Can’t you run a parallel make? Even
using -j2 should cut the time down to about half that.
Tom
Hi,
Yes, we made the big move the other day towards the 3.7.0 release.
Basically, we made next into master, so master is tracking the 3.7 API
branch
now. You should have noticed the ~1100 updates when you pulled master.
Yes, of course.
All blocks and code that come with GNU Radio should work fine (we’re bug
testing, so reports on bugs in out blocks are welcome). So anything you
have
that uses only GNU Radio blocks should update fine, as long as updated any
of the ‘old’ blocks with the newer ones.
This is exactly what I have found out now; I had a mixture of blocks on
my
system from different sources, most came with Marcus’ build script.
Cleaning
up there makes things a lot clearer to me.
I just sent another message to the listserv about this. All external GNU
Radio
Seen…
projects must be updated to work with the 3.7 API. I’ve already started
this
with gr-osmosdr, including the interface to RTL-SDR. See the gr-next
branch
on this repo:
GitHub - trondeau/gr-osmosdr
…and right now build in process.
Why does it take an hour to build? Can’t you run a parallel make? Even
using -
j2 should cut the time down to about half that.
Just an estimation, maybe it is less after the last changes, but I am
using
a relative slow C2D machine, 1.6 GHz. For normal usage fast enough due
to
the SSD, but of course number crunching (compiling, “SDRing”) takes
longer
Should be 30-45 minutes even with -j2.
Ralph.
Tom
Hi,
The up-to-date version of build-gnuradio has, for a couple of weeks, been
tweaked so that by default it pulls “maint”, which I believe should
now correspond to the 3.6.5 release. So “old stuff” should still work
if
you’re purely using build-gnuradio. It now has a “-m” option to
force it to pull “master”, but by default, it now pulls “maint”.
This at least is interesting to know! The stuff I do is more basic
stuff, so
I see no problem in using 3.7 for it. Such problems always sharpen my
understanding for “how stuff works” 
After having discovered the
mixture
of blocks it was easy to sort things out.
–
Marcus L.
Ralph.
On 05/28/2013 05:59 AM, Ralph A. Schmid, dk5ras wrote:
Hi,
Yes, we made the big move the other day towards the 3.7.0 release.
Basically, we made next into master, so master is tracking the 3.7 API
branch
The up-to-date version of build-gnuradio has, for a couple of weeks,
been tweaked so that by default it pulls “maint”, which I believe should
now correspond to the 3.6.5 release. So “old stuff” should still
work if you’re purely using build-gnuradio. It now has a “-m” option to
force it to pull “master”, but by default, it now pulls “maint”.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
As my email said, this branch only currently supports the RTL-SDR and
HackRF
interfaces. I haven’t tried to update the interface to the osmosdr
library,
which is what you are seeing. I think you can use -DENABLE_OSMOSDR=False
to turn this off. But then, you’ll only be able to use the RTL-SDR source
in
GRC; not the more generic osmosdr source.
Ah, OK, great. This is exactly what I need, so I will give it a
try…and it
works.
Tom
Ralph.
On Tue, May 28, 2013 at 5:59 AM, Ralph A. Schmid, dk5ras
[email protected] wrote:
testing, so reports on bugs in out blocks are welcome). So anything you
…and right now build in process.
Ralph.
Tom
As my email said, this branch only currently supports the RTL-SDR and
HackRF interfaces. I haven’t tried to update the interface to the
osmosdr library, which is what you are seeing. I think you can use
-DENABLE_OSMOSDR=False to turn this off. But then, you’ll only be able
to use the RTL-SDR source in GRC; not the more generic osmosdr source.
I mostly did this branch for myself, as I wanted to be able to play
around and test things out. I pushed it publicly since I figured it
would be useful to others. But it’s certainly not complete nor meant
to be. So if anyone wants to help improve it for other hardware
interfaces, send me a pull request!
Tom