Forum: GNU Radio grGPS Preliminary Schematic

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
David Bengtson (Guest)
on 2006-04-06 05:21
(Received via mailing list)
After far to long, I've updated the information on the Gnu Radio GPS
board. I've finished a preliminary schematic, and I'd appreciate any
comments that anyone might have.

Page:
http://www.keystoneradio.com/grGPS.html

Schematic

http://www.keystoneradio.com/pdfs/Schematic_1.pdf

Thanks


Dave
Lee P. (Guest)
on 2006-04-06 05:55
(Received via mailing list)
Is there an inherent problem with using the DBS Rx?  I think this
discussion started once, but I can't find it in the archives.

Has any one successfully captured GPS and processed out position
information using GNU Radio and USRP?  I remember Krys Kamieniecki was
working on it, but last I remember, his code worked on some data files,
but he couldn't capture with DBS Rx.
Martin D. (Guest)
on 2006-04-06 07:47
(Received via mailing list)
David Bengtson wrote:
> After far to long, I've updated the information on the Gnu Radio GPS
> board. I've finished a preliminary schematic, and I'd appreciate any
> comments that anyone might have.
Why don't you use the usrp to generate your 16.384 or 32.768 MHz
refclock.
Most daugterboards (except the tvrx) use this feature (They all use a
4Mhz refclock on io pin 0.
The only difference with your design is that you need another frequency.
The cyclone fpga in the usrp has internal PLLs which can generate all
kinds of frequencies.
(They are not used at the moment)

This way you would have a phase coherent system.
Which is very nice if you start to play with multiple gps
daughterboards.

You could then even play with modifying the refclock frequency to
receive other frequencies.
(like the russian or the european GPS-like systems, which are on
frequencies near the GPS frequency)

Greetings,
Martin
Daniel O'Connor (Guest)
on 2006-04-06 08:52
(Received via mailing list)
On Thursday 06 April 2006 13:14, Martin D. wrote:
> other frequencies. (like the russian or the european GPS-like systems,
> which are on frequencies near the GPS frequency)

Farnell sell 32.768 MHz crystals (They're not what you'd call cheap
though -
AU$17). Hmm they have 16.384 MHz ones for $12.81. Still not cheap..

Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty
difficult (if not impossible)
Marcus L. (Guest)
on 2006-04-06 09:43
(Received via mailing list)
> Farnell sell 32.768 MHz crystals (They're not what you'd call cheap though -
> AU$17). Hmm they have 16.384 MHz ones for $12.81. Still not cheap..
>
> Also, I think getting 32.768 MHz from 4Mhz with a PLL would be pretty
> difficult (if not impossible)
>
>
Given that you haven't looked into the PLLs on the FPGA, it's rather too
early
  to conclude that you couldn't synthesize 32.768Mhz from the 4Mhz
reference
  clock that's already on the USRP.

Given reasonable dividers for both reference and VFO, I can't see why
synthesizing
  32.768Mhz would be all that difficult.  I can understand why you might
want to
  use a dedicated oscillator--you don't have to muck with the FPGA.
But asserting that
  it's "difficult (if not impossible)" is hard to support if you haven't
looked into it.
Daniel O'Connor (Guest)
on 2006-04-06 10:41
(Received via mailing list)
On Thursday 06 April 2006 15:11, Marcus L. wrote:
> want to
>   use a dedicated oscillator--you don't have to muck with the FPGA.
> But asserting that
>   it's "difficult (if not impossible)" is hard to support if you haven't
> looked into it.

According to the datasheet the PLL can only do m/n where m is between 1
and 32
and n is between 1 and 4.

Therefore I don't see how it's possible. I was only guessing before, but
I
just checked the datasheet and it seems impossible.

You could get close with a Stratix II.. 4 * 498/62 = 32.129 MHz

Whereas a Cyclone can only do m/n where m is 1 to 32 and n is 1 to 4.
David Bengtson (Guest)
on 2006-04-06 14:21
(Received via mailing list)
Martin D. wrote:
> David Bengtson wrote:
>> After far to long, I've updated the information on the Gnu Radio GPS
>> board. I've finished a preliminary schematic, and I'd appreciate any
>> comments that anyone might have.
> Why don't you use the usrp to generate your 16.384 or 32.768 MHz refclock.
> Most daugterboards (except the tvrx) use this feature (They all use a 4Mhz refclock on 
io pin 0.
> The only difference with your design is that you need another frequency.
> The cyclone fpga in the usrp has internal PLLs which can generate all kinds of 
frequencies.
> (They are not used at the moment)
>

(Sorry, there is a typo, the reference frequencies are 16.368/32.736
MHz)
That might work. 16.368 MHz/4 MHz is 1023/250, or a comparison frequency
of 16 kHz. From a frequency generation point of view, I could probably
get the right frequency from the USRP. I'm concerned about jitter and
noise on that line though. The reference is used directly for the
comparison frequency in the on-chip PLL, to generate a LO that is
1571.328 MHz. A 16 kHz spurious on this would really cause problems.

Because of this, I'd like to use a a clean reference clock for the
reference. I could change the layout to bring a signal over from the
connector to the reference input to check that though.  That would make
it possible to try this approach.

Re-Using the reference clock is why I brought the buffered clock signal
over to the connector, so that it will be available to the FPGA.

Dave
Clark P. (Guest)
on 2006-04-06 16:25
(Received via mailing list)
I guess I missed the answer to why you can't do GPS with the DBS board?
It
has the hooks to apply power to the antenna and it certainly has the
bandwidth and tuning range. If you're concerned about having a nice
clock
rate to make the despreading easier you can replace the oscillator on
your
USRP with a 32.768MHz oscillator, for example. (I'm in the process of
switching mine to 44 MHz ro make wlan easier.)

-Clark


>>>After far to long, I've updated the information on the Gnu Radio GPS
>
>connector to the reference input to check that though.  That would make it
>removed_email_address@domain.invalid
>http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's
FREE!
http://messenger.msn.click-url.com/go/onm00200471a...
Marcus L. (Guest)
on 2006-04-06 17:20
(Received via mailing list)
Daniel O'Connor wrote:
>
Well, that blows my "reasonable dividers" theory to flinders, then :-)
Robert W McGwier (Guest)
on 2006-04-06 18:41
(Received via mailing list)
David Bengtson wrote:
>
> (Sorry, there is a typo, the reference frequencies are 16.368/32.736 MHz)
> That might work. 16.368 MHz/4 MHz is 1023/250, or a comparison
> frequency of 16 kHz. From a frequency generation point of view, I
> could probably get the right frequency from the USRP
> I'm concerned about jitter and noise on that line though. The
> reference is used directly for the comparison frequency in the on-chip
> PLL, to generate a LO that is 1571.328 MHz. A 16 kHz
The generation of 1571.328 from this source is almost surely a deal
killer because of the phase noise.   That LO must be accurate, stable,
and as phase noise free as possible.  We are trying to work with a
signal of only a few dB dynamic range signal and it is weak, right at
the noise floor in most systems.  Cascaded LNA's will bring the signal
up but also lower the IP3 and the dynamic range and greatly increase the
front end susceptibility to overload, interference, and collapse.  This
particular oscillator and the attendant mixer cannot be scrimped on.  At
least do a serious noise budget analysis to make sure the system will
actually be usable after built.

> Dave
>


--
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
Berndt Josef W. (Guest)
on 2006-04-07 02:22
(Received via mailing list)
G'day,

gr-audio-oss segfaults when built using the gr-audio-oss-0.8.tar.gz
tarball.
The reason for this is that the tarball includes audio_oss.cc which
normally
is created by swig. Consequently, the interfaces created in this file
may not
be correct for the  every target system. I guess this was overlooked
during
the  creation of the tarball.

It would be nice if we can create a new tarball e.g
gr-audio-oss-0.8.1.tar.gz
that excludes this file. I believe that package maintainers would
appreciate
this.

cheerio Berndt
Eric B. (Guest)
on 2006-04-07 02:31
(Received via mailing list)
On Fri, Apr 07, 2006 at 07:50:53AM +0930, Berndt Josef W. wrote:
> this.
>
> cheerio Berndt


Thanks for the problem report and the solution.

Will fix soon.

Eric
David Bengtson (Guest)
on 2006-04-07 02:43
(Received via mailing list)
Robert W McGwier wrote:
>> (Sorry, there is a typo, the reference frequencies are
> right at the noise floor in most systems.  Cascaded LNA's will bring
> the signal up but also lower the IP3 and the dynamic range and
> greatly increase the front end susceptibility to overload,
> interference, and collapse.  This particular oscillator and the
> attendant mixer cannot be scrimped on.  At least do a serious noise
> budget analysis to make sure the system will actually be usable after
> built.
>

I'm aware that this is a very weak signal system, which is why I'm
concerned about the phase noise. Since the Maxim Chip is a SOC, there
really isn't much to be done with respect to adjusting the noise budget
other than improving the Reference oscillator phase noise. An external
GPS Band Pass filter and LNA are about the only degrees of freedom
available.
David Bengtson (Guest)
on 2006-04-07 02:55
(Received via mailing list)
Clark P. wrote:
> I guess I missed the answer to why you can't do GPS with the DBS board?
> It has the hooks to apply power to the antenna and it certainly has the
> bandwidth and tuning range. If you're concerned about having a nice
> clock rate to make the despreading easier you can replace the oscillator
> on your USRP with a 32.768MHz oscillator, for example. (I'm in the
> process of switching mine to 44 MHz ro make wlan easier.)
>
> -Clark

You may well be able to do it with the DBS board. However, GPS is a
pretty weak signal, and I suspect that the noise figure is too high.

Also, there is a good sized population of college students doing GPS
work, so I thought that building a GPS specific board would be useful
for those folks.
David Bengtson (Guest)
on 2006-04-07 03:01
(Received via mailing list)
Martin D. wrote:
> This way you would have a phase coherent system.
> Which is very nice if you start to play with multiple gps daughterboards.
>

GPS is a single frequency spread spectrum system, so you can get it all
from a single RF channel receiver with multiple de-correllators in the
baseband.

I'm sure there would be mandatory changes to do metrology grade gps
reception, but I'm not sure what they are, and I'm not sure I'm ready to
support this.

Dave
Matt E. (Guest)
on 2006-04-07 03:14
(Received via mailing list)
> You may well be able to do it with the DBS board. However, GPS is a
> pretty weak signal, and I suspect that the noise figure is too high.


The DBS board has about a 3-5 dB noise figure as I recall, but that
doesn't really matter.  Nearly all GPS antennas have their own LNAs
inside, so noise figure after all that gain (usually 20 to 40 dB)
doesn't make any difference.

Matt
David Bengtson (Guest)
on 2006-04-07 05:09
(Received via mailing list)
Matt E. wrote:
>> You may well be able to do it with the DBS board. However, GPS is a
>> pretty weak signal, and I suspect that the noise figure is too high.
>
>
> The DBS board has about a 3-5 dB noise figure as I recall, but that
> doesn't really matter.  Nearly all GPS antennas have their own LNAs
> inside, so noise figure after all that gain (usually 20 to 40 dB)
> doesn't make any difference.
>
> Matt

Then you should be able to get GPS from a DBS board using an external
LNA/Antenna combination. The software is left as an exercise for the
student :-).
Marcus L. (Guest)
on 2006-04-07 05:42
(Received via mailing list)
David Bengtson wrote:
>
> Then you should be able to get GPS from a DBS board using an external
> LNA/Antenna combination. The software is left as an exercise for the
> student :-).
Remind me, and I'll show a spectral spike of the GPS L1 signal.  I have
a DBS_RX, with an external LNA
  right at the feed of my dish.  The L1 signal at 1575.420 is quite
