Martin-
> On Tue, Feb 14, 2012 at 09:11:19AM -0500, Clark Pope wrote:
>> Without a monetization strategy I don't see how the gnu radio project gets
>> much past its current state. The problem
>> is the functionality of a prototyper or student is implemented in about 20%
>> of the effort for a fu
Ed-
> On 2/15/12 11:31 AM, Jeff Brower wrote:
> > GNU Radio is owned by National Instruments .
>
> !
>
> You are confusing GnuRadio with Ettus Research.
>
> GnuRadio is an open source SDR framework.
>
> Ettus is the manufacturer of
All-
I'm looking for advanced developers who are interested in taking our OpenMP
accelerator and creating a demo GNU radio
application.
The accelerator is a 2.5 Teraflop (32-core) PCIe card with a 1 GBe port and is
programmed via OpenMP. The objectives
are twofold:
-fast response / low late
Tom-
> Thanks Matt, Eric and Jonathan (hope I didn't forget anyone. :-) ).
>
> We greatly appreciate the information and need to think about stuff on
> our end. I've been deliberately vague about our application (not that
> I could really explain it even if I felt authorized discuss it). The
>
Matt-
> We are currently working on a fix for the problems with compiling
> under the ISE 11. We believe it to be a problem with ISE 11,
> since the design works fine under ISE 10, but have not gotten
> very far. Any help anyone can provide on this would be much
> appreciated.
I didn't see ISE
Ian-
> Perhaps? We only have two USRP2s and 2 XCVR2450s. However,
> if it was the SD card, I would think both XCVR2450s should
> have the problem. Actually, even the better of the two
> occasionally fails, so I can't be sure.
If you rule out the SD card, then is there a way you and Manav can comp
NI has a reputation for fiercely protecting their patents. They sued The
MathWorks
over Simulink in a lengthy and hard-fought case and won in a jury trial in
2003.
This is why, to this day, you can't change source block parameters via dialog
box or
other visual or "control panel" means while
Don-
> I'm not going to get all "awestruck" about the guy. No one is worthy of
> that. He
> may be your friend, but this is just business. Nothing personal.
After seeing 100s of engineers and projects and companies go by in my 30 years
of
engineering, I can say you probably ought to be awest
Don-
> But what happens
> when your project won't fit into the square form factor? What if you
> have this great idea but can only fit into the form factor of say a cell
> phone... then what? I'm not the only one with the same idea... Look at
> the beagleboard guys doing their USRP work.
The B
Ettus Guys-
> http://www.army.mil/-news/2010/01/27/33577-no-knob-radio-the-future-of-warfighter-communications/
>
> "No-knob" radio: the future of Warfighter communications?
After as week, this brings up a question: is there supposed to be an official
PR or other announcement about the
acquisit
asking such questions.
I can see I'm probably being annoying, so I'll keep my questions about an NI
announcement to myself from this point.
-Jeff
> On 02/12/2010 04:43 PM, Jeff Brower wrote:
>> Ettus Guys-
>>
>>> http://www.army.mil/-news/2010/01/27/33577-no-knob-
Tracey-
> I was able to place and route the design on ISE 11.4 using a 'high' effort
> and ensuring that the speed grade selected is -5 (that really made a
> difference of about 20MHz in the speed of the final design). However, when
> it comes time to generate the bitstream, it complains about the
John-
> I have a USRP2 and I'm interested in doing an experiment where I'd like to
> simply use the USRP2 as an A/D and D/A device, essentially disabling the RF
> tuning portions. The signal I'm trying to digitize is a stream of digital
> TTL pulses. I assume that the best way to interface to th
Philip-
> On 03/16/2010 06:51 AM, halidziya yerebakan wrote:
>> Hi all;
>>
>> Thanks to Mr. Balister I run USRP on BeagleBoard (
>> http://www.opensdr.com/node/17) . But it doesn't give any sound when I try
>> to listen FM radio. I think there is some mismatch in sampling rates or data
>>
z? That's way slow... what is the reason?
-Jeff
> On Tue, Mar 16, 2010 at 9:59 PM, Jeff Brower wrote:
>
> Philip-
>
> > On 03/16/2010 06:51 AM, halidziya yerebakan wrote:
> >> Hi all;
> >>
> >> ? ? ? ? T
Per-
> If we had an fpga image that allowed us to store samples on the USRP2
> that would be very benefitial, at least for me. Then one could test
> algorithms with 100MHz sample-rate. Yes, it would not be possible to
> use the channel continously. Receiving 1ms of samples would take 4ms to
> uplo
Matt-
We're working on a project at Signalogic to interface one of our DSP array PCIe
cards to the USRP2. This would
provide a way for one or more TI DSPs to "insert" into the data flow and run
C/C++ code for low-latency and/or other
high performance applications. The idea is that we would mod
Firas-
>> We're working on a project at Signalogic to interface one of our DSP array
>> PCIe cards to the USRP2. This would
> ?>provide a way for one or more TI DSPs to "insert" into the data flow and
> run C/C++ code for low-latency
>> and/or other high performance applications. The idea is
Firas-
>> From: Jeff Brower
>>
>> Firas-
>> A couple of brief comments:
>> 1) Sounds like this was a
>> high-speed data acq card, optimized for streaming, not an accelerator
>> card. How big was the
>> FIFO?
>
> The FIFO was 64MByte.
That&
George-
>> Thanks for the reply George. I'm still looking for a little more
>> information on this topic.
>>
>> - What is PMT
>
> http://gnuradio.org/redmine/wiki/1/TypePMT
>
>> - Why was m-block removed
>
> http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html
>
>> - Has anyone measured
Veljko-
> I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but
> the delay was too long and inconsistent. I can't remember the exact
> figures, but definitely up to milliseconds.
Do you mean two USRP2s back-to-back? Or both connected to motherboard ports?
-Jeff
> 2010/4/6 George
George-
> Jeff, I definitely agree that buffering also adds significant latency. How
> much of the MAC can you get around? I just think that, there are a number
> of people who want the flexibility of the SDR, but want to do MAC research,
> and current common SDR architecture is just not good en
Philip-
> On 04/06/2010 04:19 PM, George Nychis wrote:
>> Jeff, I definitely agree that buffering also adds significant latency. How
>> much of the MAC can you get around? I just think that, there are a number
>> of people who want the flexibility of the SDR, but want to do MAC research,
>> and
Charles-
>> I would tend to blame Linux and buffering more than GbE itself (MAC + PHY).
>> Here is an interesting doc where the
>> researchers were asking similar questions:
>>
>> http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf
>>
>> I'm not sure yet how much buffering is d
George-
>> Did you see my previous post about the accelerator PCIe card? To some
>> extent the Microsoft approach is what we're
>> doing. But we want to stay compatible with USRP2 hardware so we connect
>> GbE to the accelerator card; non MAC-related
>> dataflow is PCIe from there. Buffering re
George-
>> What I got from your paper is that the matched filter approach for
>> fast packet detection would not work in an OFDM setting. What about
>> fast ACK generation? Would it require an IFFT implementation on the
>> USRP? Would it help much?
>
> It's a good question, and something I haven't
Marcus-
> On 04/06/2010 09:44 PM, John Gilmore wrote:
>>> Which part of the Linux issue... sustained throughput or latency? I
>>> wouldn't be surprised to find that latency
>>> hasn't
>>> improved substantially because it's not a priority for server software.
>>> Even VoIP applications are not
John-
>> Which part of the Linux issue... sustained throughput or latency? I
>> wouldn't be surprised to find that latency
>> hasn't
>> improved substantially because it's not a priority for server software.
>> Even VoIP applications are not concerned
>> about a 1 msec improvement... whereas t
Matt-
About Vikram's 10/100 mode question, we were wondering if it's a design flaw;
i.e. something wrong from the start in
the original opencores.org source, or if it's fixable but hasn't been a high
priority item given USRP2's high data
rate requirements. But then I found this post:
http://
Matt-
>> About Vikram's 10/100 mode question, we were wondering if it's a design
>> flaw; i.e. something wrong from the start in
>> the original opencores.org source, or if it's fixable but hasn't been a high
>> priority item given USRP2's high data
>> rate requirements. But then I found this p
Matt-
>> My understanding is that it takes 3 BUFGs and one DCM for tri-mode (maybe
>> one more of each for RGMII support but I
>> don't see that) and, between this and other USRP2 needs, you ran into the
>> limit of 8. Is that accurate? Or would
>> 10/100/1000 support would take more than 3...
Catalin-
> On Mon, Apr 12, 2010 at 12:00 PM, wrote:
>> Date: Mon, 12 Apr 2010 16:02:43 +0800
>> From: Liang Xin 缐>> Subject: [Discuss-gnuradio] About EEPROM and FX2(68013a) USB interface
>> in USRP
>> To: discuss-gnuradio@gnu.org
>> Message-ID:
>>
>> Content-Type: text/p
Per-
> I also have a xcvr2450 that won't lock sometimes. This is at 2.4GHz.
>
> Also an issue about IQ imbalance:
>
> I am measuring IQ imbalance. The values are generally quite good.
> However, one thing I don't understand is that the mirror frequency
> doesn't turn up on exactely "-f" but a few
Marcus-
Your sentiments are understandable. I know the feeling. But please allow me
to give an a different perspective.
I've posted for years (since 1999) 1000s of times on DSP, audio, speech, MATLAB
and FPGA groups -- on voluntary basis,
because I want to. I can't count the number of times
Marcus-
> On 04/25/2010 02:04 PM, Jeff Brower wrote:
>>
>>
>> Yes I know such positive results are a minority of the posts you're thinking
>> about. And yes it takes patience and
>> can
>> be exasperating, but isn't that generally true of raisin
Steve-
> Further to my problem trying to discover the USRP2. From a cold start
> (the USRP2 was left without power since my last posts) I configure the
> GigE port using ethtool and enable TX pause frames (this seems to be
> necessary magic on my PC). I then run this at the command line:
>
> while
Hanks-
> I am new to GNU Radio. Currently I am considering to implement basic software
> radio and signal processing on TI DSP environment, such as TI TMS320C674x and
> C647x DSPs and the evaluation boards.
>
>
> I know GNU radio are usually running on PC environments for Linux or Window
> OS,
>
owd.
-Jeff
> ____
> ·¢¼þÈË£º Jeff Brower
> ÊÕ¼þÈË£º Hanks
> ³ ËÍ£º discuss-gnuradio@gnu.org
> ·¢ËÍÈÕÆÚ£º 2010/7/9 (ÖÜÎå) 6:41:05 ÏÂÎç
> Ö÷ Ì⣺ Re: [Discuss-gnuradio] Can GNU Radio run on TI DSP environment?
>
> Hanks-
>
>> I am new to GNU Radio. C
om/archive/2010/04/27/texas-instruments-embraces-linux-for-c64x-dsps-395817.aspx
also you could post on e2e.ti.com and ask TI guys.
-Jeff
> ________
> åä»¶äººï¼ Jeff Brower
> æ¶ä»¶äººï¼ Hanks
> æ éï¼ discuss-gnuradio@gnu.org
> åéæ¥æï¼
>
>
>
>
>> Date: Fri, 30 Jul 2010 10:19:35 -0700
>> From: dhalp...@cs.washington.edu
>> To: m...@ettus.com
>> CC: cepop...@hotmail.com; discuss-gnuradio@gnu.org
>> Subject: Re: [Discuss-gnuradio] gnuradio land speed record?
>>
>> > On 07/30/2010 09:33 AM, Cl
Elvis-
> On Dec 14, 2010, at 11:14 PM, Matt Ettus wrote:
>
Since the OMAP has a GPU incorporated does that mean that we could use it
for processing? Is there a CUDA equivalent for this type of GPU?
>>
>>
>> Doug has it pretty correct here. This is one of those areas I would call
>> the
To the students:
Suggest that you give Matt your Professor/Advisor contact info, and also get
your Prof to send a note to Matt on your
behalf.
Bringing your Prof into the dialog is a good idea for several reasons. For
example, there might be an opportunity to
set up an instructional lab or oth
Jamie-
> Hi Brian,
>
> That sounds like a pretty good system. I should say right
> off the bat that if I am involved to make this I would want
> to add a clause in the open source hardware license to not
> allow the hardware to be used for military applications. I
> think it is important to stat
Alexander-
> okay here are my 2 cents
>
> 2- TI actually offers all the tools you need to develop for their DSP for
> free, I can vouch for the C64x+ DSP since
> that's what I have experience using. You can download and look at the
> supported DSP for the free download from
> http://software-d
Don-
> Hi Jeff: interesting reply. I remember when TI and MOT did exactly the
> opposite. TI had the 9900 processor series that was much better than
> anything on the market, and essentially blew it off. MOT had the
> 6800/68000 series, that became moderately successful. The most crippled
> proces
> On 04/19/2011 01:10 PM, i...@agile-sdr-solutions.com wrote:
>>
>> Dear Matt,
>>
>> We honestly went through every material in search on Google but we
>> couldn't locate a single article published successful testing for
>> STBC/SFBC.
>>
>> For whatever reason, we would like to know, if you can con
Alexander-
Well said.
I would add an additional comment about "Linux as a model" for GNU Radio.
Linux exists at least in part because of
widespread developer anger with Microsoft in the 1990s. Guys like Ballmer
simply couldn't think straight and failed
to respect developers' time and effort.
Gregory-
> On Mon, May 9, 2011 at 2:59 PM, Andrew Lentvorski wrote:
>> No embedded engineer who values his job will touch a GPL piece of code with
>> a 10 foot pole. Â Period.
>
> and these are folks who will be out-competed in the marketplace by
> competitors who are more agile and less phobic.
Martin-
:
:
> To a non GPL-philic, non-nerd, why choose GNU Radio? There is no reason:
> - Matlab is generally free of charge for universities
> - Matlab is used by the industry
> - Matlab is better documented and has a wider user base
> - Simulink has more blocks already incorporated
> - Mat
Martin-
> On Tue, May 10, 2011 at 09:07:38AM -0500, Jeff Brower wrote:
>> Martin-
>>
>> > To a non GPL-philic, non-nerd, why choose GNU Radio? There is no reason:
>> > - Matlab is generally free of charge for universities
>> > - Matlab is used by the i
Michael-
> Hi Alexander - I think Martin & Tom covered that GNU Radio
> is quite capable of being programmed for the basic receiver
> processing. You might need to play around a bit with your
> DSP blocks, but otherwise I think GNU Radio's data
> processing is up to the task.
>
> On May 23, 2011,
Marcus-
>> Alexander is asking excellent questions and I'm surprised at the tepid
>> response -- he's got like 4 replies so far? He's the prototype GNU
>> radio user who needs to maintain his group's IP, he should be
>> receiving "how to's", not "INALs". -Jeff
> Actually, IANAL is a perfectly-vali
Colby-
>> How do the companies write closed-source drivers for the Linux Kernel
>> without running into GPL2 issues? I can only recall that there is a
>> "user-land" and a "kernel-land" driver, where the "kernel-land" is the
>> only part that is open source. Is this correct?
>>
>> Perhaps that met
Bob-
> It appears that TI has withdrawn the free offering of a linux version of
> its compilers that I pointed out earlier (in October) at this link.
>
>
> https://www-a.ti.com/downloads/sds_support/targetcontent/LinuxDspTools/download.html
>
> This is very disappointing. Without free tools
Pablo-
> The exact question is: Were, in the python code of the GnuRadio core,
> can I insert the Driver that i mention? I am reading the python code
> but i can not find were the code read/send data to the USB (to
> substitute it with the PCI control code). The other question is were
> in the Ver
Ryan-
> I have been working on modifications to the USRP board so that I can pass
> a gating signal through the basic RX daughterboard to gate signal
> collection for a pulsed radar application. This is somewhat working, but I
> am having problems with data alignment when stopping and starting the
Ryan-
Could you hack the FX2 firmware and reprogram it to clear its internal buffers
and/or reset pointers and counters on
Reset? Or if that's already being done, then do it again at some point
depending on a signal from the FPGA and/or
host driver?
I found some threads discussing FX2 firmware
Marcus-
> > It appears that you do not have the current firmware (and possibly
> > FPGA image) installed on the SD Card. Please grab the latest from:
> > http://gnuradio.org/releases/usrp2-bin/trunk/
> >
> > Eric
> >
> >
> set-curmudgeon-mode(True)
>
> Segmentation Fault on the host should *neve
Firas-
> Has anyone tried to run USRP1 without PC?
>
> I have an application where a friend supported me with a standalone USRP
> FPGA image. I used the PC only to load this image to the USRP using gnuradio
> blocks/tools. After that I can plug-off (disconnect) the USB cable from the
> PC and USR
Milo-
> I found sine waves will be terribly distorted when they are generated at
> relatively high frequency(above 5khz) from signal source in GRC. I set the
> sampl_rate of scope sink to 2Ghz(high enough, I think), and there are always
> spikes on generated sine wave. This problem is especially d
Ilkyoung Kwoun-
> Thank you for your advice. Actually I am aware of basic characteristics of
> half band filter. It is very well explained in Rick Ryon's "Understanding
> Digital Signal Processing (2nd Ed.)" (
> http://www.amazon.com/Understanding-Digital-Signal-Processing-2nd/dp/0131089897/ref=sr
Juha-
> Who has had success with 11.x? I'm eager to start working with the
> usrp2 code, but I cannot get the tools to work.
>
> I was on the phone today for 30 minutes with the local Xilinx sales
> rep and they just won't allow me to get 10.1.03. You can't buy it, you
> can't get it for free, and
Cosmin-
> Hey,Could it be possible to install gnuradio on smarphones
> or iphone (v1 to v3) -maybe a minimal version- in order to
> get working the usrp (or a minimal harware) with it?Maybe a
> custom usrp hardware?Changing the dock for example.
Interesting question. The Palm Pre and Mot Droid h
Cosmin-
>> If all you need is a portable software radio package you can
>> reconfigure and monitor (ie, via a screen), Notre Dame is making big
>> strides in that area
>> https://radioware.nd.edu/prototypes/prototype-portable-software-radio
>
> Yes I like very mutch this prototype!
> It looks like
Adib-
> > Important Note:
> > Beside tunning time depends on the hardware (RF syenthesizer speed),
> > one should remameber that the time needed to collect 1024 samples
> > with decimation rate=8 (minimum USRP decimation) is 128 usec
> >
> > while :
> >
> > Time needed to collect 1024 samples with
Johnathan-
> > I assume this also true for the BasicRX daughterboard? (Doesn't do
> > downconversion, but does do analog multiplication to get I and Q?)
>
> Almost. The boards don't do anything with the signal, but have separate
> I and Q inputs that go to the ADCs as is.
>
> On the FPGA, howev
Ian-
> Ok, that makes sense. Looking back at this site
> (http://www.nd.edu/~jnl/sdr/docs/tutorials/4.html#tth_sEc2.1) I see
> that the DDC is combining the I and Q inputs to do complex
> multiplication. I originally thought it was multiplying the I and Q
> components separately, so that no inpu
Roshan-
> > I think the OP is confused at what "signal processing" is happening on the
> > RF
> > daughterboard. Although some recent posts have said "none", there actually
> > is some
> > -- filters to separate the I and Q signals which were summed at the point
> > of original
> > transmissio
Johnathan-
> > The LFRX has two separate antenna inputs, supplied to Vin-A and
> > Vin-B. These are not I-Q data. USRP board FPGA logic would apply
> > one mixer or two (30 MHz or less).
>
> [...]
>
> > The RFX2400 mixes with a 2.4 GHz osc and creates one set of I-Q 65
> > MHz range signals, +
Eric-
> > > The LFRX has two separate antenna inputs, supplied to Vin-A and
> > > Vin-B. These are not I-Q data. USRP board FPGA logic would apply
> > > one mixer or two (30 MHz or less).
> >
> > [...]
> >
> > > The RFX2400 mixes with a 2.4 GHz osc and creates one set of I-Q 65
> > > MHz range s
Dong Li-
> :
> :
> We've checked the interface of USRP, its SMA Female, and nearly all
> the antenna's interface for wireless which are sold in Fry's
> Electronics is SMA Reverse Plug. So I guess a adapter from SMA Male to
> SMA Reverse Jack will connector the USRP's RF end to an antenna.
> Is any
Chris-
> Dumb question:
>
> Why is the USRP supplying values outside -127/127 when it has on board
> an 8 bit ADC?
The AD9862 is a 12-bit ADC.
-Jeff
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/dis
Marcus-
> What is the maximum DC supply voltage for the USRP?
>
> I've been running it off of a 5V switched supply, but I wanted to move
> all power
> supplies outside of the USRP cabinet that I have, so I'm using an
> external 13.8V
> supply, with a LM7805 regulator. The regulator is saggin
George-
> We'd greatly appreciate any help, thanks!
I started to take a look at your Verilog code and see if I could find
something, then
stopped. Can you repost it with correct indent/alignment? It's hard to read
when
you've got something like this:
if (fifodata[`START
Reid-
> I've written a small Verilog module for the FPGA on the USRP to do phase
> recovery. I'd like to test it in isolation before I try it out on the board,
> but I'm having major problems feeding Quartus two 16 bit sine and cosine
> signals with a random phase offset. The idea is that q_out
Lisa-
> The USRP sales brochure lists as a feature "Capable of processing signals up
> to 16
> MHz wide". I can only figure out how it can process signals up to 8 MHz wide.
> What
> am I missing?
>
> Since samples sent across the USB are 16-bit signed integers (16-bit I and
> 16-bit Q
> for co
SRP data rates
Date: Wed, 08 Aug 2007 23:07:14 -0500
From: Jeff Brower <[EMAIL PROTECTED]>
Organization: Signalogic, Inc
To: Lisa Creer <[EMAIL PROTECTED]>
CC: discuss-gnuradio@gnu.org
Lisa-
> The USRP sales brochure lists as a feature "Capable of processing signals up
> to
Michael-
> I think the most comprehensive page I've found is < http://
> en.wikipedia.org/wiki/XMax >. Links to patents and reviews (e.g.
> Phil Karn's). - MLD
Phil Karn is a Qualcomm employee -- maybe not the most impartial source. Here
is
something recent, starting with an actual face-to-fac
Marcus-
> I couldn't find Jeffs response in my "discuss-gnuradio" archive, so I'm
> responding here.
>
> I've known Phil personally for many years (yikes, a couple of decades
> now!). I'd be utterly
> shocked to find him simply "spouting the company line".
>
> I've read his analysis, and tal
Jordan-
> > Phil Karn is a Qualcomm employee -- maybe not the most impartial
> > source.
>
> Hey, Jeff: welcome to the Internet. I see this must be your first day
> :)
It seems like Phil has worked carefully and thoroughly to show areas of
weakness --
or unexplained gaps -- in xG's approach an
William-
> I supposed I can reconstruct a virtual local oscillator by looking at
> the zero crossings and syncing a sine generator to that and then using
> the sine generator to determine the sign (making it a sign generator ;-P).
> Then my entire waveform might be inverted, but that is probably n
Jon-
>> On Fri, Aug 17, 2007 at 05:23:06PM -0600, Bahn William L Civ USAFA/DFCS
>> wrote:
>>
>>> Q1) One of the formats in which I can send data to the USRP is as IQ data.
>>> What does the USRP do with IQ data
>>> pairs? In the USRP documentation there is a block diagram of the Digital
>>> Dow
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
> > Of Brian Padalino
> > Sent: Monday, October 01, 2007 5:53 PM
> > To: Matt Ettus
> > Cc: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] Default FPGA I/O standard
> >
> > On 10/1/07,
KC Huang-
> I have two questions about Gnuradio latency:
>
> 1. In transmit path, the USB delay is constant due to the 32KB buffer
> between "signal source output" and "USB". If the sampling rate is 1MS/s and
> each sample is complex 16 bits( sample size=4bytes), we can get the USB
> latency = 8m
Eric-
> Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized
> WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I
> downloaded a recent revision of gnuradio (revision 6595) onto the host.
This should work Ok, but let me comment that based on personal experience
Eric-
> On Mon, Oct 08, 2007 at 07:41:06PM -0500, Jeff Brower wrote:
> > Eric-
> >
> > > Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized
> > > WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I
> > > downloaded a
George-
Ok, I get it. Sounds very promising.
A couple of quick questions:
1) What about commands (meta-data) to help deal with latency? For example, 'if
you receive such-and-such request,
send this ACK'?
2) Does your new FPGA code require the next-gen USRP, with Spartan 3 FPGA? My
understa
Brian-
> > 2) Does your new FPGA code require the next-gen USRP, with Spartan 3 FPGA?
> > My understanding is that capacity is very
> > limited in the Cyclone, which is an old FPGA (around yr 2002 time-frame).
>
> If you have a single, specific application in mind, you should be able
> to reduc
Brian-
> On 10/12/07, Jeff Brower <[EMAIL PROTECTED]> wrote:
> > I think the biggest concerns with Cyclone I are lack of multipliers and low
> > amount of
> > internal mem (26 kbyte for the EPC1C12).
>
> Understandable, but also remember that a CORDIC can perfo
Brian-
> > 2) Does your new FPGA code require the next-gen USRP, with Spartan 3 FPGA?
> > My understanding is that capacity is very
> > limited in the Cyclone, which is an old FPGA (around yr 2002 time-frame).
>
> If you have a single, specific application in mind, you should be able
> to reduc
Steven-
> I've made some improvements to the built-in GMSK demodulator, based mostly on
> Simon
> & Wang's "Differential Detection of Gaussian MSK in a Mobile Radio
> Environment".
> Also see "Differential Detection of GMSK Using Decision Feedback", Yongacoglu,
> A.Makrakis, D.Feher, K.
Ronald-
> I needed some help with Verilog Cordic code.(cordic.v and
> cordic_stage.v) I do understand the Cordic Logic, but was having some
> trouble with the pipelined code implementation of cordic.v . My
> questions start with Q --.
>
> In cordic.v:
> --
> 16 bit vector xi, yi a
John-
> I brought this up some time ago, but no one was able
> to help me. I have a little more information now, so
> maybe we can make progress.
>
> In the application we are working on, we would like to
> perform continuous split-second captures from the USRP
> over days at a time. Unfortunat
is confusing and there are other ways,
such as
defparam, that avoid confusion with the # token when it's used for simulator
delays.
-Jeff
> On Nov 25, 2007 3:13 AM, Jeff Brower <[EMAIL PROTECTED]> wrote:
>
> Ronald-
>
> > I needed some help with V
Jim-
> I'm working on a software-defined acoustic communications transceiver,
> currently based on DSP-targeted code generated by MATLAB and Simulink.
> I'm looking into options for converting the project to free software and
> so far I have been reading about Scicos and GNURadio. As part of movin
Jim-
> >> How many MFLOPS does your DSP solution currently require? You mention
> >> a floating-point DSP; is it the Texas Inst
> >> C6713? If so is it running 300 MHz / 1200 MFLOPS?
> >
> > Yes, that's right. I do fear we are using it rather inefficiently, though.
> >
>
> To clarify: we are ru
Eric-
> On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote:
> > On Wed, 16 Jan 2008, Ignacio wrote:
> > > I use xilinx ise tools regularly so please do not commit the whole
> > > ise project, this generates a corrupted project sooner o later.
> > > Xilinx made a workaround to make ver
Eric-
> On Thu, Jan 17, 2008 at 11:55:42AM -0600, Jeff Brower wrote:
> > Eric-
> >
> > > On Thu, Jan 17, 2008 at 03:33:18PM +1030, Daniel O'Connor wrote:
> > > > On Wed, 16 Jan 2008, Ignacio wrote:
> > > > > I use xilinx ise tools regularly
Brian-
> On Jan 17, 2008 12:55 PM, Jeff Brower <[EMAIL PROTECTED]> wrote:
> > How do you implement FIFOs, SDRAM controller, GbE MAC, etc? Using a
> > 'non-Xilinx'
> > method?
>
> I don't think there's any SDRAM on the new USRP2, but if the
Toby-
> I hope no one minds me putting this up here:
I took a look at the Path Intelligence website. It's actually the case that you
would track individuals to within a few meters using their cellphones without
their
knowledge? What about privacy concerns? It's one thing to be monitored by
s
1 - 100 of 142 matches
Mail list logo
