Re: [Discuss-gnuradio] Upgrade to Fedora 7?

[mgray]

I've been using Ubuntu with much better results.  You'll spend less time 
fixing the OS and more time on doing GNU radio stuff.



On Tue, 7 Aug 2007, Marcus Leech wrote:

> I'm considering upgrading my receiver 'puter (a Dual-core Pentium
> system) from FC6 to Fedora7.
> 
> Anything I need to know for Gnu Radio?
> 
> I've already noticed that Firefox 2.0.0.5 is *very* flakey on Fedora
> 7--crashes without provocation every few
>   minutes.  [If anyone here happens to know the fix for that, that would
> be cool, but I'm mostly interested
>   in Gnu Radio "gotchas"].
> 
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] KD7LMO GPS sample and sample rate nomenclature

[mgray]

Either I recorded them as 64-bit floats (double) or I did the conversion
from time in seconds to samples incorrectly.  The capture script I wrote
is located at:

http://www.kd7lmo.net/ground_gnuradio_software.html

The code calls the file_sink method.  I'm not sure what units/types it 
generates.

dst = gr.file_sink (gr.sizeof_gr_complex, filename)

head = gr.head(gr.sizeof_gr_complex, sample_count)

fg.connect(src, head, dst)


So the recording may be 1 seconds, instead of 500mS.

On Thu, 25 Jan 2007, Chris Stankevitz wrote:

> Hi,
> 
> KD7LMO provides a binary GPS recording, presumably made with the USRP 
> (thank you!).  It is advertised as "4msps / complex GPS Snapshot (500 
> mS)".  I use these ratios to determine what the file size should be:
> 
> 500e-3 seconds
> 4e6 complex_samples / second
> 2 floats / complex_sample
> 32 bits / float
> 1/8 bytes / bit
> 
> Multiply them all together and I get 16e6 bytes.  However, KD7LMO's file 
> is 32e6 bytes large.  Can someone explain the discrepancy or 
> misunderstanding?
> 
> Thank you!
> 
> Chris
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP Enclosure

[mgray]

Couldn't find a photo of the new USRP Enclosure on the Wiki or Matt's web 
site, so I posted one on mine:

http://www.kd7lmo.net/ground_gnuradio.html

The new enclosure is nice.  Heavy gauge metal and it gives the USRP a 
finished, professional look.





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 10.7 IF output Scanner Suggestions sought

[mgray]

AOR makes a good set of radios with IF outputs.

http://www.aorusa.com/b&m.html

High IP3, wide frequency range, and 10MHz BW IF.  You can also disable the 
AGC from the front panel.


On Tue, 12 Dec 2006, M. Ranganathan wrote:

> I am hoping somebody can recommend a scanner with a 10.7 MHZ IF output
> to connect to the Ettus Research USRP + Basic RX that I just recently
> acquired. I googled around and found a couple but I lack experience to
> which ones are good. Any suggestions? I am just getting started with
> this and I could use some help.
> 
> Thanks in advance.
> 
> Ranga
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] distribution of USRP image

[mgray]

Feel free to use the picture.  If you want to post a credit on it, that 
would be nice, but not required.

Michael Gray
KD7LMO (Radio Call Sign)


On Tue, 14 Nov 2006, Eric Hill Matlis wrote:

> Matt-
> 
> I have giving a presentation at this year's American Physical Society 
> Fluid Mechanics meeting in Tampa, Fl.  I am going to be demo'ing a new 
> flow sensor I designed that will use the USRP.  I'd like to include an 
> image of the USRP from your website on a poster. I just want to ok that 
> with you; I don't know if that image is protected via copy-right in any 
> way.  I believe the image, which I found at:
> 
> http://www.comsec.com/wiki?UniversalSoftwareRadioPeripheral
> 
> is courtesy of KD7LMO, so maybe I should be asking him.
> 
> Incidentally, the USRP really makes this sensor shine!  I am going to demo 
> a wireless mode of transmission.  Just as a quick background, the sensor 
> uses a 3 MHz a.c.-driven glow-discharge as the sensing element; the output 
> is AM modulated.  Because a glow discharge emits a strong electromagnetic 
> energy content, I found I could simply hang some wire as an antenna and 
> the USRP picks it up beautifully.
> 
> thanks,
> 
> eric
> 
> 
> Eric H. Matlis, Ph.D.
> Aerospace & Mechanical Engineering Dept.
> 120 Hessert Center for Aerospace Research
> University of Notre Dame
> Notre Dame, IN 46556-5684
> Phone: (574) 631-6054
> Fax:   (574) 631-8355
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] The coming deluge of CPU cycles

[mgray]

I'd vote for Gigabit Ethernet as an interface.  It offers the following:

1. Place the USRP very close to the antenna.

2. Distribute the signal to multiple computers. (Multi-cast IP)

3. Very low cost infrastructure of Ethernet switches and cables.

4. Ethernet is easier to use across common platforms like
Windoze/Linux/Embedded systems.




On Wed, 26 Jul 2006, Marcus Leech wrote:

> So, I read yesterday that Intel is going to start introducing quad-core 
> CPUs sometime late this
>  year, rather than 2007 as originally announced.
> 
> Two questions occur to me:
> 
> o How can we best take advantage of the multiple CPU cores in Gnu Radio?
>Being able to process larger bandwidths and "do stuff" with that 
> bandwidth
>would seem to be a good goal.   Like implementing a CDMA/GSM/whatever
>basestation RF processor all inside Gnu Radio, for example.  [Me, 
> I just want to
>be able to process radio astronomy data at higher bandwidths :-)].
> 
> o Is it time to think about moving away from USB for USRP?  Perhaps to
>PCI-X 2.0, or PCI-Express?
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] atsc receiver error rate: 5.19e-05

[mgray]

As a side note, if you want to keep the program in HD you can burn the 
MPEG program on a standard red-laser DVD and play them with this DVD 
player:

http://pro.jvc.com/prof/attributes/press_res.jsp?model_id=MDL101546&feature_id=08

You'll have to burn it as a DL disc, but 8 MB would fit.  You can also 
encode it to WMV-HD or DiVX-HD to make the program much smaller.

This is all kind of stop-gap until we get HD-DVD and/or Blu-Ray.  But it 
is sweet to play HD content off a DVD.

On Wed, 19 Apr 2006, Charles Swiger wrote:

> I thought this was pretty good for last night's recording of
> "Boston Legal":
> 
> end of file, exiting
> 661 errors out of 12727848 mpeg packets.  12727187 good packets.  Error
> rate = 5.19e-05
> 
> 
> That's for a 450Kw xmtr 10 miles away receiving with a scanner antenna.
> 
> What works so far is: recording an hour long program in 3 20-minute
> segments, making about 80Gb per segment. Then running gnuradio-0.9
> on 3 cpu's (with fake mc4020's on another 3 cpu's) and by about
> 10AM the next day they're done.  Then concatenate the 3 transport
> streams into 1 8Gb file, and running hdtv2dvd on it for 2 hours, 
> and out pops one hour long 720x480 ntsc high quality dvd, all from
> thin air.
> 
> Tonight's target video: Bones.
> 
> --Chuck
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Stereo gain "hacked"

[mgray]

Here is a link to the RBDS standard:

ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf


And another link to the digital AM radio standard:

http://www.ibiquity.com/technology/pdf/Waveforms_AM.pdf


On Tue, 14 Feb 2006, Robert McGwier wrote:

> Al, Matt:
> 
> Thanks for your input.  I am pretty ignorant about these FM standards 
> and basically I googled my way to a reasonable spec,  drew the flow 
> graph and coded it.  The stereo demux was definitely not working with 
> DEemphasis applied to the composite signal.  And it was clear why.  The 
> taper was awful and the lower sideband was approximately 10 dB higher 
> than the USB on the L-R, DSBSC stereo signal.  I removed the deemphasis 
> and voila, stereo.  That said,  when the pilot/carrier is 20 dB out of 
> the noise in the 512 pt FFT, that should be strong enough that you do 
> not have hiss that is irritating.  But the COMPOSITE signal is what is 
> FM modulated but I bet they do not preemphasize the composite signal. 
> They might do preemphasis on the L+R baseband signal as Matt suggests 
> but I just don't know about the others.  I am trying to understand what 
> about that would make sense.  It would be very interesting to read a 
> real spec.  I have googled and not really found one a  useful one.
> 
> I hate this RDS Top Secret MONEYWORD specification.  Frank and I are 
> determined to fix their wagon.
> 
> I did not know about Achilleas work.  I will search the archive.
> 
> Bob
> 
> 
> 
> al davis wrote:
> > On Monday 13 February 2006 20:06, Matt Ettus wrote:
> >   
> >> I seem to remember that the preemphasis on stereo signals is
> >> not performed on the multiplexed signal.  It is actually
> >> performed on the audio components separately, before mixing
> >> with the stereo subcarrier. Therefore deemphasis needs to be
> >> done after the stereo part is mixed back down to baseband.
> >>
> >> To me, this is backwards, and is not useful, but I think that
> >> is the standard.  Achilleas sent an email to the list several
> >> months ago on this subject.  He also had a simple
> >> implementation that did stereo.
> >> 
> >
> > Actually it is very useful the way it is.  It would be bad to 
> > preemphasize the composite signal.
> >
> > To preemphasize the composite in effect converts the system to 
> > phase modulation.  The subcarrier would then consume most of 
> > the bandwidth, and the baseband (mono) would be drastically 
> > reduced, resulting in a significant reduction in apparent mono 
> > signal to noise ratio. Stereo signal to noise ratio would be 
> > about the same as it is now, but there would be no advantage to 
> > mono.
> >
> > In the existing system, if stereo SNR is not good enough, you 
> > can switch to mono and get almost as good SNR as if stereo 
> > wasn't there.  "Almost" means about a 6 db degradation, which 
> > is due to the fact that baseband modulation must be lowered by 
> > that much.
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >   
> 
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] d_usb_data_rate