obvious...   My application is Radio Astronomy
  at 1420.4058Mhz, but my feed is fairly broad.  I use GPS L1 as a
calibration signal sometimes...
Eric B. (Guest)
on 2006-04-07 06:06
(Received via mailing list)
On Fri, Apr 07, 2006 at 07:50:53AM +0930, Berndt Josef W. wrote:
> this.
>
> cheerio Berndt


Hi Berndt,

After taking a look at this, I think the problem is in the
gnuradio-core build process.  All the tarballs that I checked
designate the swig generated output files as BUILT_SOURCES, and all
contain the output of running swig on the machine I built the tarballs
on.

That part is right.

The part that's wrong, is that something in the gnuradio-core build
process is triggering a dependency that's having gnuradio-core's swig
output be regenerated.  This could lead to a situation where
gnuradio-core's stuff is built with one version of swig, while all the
others use a different version.  I suspect that some of the machine
generated code (particularly the .i and .h files) in general and/or
filter isn't labeled BUILT_SOURCES, and thus isn't in the tarball.
Building that stuff would then force swig to be run, causing the
potential swig version inconsistency.


I'll continue to investigate, but not right now.


If someone else wants to help sort this out, please dive in.

BTW, this problem isn't new.  It's been in all the tarballs generated
over the last couple of years.  I think we're seeing it now because I
used swig 1.3.29 on the build machine.  The swig generated code changed
for the better between 1.3.27 and 1.3.28.


