Re: [Discuss-gnuradio] new 802.11b receiver
On Mon, Mar 24, 2008 at 1:02 AM, Mohammad Hamed Firooz <[EMAIL PROTECTED]> wrote: > Hi, > As you may know, BBN guys have developed a receiver for 802.11b. But > due to the USB limitation, they had to cut the spectrum which leads to > low SNR. We have developed a new receiver by doing some operation > (especially de-spreading) inside the FPGA (before sending data to USB). > Therefore, our receiver use the whole spectrum to abstract the data. > you can find more information and the codes in our website: > http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver So, where's the Verilog for the changed FPGA build? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- > I got the DV Dongle friday and it seems to work. I downloaded an > application to decode DStar on the computer but DStar is not very > popular in the area yet. I have not decoded any DStar voice so far. > I only did a AMBE loopback test. > > I got concerned because all the application software I downloaded on the > dv dongle website was closed source with no mention of the open source > firmware or GNU licenses. All the various voice rates in the test > software are gone. It appears to be DStar only. There is a link on the > dvdongle.com website pointing to the open source firmware project but > the link does not mention firmware source. It is possible the makers > locked out non-DStar voice rates before taking the product commercial. > > I asked on the DV Dongle Yahoo Groups list and it appears there is no > developer's SDK. There is no documentation on using what appears to be > a UDP to ascp daemon. A person replied to my query and said all IMBE > rates are available. But given the events I wonder if anyone has tried > other rates. It seems the makers are trying to make it difficult to use > this device for non-DStar stuff. > > It also appears the company making the DV Dongle is violating the terms > of the GNU License. None of the materials in the box or on the website > mention it uses GNU tools and that source is available. There is a link > to source code but the link description does not mention source code and > it goes to another site. > > So it will likely be a week or so before I can test the device due to > writing and debugging an ASCP driver. It looks like I am on my own in > figuring it out using the provided documentation. Can you clarify for me, why should the DV Dongle contents be open source? What GNU licensed code are they using that requires them to give back? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- > APCO Project 25 has quite a number of standards documents. If you look > at a list for vocoders: > > ANSI/TIA/EIA 102.BABA Vocoder Description > ANSI/TIA/EIA 102.BABB-A Vocoder Mean Opinion Score (MOS) Test > ANSI/TIA/EIA 102.BABC Vocoder Reference Test > ANSI/TIA/EIA 102.BABD Vocoder Selection Process > ANSI/TIA/EIA 102.BABD Vocoder Selection Process Tapes > > I have not looked at these standards to see the level of detail. > > There are other parts of the standard that deal with compliance on a > system level. > http://ftp.tiaonline.org/TR-8/APIC/FSITG/CAPPTG%20(06-08-004)_TIA%20102%5B1%5D.CABC-A(draft).doc > > I was recently involved in testing a device to a standard where a third > party creates the test suite and grants the certificate. > > Using a AMBE or other codec chip is part of the hardware versus software > decision. We want to do everything in software but there are > limitations. For example, the functions of the Maxim chip used in the > USRP DBS tuner could be done in software if there was sampling rates > above 4Gsps and the computing power to handle it. A hardware solution > is used because of these limitations. Because we can peek into the IMBE > black box and know that it can be easily implemented in software we tend > to discount a hardware solution. It is much like the situation with the > HDTV decoder where current PC hardware can not do all the decoding. If > a hardware MPEG-2 decoder was used, then it could be done, but it ruins > the all software solution. Agree. In the open source voice community, many times I see people try to cram something into software, even though they know it's would barely fit or likely would not. In some of the more flagrant cases I've seen, after spending great time and effort, the end result is poor voice quality (usually due to increased latency), unstable system that crashes or hangs easily, and code that is dependent on server characteristics. They're so determined to avoid a hardware solution they end up with no solution. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
On Mon, Mar 24, 2008 at 11:24 AM, Jeff Brower <[EMAIL PROTECTED]> wrote: [snip] > > Using a AMBE or other codec chip is part of the hardware versus software > > decision. We want to do everything in software but there are > > limitations. [snip] > Agree. In the open source voice community, many times I see people try to > cram something into software, even though > they know it's would barely fit or likely would not. In some of the more > flagrant cases I've seen, after spending > great time and effort, the end result is poor voice quality (usually due to > increased latency), unstable system that > crashes or hangs easily, and code that is dependent on server > characteristics. They're so determined to avoid a > hardware solution they end up with no solution. You guys do realize that the 'hardware' AMBE solutions are just software running on a TI DSP, don't you? Unlike filters or RF mixers wisely implemented in the analog domain for reasons of physics, dynamic range, and component availability AMBE is available only on chips in order to protect the ability of some to profit at the expense of freedom and flexibility for users of the technology. (I'm making no argument here about the ethics of limiting people's freedom in order to maximize profit, only pointing out the irrefutable fact it is being done. Being that this is *GNU*Radio perhaps I should be, however). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] a question about wx.App()
hello, everybody! I am reading wfm_rcv_gui.py (usrp_wfm_rcv.py), but there are something confusing me! 1, there should be a class wx.App(),from which stdapp is derived! But where can I find it, what is the pathof it? i have checked out the path:usr/lib/python2.5/sitepackages/wx-2.8-gtk2-unicode/wx, but there is nofile named App()! Where is it? 3, How can i find the entire code of Mainloop(), a method of class App()??? Thank you!!! Bill Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Gregory- > You guys do realize that the 'hardware' AMBE solutions are just > software running on a TI DSP, don't you? Have you been following this thread and mention of TI DSPs, other low bitrate codecs that run on TI DSPs (MELPe), etc? We were speculating on which underlying TI chip that DVSI had ROM'ed for their IMBE implementation, which should answer your question. > Unlike filters or RF mixers wisely implemented in the analog domain > for reasons of physics, dynamic range, and component availability AMBE > is available only on chips in order to protect the ability of some to > profit at the expense of freedom and flexibility for users of the > technology. (I'm making no argument here about the ethics of limiting > people's freedom in order to maximize profit, only pointing out the > irrefutable fact it is being done. Being that this is *GNU*Radio > perhaps I should be, however). My context in making a point about when to use software vs. hardware is solely from an engineering perspective -- get it working correctly, well and reliably, without wasting time. Know when to make the tradeoff, and move on. As good as x86 processors are and continue to become, clearly they waste millions of transistors on motherboard and software compatibility, leaving many weaknesses to be exploited by specialized chips. DSPs, FPGAs, many-core network processors are examples that highlight the situation. These vendors continue to thrive, doing better every year, just as does Intel. As for DSPs specifically, Intel has been trying to convince people of a compute world without DSPs since 1995, when they came up with NSP. Obviously it's not going to happen as long as they are tied to support for standard OS's and motherboards. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
> Can you clarify for me, why should the DV Dongle contents be open source? > What GNU licensed code are they using that requires them to give back? > > -Jeff Hello, The DV Dongle device uses open source firmware. It appears the manufacturer is not following the provisions of the GNU license as documentation in the box and the www.dvdongle.com website mentioned in the documentation has no mention of the open source firmware, GNU licenses or directly provides the source code. I am surprised that there is no open source project for the PC side of this device. I would start one but have not written too many Linux or Windows drivers. I need to find a driver guru to join the project. The SDR-14, SDR-IQ, and DV Dongle use the same ASCP protocol. My initial thinking is doing libascp libraries to handle the low level stuff. I was thinking of getting a SDR-IQ. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] top_block/flowgraph problem
I am using two TVRx modules on the same motherboard to write a 1 second
sample every minute for 30mins. theoretically I should have 60 sample sets,
collectively.
I am able to write the first sample set succesfully but all writes after
that fail!
Please take a moment to look at what I may be doing wrong.
with thanks.
+
class my_top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
usage="%prog: [options] output_filename0 output_filename1 "
parser = OptionParser(option_class=eng_option, usage=usage)
parser.add_option("-R", "--rx-subdev-spec0", type="subdev",
default=None,
help="first channel select USRP Rx side A or B
(default=A)")
parser.add_option("-r", "--rx-subdev-spec1", type="subdev",
default=None,
help="second channel select USRP Rx side A or B
(default=A)")
parser.add_option("-d", "--decim", type="int", default=256,
help="set fgpa decimation rate to DECIM
[default=%default]")
parser.add_option("-f", "--freq", type="eng_float", default=100e6,
help="set frequency to FREQ", metavar="FREQ")
parser.add_option("-g", "--gain", type="eng_float", default=None,
help="set gain in dB (default is midpoint)")
parser.add_option("-N", "--nsamples", type="eng_float",
default=960,
help="number of samples to collect
[default=960]")
parser.add_option("-t", "--time", type="eng_float", default=0,
help="length of recording in seconds [default=0]")
(options, args) = parser.parse_args ()
decim_rate = options.decim
if options.time:
options.nsamples = int(float(options.time) * 64e6 /
float(decim_rate))
else:
options.time = float(options.nsamples / (64e6 /
float(decim_rate)) )
if options.freq is None:
parser.print_help()
sys.stderr.write('You must specify the frequency with -f
FREQ\n');
raise SystemExit, 1
# setup USRP source
self.u = usrp.source_c(decim_rate = options.decim, nchan = 2)
# set up daughterboard positions and subdevices
if options.rx_subdev_spec0 is None:
options.rx_subdev_spec0 = (0,0)
if options.rx_subdev_spec1 is None:
options.rx_subdev_spec1 = (1,0)
# determine the daughterboard subdevice we're using
self.subdev0 = usrp.selected_subdev(self.u, options.rx_subdev_spec0)
self.subdev1 = usrp.selected_subdev(self.u, options.rx_subdev_spec1)
#setup Mux
mux_val0 = usrp.determine_rx_mux_value(self.u,
options.rx_subdev_spec0)
mux_val1 = usrp.determine_rx_mux_value(self.u,
options.rx_subdev_spec1)
mux_val0 |= (mux_val1 << 8) & 0xff00
self.u.set_mux(mux_val0)
if options.gain is None:
# if no gain was specified, use the mid-point in dB
g0 = self.subdev0.gain_range()
g1 = self.subdev1.gain_range()
options.gain = float(g0[0]+g0[1])/2
self.subdev0.set_gain(options.gain)
self.subdev1.set_gain(options.gain)
ddc = -19.9e6
self.subdev = (self.subdev0, self.subdev1)
#Tune daughterboards
for n in range(2):
ok, baseband_freq = self.subdev[n].set_freq(options.freq)
print "baseband Freq is: %s" %
(eng_notation.num_to_str(baseband_freq))
dxc_freq, inverted = usrp.calc_dxc_freq(options.freq,
baseband_freq,
self.u.converter_rate())
print "dxc Freq is: %s" % (eng_notation.num_to_str(dxc_freq))
print "ddc Freq is: %s" % (eng_notation.num_to_str(ddc))
self.u.set_rx_freq(n, ddc)
input_rate = self.u.adc_freq() / self.u.decim_rate()
print "Using RX d'board %s" % (self.subdev0.side_and_name(),)
print "Using RX d'board %s" % (self.subdev1.side_and_name(),)
print "USB sample rate: %s" % (eng_notation.num_to_str(input_rate))
print "Freq is set to: %s" % (eng_notation.num_to_str(options.freq))
print "Recording time is: %ss" % (options.time)
print "Mux value is: %x" % (mux_val0 & 65535)
self.num_samples = options.nsamples
#return (self, num_samples)
def __del__(self):
# Avoid weak reference error
del self.subdev
def write_file(self, file_num, file_size):
# deinterleave two channels from FPGA
self.di = gr.deinterleave(gr.sizeof_gr_complex)
self.skiphead0 = gr.skiphead(gr.sizeof_gr_complex, 1000)
self.skiphead1 = gr.skiphead(gr.sizeof_gr_complex, 1000)
self.head0 = gr.head(gr.sizeof_gr_complex, file_size)
self.head1 = gr.head(gr.sizeof_gr_complex, file_size)
self.dst0 = gr.file_sink(gr.sizeof_gr_complex
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- >> Can you clarify for me, why should the DV Dongle contents be open source? >> What GNU licensed code are they using >> that requires them to give back? > > The DV Dongle device uses open source firmware. Do you mean inside the Dongle? If so, which firmware? > It appears the manufacturer is not following the provisions of the GNU > license as documentation in the box and the www.dvdongle.com website > mentioned in the documentation has no mention of > the open source firmware, GNU licenses or directly provides the source code. > > I am surprised that there is no open source project for the PC side of this > device. I would start one but have not > written too many Linux or Windows drivers. I need to find a driver guru to > join the project. > > The SDR-14, SDR-IQ, and DV Dongle use the same ASCP protocol. My initial > thinking is doing libascp libraries to > handle the low level stuff. I was thinking of getting a SDR-IQ. Is it Moetronix that is promoting the ASCP (Amateur Station Control Protocol) protocol? I can find very few references to it. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about wx.App()
On Mar 24, 2008, at 11:02 AM, Bill Stevenson wrote: 1, there should be a class wx.App(), from which stdapp is derived! But where can I find it, what is the path of it? i have checked out the path: usr/lib/python2.5/sitepackages/wx-2.8-gtk2-unicode/wx, but there is no file named App()! Where is it? 3, How can i find the entire code of Mainloop(), a method of class App()??? You need to browse the original source code to wxWidgets and wxPython for those. The stuff installed where you mention is either PY code or SO libraries (make from compiled C++). You can glean a little from code fragments in (I think; starting from where you left off): _code.py and _code_.py ... but these don't really help a lot. Looking at the source codes helps a bit more (I recently did exactly what you are trying to do). You can find the original C++ code to wx.App in the wxWidgets source. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
- Start Original Message - Sent: Mon, 24 Mar 2008 11:33:26 -0600 (CST) From: "Jeff Brower" <[EMAIL PROTECTED]> To: "Eric Cottrell" <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > Eric- > > >> Can you clarify for me, why should the DV Dongle contents be open source? > >> What GNU licensed code are they using > >> that requires them to give back? > > > > The DV Dongle device uses open source firmware. > > Do you mean inside the Dongle? If so, which firmware? >From the information on the DV Dongle list the shipping firmware is the same >as on the moetronix.com web site. http://www.moetronix.com/dvdongle/ > > > It appears the manufacturer is not following the provisions of the GNU > > license as documentation in the box and the www.dvdongle.com website > > mentioned in the documentation has no mention of > > the open source firmware, GNU licenses or directly provides the source code. > > > > I am surprised that there is no open source project for the PC side of this > > device. I would start one but have not > > written too many Linux or Windows drivers. I need to find a driver guru to > > join the project. > > > > The SDR-14, SDR-IQ, and DV Dongle use the same ASCP protocol. My initial > > thinking is doing libascp libraries to > > handle the low level stuff. I was thinking of getting a SDR-IQ. > > Is it Moetronix that is promoting the ASCP (Amateur Station Control Protocol) > protocol? I can find very few > references to it. Yes, I think it is Moetronix that developed it for the SDR products. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 proof computer.
Philip Balister wrote: On Tue, Mar 18, 2008 at 1:45 PM, Per Zetterberg <[EMAIL PROTECTED]> wrote: Hi All, I am about to buy a new computer. Preferably a laptop. However, in the future I may be using USRP2. Is there any Dell laptop that can be recommended (my university has a deal with Dell) ? Mine worked fine with my old Dell 600m. I think he was asking about the USRP2, which isn't out yet. Built-in gigabit ethernet is a good start. Dual cores would be nice as well. I wouldn't use a gigabit ethernet PCMCIA or Cardbus card, since that will be slow. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Release 3.1.2 available for download
GNU Radio release 3.1.2 is now available: ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.1.2.tar.gz ftp://ftp.gnu.org/gnu/gnuradio/gr-howto-write-a-block-3.1.2.tar.gz Release 3.1.2 is a feature and maintenance release, incorporating numerous bug fixes and new functionality. Please refer to the release log for futher details: http://gnuradio.org/trac/wiki/Release3.1Branch Instructions for installation may be found at: http://gnuradio.org/trac/wiki/BuildGuide Source code-based installation of GNU Radio requires ensuring the build prerequisites are installed on your system, followed by the traditional 'configure' and 'make' process. See the OS specific instructions at the above wiki page to accomplish this. Binary packages for Ubuntu 7.10 (both 32- and 64-bit versions) are available: http://gnuradio.org/trac/wiki/DebianPackages -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Impulse response USRP DAC<->ADC
Per Zetterberg wrote: Hi All, I connected the DAC of the USRP directly to the ADC (basic db, 50ohm cable), 2MHz sample-rate. The impulse responses I get are: h1=[0,-2,2,-7,8,-6,314,479,-47,-161,-124,-103,-79,-63,-50,-39,-29,-23,-17,-1 4,-13,-9,-7,-5,-4,-3,-3,-2,-1,-3,-3]; h2=[0,-1,-1,0,-2,2,22,274,208,-77,-79,-71,-53,-46,-36,-28,-23,-17,-15,-12,-1 0,-7,-5,-4,-4,-3,-4,-2,-2,-2,-1,-2]; Where h1 is with "set_adc_buffer_bypass" and h2 without it. Does this make sense ? Yes, this looks reasonable. You are seeing a hole at DC because of the low frequency cutoff of the transformers. If you used the LFRX and LFTX instead of the BasicRX and BasicTX, you wouldn't see the hole there. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new 802.11b receiver
Brian Padalino wrote: On Mon, Mar 24, 2008 at 1:02 AM, Mohammad Hamed Firooz <[EMAIL PROTECTED]> wrote: Hi, As you may know, BBN guys have developed a receiver for 802.11b. But due to the USB limitation, they had to cut the spectrum which leads to low SNR. We have developed a new receiver by doing some operation (especially de-spreading) inside the FPGA (before sending data to USB). Therefore, our receiver use the whole spectrum to abstract the data. you can find more information and the codes in our website: http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver So, where's the Verilog for the changed FPGA build? Considering the amount of research in 802.11 networks, I'm sure it will be extremely helpful for someone in the future who might want to modify your implementation for you to host the Verilog code... just as Matt was nice enough to provide you his FPGA code for the USRP ;) Maybe make it a separate archive that you are hosting. Nonetheless, cool and thanks for sharing! I'm sure someone will poke around with this. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new 802.11b receiver
On Mon, Mar 24, 2008 at 04:19:48PM -0400, George Nychis wrote: > > > Brian Padalino wrote: >> On Mon, Mar 24, 2008 at 1:02 AM, Mohammad Hamed Firooz >> <[EMAIL PROTECTED]> wrote: >>> Hi, >>> As you may know, BBN guys have developed a receiver for 802.11b. But >>> due to the USB limitation, they had to cut the spectrum which leads to >>> low SNR. We have developed a new receiver by doing some operation >>> (especially de-spreading) inside the FPGA (before sending data to USB). >>> Therefore, our receiver use the whole spectrum to abstract the data. >>> you can find more information and the codes in our website: >>> http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver >> >> So, where's the Verilog for the changed FPGA build? >> > > Considering the amount of research in 802.11 networks, I'm sure it will be > extremely helpful for someone in the future who might want to modify your > implementation for you to host the Verilog code... just as Matt was nice > enough to provide you his FPGA code for the USRP ;) > > Maybe make it a separate archive that you are hosting. > > Nonetheless, cool and thanks for sharing! I'm sure someone will poke > around with this. > Is there GPL'ed code behind the "click through"? If so, that's problematic. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sense spectrum by usrp_spectrum_sense.py
Hi All, I am using usrp_spectrum_sense.py 1400M 2000M -F 512 -d 16 --tune-delay 1e-3 --dwell-delay 10e-3 to sense the spectrum. In main_loop(tb), I print m.center_freq and m.data. freq_step = 0.75 * usrp_rate=0.75*(64M/16)=3M. So m.center_freq[0]=1401.5M, m.data[0]~m.data[511] are 512 bins corresponding to m.center_freq[0]; m.center_freq[1]=1404.5M, m.data[0]~m.data[511] are 2nd 512 bins corresponding to m.center_freq[1], and so on. There are some comment lines say: # m.data are the mag_squared of the fft output (they are in the # standard order. I.e., bin 0 == DC.) # You'll probably want to do the equivalent of "fftshift" on them # m.raw_data is a string that contains the binary floats. # You could write this as binary to a file. So actually, for each 512 bins, (m.data[0]) to (m.data[255]) are mag_squared values for (m.center[0]) to (m.center[0] +freq_step/2), and (m.data[256]) to (m.data[511]) are mag_squared values for (m.center[0]-freq_step/2) to (m.center[0]). Am I right? How to use fftshift here? Dose fftshift(m.data) give me regular order? Are fftshift(m.data) mag_squared values corresponding to [(m.center[0]-freq_step/2):(m.center[0]+freq_step/2)]? If I plot all m.data or fftshift(m.data) versus all the m.center_freq from 1400M to 2000M, I should get the whole spectrum from 1400M upto 2000M. Did I do right here? Can I get time domain signal if I do ifft(m.data)? I suppose not. Because m.data are mag_squared rather than mag. If not, how can I get the time-domain signal before fft, from 1400M to 2000M? Thanks, Brook -- View this message in context: http://www.nabble.com/Sense-spectrum-by-usrp_spectrum_sense.py-tp16261178p16261178.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new 802.11b receiver
Quoting George Nychis <[EMAIL PROTECTED]>: Brian Padalino wrote: On Mon, Mar 24, 2008 at 1:02 AM, Mohammad Hamed Firooz <[EMAIL PROTECTED]> wrote: Hi, As you may know, BBN guys have developed a receiver for 802.11b. But due to the USB limitation, they had to cut the spectrum which leads to low SNR. We have developed a new receiver by doing some operation (especially de-spreading) inside the FPGA (before sending data to USB). Therefore, our receiver use the whole spectrum to abstract the data. you can find more information and the codes in our website: http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver So, where's the Verilog for the changed FPGA build? Considering the amount of research in 802.11 networks, I'm sure it will be extremely helpful for someone in the future who might want to modify your implementation for you to host the Verilog code... just as Matt was nice enough to provide you his FPGA code for the USRP ;) Maybe make it a separate archive that you are hosting. Nonetheless, cool and thanks for sharing! I'm sure someone will poke around with this. - George Sure, I will probably post the Verilog codes by tomorrow. Right now, I am trying to make it more readable and neat. Sorry for the delay. -- hamed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Signal processing block compiling problem
Hey Everyone, To whoever can help me out, I'm trying to make my own signal processing block. I've gotten to the point where I run the make file, but I keep getting the following error: "/usr/bin/ld: cannot find -lfftw3f" This even occurs if I try to compile the howto example. Another member on my team has installed FFTW3, so I'm not sure why I am getting this error. Can anyone help me out? Thanks! Jon Pendlum Purdue University Undergrad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Gregory Maxwell wrote: On Mon, Mar 24, 2008 at 11:24 AM, Jeff Brower <[EMAIL PROTECTED]> wrote: [snip] > Using a AMBE or other codec chip is part of the hardware versus software > decision. We want to do everything in software but there are > limitations. [snip] Agree. In the open source voice community, many times I see people try to cram something into software, even though they know it's would barely fit or likely would not. In some of the more flagrant cases I've seen, after spending great time and effort, the end result is poor voice quality (usually due to increased latency), unstable system that crashes or hangs easily, and code that is dependent on server characteristics. They're so determined to avoid a hardware solution they end up with no solution. You guys do realize that the 'hardware' AMBE solutions are just software running on a TI DSP, don't you? Hello, That is what I meant by "peeking in the black box". :) Unlike filters or RF mixers wisely implemented in the analog domain for reasons of physics, dynamic range, and component availability AMBE is available only on chips in order to protect the ability of some to profit at the expense of freedom and flexibility for users of the technology. (I'm making no argument here about the ethics of limiting people's freedom in order to maximize profit, only pointing out the irrefutable fact it is being done. Being that this is *GNU*Radio perhaps I should be, however). Well, after being part of a weird process where my employer had to sign a NDA and get an account to access one small area of a company's site to look at one datasheet for a hardware chip my employer was considering, I think DVSI is reasonable in providing AMBE2000 documentation freely on their website even if it is marked confidential. Hardware companies should be in the business of providing hardware. Some companies feel that hiding how to interface to the hardware gives them a competitive advantage and it seems some companies go to extremes. I thought about the issues of including IMBE support in GNU Radio but did not think it would spark a lively discussion. I consider the other long-term GNURadio developers like EB to have a better handle on these issues. I just use and write GNURadio code as my hobby of learning about and building SDR. I think it is neat that when I have an interest in some digital mode I can code a receiver and learn some DSP techniques. So if it is decided not to include IMBE support in GNURadio then I will still likely write it for my own private use. On another note, I found some example ASCP source code for the RF Space SDR-14 that I can modify to use with the DV Dongle. I got off on the wrong foot on DV Dongle list but I got a surprise tonight of the AMBETest application posted to the web site. This is a good start but I may still need to write some of my own code. http://www.moetronix.com/files/ambetest103.zip If I modify the SDR-14 files to work on the DV Dongle and get a C++ API for my experiments then I plan to feed that back to the DV Dongle project. They need some example files if they expect software developers to use it for other modes. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Eric- > > >> Can you clarify for me, why should the DV Dongle contents be open > > >> source? What GNU licensed code are they using > > >> that requires them to give back? > > > > > > The DV Dongle device uses open source firmware. > > > > Do you mean inside the Dongle? If so, which firmware? > > From the information on the DV Dongle list the shipping firmware is the same > as on the moetronix.com web site. > http://www.moetronix.com/dvdongle/ Hmm. Yes it does seem they are saying everything inside the Dongle is open source. But I don't see how they can do that since as far as I know, DVSI has never provided open source for IMBE or AMBE. I'm going to guess that if you pin down Moetronix, they will tell you the open source refers to the Atmel 91SAM7S microcontroller that's in there, not the TI DSP. I would further guess that since there is a hardware 'boundary' between the Atmel and the DSP (most likely one of the "McBSP" simple synchronous serial ports found on many TI DSPs), they will tell you they don't face a GPL requirement to show the DVSI source. I.e. it looks like a brick and they don't know what's in it. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