[mgray]

In the context of GNU radio it probably meant, Scientific Wild Ass Guess


On Thu, 19 Jan 2006 [EMAIL PROTECTED] wrote:

> Stuff We All Get = SWAG
> 
> i.e. Handouts
> 
> Vy 73;
> 
> Bob
> w9ya
> 
> 
> > SWAG -- basically a guess.   See
> > http://www.urbandictionary.com/define.php?term=swag (usage 2)
> >
> > Regards,
> >
> > Bill
> >
> >
> > At 06:56 PM 1/18/2006, David R. Palchak wrote:
> >
> >>  <>
> >>  The comment on the
> >>line simply says "// SWAG".  What does this comment mean?
> >><...>
> >>
> >>Thanks,
> >>David Palchak
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gmsk error

[mgray]

Try http://www.superbookdeals.com/

Search by ISBN, they can ship it in a couple days.  "Only" $89.



On Tue, 6 Dec 2005, [EMAIL PROTECTED] wrote:

>  On Tue, 6 Dec 2005 14:24:43 -0800, Eric Blossom [EMAIL PROTECTED] wrote:
> > Quick answer: 
> >
> >   use the defaults.
> >
> > Involved answer: 
> >
> > It's a Mueller and Müller (M&M) discrete-time error-tracking
> synchronizer.
> >
> >  See "Digital Communication Receivers: Synchronization, Channel
> > Estimation and Signal Processing" by Heinrich Meyr, Marc Moeneclaey, &
> Stefan Fechtel.
> >  ISBN 0-471-50275-8.
> 
> I should have seen that answere coming.  I am trying to get the book, no
> luck so far.
> 
> The default values dont seem to work.
> 
> What should the data going in and out of the gr.clock_recovery_mm_ff look
> like?
> 
> I see that in gmsk2.py you remove DC offset, should the signal be varying
> +/-Vpeak equally?
> 
> Any requirements that the signal should be over sampled?
> 
> Is the output basically resampled at the data clock rate so that each
> output point represent a bit?
> 
> Mike
> 
> 
> 
> 
> 
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gmsk error

[mgray]

This is the whole thing.  You don't need a lookup table.

/**
 *Calculate the CRC-16 CCITT of buffer that is length 
bytes long.
 *The crc parameter allow the calculation on the CRC on 
multiple buffers.
 *
 *@param buffer Pointer to data buffer.
 *@param length number of bytes in data buffer
 *@param crc starting value
 *
 *@return CRC-16 of buffer[0 .. length]
 */
uint16_t sysCRC16(uint8_t *buffer, uint8_t length, uint16_t crc)
{
uint8_t i, bit, value;

for (i = 0; i < length; ++i) 
{
value = buffer[i];

for (bit = 0; bit < 8; ++bit) 
{
crc ^= (value & 0x01);
crc = ( crc & 0x01 ) ? ( crc >> 1 ) ^ 0x8408 : ( crc >> 1 );
value = value >> 1;
} // END for
} // END for

return crc ^ 0x;
}


On Mon, 5 Dec 2005, [EMAIL PROTECTED] wrote:

> On Thu, 1 Dec 2005 16:02:59 -0700 (MST), mgray wrote:
> > The following is a link to CRC16 for the PIC controller with similiar
> > memory limitations:
> 
> > http://www.kd7lmo.net/picobeacon_code.html
> 
> I looked at the code and all I could find was the function sysCRC16 in
> lines 1899-1916 of the PicoBeacon.c.
> 
> I could not find a lookup table.  Is there any look up table or is it just
> the codes in the lines I mentioned?
> 
> Mike
> 
> 
> 
> 
> 
> 
> mail2web - Check your email from the web at
> http://mail2web.com/ .
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gmsk2 - CRC and whitening

[mgray]

The following is a link to CRC16 for the PIC controller with similiar 
memory limitations:

http://www.kd7lmo.net/picobeacon_code.html



On Thu, 1 Dec 2005, Eric Blossom wrote:

> On Thu, Dec 01, 2005 at 05:42:36PM -0500, [EMAIL PROTECTED] wrote:
> > Good suggestions, will look into implementing CRC16 with hardware and the
> > whitening for small payload.
> > 
> > Processor - Atmel AT90S8535 - face turns beat red. =)
> 
> The AVR processors are very nice.  Sort of a minature RISC architecture.
> You've got 8K of flash, so I don't see any problem at all.  I think
> there's a port of GCC that targets it too.
> 
> > Looking at the packet.sink code, it looks like it's independant of the CRC
> > code.  Is this right?
> 
> Yes.  It just checks that it's found the sync pattern and that the
> header length was properly detected.
> 
> > gmsk2_pkt.py uses delete_head().  I can't find this code, where is it?
> 
> gr_msg_queue.{h,cc}
> 
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reflection Vector Analyzer

[mgray]

Damn, I just bought an Agilent 5230. :)  I should have waited.

Looks good though.

On Wed, 9 Nov 2005, cswiger wrote:

> Gang - My Vector Analyzer works amazingly well enough that I put up
> a brag page:
> 
> http://webpages.charter.net/cswiger/phase/reflection_smith/smith_chart.html
> 
> that is to say, I plug in a 1nF cap and it reads -9.95e-10 (995pF), plug
> in a 1.5uH inductor and it reads 1.59E-6.  Essentially it measures
> Gamma, computes resistance and reactance from Gamma and the system
> impedance (50 ohms), then computes component values from the reactance
> and frequency. Also draws a Smith chart in real time.
> 
> Still needs a calibration and compensation system - in progress.
> 
> --Chuck
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PSK31 samples?

[mgray]

There is a 60 second sample at 20 meters during a contest.  Look for 
PSK-31 down low along with RTTY.

http://www.kd7lmo.net/ground_gnuradio_ota.html



On Wed, 26 Oct 2005, Ramakrishnan Muthukrishnan wrote:

> 
> Is there PSK31 sample captures available somewhere or can be made
> available somewhere?
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] (no subject)

[mgray]

I removed the xerces stuff from the build and install scripts last month.  
You may want to download the scripts again:

http://www.kd7lmo.net/ground_gnuradio_baseline.html




On Sat, 22 Oct 2005, Robitaille, Michael wrote:

> >On Fri, 21 Oct 2005 14:26:23 -0700, Eric Blossom wrote:
> 
>  
> 
> >>On Fri, Oct 21, 2005 at 03:09:21PM -0600, Robitaille, Michael wrote:
> >> Hello all and thanks for your.
> >> 
> >> I finally got all the baseline and gnuradio software installed per
> >> KD7LMO.net with some modification and still some question, for instance:
> >> 
> >> 1- In the install_baseline.sh there is the installation of
> >> xerces-c-src-2_6_0  but not in the baseline build shell or in the list of
> >> items needed.  I did not install this package, is this ok?
> 
>  
> 
> >You don't need xerces.  This is OK
>  
> It would be good to change the install script at KD7LM0 web site.
>  
> >> 2- Is the Octave/Octave-forge package needed?  I did build
> and
> >> installed these packages.
> 
>  
> 
> >Not required for GNU Radio, but nice to have.
> 
>  
> 
> It would be good to to mention that this is optional at KD7LM0 web site.
> 
>  
> 
> >> 3- Should any of these packages, including gnuradio, be
> 
> >> installed with sudo?
> 
>  
> 
> > Depends on your setup.  I don't install with sudo (being generally
> > paranoid), and have arranged things so that I'm in a group that has
> > write access to everything under /usr/local.  Judicious use of 
> 
> >  chmod g+s on directories under there is useful.
> 
>  
> 
> I like the idea of not having to use sudo.  I will try to change the
> permission on the appropriate directory.
> 
> Does anyone have a list of what those directories are?
> 
>  
> 
> >> I then tried to do install my brand new USRP, =), based on the wiki
> >> UsrpInstall.  Here are the problems I have encountered and need help
> with:
>  
>  
> >> 1-   The directory /usr/local/share/usrp/rev2 was not created with
> the
> >> required files (firmware).  I created the directory and added the files
> as
> >> root manually.  Running the program test_usrp_standard_tx does not seem
> to
> >> install the firmware file in the directory.  Most likely related to #3
> above
> >> but not I did try to do gnuradio install with sudo and it did not put the
> >> fillies.  I did use CVS and per the instruction, I manually copied the
> file
> >> usrp_fpga.rbf to the directory.
> 
>  
> 
> > I think this was a permissions problem.  Unless you're setup to write
> 
> > /usr/local and below, you will want to "sudo make install".
> 
>  
> 
> >> 2-   When I run test_usrp_standard_tx I get the error - can't find
> >> usrp_fpga.rbf.  The LED on the USRP does change from 2Hz to 1Hz, so the
> 
> >> firmware did get loaded.
> 
>  
> 
> > If you're building from CVS, you need to install the .rbf file manually.
> > Grab http://comsec.com/usrp/usrp_fpga_rev2_2005_10_20.rbf
>   and install
> > it as /usr/local/share/usrp/rev2/usrp_fpga.rbf
>  
> I did that (see last sentence in #1) and I still got the error that it could
> not find usrp_fpga.rbf.
> Is this file supposed to be somewhere else to?
>  
> Isn't' there a better method to set this up with the CVS release?
>  
> >> 3-   I do have hotplug running and seem to have permission to access
> the
> >> USRP device (when I had a camera to the USB port, it loaded
> automatically).
> >> When I check the /etc/hotplup/usb, I do not see usrp or usrp.usremap.
>  
> > We don't use the hotplug stuff.  Our library loads the firmware and fpga
> 
> > bitstream when you first open the device.
> 
>  
> 
> Why the the UsrpInstall wiki mention that you need hotplug for setting up
> USB device permission?
> 
>  
> 
> I am on FC4, how can I make sure that I have permission for the USB?
> 
>  
> 
> I do not see any usrp or usrp.usremap in the /etc/hotplug/usb directory but
> I do see some for the USB camera that I connected.
> 
>  
> 
> Can I get more information about the scrip that set the device permission
> mention in the UsrpInstall wiki?
> 
>  
> 
> > There's lots of variation on usb device permissions depending on your
> > distribution.  Under SuSE 9.3 it "just works".  Not sure why!
> > Under Mandrake 10.1 I made myself a member of group usb, which is the
> > group that owns everything under /proc/bus/usb/*
> > FWIW, the gid and perms used by usbfs can be set with a mount command
> > option.  E.g., 
>  
> >   [EMAIL PROTECTED] ~]$ grep usbfs /etc/rc.d/init.d/usb
> > action "Mount USB filesystem" mount -t usbfs -o
> devmode=0664,devgid=43 
> 
> >  none /proc/bus/usb
> 
>  
> 
> I am running on FC4, any help with those that have experience or have USRP
> running on FC4 would be appreciated.
> 
>  
> 
> >> 
> >> 4-   When I run the example usrp_oscope.py I get the error No module
> >> named gnuradio.
>  
> > Did you make install?  Did it work?
> > You might try "sudo ldconfig"
> > Is your PY

Re: [Discuss-gnuradio] 2.6 release coming RSN

[mgray]

Yes, yes, half-band filter!



On Fri, 21 Oct 2005, Eric Blossom wrote:

> Yes, I know it's *really* time for a new release.  
> [I can tell because I keep telling everyone to use CVS!]
> 
> Anyhow, there are a few things still left to finish off.
> 
> In no particular order:
> 
> * Finish refactoring *all* examples so that they use the best practices
>   with regard to GUI organization, hierarchical blocks, unified handling of
>   usrp daughterboards, command line arguments, control-C handling, etc.
> 
>   usrp_fft.py, usrp_wfm_rcv.py and the stuff in the audio directory are
>   currently done.  Take a look at them to see where we're headed.
> 
> * Rework usrp_nbfm_ptt (basic narrow band FM tranceiver) so that it
>   works with all daughterboards.
> 
> * FPGA half-band filter.
> 
> * Integrate the native python documentation (pydoc stuff)
> 
> * Add support to query and control IF bandwidth to the generic usrp
>   daughterboard code [Needed for dbs_rx].
> 
> There a ton of other things on the list, but I think these are the
> critical items.
> 
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Need some answers about FM TX

[mgray]

Here is an article that discusses using this technique in a radio:

http://img.cmpnet.com/commsdesign/csd/2002/oct02/eamon-fig3.jpg


Here is a graphic that shows the various images that are present in the
spectrum.

http://img.cmpnet.com/commsdesign/csd/2002/oct02/eamon-fig3.jpg


This is not a clock leakage or a DAC non-linearity problem.  It is just 
Nyquist digital sampling theory.

http://en.wikipedia.org/wiki/Shannon-Nyquist_sampling_theorem


On Sat, 1 Oct 2005, Robert McGwier wrote:

> Thanks for all the comments but I still have my doubts.  I am more like 
> to believe in clock leakage and DAC nonlinearities causing this than I 
> am with square wave harmonic activity.  I will investigate further with 
> the spec-an if I have time.
> 
> The pico-board looks great. I recently acquired the AD9954 eval board 
> (two 9954's sync'd for I/Q)  and a AD9958 eval board to learn what was 
> going on.  AD is a serious believer these days in DAC nonlinearities and 
> clock leakage causing all sorts of issues that are mistaken for other 
> things and as such they are truly seriously pushing the 9958 with its 10 
> bit DAC and smaller accumulator and phase word which seems so 
> counterintuitive but as you all say, measurements will tell the tale.  
> Their app engineers are all over you when you talk to them at length 
> about the problems attributed to phase truncations which mathematically 
> cannot be and which they have tracked down to DAC/clock leak issues.
> 
> I will post a note here with some results.
> 
> Bob
> 
> 
> 
> 
> [EMAIL PROTECTED] wrote:
> 
> >The same does apply to a DAC as well as an ADC.  They are both sampling 
> >systems.  A DAC typically has a low pass filter to cut all the alias 
> >images.  But you can also bandpass filter those images to produce the 
> >desired signal.  The system is very linear and isn't a mixer.
> >
> >Here is my original post:
> >
> >  
> >
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Need some answers about FM TX

[mgray]

The same does apply to a DAC as well as an ADC.  They are both sampling 
systems.  A DAC typically has a low pass filter to cut all the alias 
images.  But you can also bandpass filter those images to produce the 
desired signal.  The system is very linear and isn't a mixer.

Here is my original post:

Another trick to get higher frequencies is to use an image that is
produced the DAC. If you program the DAC to 29.3 MHz, you'll also get RF
at the SampleRate +/- DAC Freq. So you'll get a signal at 128 - 29.3 and
128 + 29.3. So in this case 98.7 and 157.3.  The signal levels will be
lower, but with the proper bandpass filter and amplifier chain, you can
generate a complete signal.  The signal levels fall off at a sin(x)/x 
rate.

I don't recall if there is a low pass filter on the DAC channel. If there
is, you'll need to remove the filter to get the images. With a short piece
of wire stuffed in the SMA connector, you could broadcast across the room
to an FM receiver.


For an example of the band pass filters/RF chain, view:

http://www.kd7lmo.net/picobeacon_hardware.html

This is setup for operation in the UHF band at 445 MHz.



On Sat, 1 Oct 2005, Robert McGwier wrote:

> Jorge:
> 
> The paper you included and the mathematical and electrical phenomenon 
> you are talking about applies to the analog to digital converter, the 
> receiver only.  This is undersampling as you call it.  Most engineers 
> call it bandpass sampling.  It applies to the use of aliasing to bring a 
> higher frequencies down low on receive.  This cannot be done with all 
> analog to digital converters.  It can be done with those analog to 
> digital converters that can "see" the high frequency.  In order for them 
> to see the high frequency, their conversion time must be small compared 
> to the high frequency, and they must respond to the higher frequency. 
> 
> You cannot do the reverse on transmit.  It is a "one to many" problem.  
> The only way you can get a higher frequency is for some (BAD) 
> nonlinearity to be producing the higher frequency content. 
> 
> My apologies, I wish my Spanish was good.  I have included a Google 
> translation and I hope it helps rather than hurts:
> 
> "El papel usted incluido y el fenómeno matemático y eléctrico que usted 
> está hablando se aplica a convertidor a digital análogo, el receptor 
> solamente.  Esto undersampling como usted lo llama. La mayoría de la 
> llamada de los ingenieros él muestreo bandpass.  Se aplica al uso del 
> aliasing de traer frecuencias más altas abajo bajo en recibe.  Esto no 
> se puede hacer con los convertidores a digitales todo análogos.  Puede 
> ser hecha con esos los convertidores a digitales análogos que pueden 
> "ver" el de alta frecuencia.  En la orden para que consideren el de alta 
> frecuencia, su tiempo de la conversión debe ser pequeño comparado al de 
> alta frecuencia, y deben responder a la frecuencia más alta.  Usted no 
> puede hacer el revés encendido transmite.  Es "el que esta' a muchos" 
> problema.  La única manera que usted puede conseguir una frecuencia más 
> alta está para que un cierto nonlinearity (del MALO) produzca el 
> contenido de una frecuencia más alta.
> "
> 
> Bob
> 
> Jorge Chávez wrote:
> 
> > If I run the fm_tx4.py, I TX in 29.3MHz and?? Which other 
> > frecuencies??, Which one is the frecuency of the Sample Rate??
> > Please Help me, and sorry for my english
> >
> >  
> > On Fri, Sep 30, 2005 at 10:47:47AM -0500, Jorge Chávez wrote:
> >> I'm trying to FM TX with the fm_tx4.py but it doesn work for
> > comercial FM
> >> Band (88 to 108MHz) but I need to TX in this frecuencys.
> >> Whe I submit my needs in the gnuradio discuss I get the next tip:
> >>
> >> Another trick to get higher frequencies is to use an image that is
> >> produced the DAC. If you program the DAC to 29.3 MHz, you'll also
> > get RF
> >> at the SampleRate +/- DAC Freq. So you'll get a signal at 128 -
> > 29.3 and
> >> 128 + 29.3. So in this case 98.7 and 157.3. The signal levels will be
> >> lower, but with the proper bandpass filter and amplifier chain,
> > you can
> >> generate a complete signal.
> >
> > It really works.No sample rate change required.
> > If you have access to a spectrum analyzer, this is easily verified.
> > Richard Lyons' book "Understanding Digital Signal Processing" has a
> > very clear explanation of the phenomenon.
> >
> > There are images produced each 64 MHz (sampling rate / 2).  Every
> > other one of them has the spectrum inverted, but that won't matter for
> > FM.  You might try googling for "Nyquist zone" or "bandpass sampling"
> >
> >  http://www.national.com/appinfo/adc/files/Undersampling.pdf
> >
> > Note that broadcast FM is much wider-band than narrow-band FM.
> > Very similar, but putting together a wfm tx block would make sense.
> >
> > If you just connect a wire to the SMA connector and the FM receiver is
> > close by you can probably hear

Re: [Discuss-gnuradio] Can I do this?

[mgray]

Another trick to get higher frequencies is to use an image that is 
produced the DAC.  If you program the DAC to 29.3 MHz, you'll also get RF 
at the SampleRate +/- DAC Freq.  So you'll get a signal at 128 - 29.3 and 
128 + 29.3.  So in this case 98.7 and 157.3. The signal levels will be 
lower, but with the proper bandpass filter and amplifier chain, you can 
generate a complete signal.  

I don't recall if there is a low pass filter on the DAC channel.  If there 
is, you'll need to remove the filter to get the images.  With a short 
piece of wire stuffed in the SMA connector, you could broadcast across the 
room to an FM receiver.


For an example of the band pass filters/RF chain, view:

http://www.kd7lmo.net/picobeacon_hardware.html

This is setup for operation in the UHF band at 445 MHz.


On Tue, 27 Sep 2005, Ilia Mirkin wrote:

> You simply can't do that. The hardware on the USRP has a DAC capable of
> 128MS/s (iirc), which means that AT MOST you could get it to put out a
> 64 MHz signal. If you shift over by 98.7MHz, then that'll be past the
> DAC's ability to reproduce an accurate signal (it will in fact fold over
> to like 98.7 - 64 MHz, I think). Coincidentally, the -c option usually
> takes Hz, not MHz, so you're shifting it over by 98.7Hz. (Didn't look at
> the actual code, so I could be wrong on that.)
> 
> If you want to transmit in the FM band, you will need an upconverter
> that will take the baseband signal out of the USRP and move it over to a
> higher frequency.
> 
> Good luck.
> 
> On Tue, 2005-09-27 at 19:19 -0500, Jorge Chávez wrote:
> > Hi gnuradio's
> > 
> > I'm trying to FM TX, can I do this with the fm_tx4.py:
> > 
> > [EMAIL PROTECTED]:/home/gr-build/gnuradio-examples/python/usrp # ./fm_tx4.py
> > -c 98.7
> >  
> > When I run it I get this:
> > 
> > [EMAIL PROTECTED]:/home/gr-build/gnuradio-examples/python/usrp # ./fm_tx4.py
> > -c 98.7 ddc_freq = 98.7
> > len(interp_taps) = 356
> > >>> gr_fir_fff: using SSE
> > len(interp_taps) = 356
> > len(interp_taps) = 356
> > len(interp_taps) = 356
> > TX d'board A: Basic Tx
> > TX d'board B: 
> > 
> > But I can't hear in a Radio (98.7MHz) what I record in audio-0(-4).dat
> > 
> > What am I doing wrong?
> > what is missing?
> > I'm thinking that it yust work for 29.326MHz, but my convencional
> > radio system is not alowed to do this frecuency.
> > 
> > Thanks for your answers, and sorry for my english..
> > 
> > Jorge Chávez
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Instaling Baseline requirment problem

[mgray]

As requested, the build sample information has been updated:

http://www.kd7lmo.net/ground_gnuradio_baseline.html



On Tue, 20 Sep 2005, Eric Blossom wrote:

> On Tue, Sep 20, 2005 at 12:18:10PM +, Robert McGwier wrote:
> > Same here:
> > 
> > Under Suse 9.3 (WHICH I HAVE HAD FOR MONTHS)  8-)   ,  xerces will not 
> > compile.  The latest version, 2_7_0 gets further into the build than 
> > before but will not build.  Since I could not figure out a single need 
> > for it,  I removed it from KD7LMO's  baseline build stuff.
> > 
> > Please let me pass along a warning.  A month ago,  I upgraded gcc and 
> > got all bold (sigh).  I attempted to upgrade pango, atk, gtk, wxgtk, and 
> > remake wxPython 2.6.1 in an abortive attempt to get beyond some of this 
> > "coloring with Crayola crayon and finger painting"  look with improperly 
> > initialized controls/broken controls, etc. have in wxGtk/wxPython.   
> > WHAT A MISTAKE.  I have been unable to go backwards and get gnuRadio to 
> > work since.  I have been completely dead in the water, unable to 
> > diagnose what was wrong other than import wx gave me "undefined symbols 
> > in pango" even after I went backwards.  I finally just pulled off my 
> > personal files and rebuilt the distribution and used the wxGtk that came 
> > with SUSE.   I admit I had other things going on during that month that 
> > interfered (the month from just north of the river Styx), but this was a 
> > painful reminder of the old addage" if it ain't broke, don't fix it 
> > unless you want to stall development.
> > 
> > Bob
> 
> Good points.
> 
> KD7LMO, can you please remove xerces from your build instructions?
> Not sure what program uses it, but it's not one of ours.
> 
> Thanks,
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Instaling Baseline requirment problem

[mgray]

Sure, I can remove the xerces stuff from the install.  I think it may have 
been required for octave, but I'm not sure.

If there are any other thoughts or suggestions, let me know.  



On Tue, 20 Sep 2005, Eric Blossom wrote:

> On Tue, Sep 20, 2005 at 12:18:10PM +, Robert McGwier wrote:
> > Same here:
> > 
> > Under Suse 9.3 (WHICH I HAVE HAD FOR MONTHS)  8-)   ,  xerces will not 
> > compile.  The latest version, 2_7_0 gets further into the build than 
> > before but will not build.  Since I could not figure out a single need 
> > for it,  I removed it from KD7LMO's  baseline build stuff.
> > 
> > Please let me pass along a warning.  A month ago,  I upgraded gcc and 
> > got all bold (sigh).  I attempted to upgrade pango, atk, gtk, wxgtk, and 
> > remake wxPython 2.6.1 in an abortive attempt to get beyond some of this 
> > "coloring with Crayola crayon and finger painting"  look with improperly 
> > initialized controls/broken controls, etc. have in wxGtk/wxPython.   
> > WHAT A MISTAKE.  I have been unable to go backwards and get gnuRadio to 
> > work since.  I have been completely dead in the water, unable to 
> > diagnose what was wrong other than import wx gave me "undefined symbols 
> > in pango" even after I went backwards.  I finally just pulled off my 
> > personal files and rebuilt the distribution and used the wxGtk that came 
> > with SUSE.   I admit I had other things going on during that month that 
> > interfered (the month from just north of the river Styx), but this was a 
> > painful reminder of the old addage" if it ain't broke, don't fix it 
> > unless you want to stall development.
> > 
> > Bob
> 
> Good points.
> 
> KD7LMO, can you please remove xerces from your build instructions?
> Not sure what program uses it, but it's not one of ours.
> 
> Thanks,
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New OTA Samples

[mgray]

As requested over the past month or so, additional over the air samples 
have been captured.  These samples will let you experiment and build GNU 
radio applications without the USRP and related RF hardware.

The samples include 60 seconds of GPS L1 C/A code (large 420MB download), 
Trunked Radio control channel with associated narrow band FM signals in 
the same capture, HD AM (basically digital AM radio), and LF (125KHz).

http://www.kd7lmo.net/ground_gnuradio_ota.html

Enjoy!





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] NTSC Demo

[mgray]

No problem.  I've posted - 

http://www.kd7lmo.net/gnuradio/ntsc_final.zip


and will try the Thesis later.  The Thesis isn't there yet because
Geocities BW limit.  If you e-mail it, I'll post it.

http://www.kd7lmo.net/gnuradio/thesis.pdf


On Mon, 20 Jun 2005, Prateek Dayal wrote:

> Thanks a lot ... I am trying to get some webspace somewhere where
> there is a larger bandwidth allocated ... In particular I am trying
> hostingzero.com which gives space out for free if you have more
> traffic 
> 
> I think we can have some gnuradio space where whoever contributing
> tothe project can put up some files even if moderated by an
> administrator ...
> 
> Regards
> 
> Prateek 
> 
> PS: mgray it would really help if you can also put up the thesis and
> the demo video on your website ...
> 
> On 6/20/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > I reposted the code at:
> > 
> > http://www.kd7lmo.net/gnuradio/tv_code.zip
> > 
> > 
> > On Mon, 20 Jun 2005, Thom Rainwater wrote:
> > 
> > > >
> > > > Hi,
> > > >
> > > > Sorry ... the correct link to the thesis is
> > > >
> > > > www.geocities.com/pmd_iitgw/thesis.pdf<http://www.geocities.com/pmd_iitgw/thesis.pdf>
> > > >
> > > > and the link to the code (Matlab) is
> > > >
> > > > www.geocities.com/pmd_iitgw/tv_code.zip<http://www.geocities.com/pmd_iitgw/tv_code.zip>
> > > >
> > > > link to the samples
> > > >
> > > > http://comsec.com/private/ch21-ntsc.cmplx-short-8MS.dat.gz
> > > >
> > > > and link to the sample monochrome avi file (made from movie_maker.m
> > > > file in the code)
> > > >
> > > > www.geocities.com/pmd_iitgw/ntsc_final.zip<http://www.geocities.com/pmd_iitgw/ntsc_final.zip>
> > > >
> > > > Please do email me if you have any comments regarding the code 
> > > >
> > > > Regards
> > > >
> > >  When I visit the link to download the code, I get an error that says that
> > > you have exceeded data transfer limit. Is there some other way I can take 
> > > a
> > > look at the code? Can someone else repost the code? I am very interested 
> > > in
> > > this. Thanks
> > >  Thom Rainwater
> > >
> > 
> > 
> 
> 
> 




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] NTSC Demo

[mgray]

I reposted the code at:

http://www.kd7lmo.net/gnuradio/tv_code.zip


On Mon, 20 Jun 2005, Thom Rainwater wrote:

> > 
> > Hi,
> > 
> > Sorry ... the correct link to the thesis is
> > 
> > www.geocities.com/pmd_iitgw/thesis.pdf
> > 
> > and the link to the code (Matlab) is 
> > 
> > www.geocities.com/pmd_iitgw/tv_code.zip
> > 
> > link to the samples 
> > 
> > http://comsec.com/private/ch21-ntsc.cmplx-short-8MS.dat.gz
> > 
> > and link to the sample monochrome avi file (made from movie_maker.m
> > file in the code)
> > 
> > www.geocities.com/pmd_iitgw/ntsc_final.zip
> > 
> > Please do email me if you have any comments regarding the code 
> > 
> > Regards
> > 
>  When I visit the link to download the code, I get an error that says that 
> you have exceeded data transfer limit. Is there some other way I can take a 
> look at the code? Can someone else repost the code? I am very interested in 
> this. Thanks
>  Thom Rainwater
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] CVS compilation problem (actually a test fails)

[mgray]

I've posted an installation guide for GNU radio that might be helpful:

http://www.kd7lmo.net/ground_gnuradio_install.html

Maybe someone can post a link from the Wiki to my site.



On Mon, 2 May 2005, n4hy wrote:

> I wasted an entire WEEKEND trying to figure this out.
> 
> Bob
> 
> 
> [EMAIL PROTECTED] wrote:
> 
> >Hi,
> >
> >I can't check the archives at the moment as lists.gnu.org doesn't want
> >to talk to anyone, but I don't remember anyone saying anything about
> >this.
> >
> >A couple of weeks ago I compiled and ran all the gnuradio code. I then
> >had a disk failure and had to rebuild the whole of my system. I
> >downloaded all of the source code again (from CVS) and rebuilt it, but
> >now I get the following error:
> >
> >  
> >
> gr_fir_fff: using 3DNow!
> 
> 
> >.
> >--
> >Ran 1 test in 0.011s
> >
> >OK
> >E.
> >==
> >ERROR: test_blks_import (__main__.test_head)
> >--
> >Traceback (most recent call last):
> >  File "./qa_kludged_imports.py", line 35, in test_blks_import
> >from gnuradio import blks
> >  File 
> > "/data/matt/usrp/gr-build/gnuradio-core/src/python/gnuradio/blks/__init__.py",
> >  line 37, in ?
> >exec "from gnuradio.blksimpl.%s import *" % (f,)
> >  File "", line 1, in ?
> >  File 
> > "/data/matt/usrp/gr-build/gnuradio-core/src/python/gnuradio/blksimpl/digital_voice.py",
> >  line 33, in ?
> >from gnuradio.vocoder import gsm_full_rate
> >ImportError: No module named vocoder
> >--
> >  
> >
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] newbie installation questions

[mgray]

Here is my installation guide for FC3.  Not perfect yet, but it might help 
you out:

http://www.kd7lmo.net/ground_gnuradio_install.html



On Wed, 27 Apr 2005, Jamie Morken wrote:

> Hi,
> 
> I am installing gnuradio on fedora core3 and am getting some errors with 
> python, I am able to test the USRP with ./test_usrp_standard_rx and 
> ./test_usrp_standard_rx, but when I try to run ./burn-basic-eeprom I get this 
> error:
> 
> Traceback (most recent call last):
>   File "./burn-basic-eeprom", line 23, in ?
> from usrp_prims import *
> ImportError: No module named usrp_prims
> 
> 
> Also I get this error when I try to run ./usrp_oscope.py:
> 
> Traceback (most recent call last):
>   File "./usrp_oscope.py", line 23, in ?
> from gnuradio import gr
> ImportError: No module named gnuradio
> 
> I checked the gnuradio archive and found a related message from about a year 
> ago:
> http://lists.gnu.org/archive/html/discuss-gnuradio/2004-03/msg00020.html
> 
> I'm not sure if the Python path variable is the problem or not though.
> 
> Thanks for your help! 
> 
> ps. I haven't used linux for a few years =)
> 
> best regards,
> Jamie Morken
> 
> 
> 
> 
> 
> 
> and/or any of the
> 
> test_usrp_standard_rx
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OTA Samples

[mgray]

I've posted some new OTA samples that include FM broadcast stations.  
Stations contain SCA (Subsidiary Communications Authorization) and RBDS 
(Radio Broadcast Data System).  The RBDS system provides song title, 
artist, station callsign, and other basic information that is displayed on 
common automotive receivers.  The RBDS signal is a 57KHz (3 x 19KHz pilot 
tone) sub carrier that is BPSK modulated at 1187.5 bps.  This is an open 
standard that would be interesting to process.

I've also posted another GPS snapshot.  I have some Octave (open source 
Matlab) that process the snapshots and provides PRN and doppler shift of 
the each GPS satellite.  I'll post the scripts later this week.

Finally, I have an updated NTSC snapshot of color bars.  The original
snapshots provided a couple weeks ago were of the wrong sideband.  NTSC is
a VSB system where the lower side band is attenuated below the video
carrier.

http://www.kd7lmo.net/ground_gnuradio_ota.html


Also provided is an udpated script for the newest version of numarray 
(1.3.1):

http://www.kd7lmo.net/ground_gnuradio_baseline.html


Hope they are useful




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] TVRX AGC Disable

[mgray]

Is there a way to disable the AGC on the TVRX (cable MODEM) board?

If a strong signal appears within the 6 MHz BW the AGC is activated and 
many weak signals are lost.  It limits the receiver dynamic range to about 
10dB.

Thanks




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Built most of gr-*

[mgray]

John,

I have a set of Over-The-Air captures of a wide variety of signals for 
download:

http://www.kd7lmo.net/ground_gnuradio_ota.html


As well as sample GNU radio code to demod and process them:

http://www.kd7lmo.net/ground_gnuradio_software.html


Hope that helps and gets you started.



On Wed, 20 Apr 2005, John Clark wrote:

> I don't have any hardware for the highspeed conversions, and have not 
> set up to use 'sound cards' etc. for
> low speed testing.
> 
> However, I have been able to get gnuradio-core, as well as several other 
> gr-* packages to compile.
> The most problem seemed to be centered on having 1) a somewhat large set 
> of additional packages
> that don't seem to have much to do with signal processing, such as 
> various cpp pre-preprocessing
> tools, or the like. If the intent was to have a package that was 
> 'portable', then having a large number
> of ancillary packages, which have not only interdependencies, but also 
> mutual exlucusions for an
> existing system configuration, seems to go counter to that goal.
> 
> Since I don't have much (like absolutely none) of anything based on an 
> existing installed python
> environment, the fact that a number of libraries and packages where 
> 'installed' to get things for
> gnuradio to compile correctly, it is of no real great difficulty, other 
> than just which ones, and what
> upstream package requirements are needed.
> 
> Moving on... Since I don't have hardware at the moment, are there some 
> examples of using simulated
> signal generators or the like in the existing cvs packages, or out on 
> the net. Also, the gnuradio web site
> has some pictures of oscope, or fft output, are those buried some where 
> in the gr-* set of code.
> 
> Perhaps next week I'll have the time to see if I can set this up on a 
> NetBSD machine, but in the mean
> time I'd like test things on the linux box I have at the moment.
> 
> Thanks
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT Baselines curved?

[mgray]

That is the shape of the 4-stage decimating CIC filter in the FPGA.  For 
now, sample at 2X or 4X the desired band width and then process using the 
host processor.  Half band filters are on the way to help correct this 
problem.


On Mon, 18 Apr 2005, Lamar Owen wrote:

> Anyone have any idea why the noise floor baselines would be curved?  Attached 
> is a png of an example.
> 
> I would have expected it to be flatter.
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] No module named wx

[mgray]

I fixed it by adding the following softlink:

ln -s ./wx-2.5.5-gtk2-ansi/wx

in the .../lib/python2.3/site-packages

directory.

Worked fine after that.  There is a wx.pth in the site-packages directory 
that Python should use to follow it, but it doesn't work.  This was a 
quick fix.

Hope that helps



On Thu, 14 Apr 2005, John Clark wrote:

> LRK wrote:
> 
> >On Thu, Apr 14, 2005 at 12:01:11PM -0500, Suvda Myagmar wrote:
> >  
> >
> >>I also got USRP hardware recently and installed the latest baseline and 
> >>gnuradio packages to test the HW. When I ran an example this is what I got:
> >>
> >>$ ./usrp_oscope.py
> >>Traceback (most recent call last):
> >>  File "usrp_oscope.py", line 26, in ?
> >>from gnuradio.wxgui import stdgui, fftsink, scopesink
> >>  File 
> >>"/home/myagmar/gr/lib/python2.3/site-packages/gnuradio/wxgui/stdgui.py", 
> >>line 24, in ?
> >>import wx
> >>ImportError: No module named wx
> >>
> >>
> >>Another thing that might give a clue to my trouble is while building cvs 
> >>gnuradio-core make check failed:
> >>
> >>$ make check
> >>
> >>
> >>>==
> >>>ERROR: test_gru_import (__main__.test_head)
> >>>--
> >>>Traceback (most recent call last):
> >>> File "./qa_kludged_imports.py", line 39, in test_gru_import
> >>>   from gnuradio import gru
> >>> File 
> >>> "/home/myagmar/gnuradio/gnuradio-core/src/python/gnuradio/gru/__init__.py",
> >>>  line 37, in ?
> >>>   exec "from gnuradio.gruimpl.%s import *" % (f,)
> >>> File "", line 1, in ?
> >>> File 
> >>> "/home/myagmar/gnuradio/gnuradio-core/src/python/gnuradio/gruimpl/freqz.py",
> >>>  line 57, in ?
> >>>   import Numeric
> >>>ImportError: No module named Numeric
> >>>  
> >>>
> >
> >Setting PYTHONPATH to /home/myagmar/gr/lib/python2.3/site-packages
> >is supposed to fix that. Doesn't for me either. Still working on why.
> >
> >There should be another "site-packages" where python is installed, in my
> >case /usr/local/lib/python2.4/site-packages. Last resort is to put files 
> >Numeric.pth and wx.pth in that directory which contain the whole path to 
> >the packages.
> >  
> >
> 
> I'll chime in on the 'easy to intuit' requirements to get any of gr-* 
> up, especially the gr-wxgui.
> Unfortunately other projects press and I have not been able to get a 
> working 'graphical' user
> environment up, when most of the antecedent 'packages' don't seem to 
> just build, and when
> they do the install seems not to place things in the 'right' places for 
> building or using the gr-*
> codes sets.
> 
> When I have time, I'll continue on.
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Installation Guide

[mgray]

Since there seems to be a lot of questions on getting all the software 
installed for GNU radio, I've put together an installation guide and shell 
scripts to hopefully greatly simplify the process:

http://www.kd7lmo.net/ground_gnuradio_install.html

All comments and suggestions are appreciated.

If they are helpful, maybe someone can post them to the Wiki or link to 
these pages from the Wiki.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segmentation fault

[mgray]

I built gcc-3.4.3 from the ground up and then built all the support 
applications and GNU radio using gcc 3.4.3.  I still get the same core 
dump if I use the --enable-sse command line argument. 

If I REMOVE this setting and build it, everything works fine.

I do have the core files and can do any other tests as desired.

Building all that stuff takes a while, even on a fast machine.  I need to 
get back to the DOS days and make a RAM drive. :)



On Tue, 5 Apr 2005, Eric Blossom wrote:

> On Mon, Apr 04, 2005 at 09:19:14PM -0700, [EMAIL PROTECTED] wrote:
> > I built FFTW with 
> > 
> > ./configure --prefix=$HOME/gr --enable-single --enable-shared
> > 
> > and wxPython-src-2.5.4.1.tar.gz
> > 
> > under Red Hat FC 3 with all updates (using up2date) and it now runs all 
> > the gnuradio-examples
> > 
> > It looks like there is some sort of problem in libfftw3f with the SSE
> > instructions.  I'm not sure why.  I thought the SSE would run on a stock
> > P4 processor.
> 
> I suspect that FC3 has patched a bug into gcc.
> 
> I run with --enable-sse all the time and don't see a problem.  
> FWIW, I don't use FC2 and FC3 because I find them excessively buggy.
> 
> Eric
> 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrper fails in usb_claim_interface

[mgray]

Are you physically plugged into a USB 2.0 port?

A system may have multiple of USB ports, but not all of them are 2.0.  
Many will be USB 1.1 (high-speed 12mbps) devices.

If you run usbtree, you can verify your connection.  The following is an 
example of the USRP connected to an USB 2.0 port.

[EMAIL PROTECTED] ~]$ usbtree
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/2p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/3p, 12M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/5p, 480M
|__ Port 1: Dev 15, If 0, Class=vend., Driver=none, 480M
|__ Port 1: Dev 15, If 1, Class=vend., Driver=none, 480M
|__ Port 1: Dev 15, If 2, Class=vend., Driver=none, 480M



On Tue, 5 Apr 2005, Larry Doolittle wrote:

> Hi -
> 
> I have an Avnet Virtex 4 evaluation board, intended for
> projects similar in concept to GNU Radio.  It uses the
> same CY7C68013 chip as USRP.
> 
> I used USRP as a software reference design, and started
> splicing in some code of my own.  I think that part is
> in good shape, after coming up to speed on SDCC etc.
> 
> When I go to download my .ihx file, usrper says:
> 
> # usrper -x load_firmware ${FOO}/usrp_main.ihx
> lt-usrper: found unconfigured FX2; needs firmware.
> usrp_open_interface:usb_claim_interface: failed interface 0
> could not claim interface 0: Device or resource busy
> lt-usrper: failed to open_cmd_interface
> # 
> 
> I am running this as root, to avoid possible permissions
> problems.  The Linux kernel is 2.6.10-9-amd64-k8, base
> distribution is debian sid.
> 
> The curious thing is that both fxload and fx2_programmer
> seem to work; with fxload, I have even confirmed (by watching
> I/O pins with a scope) that my .ihx file loads and runs.
> 
> strace shows a non-surprising:
> 
> open("/proc/bus/usb/005/005", O_RDWR)   = 3
> ioctl(3, USBDEVFS_SETCONFIGURATION, 0x7fbb2c) = 0
> ioctl(3, USBDEVFS_CLAIMINTERFACE, 0x7fbb2c) = -1 EBUSY (Device or 
> resource busy)
> write(2, 
> "usrp_open_interface:usb_claim_in"...,60usrp_open_interface:usb_claim_interface:
>  failed interface 0
> ) = 60
> 
> I found http://comsec.com/wiki?UsrpInstall, where this message
> is listed, and it says to use USB 2.0 instead of USB 1.1.
> If I read my kernel logs correctly, I _do_ have USB 2.0 active:
> 
> 2005-04-05 11:20:16.200324500 <6>usb 5-1: new high speed USB device using 
> ehci_hcd and address 6
> 2005-04-05 11:20:16.264596500 <6>usbtest 5-1:1.0: FX2 device
> 2005-04-05 11:20:16.264640500 <6>usbtest 5-1:1.0: high speed {control bulk-in 
> bulk-out} tests (+alt)
> 2005-04-05 11:20:45.881313500 <4>usb 5-1: usbfs: interface 0 claimed while 
> 'lt-usrper' sets config #1
> 2005-04-05 11:35:07.626327500 <4>usb 5-1: usbfs: interface 0 claimed while 
> 'lt-usrper' sets config #1
> 
> Anybody have a clue they can share with me?
> 
> - Larry
> 




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segmentation fault

[mgray]

I built FFTW with 

./configure --prefix=$HOME/gr --enable-single --enable-shared

and wxPython-src-2.5.4.1.tar.gz

under Red Hat FC 3 with all updates (using up2date) and it now runs all 
the gnuradio-examples

It looks like there is some sort of problem in libfftw3f with the SSE
instructions.  I'm not sure why.  I thought the SSE would run on a stock
P4 processor.

Since there seems to be a number of installation and setup issues, I'm 
going to post a complete set of build and setup instructions for GNU radio 
stuff later this week.  I'll include all the build scripts and 
instructions to get the complete system working under FC3.

On a side note, the graphical stuff is pretty nice.  It is great to get a 
live FFT of the what the USRP is seeing of a down converter.



On Sun, 3 Apr 2005, Sachi wrote:

> Hi, Eric
> 
> Toby's suggestion helped me solve the problem. If I
> configure "without" the --enable-sse option, then
> everything works well. Is --enable-sse option
> necessary here?
> 
> Thanks to you guys
> 
> Sachi
> 
> --- Eric Blossom <[EMAIL PROTECTED]> wrote:
> > On Sat, Apr 02, 2005 at 11:03:48PM -0800, Sachi
> > wrote:
> > > Hi, Eric
> > > 
> > > I have checked it with gdb, it returned:
> > > 
> > > (gdb) continue
> > > Continuing.
> > > 
> > > Program received signal SIGSEGV, Segmentation
> > fault.
> > > [Switching to Thread -1208514880 (LWP 1030)]
> > > 0x007eb73f in m2fv_64_0 () from
> > > /usr/local/lib/libfftw3f.so.3
> > > 
> > > Then gdb stopped. I didn't use any breakpoints in
> > the
> > > code. BTW: I can run the demos provided by
> > wxPython.
> > > 
> > > Can you sqeeze any information from this? Or what
> > > should I do next?
> > > Thanks for your time
> > > Sachi
> > 
> > This is good info.  It's blowing up libfftw3f, the
> > FFTW code.
> > Haven't ever seen that failure.
> > 
> > I'd suggest building fftw from source (www.fftw.org)
> > using the
> > --enable-single --enable-sse --enable-shared
> > configure options, and
> > then after it's built make sure that its "make
> > check" passes.
> > 
> > If this fixes the problem, there may be a problem
> > with the libfftw3f
> > library distributed with FC3.
> > 
> > Eric
> > 
> 
> 
>   
> __ 
> Yahoo! Messenger 
> Show us what our next emoticon should look like. Join the fun. 
> http://www.advision.webevents.yahoo.com/emoticontest
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fresh NTSC samples needed

[mgray]

I've just posted a wide variety of NTSC captures from a signal generator.  
Included are black (sync only), SMPTE color bars, solid color raster (red, 
green, and blue), ramps, and a cross hatch pattern.  Each also includes 
the sound carrier with a 1KHz test tone.

http://www.kd7lmo.net/ground_gnuradio_ota.html


Also a utility for capturing USRP signal to a file:

http://www.kd7lmo.net/ground_gnuradio_software.html


The RF output of the signal generator was used (channel 4) and down
converted to 10.7MHz for processing by the USRP.  The generator output is
an AM DSB signal, where as OTA NTSC signals are VSB where the lower side
band is supressed 1.25 MHz below the video carrier.  This shouldn't effect
the demodulator as I would guess it is a standard AM demodulator and
doesn't so any kind of LSB filtering (matched filtering).

Enjoy


On Wed, 30 Mar 2005, Prateek Dayal wrote:

> Hi,
> 
> I think that the color bars should help ... specially since we know what
> to expect. A capture of a soap or something makes a nice demonstration
> :-)
> 
> When Eric gave me the samples, he took the tuner output at 5.75 Mhz
> (center of the 6 Mhz band) and then quadrature sampled it. Therefore in
> the final samples, the video carrier was at -2.75 Mhz, Audio carrier at
> 1.75 Mhz. I think you get the picture.
> 
> Please capture may be a sec of video using a test signal generator and a
> sec of video showing some program. The color bars that Krzysztof pointed
> should help. Otherwise anything you can generate; as long as I know what
> they should look like :-)
> 
> Regards
> 
> PMD
> 
> 
> On Tue, 29 Mar 2005 13:54:42 -0700 (MST), [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Would it be helpful to capture NTSC color bars or other test signals?
> > 
> > I have an USRP and TEK signal generator.
> > 
> > Where is 0Hz IF when you capture video?
> > 
> > 
> > On Tue, 29 Mar 2005, Prateek Dayal wrote:
> > 
> > > Hi,
> > >
> > > I am testing my NTSC color decoding algorithm currently. The problem
> > > that I am facing is that the NTSC samples that I have downloaded from
> > > comsec have only a text message displayed on the screen, so it is
> > > very dificult to make out if the colors that I am getting make any
> > > sense or not.
> > >
> > > It would be very very helpful if someone could cut about 2 seconds of
> > > video with some humans or something in it so that I can make some
> > > sense out of the image or colors.
> > >
> > > Please help me out 
> > >
> > > Regards
> > >
> > >
> > 
> > 
> 
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BPSK, Costas loop

[mgray]

I've built and flown a PSK-31 transmitter on board a high altitude weather 
balloon.  The HF signal is useful for over the horizon tracking.  Although 
it wasn't done using GNU radio, all the hardware and software is open 
source.  This could be adapted to work with GNU radio:

http://www.kd7lmo.net/psk31.html

Things like building the message, varicode, modulation, etc. are all 
reusable.

On Thu, 31 Mar 2005, Robert Kelley wrote:

> That's a great source of information about PSK31, thanks.
> 
> I am especially interested in using gnuradio for PSK31.
> 
> The URL is wrong, it's psk31.htm but I found it anyway.
> 
> Chuck Swiger wrote:
> 
> > At 03:09 AM 3/31/2005 -0500, you wrote:
> >
> >> Hey everyone,
> >>
> >> I think I have a semi-decent implementation of BPSK modulation and
> >> demodulation (via a Costas loop). I wrote up some details about it at
> >> http://web.mit.edu/imirkin/www/gnuradio/bpsk.html . It seems to work
> >> with the script that I was testing it with, but I haven't actually tried
> >> anything OTA or with any *real* drift and so on. This applies into the
> >> gnuradio-core tree directly.
> >
> >
> > Hey - looks good - here's a plot of     1010 1010  0101...
> >
> >
> > http://webpages.charter.net/cswiger/bpsk.jpg
> >
> > I would be interested in using that with this description of psk31
> >
> > http://home.teleport.com/~nb6z/psk31.html
> >
> > to create a transmitter completely within gnuradio.
> > (currently I'm looping audio from linpsk)
> >
> > Any better links to psk31 details appreciated.
> >
> > --Chuck
> >
> >
> >
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] USRP Sampling

[mgray]

I have the following program to capture USRP samples and write them to a 
file.  What is a simple way to have the program capture for X number of 
samples and then stop?

Thanks



from gnuradio import gr
from gnuradio import audio
from gnuradio import usrp
from gnuradio.eng_option import eng_option
from optparse import OptionParser

def build_graph (IF_freq, filename):

fg = gr.flow_graph ()

# 256K sample rate
adc_rate = 64e6
decim = 16
mux = 0xf0f0f0f0

src = usrp.source_c (0, decim, 1, mux)
src.set_rx_freq (0, -IF_freq)

src.set_pga (0, 20)

dst1 = gr.file_sink (gr.sizeof_gr_complex, filename)
fg.connect ((src, 0), dst1)
return fg

def main ():

fg = build_graph (10.7e6, "if_sample_4m_complex.dat")

fg.start ()
raw_input ('Press Enter to quit: ')
fg.stop ()

if __name__ == '__main__':
main ()



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fresh NTSC samples needed

[mgray]

Would it be helpful to capture NTSC color bars or other test signals?

I have an USRP and TEK signal generator.

Where is 0Hz IF when you capture video?



On Tue, 29 Mar 2005, Prateek Dayal wrote:

> Hi,
> 
> I am testing my NTSC color decoding algorithm currently. The problem
> that I am facing is that the NTSC samples that I have downloaded from
> comsec have only a text message displayed on the screen, so it is
> very dificult to make out if the colors that I am getting make any
> sense or not.
> 
> It would be very very helpful if someone could cut about 2 seconds of
> video with some humans or something in it so that I can make some
> sense out of the image or colors.
> 
> Please help me out 
> 
> Regards
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] OTA Samples (GPS/HF)

[mgray]

I've posted a number of OTA (Over The Air) samples on my web page.  These
include 7.2 and 10.0 MHz captures in the HF band.  (As requested by
someone on this board).  

Also included is 2 second snap shot of GPS L1 carrier.  Should be good for 
some software work.


Captures:

http://www.kd7lmo.net/ground_gnuradio_ota.html


Sample software to listen to the captures:

http://www.kd7lmo.net/ground_gnuradio_software.html


Information on USRP system latency:

http://www.kd7lmo.net/ground_gnuradio_latency.html





___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] wxPython and FC3

[mgray]

Thanks for the information.  I did install the RPMs as well as version 
libstdc++-3.3.3-7 from FC2.  The wxPython*rpm were expecting version 
libstdc++.so.5 of the C++ libraries.

However, I have the same core dump issues.  Using the nbfm_rcv.py from the 
latest CVS gnuradio-examples it runs correctly with the --no-gui option.  
With the GUI enabled as soon as it tries to execute:

usrp_fft, fft_win1 = \
   fftsink.make_fft_sink_c (self, panel, "USRP Output", 512,
   IF_rate, 0, 100)

usrp: found usrp rev2
RX d'board A: Basic Rx
RX d'board B: Basic Rx
RF Freq  1070.0
IF freq  39843.75
len(chan_coeffs) = 397
>>> gr_fir_ccc: using SSE
len(audio_taps) = 85
>>> gr_fir_fff: using SSE
Segmentation fault (core dumped)
[EMAIL PROTECTED] py]$ 

One other note, I'm using Cygwin as my X-terminal and sending the display 
there.  

However, the usrp_oscope.py works fine and displays everything.  It auto 
scales and shows the input signals.

I guess it is back to command line only for a while...

Thanks for the help


On Thu, 24 Mar 2005, Sachi wrote:

> I also use FC3, for wxPython, my way is:
> from the download page:
> https://sourceforge.net/project/showfiles.php?group_id=10718
> download the following rpms
> wxPython2.5-gtk2-unicode-2.5.4.1-fc2_py2.3.i386.rpm
> wxPython-common-gtk2-unicode-2.5.4.1-fc2_py2.3.i386.rpm
> wxPython2.5-devel-gtk2-unicode-2.5.4.1-fc2_py2.3.i386.rpm
> 
> if you r using python 2.4, you should change them
> correspondingly. That works
> 
> Dawei
> 
> --- [EMAIL PROTECTED] wrote:
> > What is the best way to get wxPython working under
> > Fedora Core 3?  
> > 
> > I tried to download and build the source, but it has
> > been very painful.
> > 
> > When I run the program I typically get core dumps:
> > 
> > [EMAIL PROTECTED] usrp]$ ./usrp_fft.py
> > usrp: found usrp rev2
> > RX d'board A: Basic Rx
> > RX d'board B: Basic Rx
> > Segmentation fault (core dumped)
> > [EMAIL PROTECTED] usrp]$ 
> > 
> > [EMAIL PROTECTED] usrp]$ ./wfm_rcv_gui.py 10.7
> > usrp: found usrp rev2
> > RX d'board A: Basic Rx
> > RX d'board B: Basic Rx
> > usrp_standard_rx::set_decim_rate: WARNING rates >
> > 128 result in incorrect 
> > gain.
> > >>> gr_fir_fff: using SSE
> > Segmentation fault (core dumped)
> > 
> > 
> > On a good note, the O'scope works alright
> > usrp_oscope.py 
> > 
> > Thanks for any assitance...
> > 
> > 
> > The following was my last build attempt:
> > 
> > tar zxf wxPython-src-2.5.4.1.tar.gz 
> > cd wxPython-src-2.5.4.1
> > mkdir bld
> > cd bld
> > ../configure --prefix=$HOME/gr \
> > --enable-rpath=$HOME/gr \
> > --with-gtk \
> > --with-opengl \
> > --enable-debug \
> > --enable-geometry \
> > --enable-sound --with-sdl \
> > --enable-display \
> > --disable-debugreport \
> > --with-libjpeg=builtin \
> > --with-libpng=builtin \
> > --with-libtiff=builtin \
> > --with-zlib=builtin
> > 
> > make
> > make -C contrib/src/gizmos
> > make -C contrib/src/stc
> > 
> > make install
> > make install -C contrib/src/gizmos
> > make install -C contrib/src/stc
> > 
> > cd ../wxPython
> > python setup.py build
> > python setup.py install --prefix=$HOME/gr
> > cd
> > 
> > 
> > 
> > I'm using the following support packages:
> > 
> > tar zxf fftw-3.0.1.tar.gz
> > tar xzf swig-1.3.24.tar.gz
> > tar xzf cppunit-1.10.2.tar.gz
> > tar xzf sdcc-2.4.0.tar.gz
> > tar zxf xerces-c-src_2_6_0.tar.gz
> > 
> > 
> > The of the GNU radio core compiles and runs without
> > any problems.
> > 
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> >
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> 
> 
>   
> __ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/ 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] wxPython and FC3

[mgray]

What is the best way to get wxPython working under Fedora Core 3?  

I tried to download and build the source, but it has been very painful.

When I run the program I typically get core dumps:

[EMAIL PROTECTED] usrp]$ ./usrp_fft.py
usrp: found usrp rev2
RX d'board A: Basic Rx
RX d'board B: Basic Rx
Segmentation fault (core dumped)
[EMAIL PROTECTED] usrp]$ 

[EMAIL PROTECTED] usrp]$ ./wfm_rcv_gui.py 10.7
usrp: found usrp rev2
RX d'board A: Basic Rx
RX d'board B: Basic Rx
usrp_standard_rx::set_decim_rate: WARNING rates > 128 result in incorrect 
gain.
>>> gr_fir_fff: using SSE
Segmentation fault (core dumped)


On a good note, the O'scope works alright usrp_oscope.py 

Thanks for any assitance...


The following was my last build attempt:

tar zxf wxPython-src-2.5.4.1.tar.gz 
cd wxPython-src-2.5.4.1
mkdir bld
cd bld
../configure --prefix=$HOME/gr \
--enable-rpath=$HOME/gr \
--with-gtk \
--with-opengl \
--enable-debug \
--enable-geometry \
--enable-sound --with-sdl \
--enable-display \
--disable-debugreport \
--with-libjpeg=builtin \
--with-libpng=builtin \
--with-libtiff=builtin \
--with-zlib=builtin

make
make -C contrib/src/gizmos
make -C contrib/src/stc

make install
make install -C contrib/src/gizmos
make install -C contrib/src/stc

cd ../wxPython
python setup.py build
python setup.py install --prefix=$HOME/gr
cd



I'm using the following support packages:

tar zxf fftw-3.0.1.tar.gz
tar xzf swig-1.3.24.tar.gz
tar xzf cppunit-1.10.2.tar.gz
tar xzf sdcc-2.4.0.tar.gz
tar zxf xerces-c-src_2_6_0.tar.gz


The of the GNU radio core compiles and runs without any problems.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Looking for signals

[mgray]

Dan,

I can snap that for you.  What time of day do you want?  I'm in the SW US.

Any other HF bands?  

On Fri, 18 Mar 2005, Dan Gisselquist wrote:

> Hello all,
> 
> I'm looking for someone who could get me a 30 second cut of the 14 MHz band  
> from 14.0 MHz to 14.1 Mhz.  I'm hoping for roughly 30 seconds or so.  I 
> figure  
> 8 bit samples, at 250 ksps, for 30 secs -> about 7.5 Mbytes.
> 
> What I'd like is a cut, very similar to the one RFSpace shows at,
> 
> http://www.rfspace.com/images/20_meter_cw.gif
> 
> This is a great demo picture, given that it shows a diverse set of signals 
> all  
> at the same time.  My only problem is, I'd like to tinker with how it was  
> generated, the spectral analysis method, the colors in the display, etc. and  
> to do that I need a real signal.
> 
> Any takers?
> 
> Thanks!
> 
> Dan
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Missing Makefile.in

[mgray]

Yes, I have to do that with FC3 and the latest patches.  It reports the 
same error you are showing below.


On Mon, 28 Feb 2005, Joshua Lackey wrote:

> Does anyone else have to "./bootstrap" twice in a freshly checked-out
> tree?
> 
> I'm wondering if it is just my setup, but I have to "./bootstrap;
> ./bootstrap" or else the Makefile.in doesn't appear.
> 
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp> cvs -d :ext:[EMAIL 
> PROTECTED]:/cvsroot/gnuradio co gnuradio-core
>   cvs checkout: Updating gnuradio-core
>   U gnuradio-core/.buildpri
>   U gnuradio-core/.cvsignore
>   U gnuradio-core/AUTHORS
>   [...]
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp> cd gnuradio-core
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./bootstrap 
>   [ delete m4 warnings ]
>   configure.ac: installing `./install-sh'
>   configure.ac: installing `./missing'
>   src/gen_interpolator_taps/Makefile.am: installing `./depcomp'
>   src/lib/swig/Makefile.am:50: installing `./py-compile'
>   configure.ac:24: required file `config.h.in' not found
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./configure
>   checking build system type... x86_64-unknown-linux-gnu
>   [...]
>   config.status: creating Makefile
>   config.status: error: cannot find input file: Makefile.in
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./bootstrap 
>   [ delete m4 warnings ]
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> ./configure
>   checking build system type... x86_64-unknown-linux-gnu
>   [...]
>   config.status: creating Makefile
>   config.status: creating gnuradio-core.pc
>   [...]
>   config.status: executing swig_deps commands
>   [EMAIL PROTECTED]:~/src/gnuradio/tmp/gnuradio-core> 
> 
> 
> If I apply the following patch to "bootstrap", a single pass suffices.
> 
> *** gnuradio-core-old/bootstrap Mon Feb 28 15:29:38 2005
> --- gnuradio-core/bootstrap Sat Apr 10 10:59:35 2004
> ***
> *** 29,37 
> (
>   cd $dir
>   aclocal -I config
> - autoconf
> - autoheader
>   libtoolize --automake
>   automake --add-missing
> )
>   done
> --- 29,37 
> (
>   cd $dir
>   aclocal -I config
>   libtoolize --automake
>   automake --add-missing
> + autoconf
> + autoheader
> )
>   done
> 
> 
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Some nice HUM

[mgray]

Some NBFM voice signals also include a sub-audible tone for squelch
control.  These are typically in the range 67Hz to 255Hz.  You might be
hearing these.

>From additional information:

http://www.eecis.udel.edu/~dra/pl.html




On Tue, 22 Feb 2005, James Cooley wrote:

> Hi all,
> 
> OK, Got FM radio and FM stereo to work using USRP + Basic RX + microtune 
> 4937 frontend.
> 
> I'm hearing a nice hum along with whatever I tune into. Anyone else?
> 
> This is not 60Hz, but, purely guessing here, it *could* be 120Hz. Could 
> this be an image of the 60Hz somehow? Also, how do I get rid of it?
> 
> I tried constructing a notch filter after Chuck's example from NBFM 
> Something like
> 
> # insert an audio notch filter for 120 Hz
> taps = [1]  # original signal, no delay
> for i in range(1,133):  # 4.17mSec ( 1/2 cycle at 120Hz ) = 
> 132/16000
> taps = taps + [0]
> taps = taps + [1]   # signal delayed 4.17mSec cancels self at 120Hz
> notch0 = gr.fir_filter_fff (1, taps)
> notch1 = gr.fir_filter_fff (1, taps)
> 
> And stuck it in-between the demod/dsp graph and the audio sink.
> 
> Doesn't really work too well. It's too noticeable both because it's 
> within audible range and because the delay is slow enough so that you 
> can hear phase difference (kind of a slight flanger effect). Of course 
> the latter is true, it's 4.17ms delay.
> 
> -jamie
> 
> 
> 
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio