Re: [Discuss-gnuradio] Re: Cellular relay
On Mon, Sep 19, 2005 at 04:54:35PM -0400, Aaditeshwar Seth wrote: > Hi > > This is a follow-up on a mail I had sent out earlier to the list but > didn't get a reply. I found something interesting that I thought of > sharing with you guys. And it'll be great if you can tell me about some > public CDMA SDR implementations, and whether the people on this list are > thinking of doing anything about it in the future. > > Ok, so making this kind of a relay is indeed possible. And the kind of > applications it opens up are quite interesting. Have a look at > http://blizzard.cs.uwaterloo.ca/keshav/mediawiki-1.4.7/index.php/Recycling_a_billion_cell_phones > > which is my PhD supervisor's idea on reusing old cellphones. Now, when you > have this kind of a low-bandwidth cellular relay, you can have all your old > cellphones plugged in different rooms as security cameras (all cellphones > have cameras already!), or for medical survelliance, or just to do some > cool digital-home kind of stuff. So, it is indeed useful to have something > like this. And to do it, here is a small email exchange I had with people > working at a leading cellular provider. Aaditeshwar, It is a shame if I have to buy or build a basestation to get any use out of old cell phones in my home, even if I can use a USRP and GNU Radio to do it. :-) Are any cellular modes more symmetric than CDMA? Is direct phone-to-phone communication possible, even without WiFi? Do you know whether or not it is possible to get instructions for re-programming the old phones? Dave -- David Young OJC Technologies [EMAIL PROTECTED] Urbana, IL * (217) 278-3933 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Instaling Baseline requirment problem
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] gnuradio-core build failure
Dear Eric: You are very helpful! My responses to all the queries you recommend are *identical* to yours, EXCEPT for automake (and a trivial difference in uname -a): [EMAIL PROTECTED] gr-build]$ which automake /usr/bin/automake [EMAIL PROTECTED] gr-build]$ automake --version automake (GNU automake) 1.4-p6 So this looks like the source of the problem; I don't know why the OS install did this, but I will try to install at least 1.8.5 somehow. Thanks again, Weo WN6I ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CVS updates (automatic daughterboard handling)
I've just checked in a substantial set of updates that deal primarily
with automatically "doing the right thing" with the USRP and any
installed daughterboards.
The changes are in gnuradio-core, usrp, gr-usrp and gnuradio-examples.
The test case for these ideas is the revised usrp_fft.py.
It now looks like this: http://comsec.com/images/usrp_fft_example.png
The fundamental thing to notice is that it allows you to tune and set
the gain. This works regardless of what daughterboards you have
installed, and reflects the frequency and gain ranges of the
daughterboard subdevice selected on the command line.
In general, you specify the "side" and "subdevice" using the -S
command line parameter. In the typical case, just use -S a or -S b.
Conceptually, Tx and Rx daughterboards can be split into two general
categories:
Those that use both converters as a pair (boards doing quadrature up
or down conversion) and those that can use the converters
independently.
Because we're using the digital up converter in the AD9862 in "Dual
Channel Complex DAC Data Mode", both D/A outputs are related (I&Q) and
as a result, all TX daughterboards are "quadrature" boards.
On the receive side we've got a bit more variation.
The TV_RX board is *not* a quadrature board, since it only uses a
single A/D.
On the FlexRF transceiver boards (400, 900, 1200 and 2400), both the
Tx side and Rx side are quadrature.
For the Basic Rx, it all depends on how you've got it hooked up and
how you're using it. More about this later.
Subdevices. A given Tx or Rx daughterboard consists of either one or
two subdevices. Quadrature boards have a single subdevice.
Non-quadrature boards have one or two subdevices depending on the
daughterboard design.
The fundamental capabilities of a subdevice is the ability to tune and
set gain. Each subdevice has a daughterboard specific class that is
derived from db_base.py (in gr-usrp). The visible methods are:
def dbid(self):
"""
Returns integer daughterboard ID from EEPROM
"""
def name(self):
"""
Name of daughterboard. E.g., "TV Rx"
"""
def freq_range(self):
"""
Return range of frequencies in Hz that can be tuned by this d'board.
@returns (min_freq, max_freq, step_size)
@rtype tuple
"""
def set_freq(self, target_freq):
"""
Set the frequency.
@param freq: target RF frequency in Hz
@type freq: float
@returns (ok, actual_baseband_freq) where:
ok is True or False and indicates success or failure,
actual_baseband_freq is the RF frequency that corresponds to DC in
the IF.
"""
def gain_range(self):
"""
Return range of gain that can be set by this d'board.
@returns (min_gain, max_gain, step_size)
Where gains are expressed in decibels (your mileage may vary)
"""
def set_gain(self, gain):
"""
Set the gain.
@param gain: gain in decibels
@returns True/False
"""
def is_quadrature(self):
"""
Return True if this daughterboard does quadrature up or down conversion.
That is, return True if this board requires both I & Q analog channels.
This bit of info is useful when setting up the USRP Rx mux register.
"""
At this point, you're probably asking, why is he telling me all this...
As a result of these changes, when you create an instance of a usrp
source or sink, you now get an additional attribute, "db", that lets you
control the daughterboard subdevices.
u = usrp.source_c(0, 64)
u.db is a tuple of length 2.
u.db[0] contains a tuple of the subdevices for "side A"
u.db[1] contains a tuple of the subdevices for "side B"
The tuples of subdevices each have either 1 or 2 elements depending on
the daughterboard installed on the respective side. Each subdevice is
an instance of a class that's derived from db_base and exports the
methods listed above.
At this point, you have everything you need to control the daughterboards.
The -S command line option also has an "extended version" that allows
explicit selection of subdevices for cards with multiple subdevices.
Instead of just specifying, say -S a, you can specify -S a:0 or
-S a:1.
All this infrastruture has now made it possible to automatically
compute the appropriate Rx mux values given a user specified
subdevice specification. This is implemented with a combination of
the option parser and the usrp.determine_rx_mux_value function.
parser = OptionParser (option_class=eng_option)
parser.add_option("-S", "--subdev", type="subdev", default=(0, None),
help="select USRP Rx side A or B (default=A)")
...
(options, args) = parser.parse_args()
self.u = usrp.source_c(0, options.decim, 1, 0, 0)
self.u.set_mux(usrp.determine_rx_mux_value(self.u, option
AM Distortion fixed (was: Re: [Discuss-gnuradio] USRP at Ham Field Day)
At 03:48 PM 6/26/2005 -0400, you wrote: (a) trying to tune in broadcast stations on AM resulted in horrible distortion -- sounds like extreme overload and clipping; Yes - I just now realized (3 months later) that the DC-blocking / 0-restorer was missing in the AM demodulator, which causes distortion at much lower levels. That's been fixed here: http://webpages.charter.net/cswiger/hfx/ Also, just tried out a GaAsFET front-end from Advanced Receiver Research, 26db gain, 0.5 db noise, for 7-7.4Mhz, mounted right at the dipole antenna feed point at a cabin in the woods. The noise floor was 20db below usual apartment conditions. --Chuck ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