Thanks again for noticing & reporting the problem,
Eric
Berndt Josef W. (Guest)
on 2006-04-07 06:25
(Received via mailing list)
On Friday 07 April 2006 11:35, Eric B. wrote:
> > gr-audio-oss-0.8.1.tar.gz that excludes this file. I believe that package
> on.
> Building that stuff would then force swig to be run, causing the
> potential swig version inconsistency.

Not quite sure what you mean. Currently I have to regenerate this file
with
swig in order to avoid the segfault.

The log below shows the part that does go wrong. Note that swig wasn't
executed in order to regenerate audio_oss.cc

--------------------------------------------------------------------8<---------------------------------------------------------
gmake[3]: Entering directory
`/usr/pkgsrc/ham/gnuradio-audio-oss/work/gr-audio-oss-0.8/src'
if /bin/sh ../libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I.
-I.
-I.. -pthread -I/usr/pkg/include/gnuradio
-I/usr/pkg/include/python2.4
-I/usr/include -I/usr/pkg/include -I/usr/pkg/include/cppunit
-I/usr/pkg/include/python2.4  -O2 -I/usr/include -I/usr/pkg/include
-I/usr/pkg/include/cppunit -I/usr/pkg/include/python2.4 -Wall
-Woverloaded-virtual  -pthread  -MT audio_oss.lo -MD -MP -MF
".deps/audio_oss.Tpo" -c -o audio_oss.lo audio_oss.cc; \
then mv -f ".deps/audio_oss.Tpo" ".deps/audio_oss.Plo"; else rm -f
".deps/audio_oss.Tpo"; exit 1; fi
mkdir .libs
 c++ -DHAVE_CONFIG_H -I. -I.. -pthread
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/gnuradio
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/python2.4
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/cppunit -O2
-Wall -Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP
-MF .deps/audio_oss.Tpo -c audio_oss.cc  -fPIC -DPIC -o
.libs/audio_oss.o
audio_oss.cc:390: warning: `int SWIG_TypeCompare(const char*, const
char*)'
   defined but not used
