[Discuss-gnuradio] RF no tune preamplifier
I've just finished a low noise preamplifier prototype based on Avago MGA62563, and I would like to use it in conjunction with the tvrx - the device needs 3V @ 60mA, or 5V - is there any place on the board where I can get such a supply safely? ciao Matteo iz2eeq ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi_tone.py
multi_tone.py has been committed that supports jack with -O jack portaudio with -O pa oss with -O /dev/dsp alsa otherwise The portaudio sink segment faulted. jack support was partial and produces good sound on one channel if connected and rough sound if connected to the other channel. This is a good test file to get all of the outputs working correctly. We need to get the multiple channel support going. When I connect my delta 44 to jack about a dozen channel show up. On alsa this is handled by plughw but jack just handles it beautifully. On Windows, the channels are better id'd as 1/2, 3/4, and Multi (1,2,3,4) (I know this from using WSJT which I got to use portaudio and the reason for my bringing it up to this group). Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] mono_tone.py
mono_tone similarly modified. Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_tone.py
On Monday 13 March 2006 20:49, Robert McGwier wrote:
> multi_tone.py has been committed that supports
>
> jack with -O jack
> portaudio with -O pa
> oss with -O /dev/dsp
> alsa otherwise
>
> The portaudio sink segment faulted. jack support was partial and
> produces good sound on one channel if connected and rough sound if
> connected to the other channel.
>
> This is a good test file to get all of the outputs working correctly.
> We need to get the multiple channel support going. When I connect my
> delta 44 to jack about a dozen channel show up. On alsa this is
> handled by plughw but jack just handles it beautifully. On Windows,
> the channels are better id'd as 1/2, 3/4, and Multi (1,2,3,4) (I know
> this from using WSJT which I got to use portaudio and the reason for my
> bringing it up to this group).
multi_tone.py is now broken as it requires audio_portaudio and audio_jack
modules.
barossa: {11} ./multi_tone.py -O /dev/audio
Traceback (most recent call last):
File "./multi_tone.py", line 25, in ?
from gnuradio import audio_portaudio
ImportError: cannot import name audio_portaudio
Why force users to install all modules in order to run a otherwise very simple
test application? Jack and portaudio may not even be available for some
platforms.
cheerio Berndt
pgpA0suBsqMDh.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_tone.py
On 3/13/06, Berndt Josef Wulf <[EMAIL PROTECTED]> wrote:
> multi_tone.py is now broken as it requires audio_portaudio and audio_jack
> modules.
>
> barossa: {11} ./multi_tone.py -O /dev/audio
> Traceback (most recent call last):
> File "./multi_tone.py", line 25, in ?
> from gnuradio import audio_portaudio
> ImportError: cannot import name audio_portaudio
>
> Why force users to install all modules in order to run a otherwise very simple
> test application? Jack and portaudio may not even be available for some
> platforms.
>
We can provide a way to select an audio module at the audio.py layer
as it used to be for OSS/ALSA selection. Not sure whether it has
changed now.
Or under gnuradio-examples, we can have separate directories under
audio for jack, alsa and portaudio.
--
Ramakrishnan - VU3RDD
http://www.zerobeat.in
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_tone.py
Good point.
I commented out the offending lines. If you have portaudio and/or jack,
they are easily replaced.
#from gnuradio import audio_portaudio
#from gnuradio import audio_jack
and then remove the comment in front of the
dst = audio_jack.sink
and/or
dst = audio_portaudio.sink
if you wish to have local support. I could easily upload
multi_tone_allhosts.py, etc.
Bob
Berndt Josef Wulf wrote:
On Monday 13 March 2006 20:49, Robert McGwier wrote:
multi_tone.py has been committed that supports
jack with -O jack
portaudio with -O pa
oss with -O /dev/dsp
alsa otherwise
The portaudio sink segment faulted. jack support was partial and
produces good sound on one channel if connected and rough sound if
connected to the other channel.
This is a good test file to get all of the outputs working correctly.
We need to get the multiple channel support going. When I connect my
delta 44 to jack about a dozen channel show up. On alsa this is
handled by plughw but jack just handles it beautifully. On Windows,
the channels are better id'd as 1/2, 3/4, and Multi (1,2,3,4) (I know
this from using WSJT which I got to use portaudio and the reason for my
bringing it up to this group).
multi_tone.py is now broken as it requires audio_portaudio and audio_jack
modules.
barossa: {11} ./multi_tone.py -O /dev/audio
Traceback (most recent call last):
File "./multi_tone.py", line 25, in ?
from gnuradio import audio_portaudio
ImportError: cannot import name audio_portaudio
Why force users to install all modules in order to run a otherwise very simple
test application? Jack and portaudio may not even be available for some
platforms.
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity. Guilty as charged!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Stephane Fillod wrote:
> On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote:
>
>>That is why I put the message out. It will be good to have a working
>>starting point.
>
>
> Okay, there it is. Just checked in to gr-audio-portaudio repository.
> It's somewhat working, but there's still some static in the audio
> output (tested with ALSA playback, mono and stereo). Some more work
> is needed.
>
> You will need the attached patchs:
>
> - against gnuradio-core: ot_gri_ringbuffer.patch
> * src/lib/omnithread/omnithread.h: add omni_mutex::trylock
> * src/lib/general/gri_ringbuffer.{cc,h},
> src/lib/general/Makefile.am: new lockless ringbuffer (single
> reader/single writer) taken from JACK software (GPL).
>
> - against portaudio-V19(CVS): portaudio-pkg-config.patch
> * pkg-config .pc file with proper THREAD_FLAGS
>
> The code should be portable. I was missing the native Win32 call for
> mutex_trylock, so someone will have to find it, and define
> OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h,
> with appropriate semantic (return value).
I think you can do this with TryEnterCriticalSection
You could also use the omni_semaphore class defined in
gnuradio-core/src/lib/omnithread/nt.cc
This latter one uses CreateSemaphore and WaitForSingleObject with some wrapper
code.
(you probably have to change all defines if you change to using omni_semaphore)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/tryentercriticalsection.asp
http://msdn.microsoft.com/library/en-us/dllproc/base/createsemaphore.asp?frame=true
http://msdn.microsoft.com/library/en-us/dllproc/base/waitforsingleobject.asp?frame=true
Another example of how it can be used (very much like our omni_semaphore class)
http://users.pandora.be/robert.deblier/beecrypt/mutex_8h-source.html
I don't have time to implement and test right now.
(I am working hard on finishing my gnuradio presentation for wednessday in
Limburg)
If nobody implements it this week I will have a look next week.
greetings,
Martin
> The gri_pa_find_device_by_name() function will have to be made more
> smart, like accepting which HostApi (ALSA, JACK, ..) is to be chosen,
> and which device from this API. A syntax will have to be agreed upon,
> like "ALSA:hw:0" or "OSS:/dev/dsp1".
>
> Have fun,
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-usrp from cvs, please help
after installing all the requested gnu-radio packages which compiled with no errors I launched usrp_oscope.py to test the whole thing but I got the "unknown usrp rev" runtime error. so I downloaded latest updates from cvs. everything makes succesfully but gr-usrp does not. I think it is the responsible for the "unknown usrp rev" error. here is what it says: g++ -DHAVE_CONFIG_H -I. -I. -I.. -pthread -I/usr/local/include/gnuradio -I/usr/ local/include -I/usr/include/python2.3 -g -O2 -Wall - Woverloaded-virtual -pthrea d -MT usrp1_sink_base.lo -MD -MP - MF .deps/usrp1_sink_base.Tpo -c usrp1_sink_bas e.cc -fPIC -DPIC - o .libs/usrp1_sink_base.o usrp1_sink_base.cc: In constructor `usrp1_sink_base::usrp1_sink_base (const std:: string&, gr_io_signature_sptr, int, unsigned int, int, int, std::string, std::st ring)': usrp1_sink_base.cc:58: error: no matching function for call to `usrp_standard_tx ::make(int&, unsigned int&, int&, int&, int&, int&, const std::string&, const st d::string&)' /usr/local/include/usrp_standard.h:250: note: candidates are: static usrp_standa rd_tx* usrp_standard_tx::make(int, unsigned int, int, int, int, int) usrp1_sink_base.cc: In member function `std::string usrp1_sink_base::serial_numb er()': usrp1_sink_base.cc:302: error: 'class usrp_standard_tx' has no member named 'ser ial_number' make[3]: *** [usrp1_sink_base.lo] Error 1 make[3]: Leaving directory `/root/gr-usrp/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/gr-usrp/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/gr-usrp' make: *** [all] Error 2 please, help! thank you Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-usrp from cvs, please help
I am experiencing the same error when making gr-usrp. Hopefully someone can shed light. Someone offered up the suggestion that my usrp package was out of date, but I have been unable to log into CVS to download the latest version, it asks for a password even for anonymous log in and then times out if I just hit enter. -- View this message in context: http://www.nabble.com/gr-usrp-from-cvs%2C-please-help-t1273123.html#a3379821 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DC on antenna
Thanks, I see it on the board. But you mean short pins on J100, right? From: Matt Ettus <[EMAIL PROTECTED]> To: Clark Pope <[EMAIL PROTECTED]> CC: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] DC on antenna Date: Sun, 12 Mar 2006 20:37:20 -0800 Clark Pope wrote: > > Has anyone tried using the GPS antennas where you have to provide DC > power over the antenna line with a USRP? Especially for the DBS board? > Seems like there ought to be a way to get one of the DAC outputs coupled > into the RF to power a gps lna or switch elements, etc. The dbsrx board has a header on it designed specifically to do this. Just provide the voltage on J100, a 2 pin header. If you have one of the newer dbsrx boards, rev 2.1, just short the pins of J101, and you will have 5V at the antenna port. Matt _ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
With help of the examples, I was able to get a little bit further. The portaudio_sink now gets initialized, but it shortly after fails with an abort trap. The cause is line 167 in audio_portaudio_sink.cc where d_portaudio_buffer_size is 0. It looks like if Pa_GetStreamInfo(d_stream)->outputLatency is already 0. Any ideas why this happens? Thomas On 3/12/06, Stephane Fillod <[EMAIL PROTECTED]> wrote: > On Sun, Mar 12, 2006 at 07:14:15PM -0800, Thomas Schmid wrote: > > I tried your code on Mac OS X 10.4 and I get pretty far (everything > > compiles and isntalls after some hacking), but when I execute an audio > > example, I get this error: > > > > 19:04 [EMAIL PROTECTED]:~/gnuradio/gr-build/gnuradio-examples/python/audio$ > > ./dial_tone.py > > Traceback (most recent call last): > > File "./dial_tone.py", line 55, in ? > > my_graph().run() > > File "./dial_tone.py", line 48, in __init__ > > dst = audio.sink (sample_rate, options.audio_output) > > File > > "/Users/thomas/gnuradio/gr/lib/python2.4/site-packages/gnuradio/audio_portaudio.py", > > line 235, in sink > > return _audio_portaudio.sink(*args) > > NotImplementedError: No matching function for overloaded 'sink' > > > > Now I am stuck. Any idea why this happens or what could be wrong? > > Most likely the arguments are not what is expected. > Looking at gr-audio-portaudio/src/audio_portaudio.i, they should be: > > audio_portaudio_sink (int sampling_freq, >int ok_to_block, >const std::string device_name >) > > device_name defaults to "", and ok_to_block defaults to 1. > > Eric, the argument order may be tweaked. > > > > Here is what I did, if anyone wants to repeat it: > > > > - install xcode 2.2 > > - install coreaudio sdk 1.4.3 > > - downloaded portaudio V19 and applied patch > > - fixed small -framework error on line 144 of configure.in (remove > > double -framework) > > - fixed also -framework error in Makefile.in > > We should definitely add automake/libtool support to portaudio. > > > - removed the portaudio.pc directives which were added from the patch > > (no portaudio.pc target in the makefile, will do it manually later on. > > i think it is missing.) > > Look at my other mail. This should not be necessary if built from > scratch. > > -- > Stephane > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-usrp from cvs, please help
On Mon, Mar 13, 2006 at 04:37:59PM +0100, Vincenzo Pellegrini wrote: > after installing all the requested gnu-radio packages which compiled > with no errors I launched usrp_oscope.py to test the whole thing but I > got the "unknown usrp rev" runtime error. > > so I downloaded latest updates from cvs. everything makes succesfully > but gr-usrp does not. I think it is the responsible for the "unknown > usrp rev" error. My guess is that your checkout of usrp (off of sourceforge) is out of date. Sourceforge has been quite flaky lately, and sometimes "cvs -q up" doesn't complete successfully. Please confirm that your CVS copy of usrp is up to date. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Plotting doubt
I was looking at the fftsink.py and the plot.py that it uses. Is there a simple way to plot a graph with everything down under the points also filled with a colour ? I am trying to see if plot.py has a way to do that. -- Ramakrishnan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mono_tone.py
On Mon, Mar 13, 2006 at 05:24:43AM -0500, Robert McGwier wrote: > mono_tone similarly modified. > > Bob Thanks. In general, I think we ought to push the selection of audio "subsystem" into a preference somewhere. Yes, I know we're missing that feature right now. I'm fine that you've modified these to test everything, but I think we're going to want a single fix that gets them all. Probably somewhere in audio.py. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multi_tone.py
On Mon, Mar 13, 2006 at 05:25:58PM +0530, Ramakrishnan Muthukrishnan wrote: > > > > Why force users to install all modules in order to run a otherwise very > > simple > > test application? We shouldn't > > Jack and portaudio may not even be available for some platforms. Agreed. > We can provide a way to select an audio module at the audio.py layer > as it used to be for OSS/ALSA selection. Not sure whether it has > changed now. That's where the fix should go. > Or under gnuradio-examples, we can have separate directories under > audio for jack, alsa and portaudio. No, no, no! My goal is that we converge, not diverge, the audio handling. If we need to change some constructor args, etc to make them all behave the same, then so be it. Conceptually, what I'm looking for is a new abstract interface that covers *all* of the cases. Then we should make everything fit that new interface. Then fix in audio.py, with possible preference check, etc. We can probablly make good use of python keyword arguments to sort some of this out. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RF no tune preamplifier
Matteo Campanella wrote: > I've just finished a low noise preamplifier prototype based on Avago > MGA62563, and I would like to use it in conjunction with the tvrx - the > device needs 3V @ 60mA, or 5V - is there any place on the board where I > can get such a supply safely? > > If you have unused daughterboard slots, put a BasicTX or BasicRX in one of them. They both have pins for 3.3V. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RF no tune preamplifier
On Mon, Mar 13, 2006 at 10:09:57AM -0800, Matt Ettus wrote: > Matteo Campanella wrote: > > I've just finished a low noise preamplifier prototype based on Avago > > MGA62563, and I would like to use it in conjunction with the tvrx - the > > device needs 3V @ 60mA, or 5V - is there any place on the board where I > > can get such a supply safely? > > > > > > If you have unused daughterboard slots, put a BasicTX or BasicRX in one > of them. They both have pins for 3.3V. > > Matt We're running unregulated +6V to the daughterboards, right? There's probably somewhere to connect a wire to the TVRX to get the +6V. Or locally regulated +5V. A look at the schematics would shed some light. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Plotting doubt
On Mon, Mar 13, 2006 at 11:08:52PM +0530, Ramakrishnan Muthukrishnan wrote: > > I was looking at the fftsink.py and the plot.py that it uses. Is there a > simple way to plot a graph with everything down under the points also filled > with a colour ? I am trying to see if plot.py has a way to do that. It currently plots by drawing lines between data points. You'd need to change it one of a couple of ways: * draw vertical lines from the bottom horizontal axis to the right Y value. * change it to draw a filled polygon. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Plotting doubt
|| On Mon, 13 Mar 2006 10:10:31 -0800 || Eric Blossom <[EMAIL PROTECTED]> wrote: eb> It currently plots by drawing lines between data points. eb> You'd need to change it one of a couple of ways: eb> * draw vertical lines from the bottom horizontal axis to the right Y value. eb> * change it to draw a filled polygon. Thanks, I will try these ideas out. -- Ramakrishnan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulateous transmission from two daughterboards - I've got it !
Ok, Eric -- I really understand it now. Im able to start "dual_tx.py" and "dual_fft.py" and I can see the two signals ! (I have Tx_A -> Rx_A and Tx_B -> Rx_B) I can switch the signals by just swapping mux values -- nice... Now it seems trivial, but I can upload the "dual_fft.py" if is there anyone interested... My next move is try to implement receive diversity based on MRRC and transmit diversity based on Alamouti's STBC... Thank you, Angilberto. --- Eric Blossom <[EMAIL PROTECTED]> wrote: > On Sat, Mar 11, 2006 at 07:41:02AM -0800, Angilberto > Muniz Sb wrote: > > I think I've got it, Eric. > > > > According to "usrp_standard.h" the set_mux method > > understand the mux value a differente way... > > > > BTW does the same mux value works for rx way? > > > > Angilberto. > > The Tx and Rx mux work differently. > > from class usrp_standard_rx: > > /*! >* \brief Set input mux configuration. >* >* This determines which ADC (or constant zero) is > connected to >* each DDC input. There are 4 DDCs. Each has > two inputs. >* >* >* Mux value: >* >*3 2 1 > >* 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 > 8 7 6 5 4 3 2 1 0 >* > +---+---+---+---+---+---+---+---+ >* | Q3 | I3 | Q2 | I2 | Q1 | I1 > | Q0 | I0 | >* > +---+---+---+---+---+---+---+---+ >* >* Each 4-bit I field is either 0,1,2,3 >* Each 4-bit Q field is either 0,1,2,3 or 0xf > (input is const zero) >* All Q's must be 0xf or none of them may be 0xf >* >*/ > bool set_mux (int mux); > > > from class usrp_standard_tx: > > /*! >* \brief Set output mux configuration. >* >* >* 3 2 1 > >* 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 > 8 7 6 5 4 3 2 1 0 >* > +---+---+---+---+---+ >* | | DAC3 | DAC2 > | DAC1 | DAC0 | >* > +---+---+---+---+---+ >* >* There are two interpolators with complex > inputs and outputs. >* There are four DACs. >* >* Each 4-bit DACx field specifies the source for > the DAC and >* whether or not that DAC is enabled. Each > subfield is coded >* like this: >* >* 3 2 1 0 >*+-+-+ >*|E| N | >*+-+-+ >* >* Where E is set if the DAC is enabled, and N > specifies which >* interpolator output is connected to this DAC. >* >* N which interp output >* --- --- >* 0 chan 0 I >* 1 chan 0 Q >* 2 chan 1 I >* 3 chan 1 Q >* >*/ > bool set_mux (int mux); > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DC on antenna
No. Let me be clearer... If you have a DBSRX Rev 2.0 board (what most people have): Apply your bias voltage to the pin labeled "+" on J100 (the one closer to the SMA). The other pin on J100 is ground. Your bias voltage can be up to 30 V, and you can draw as much as 500 mA. If you have a DBSRX Rev 2.1 board you have 2 choices: 1) Do the same as above. 2) If your desired bias voltage is 5.0V, you can instead simply short the 2 pins of J101 (NOT J100) together. Most GPS antennas can take 5V. Ignore the silkscreen which says 6V. You can draw about 200-300mA only. J101 is only on rev 2.1 boards, not 2.0 boards. Matt Clark Pope wrote: > Thanks, I see it on the board. But you mean short pins on J100, right? > > >> From: Matt Ettus <[EMAIL PROTECTED]> >> To: Clark Pope <[EMAIL PROTECTED]> >> CC: discuss-gnuradio@gnu.org >> Subject: Re: [Discuss-gnuradio] DC on antenna >> Date: Sun, 12 Mar 2006 20:37:20 -0800 >> >> Clark Pope wrote: >> > >> > Has anyone tried using the GPS antennas where you have to provide DC >> > power over the antenna line with a USRP? Especially for the DBS board? >> > Seems like there ought to be a way to get one of the DAC outputs >> coupled >> > into the RF to power a gps lna or switch elements, etc. >> >> >> The dbsrx board has a header on it designed specifically to do this. >> Just provide the voltage on J100, a 2 pin header. If you have one of >> the newer dbsrx boards, rev 2.1, just short the pins of J101, and you >> will have 5V at the antenna port. >> >> Matt > > _ > Is your PC infected? Get a FREE online computer virus scan from McAfee® > Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DC on antenna
Clark Pope wrote: > > Has anyone tried using the GPS antennas where you have to provide DC > power over the antenna line with a USRP? Especially for the DBS board? > Seems like there ought to be a way to get one of the DAC outputs coupled > into the RF to power a gps lna or switch elements, etc. The dbsrx board has a header on it designed specifically to do this. Just provide the voltage on J100, a 2 pin header. If you have one of the newer dbsrx boards, rev 2.1, just short the pins of J101, and you will have 5V at the antenna port. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Sun, Mar 12, 2006 at 10:20:16PM +0100, Stephane Fillod wrote: > On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote: > > That is why I put the message out. It will be good to have a working > > starting point. > > Okay, there it is. Just checked in to gr-audio-portaudio repository. > It's somewhat working, but there's still some static in the audio > output (tested with ALSA playback, mono and stereo). Some more work > is needed. > > You will need the attached patchs: Stephane, Please go ahead and apply the patches. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gri_ringbuffer.{h,cc}
On Sun, Mar 12, 2006 at 10:20:16PM +0100, Stephane Fillod wrote:
>
> - against gnuradio-core: ot_gri_ringbuffer.patch
> * src/lib/general/gri_ringbuffer.{cc,h},
> src/lib/general/Makefile.am: new lockless ringbuffer (single
> reader/single writer) taken from JACK software (GPL).
Bob and Frank,
Didn't the JACK ringbuffer code cause you problems when pushing "part
of a float" into it. I.e., there was room for 3 bytes, but not all
four. If this is true, how did you fix it? Specialize for only
floats? "Yet another ringbuffer implementation" that doesn't have
the problem? I can't see an occasion when we'd need anything other
than floats.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulateous transmission from two daughterboards - I've got it !
On Sun, Mar 12, 2006 at 02:30:41PM -0800, Angilberto Muniz Sb wrote: > Ok, Eric -- I really understand it now. > > Im able to start "dual_tx.py" and "dual_fft.py" and I > can see the two signals ! (I have Tx_A -> Rx_A and > Tx_B -> Rx_B) > > I can switch the signals by just swapping mux values Glad to hear it's working ;) > Now it seems trivial, but I can upload the > "dual_fft.py" if is there anyone interested... Yes, please send it to [EMAIL PROTECTED] > My next move is try to implement receive diversity > based on MRRC and transmit diversity based on > Alamouti's STBC... Have fun! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_pll_carriertracking.h fixed
Hi, I fixed gr_pll_carriertracking.h in gnuradio-core It had one comma too many on line 41 which broke the build. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
On Mon, Mar 13, 2006 at 03:52:25PM +0100, Martin Dvh wrote: [..] > > The code should be portable. I was missing the native Win32 call for > > mutex_trylock, so someone will have to find it, and define > > OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h, > > with appropriate semantic (return value). > I think you can do this with TryEnterCriticalSection It does fit indeed. It has just been checked in. Bob, Thomas, please cvs update gnuradio-core AND gr-audio-portaudio at same time since I changed the logic of omni_mutex::trylock (returns true if it grabbed the lock), in order to comply with comment in omnithread.h. > You could also use the omni_semaphore class defined in > gnuradio-core/src/lib/omnithread/nt.cc > This latter one uses CreateSemaphore and WaitForSingleObject with some > wrapper code. > (you probably have to change all defines if you change to using > omni_semaphore) The gr-audio-portaudio code is using omni::mutex and omni::cond calls. Actually, they are not used for mutual exclusion, but simply as a notification mean (there's more room/there's more data in the ringbuffer). Good Lu*k Martin for your presentation. We can wait next week to see whether James Brown sounds even better with gr-audio-portaudio under Windows ;-) -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] initial gr-audio-portaudio
Ok. This is closer. I get a few buffers, almost 1 second and then it goes off the deep end but that is better than before when all I could get was segmentation fault! I will look at the callback interface, etc. to see if I see anything. I already know this pa works because I am using it with wsjt. Bob Stephane Fillod wrote: On Mon, Mar 13, 2006 at 03:52:25PM +0100, Martin Dvh wrote: [..] The code should be portable. I was missing the native Win32 call for mutex_trylock, so someone will have to find it, and define OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h, with appropriate semantic (return value). I think you can do this with TryEnterCriticalSection It does fit indeed. It has just been checked in. Bob, Thomas, please cvs update gnuradio-core AND gr-audio-portaudio at same time since I changed the logic of omni_mutex::trylock (returns true if it grabbed the lock), in order to comply with comment in omnithread.h. You could also use the omni_semaphore class defined in gnuradio-core/src/lib/omnithread/nt.cc This latter one uses CreateSemaphore and WaitForSingleObject with some wrapper code. (you probably have to change all defines if you change to using omni_semaphore) The gr-audio-portaudio code is using omni::mutex and omni::cond calls. Actually, they are not used for mutual exclusion, but simply as a notification mean (there's more room/there's more data in the ringbuffer). Good Lu*k Martin for your presentation. We can wait next week to see whether James Brown sounds even better with gr-audio-portaudio under Windows ;-) -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
