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
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
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
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
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
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,
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
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
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.
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.
> 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
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
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
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
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
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
>
>
>
>
>> 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
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
> åéæ¥æï¼
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
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,
>
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
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
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
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
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
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...
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-
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://
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
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
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
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
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
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
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
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-
>> 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
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&
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
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
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
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
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
>>
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
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
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-
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
Greg-
>> Your question doesn't make sense to me. If your clients pay you to
>> develop source code that derives from, or partially incorporates, GPL
>> licensed code then they own the developed source, not you. They are
>> responsible for license issues with the newly developed code.
>
> This is
Joel-
Your question doesn't make sense to me. If your clients pay you to develop
source code that derives from, or
partially incorporates, GPL licensed code then they own the developed source,
not you. They are responsible for
license issues with the newly developed code.
If someone were to a
Michael-
Really, really good questions, well formulated. I'm very interested to see the
answers -- or advice -- you receive on the forum.
-Jeff
Michael Dickens wrote:
>
> This is similar to the original discussion from 2004; see, e.g.:
> < http://lists.gnu.org/archive/html/discuss-gnuradio/20
Philip Balister wrote:
>
> Congratulations guys, you've hit the big time:
>
> http://news.slashdot.org/pollBooth.pl
More here:
http://news.slashdot.org/article.pl?sid=08/06/09/1612250
with 168 comments so far.
A serious, dedicated engineering forum on the same list as WikiLeaks and Tor?
R
;phase noise"
that
even had a formula to convert to jitter. I understand what you are saying now.
-Jeff
> Jeff Brower wrote:
> > Bob-
> >
> >
> >> In your sixteen QAM and other figures I see two effects.
> >>
> >> Notice just the slighte
Bob-
> In your sixteen QAM and other figures I see two effects.
>
> Notice just the slightest hint that arcs through the top four
> constellation points in the 16 QAM is not straight. This curvature is
> caused by nonlinearity.
>
> Your result almost surely can NOT be clock jitter. If you had
Chris-
> > I've seen cases before where the drive does handle the throughput as
> > advertised, but
> > on an average basis. Under sustained, continuous write circumstances, when
> > the drive
> > reaches a new sector, multiple of sectors, or some other internal space
> > boundary,
> > extra t
Chris-
> > Is there a way for you to temporarily take file-write out of the equation?
> > I.e. can
> > your code look at the bitstream and know if it remains continuous / intact?
> >
> > The "every minute or two" thing makes me suspicious that some HDD related
> > thing is
> > going on. 16 MBb
Chris-
> I'm using the USRP/DBSRX to record data for GPS. GPS tracking demands a
> continuous stream of data -- dropped bits make tracking impossible.
> 4Msps of complex data supplies 16 MB/s -- within USB2 bandwidth and my 4
> disk RAID0 bandwidth.
>
> I record the data using my own c++ version
John-
> Danny O'Brien of EFF pointed out this profile of Toby Oliver of Path
> Intelligence, which uses GNU Radio to build phone-monitoring
> networks for shops:
>
> http://www.cnet.com/8301-13505_1-9734052-16.html
>
> Toby Oliver, CEO of Path Intelligence, is based in Portsmouth,
> Englan
Bruce-
> > We've been working on a new lowlatency codec for speech and music,
> > CELT, and are about to public a paper on it. (celt-codec.org).
> > While CELT wouldn't be useful for narrowbanded voice some of the
> > components of CELT would be very useful in an AMBE killer.
> > (Particularly CW
Jon-
> > I'm curious .. what do use the 'biquad filters' for? I assume you mean
> > that you've
> > implemented a 4th order IIR filter? If so that would mean somewhat
> > non-linear phase
> > depending on the IIR design type. What type are you using? Elliptic?
> > Other?
>
> The pair of c
Jon-
> The UW Quantum System Engineering Laboratory has written
> code for Magnetic Resonance Force Microscopy (MRFM).
> The code is available from
>
> http://staff.washington.edu/~jon/gr-mrfm/
>
> Some of the code might be useful to other GNU Radio users. On the
> FPGA side, there is a 2-sta
William-
> > -Original Message-
> > From: Jeff Brower [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, May 01, 2008 11:55 PM
> > To: Bahn, William L Civ USAFA/DFCS
> > Cc: discuss-gnuradio@gnu.org
> > Subject: RE: [Discuss-gnuradio] GnuRadio on PCI-104
William-
Isn't there an issue of how much GNU radio can actually do on a Pentium M
system? The Lippert board you mention looks
like it's limited to 1 GHz or less with passive cooling. I assume this is a
mil app, but you can use fan cooling?
What will GNU radio actually be doing?
-Jeff
> Th
Brian-
> On Fri, Apr 25, 2008 at 9:32 AM, Jeff Brower <[EMAIL PROTECTED]> wrote:
> > You are talking about the ARM9 core on the OMAP device, right? If so then
> > you can
> > run Linux on the ARM core but overall processing capability will be
> > limited
Philip-
> > just being curious :) what are you going to use the
> >
> > combo(beagle+usrp) for? use beagle to replace the usrp
> > host? they are not connected in your pic.
>
> They really are connected. I added a note to the picture :)
>
> Right now, I can load the 8051 and see the LED blink
al processing) developer communities. Supporting that approach with
GNU
Radio would only be advantageous to GNU Radio.
-Jeff
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Gregory Maxwell
> Sent: Wednesday, April 09, 2008 2:42
Matt-
> I think the problem is that there are basically 2 separate cultures
> here. There are those coming from the CS and free software world, and
> those coming from the radio, engineering, academic, industry, hardware,
> etc. worlds. Those in the free software world often don't understand
> h
Eric-
> On Wed, Apr 09, 2008 at 10:38:23AM -0500, Jeff Brower wrote:
>> Greg-
>>
>> >> I am trying to figure out the Matlab interface to USRP. Although I
>> >> could enable the communications between Matlab and GNU Radio, I am
>> >> wondering
Greg-
> On Wed, Apr 9, 2008 at 11:38 AM, Jeff Brower <[EMAIL PROTECTED]> wrote:
> [snip]
>> I understand completely your viewpoint. However, let me point out that one
>> of your key objectives should be to
>> increase popularity of GNU Radio software. One way
Pedro-
>> I understand completely your viewpoint. However, let me point out that
>> one of your key objectives should be to
>> increase popularity of GNU Radio software. One way to do this is to
>> encourage and support GNU Radio software examples
>> that interface with MATLAB in some way.
>>
>
Greg-
>> I am trying to figure out the Matlab interface to USRP. Although I
>> could enable the communications between Matlab and GNU Radio, I am
>> wondering whether it is possible to make Matlab hook to USRP directly
>> without GNU radio. Thank you very much!
>
> (This isn't entirely directed at
Matt-
> >> This reminds me of a question I have about USRP2. My understanding is the
> >> USRP2 has a Xilinx Spartan 3, which I don't
> >> think come in anything other than BGA packages. Hopefully Matt brought
> >> the JTAG lines out in case people want to
> >> deadbug a header and use standar
> On Mon, Mar 31, 2008 at 11:46 AM, Uwe Bonnes
> <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> has there been any effort to expose more JTAG functionality via the FX2 so
>> that the USRP FX2 firmware could be used with modified other JTAG software,
>> like xc3sprog.
>
> As far as I can tell, not w
Jason-
> Unfortunately, it didn't. I would like to know how to get data from the two
> sides of a SINGLE Rx Daughterboard.
>
> Currently, I have a daughterboard at the RXA side of the USRP. I want to get
> data from both input ports of that single daughterboard. Is this possible?
Could I ask you
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?
>
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 manufactur
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
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 Sele
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 so
David-
> On Fri, Mar 21, 2008 at 04:23:00PM -0500, Rick Parrish wrote:
> > Jeff Brower wrote:
> > >All the standardized codecs that I know of, both ones with IP rights
> > >requirements and free ones, provide a reference design, typically
> > >fixed-point C
Alex-
> I was posting to GNURadio about an year ago but I got busy and then I
> stopped. I
> have again started reading about GNURadio and hope to devote my free time this
> entire year on GNURadio.
>
> So I have started reading Discrete Time Signal Processing by Oppenheim /
> Schafer /
> Buck.
Rick
> > Are these publications actual C code, along with input/output test
> > vectors that can be used to verify bit-exact performance of a software
> > implementation?
> This is not a reference implementation. The documents describe the
> algorithm(s) down to the bit level. It is not tied to a
Eric-
> This picture of the prototype shows it is a TI chip.
> http://www.moetronix.com/dvdongle/
>
> The problem is it may be a ROM or protected Flash version of the DSP
> chip. I paid for a AMBE codec so I do not want to destroy the internal
> programming,
Yes it's probably a ROM'ed version,
1 - 100 of 142 matches
Mail list logo