audio_oss.cc:437: warning: `swig_cast_info*
   SWIG_TypeCheckStruct(swig_type_info*, swig_type_info*)' defined but
not
used
audio_oss.cc:453: warning: `swig_type_info*
   SWIG_TypeDynamicCast(swig_type_info*, void**)' defined but not used
audio_oss.cc:684: warning: `const char* SWIG_UnpackDataName(const char*,
void*,
   unsigned int, const char*)' defined but not used
audio_oss.cc:1032: warning: `void SWIG_Python_SetErrorObj(PyObject*,
PyObject*)
   ' defined but not used
audio_oss.cc:1051: warning: `void SWIG_Python_SetConstant(PyObject*,
const
   char*, PyObject*)' defined but not used
audio_oss.cc:1059: warning: `PyObject*
SWIG_Python_AppendOutput(PyObject*,
   PyObject*)' defined but not used
audio_oss.cc:1949: warning: `int SWIG_Python_AcquirePtr(PyObject*, int)'
   defined but not used
audio_oss.cc:2044: warning: `int
SWIG_Python_ConvertFunctionPtr(PyObject*,
   void**, swig_type_info*)' defined but not used
audio_oss.cc:2071: warning: `int SWIG_Python_ConvertPacked(PyObject*,
void*,
   unsigned int, swig_type_info*)' defined but not used
audio_oss.cc:2179: warning: `PyObject*
   SWIG_Python_InitShadowInstance(PyObject*)' defined but not used
audio_oss.cc:2320: warning: `swig_type_info* SWIG_Python_TypeQuery(const
char*)
   ' defined but not used
audio_oss.cc:2432: warning: `void* SWIG_Python_MustGetPtr(PyObject*,
   swig_type_info*, int, int)' defined but not used
audio_oss.cc:3960: warning: `int SWIG_AsVal_double(PyObject*, double*)'
defined
   but not used
audio_oss.cc:7947: warning: `void SWIG_PropagateClientData()' defined
but not
   used
audio_oss.cc:8137: warning: `void SWIG_Python_addvarlink(PyObject*,
char*,
   PyObject*(*)(), int (*)(PyObject*))' defined but not used
audio_oss.cc:8154: warning: `PyObject* SWIG_globals()' defined but not
used
 c++ -DHAVE_CONFIG_H -I. -I.. -pthread
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/gnuradio
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/python2.4
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include
-I/usr/pkgsrc/ham/gnuradio-audio-oss/work/.buildlink/include/cppunit -O2
-Wall -Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP
-MF .deps/audio_oss.Tpo -c audio_oss.cc -o audio_oss.o >/dev/null 2>&1
--------------------------------------------------------------------8<---------------------------------------------------------

In contrast building from CVS
--------------------------------------------------------------------8<---------------------------------------------------------
/usr/pkg/bin/swig -c++ -fvirtual -python -modern
-I/usr/pkg/include/python2.4
-I/usr/pkg/include/gnuradio/swig -I/usr/pkg/include/gnuradio -module
audio_oss -o audio_oss.cc audio_oss.i
gmake  all-am
gmake[1]: Entering directory `/usr/src/gnuradio/gr-audio-oss/src'
if /usr/pkg/bin/bash ../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H
-I. -I. -I.. -pthread -I/usr/pkg/include/gnuradio   -I/usr/pkg/include
-I/usr/pkg/include/python2.4  -I/usr/pkg/include  -I/usr/pkg/include
-Wall
-Woverloaded-virtual -pthread -MT audio_oss.lo -MD -MP -MF
".deps/audio_oss.Tpo" -c -o audio_oss.lo audio_oss.cc; \
then mv -f ".deps/audio_oss.Tpo" ".deps/audio_oss.Plo"; else rm -f
".deps/audio_oss.Tpo"; exit 1; fi
mkdir .libs
 g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -I/usr/pkg/include/gnuradio
-I/usr/pkg/include -I/usr/pkg/include/python2.4 -I/usr/pkg/include
-I/usr/pkg/include -Wall -Woverloaded-virtual -pthread -MT audio_oss.lo
-MD
-MP -MF .deps/audio_oss.Tpo -c audio_oss.cc  -fPIC -DPIC -o
.libs/audio_oss.o
if /usr/pkg/bin/bash ../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H
-I. -I. -I.. -pthread -I/usr/pkg/include/gnuradio   -I/usr/pkg/include
-I/usr/pkg/include/python2.4  -I/usr/pkg/include  -I/usr/pkg/include
-Wall
-Woverloaded-virtual -pthread -MT audio_oss_sink.lo -MD -MP -MF
".deps/audio_oss_sink.Tpo" -c -o audio_oss_sink.lo audio_oss_sink.cc; \
--------------------------------------------------------------------8<---------------------------------------------------------

where swig regenerates the audio_oss.cc file

> I'll continue to investigate, but not right now.
>
>
> If someone else wants to help sort this out, please dive in.
>
> BTW, this problem isn't new.  It's been in all the tarballs generated
> over the last couple of years.  I think we're seeing it now because I
> used swig 1.3.29 on the build machine.  The swig generated code changed
> for the better between 1.3.27 and 1.3.28.

This would make sense as the version of swig used here is 1.3.27.

I was going to commit an update of the latest gnuradio release into
pkgsrc and
will have to work around it if no solution comes from here.

BTW: I've since create a package for gr-audio-portaudio which I hope to
commit
soon.

cheerio Berndt
Eric B. (Guest)
on 2006-04-07 07:14
(Received via mailing list)
On Fri, Apr 07, 2006 at 11:52:47AM +0930, Berndt Josef W. wrote:
> > > It would be nice if we can create a new tarball e.g
> > contain the output of running swig on the machine I built the tarballs
> > filter isn't labeled BUILT_SOURCES, and thus isn't in the tarball.
> > Building that stuff would then force swig to be run, causing the
> > potential swig version inconsistency.
>
> Not quite sure what you mean. Currently I have to regenerate this file with
> swig in order to avoid the segfault.
>
> The log below shows the part that does go wrong. Note that swig wasn't
> executed in order to regenerate audio_oss.cc

Note that the compile from the the tarball *does* succeed.  It does
generate some warnings about "defined but unused", but no compile time
errors.

I believe the reason you're seeing the segfault (based on
circumstantial evidence -- I don't even know *where* it's blowing up)
is that the gnuradio-core tarball *does* run swig (which it
shouldn't), while the other tarballs *don't* run swig.  This would
result in gnuradio-core using "your version of swig" and all the other
tarballs using "my version of swig".  As long as they all use the
same version of swig, everything should be OK.  Right now they're not.

Let me be clear: when compiling the tarballs, swig should *not* run
[at least that was the original intention ;) ] The fact that it is run
when building the gnuradio-core tarball is *incorrect*, and is what I
believe is causing the problem.

So, I think there are two solutions: ensure that either all of them run
swig,
or that none of them run swig.

>
> This would make sense as the version of swig used here is 1.3.27.

That's good to know.

> I was going to commit an update of the latest gnuradio release into pkgsrc and
> will have to work around it if no solution comes from here.

I appreciate your efforts.  Maybe you should hold off a few days and
see if a solution materializes.


> BTW: I've since create a package for gr-audio-portaudio which I hope to commit
> soon.

Good.

How does gr-audio-portaudio sound under NetBSD?
Does it work as well as gr-audio-oss?

FWIW, my impression of gr-audio-portaudio under GNU/Linux is that it's
not ready for prime time.  I'd still choose gr-audio-alsa over
portaudio.  It still needs some work.  Not sure if it's in our code,
the portaudio code, or both.

Eric
Berndt Josef W. (Guest)
on 2006-04-07 11:11
(Received via mailing list)
On Friday 07 April 2006 12:41, Eric B. wrote:
> > The log below shows the part that does go wrong. Note that swig wasn't
> > executed in order to regenerate audio_oss.cc
>
> Note that the compile from the the tarball *does* succeed.  It does
> generate some warnings about "defined but unused", but no compile time
> errors.

Yes, I know.

> I believe the reason you're seeing the segfault (based on
> circumstantial evidence -- I don't even know *where* it's blowing up)
> is that the gnuradio-core tarball *does* run swig (which it
> shouldn't), while the other tarballs *don't* run swig.  This would
> result in gnuradio-core using "your version of swig" and all the other
> tarballs using "my version of swig".  As long as they all use the
> same version of swig, everything should be OK.  Right now they're not.

gdb trace show:

---------------------------------------------------------8<-----------------------------------------------------
Loaded symbols for /usr/libexec/ld.elf_so
#0  0xbbb574ca in type_new () from /usr/pkg/lib/libpython2.4.so.1.0
(gdb) where
#0  0xbbb574ca in type_new () from /usr/pkg/lib/libpython2.4.so.1.0
#1  0xbbb55d10 in type_call () from /usr/pkg/lib/libpython2.4.so.1.0
#2  0xbbb25c0c in PyObject_Call () from /usr/pkg/lib/libpython2.4.so.1.0
#3  0xbb493b8b in SWIG_Python_NewShadowInstance ()
   from /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
#4  0xbb493da6 in SWIG_Python_NewPointerObj ()
   from /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
#5  0xbb4950c1 in _wrap_audio_oss_sink_sptr_input_signature ()
   from /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
#6  0xbbb46672 in PyCFunction_Call () from
/usr/pkg/lib/libpython2.4.so.1.0
#7  0xbbb25c0c in PyObject_Call () from /usr/pkg/lib/libpython2.4.so.1.0
#8  0xbbb790d3 in ext_do_call () from /usr/pkg/lib/libpython2.4.so.1.0
#9  0xbbb76cbf in PyEval_EvalFrame () from
/usr/pkg/lib/libpython2.4.so.1.0
#10 0xbbb77336 in PyEval_EvalCodeEx () from
/usr/pkg/lib/libpython2.4.so.1.0
[....]
---------------------------------------------------------8<-----------------------------------------------------



ktrace provides the following trace:

---------------------------------------------------------8<-----------------------------------------------------
[...] 15405      1 python2.4 CALL  open(0x812cc3c,1,0xbfbfde90)
 15405      1 python2.4 NAMI  "/dev/audio"
 15405      1 python2.4 RET   open 3
 15405      1 python2.4 CALL  ioctl(3,_IOWR('A',0x16,0x88),0xbfbfdd50)
 15405      1 python2.4 GIO   fd 3 wrote 136 bytes
       "\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\^P\0\0\0\^F\0\0\0\M^?\M^?\M^?\M^?\M^?
\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\^P\0\0\0\^F\0\0\0\M^?\M^?\M^?\M^?
\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?"
 15405      1 python2.4 GIO   fd 3 read 136 bytes
       "\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\^P\0\0\0\^F\0\0\0\M^?\M^?\M^?\M^?\M^?
\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\^P\0\0\0\^F\0\0\0\M^?\M^?\M^?\M^?
\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?"
 15405      1 python2.4 RET   ioctl 0
 15405      1 python2.4 CALL  ioctl(3,_IOR('A',0x15,0x88),0xbfbfdd50)
 15405      1 python2.4 GIO   fd 3 read 136 bytes
       "@\^_\0\0\^A\0\0\0\^P\0\0\0\^F\0\0\0\M^?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
        \0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\^A\0@\^_\0\0\^A\0\0\0\^P\
        \0\0\0\^F\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\a\0\0\0\0\0\^A\0\0\0\0\0\0\0\
        \0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0@\^F\0\0
(\0\0\0\^^\0\0\0\0\0\0\0\^E\
        \0\0\0"
 15405      1 python2.4 RET   ioctl 0
 15405      1 python2.4 CALL  ioctl(3,_IOWR('A',0x16,0x88),0xbfbfdd50)
 15405      1 python2.4 GIO   fd 3 wrote 136 bytes
       "\M^?\M^?\M^?\M^?\^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?"
 15405      1 python2.4 GIO   fd 3 read 136 bytes
       "\M^?\M^?\M^?\M^?\^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\^B\0\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?"
 15405      1 python2.4 RET   ioctl 0
 15405      1 python2.4 CALL  ioctl(3,_IOR('A',0x15,0x88),0xbfbfdd50)
 15405      1 python2.4 GIO   fd 3 read 136 bytes
       "@\^_\0\0\^B\0\0\0\^P\0\0\0\^F\0\0\0\M^?\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
        \0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\^A\0@\^_\0\0\^B\0\0\0\^P\
        \0\0\0\^F\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\a\0\0\0\0\0\^A\0\0\0\0\0\0\0\
        \0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0@\^F\0\0
(\0\0\0\^^\0\0\0\0\0\0\0\^E\
        \0\0\0"
 15405      1 python2.4 RET   ioctl 0
 15405      1 python2.4 CALL  ioctl(3,_IOWR('A',0x16,0x88),0xbfbfdd50)
 15405      1 python2.4 GIO   fd 3 wrote 136 bytes
       "\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?"
 15405      1 python2.4 GIO   fd 3 read 136 bytes
       "\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^@\M-;\0\0\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\
        \M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?"
 15405      1 python2.4 RET   ioctl 0
 15405      1 python2.4 CALL  ioctl(3,_IOR('A',0x15,0x88),0xbfbfdd50)
 15405      1 python2.4 GIO   fd 3 read 136 bytes
       "\M^@\M-;\0\0\^B\0\0\0\^P\0\0\0\^F\0\0\0\M^?\0\0\0\0\0\0\0\0\0\0\0\0\0\
        \0\0\0\0\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\^A\0\M^@\M-;
\0\0\^B\0\

\0\0\^P\0\0\0\^F\0\0\0\0\0\0\0\^A\0\0\0\0\0\0\0\a\0\0\0\0\0\^A\0\0\0\0\
        \0\0\0\0\0\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\M^@%\0\0\^F\0\0\0\^D\0\0\0\0\
        \0\0\0\^E\0\0\0"
 15405      1 python2.4 RET   ioctl 0
 15405      1 python2.4 PSIG  SIGSEGV SIG_DFL
 15405      1 python2.4 NAMI  "python2.4.core"
---------------------------------------------------------8<-----------------------------------------------------


> Let me be clear: when compiling the tarballs, swig should *not* run
> [at least that was the original intention ;) ] The fact that it is run
> when building the gnuradio-core tarball is *incorrect*, and is what I
> believe is causing the problem.
>
> So, I think there are two solutions: ensure that either all of them run
> swig, or that none of them run swig.
>

swig is executed with gr-audio-portaudio, gr-audio-oss,
gr-gsm-fr-vocoder,
gr-usrp but not with gnuradio-core and  usrp

> > This would make sense as the version of swig used here is 1.3.27.
> > commit soon.
>
> Good.
>
> How does gr-audio-portaudio sound under NetBSD?
> Does it work as well as gr-audio-oss?

I just finished and installed the portaudio package and run a few
applications. The sound is choppy, something that I haven't noticed with
the
older version of portaudio support which had the *_portaudio.py
applications.
However, the test applications that come with portaudio work fine.

Will investigate it later on, it's not important at the moment since
audio_oss
works fine.

> FWIW, my impression of gr-audio-portaudio under GNU/Linux is that it's
> not ready for prime time.  I'd still choose gr-audio-alsa over
> portaudio.  It still needs some work.  Not sure if it's in our code,
> the portaudio code, or both.

Will do,

cheerio Berndt
Eric B. (Guest)
on 2006-04-10 03:36
(Received via mailing list)
Hi Berndt,

I've spent some more time looking at this problem.
I think I know how to fix it "right", but it's going to take a while.
Just removing the output of swig causes a failure in the VPATH build
that takes place during "make distcheck".  I know how to fix it, but I
don't have time right now.   All the modules need the fix.

This Makefile.am pattern will remove the output of swig:

audio_oss.cc audio_oss.py: audio_oss.i $(NON_LOCAL_IFILES)
	$(SWIG) $(SWIGCPPPYTHONARGS) -module audio_oss -o audio_oss.cc $<

# Don't distribute output of swig
dist-hook:
	@for file in $(BUILT_SOURCES); do echo $(RM) $(distdir)/$$file; done
	@for file in $(BUILT_SOURCES); do $(RM) $(distdir)/$$file; done


The general idea is to ensure that the output of swig is not included
in any of the tarballs, thus causing swig to run where ever the
tarballs are built.  I think this will be a more robust fix than
trying to ensure that the output of swig *is* included in the
tarballs, because that will lead to potential failures on systems that
have a mix of tarball and CVS built modules.  That's not recommended,
but we shouldn't aggravate the problem.

I will fix this problem (unless somebody beats me to it), but due to
other commitments, it'll probably be the week of the 17th before I've
got time to work on it.

In the meantime, if you've got a local fix for the NetBSD package,
please implement it.

Eric
Berndt Josef W. (Guest)
on 2006-04-10 15:49
(Received via mailing list)
On Monday 10 April 2006 09:02, Eric B. wrote:
> audio_oss.cc audio_oss.py: audio_oss.i $(NON_LOCAL_IFILES)
> tarballs are built.  I think this will be a more robust fix than
> please implement it.
>

I also could try to update swig in pkgsrc to 1.3.29 if this is what the
current files are created by. I just won't hold my breath that this
actually
will happen (I'm not the package maintainer for swig).

It may be quicker for me to implement the changes you suggested.

cheerio Berndt
This topic is locked and can not be replied to.