Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
Rick- > > Is this a DVSI licensed and publically available closed source module > > or something "unofficial" or not generally available to the world at > > large ? It has obviously long been possible to recode some reverse > > engineered DSP chip based IMBE implemenation into C++ source code for > > Wintel/Unix/BSD use, but this would not be free of license and patent > > issues... and could not be made part of an open sourced project or > > product without a DVSI deal (and it appears they don't see this as in > > their interest). > Reverse engineering - at least for two common IMBE variants (P25 and > MA/COM's ProVoice) - isn't necessary. Both algorithms are published by > DVSI through the TIA. 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? -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: How to insert a matlab file into GNURadio in python
I used MATLAB to create waveforms and then send them to GNURadio using TCP
ports and out through the USRP (and vise versa). Not sure if this is what
you want, but this is how I did it...
On the python side, I used the following code to open the TCP socket...
http://alumni.media.mit.edu/~jcooley/gr_experiments/experiments/gr_socket.ht
m
On the MATLAB side, I used this code...
http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=345
The MATLAB code would look something like...
Data =
con=pnet('tcpconnect','127.0.0.1',8881)
pnet(con,'write', data, 'NATIVE');
pnet(con,'close');
The python code would look something like...
## imports...
from gr_socket import *
# the main flow would be as follows.
u = usrp.sink_c ()
(src, fd, conn) = make_socket_source(8881, 4)
fmtx = blks.nbfm_tx (fg, audio_rate, usrp_rate, max_dev=2.5e3, tau=75e-6)
gain = gr.multiply_const_cc (40.0)
fg.connect (src, fmtx, gain, u)
You can receive data in GNURadio and send it directly to MATLAB just as
easy. Hope this helps...
Kevin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] How to insert a matlab file into GNURadio in python
What I was talking about I think it is not post-processing like the files in the link you`ve put me in your answer. I refer for example at the synchronization matlab file which is implemented in the folder gnuradio/gnuradio-examples/python/ofdm. In this folder from the installed program is a file in matlab of synchronization and I think it is inserted by the makefile. Because of your answers I'm starting to think it is not inserted directly and the synchronization is being used by importing the blocks from blksimpl... and I think I should rewrite my code in python in order to insert it in GNURadio, isn`t it? Thank you!> Date: Wed, 19 Mar 2008 14:04:02 -0400> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]> CC: discuss-gnuradio@gnu.org> Subject: Re: [Discuss-gnuradio] How to insert a matlab file into GNURadio in python> > > > Jose Emilio Gervilla Rega wrote:> > Hello,> > > > I've made a code in matlab for GNURadio but I don't know how to insert > > this code in the files programmed in python in GNURadio. Can anyone tell > > me how to do it?I've seen there are some files done in matlab but I > > couldn't figure out how they have been inserted.> > > > Thank you very much!> > > > Hi,> > The octave scripts, found in here:> http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/utils> > ... are not actually inserted into a GNU Radio flowgraph or anything. > They are simply used to post-process data from GNU Radio.> > I think some people have managed to integrate GNU Radio and matlab in > the past, I don't know how though. But, those files I think you're > speaking of are for post-processing.> > - George _ MSN Noticias http://noticias.msn.es/comunidad.aspx___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to insert a matlab file into GNURadio in python
Jose Emilio Gervilla Rega wrote: What I was talking about I think it is not post-processing like the files in the link you`ve put me in your answer. I refer for example at the synchronization matlab file which is implemented in the folder gnuradio/gnuradio-examples/python/ofdm. In this folder from the installed program is a file in matlab of synchronization and I think it is inserted by the makefile. Because of your answers I'm starting to think it is not inserted directly and the synchronization is being used by importing the blocks from blksimpl... and I think I should rewrite my code in python in order to insert it in GNURadio, isn`t it? Thank you! We made that m-file in the OFDM directory to prototype and debug the GNU Radio synchronizer. It is not used in GNU Radio, but we put it into the source in case we (a) needed it again or (b) someone else could make use of it. Tom > Date: Wed, 19 Mar 2008 14:04:02 -0400 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] How to insert a matlab file into GNURadio in python > > > > Jose Emilio Gervilla Rega wrote: > > Hello, > > > > I've made a code in matlab for GNURadio but I don't know how to insert > > this code in the files programmed in python in GNURadio. Can anyone tell > > me how to do it?I've seen there are some files done in matlab but I > > couldn't figure out how they have been inserted. > > > > Thank you very much! > > > > Hi, > > The octave scripts, found in here: > http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/utils > > ... are not actually inserted into a GNU Radio flowgraph or anything. > They are simply used to post-process data from GNU Radio. > > I think some people have managed to integrate GNU Radio and matlab in > the past, I don't know how though. But, those files I think you're > speaking of are for post-processing. > > - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using "rb" vs. "r" to open gnuradio data files
I was attempting to use Chuck Swiger's utility at http://www.swigerco.com/gnuradio/raw2num_f.c to read a gnuradio file created by audio_to_file.py but kept getting "Input reached EOF" well before the entire file had been read. I am not a C programmer, but while debugging I noticed that he had used "r" in his fopen command rather than the "rb" used by gr_file_source.cc so I made that change and now the utility works fine. I also noticed an old post from ematlis (http://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00341.htm l) mentioning a similar utility he'd developed and noticed it uses "r" rather than "rb" also. Shouldn't "rb" be used rather than "r" to open gnuradio data files? By the way, I am using MinGW/MSYS with GCC 3.4.5 if that matters. Thanks, Rob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rules for clock recovery parameters
Hi all, I was wondering if anyone knows the rules for selecting clock recovery parameters for the gr_clock_recovery_mm_* block. In specific, I'm wondering about the following parameters: mu, gain mu, omega, omega gain, and omega limit I would like to verify the clock recovery parameters chosen by UCLA's 802.15.4 implementation: https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/802.15.4/trunk/src/python/ieee802_15_4.py#L100 The reason is that we experience no loss when using file source/sinks but experience loss using coax, which might be due to timing errors introduced by the hardware. I'd greatly appreciate any help. Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using "rb" vs. "r" to open gnuradio data files
Rob Walker wrote: I was attempting to use Chuck Swiger's utility at http://www.swigerco.com/gnuradio/raw2num_f.c to read a gnuradio file created by audio_to_file.py but kept getting "Input reached EOF" well before the entire file had been read. I am not a C programmer, but while debugging I noticed that he had used "r" in his fopen command rather than the "rb" used by gr_file_source.cc so I made that change and now the utility works fine. I also noticed an old post from ematlis (http://lists.gnu.org/archive/html/discuss-gnuradio/2007-05/msg00341.htm l) mentioning a similar utility he'd developed and noticed it uses "r" rather than "rb" also. Shouldn't "rb" be used rather than "r" to open gnuradio data files? By the way, I am using MinGW/MSYS with GCC 3.4.5 if that matters. Windows (MinGW/MSYS and Cygwin) needs to know when to convert the CR-LF line separators stored in a text file to LF on reading (text files) and when to leave them alone (binary data). For portability, I think that all files that are not text files should be opened with "rb". -- Don W. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rules for clock recovery parameters
On Thu, Mar 20, 2008 at 11:19:38AM -0400, George Nychis wrote: > Hi all, > > I was wondering if anyone knows the rules for selecting clock recovery > parameters for the gr_clock_recovery_mm_* block. In specific, I'm > wondering about the following parameters: > mu, gain mu, omega, omega gain, and omega limit > > I would like to verify the clock recovery parameters chosen by UCLA's > 802.15.4 implementation: > https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/802.15.4/trunk/src/python/ieee802_15_4.py#L100 > > The reason is that we experience no loss when using file source/sinks but > experience loss using coax, which might be due to timing errors introduced > by the hardware. > > I'd greatly appreciate any help. > Thanks! > George Have you taken a look at the books and papers referenced in the header files? /*! * \brief Mueller and Müller (M&M) based clock recovery block with float input, float output. * \ingroup clock * * This implements the Mueller and Müller (M&M) discrete-time error-tracking synchronizer. * * See "Digital Communication Receivers: Synchronization, Channel * Estimation and Signal Processing" by Heinrich Meyr, Marc Moeneclaey, & Stefan Fechtel. * ISBN 0-471-50275-8. */ /*! * \brief Mueller and Müller (M&M) based clock recovery block with complex input, complex output. * \ingroup clock * * This implements the Mueller and Müller (M&M) discrete-time error-tracking synchronizer. * The complex version here is based on: * Modified Mueller and Muller clock recovery circuit * Based: *G. R. Danesfahani, T.G. Jeans, "Optimisation of modified Mueller and Muller *algorithm," Electronics Letters, Vol. 31, no. 13, 22 June 1995, pp. 1032 - 1033. */ mu specifies the point between two samples that you want the interpolated value of. It's in [0.0, 1.0]. It's the input to the gri_mmse_fir_interpolator. The rest of the parameters are for the control loop. /*! * \brief Compute intermediate samples between signal samples x(k*Ts) * \ingroup filter * * This implements a Mininum Mean Squared Error interpolator with 8 taps. * It is suitable for signals where the bandwidth of interest B = 1/(4*Ts) * Where Ts is the time between samples. * * Although mu, the fractional delay, is specified as a float, it is actually * quantized. 0.0 <= mu <= 1.0. That is, mu is quantized in the interpolate * method to 32nd's of a sample. */ class gri_mmse_fir_interpolator_cc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] D-star
(Sorry to break the threading, I just subscribed. I've been a long time reader of this list but this is my first post.) I'm pretty interested to see d-star being discussed here, since this has been a topic of interest for me for a while. It is my position that in the US AMBE is already prohibited on amateur bands under the FCC part 97.113 (a) (4) prohibition against encryption, and that any codec which is incompletely documented, patented, incredibly expensive, prohibited for software implementation could be described no more accurately than a "codes or ciphers intended to obscure the meaning". I've drafted a complaint to the FCC to that effect, but have not yet fired it off because I do not yet have a have a good alternative. To that end I've been working on creating a fairly narrowband OFDM based modem for ham use using gnuradio. The intention was to define a technique which used OFDM, QAM16, LDPC, and Speex to deliver better than better than typical narrow FM audio quality under signal conditions which would not otherwise grant copyable speech. But I've run into issues with managing peak power: Naive OFDM has a very significant difference between peak and average power and since much of the interesting target equipment is power limited that is a serious issue. The significant gap between peak and average power also makes level adjustment for users using soundcard-based software modems much harder. There are a number of approaches to controlling OFDM peak power, but everything I've tried that works well has been computationally expensive, or not especially robust against weak signal conditions. I had not previously considered forking d-star's signaling and simply using Speex instead of ambe, as has been suggested here. Speex is a truly excellent codec for speech. At its target bitrates it is arguably one of the the best performing voice codec available. It is also fully open, not patent encumbered, and the freely licensed reference implementation has been ported to a number of DSPs and low power CPUs. At 8-32kbit/sec (32kbit for wide band) speex is hard to argue with... For higher bitrates and more general purpose audio Xiph now has a new ultra low latency free codec called CELT in development (http://www.celt-codec.org/). *However* at the bitrate that AMBE is used at in d-star speex's delivered quality is not good at all. The only reason speex has any support for those bitrates is to encode background noise during quiet times in VBR applications. This may present a challenge to anyone trying to stuff speex into d-star. The free world may yet have a speech codec for AMBE-like bitrates coming, but one does not publicly exist yet. If anyone takes any action on this front I'd be interested in helping out. If something picks up off this list please keep me in the loop. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] D-star
On Thu, Mar 20, 2008 at 01:15:16PM -0400, Gregory Maxwell wrote: > (Sorry to break the threading, I just subscribed. I've been a long > time reader of this list but this is my first post.) > > I'm pretty interested to see d-star being discussed here, since this > has been a topic of interest for me for a while. Thanks for posting! This is a perfect forum for discussion of d-star and free alternatives. Keep us posted as to your progress. 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
- Start Original Message - Sent: Wed, 19 Mar 2008 23:29:57 -0400 From: "David I. Emery" <[EMAIL PROTECTED]> To: Rick Parrish <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick Parrish wrote: > > Jeff Brower wrote: > > >If you're looking at low bitrate codecs for GNU radio, why use a > > >hardware (dongle)dependent solution? You might look at MELPe, which > > >provides 600, 1200, and 2400 bps,and can be implemented as a software > > >solution. MELPe is a US/NATO standard (STANAG4591). Common > > >applications are HF radio and L band satellite apps where bandwidth is > > >very limited. > > My interest is what is actually being used - which in the case of public > > safety communications is the P25 variant of IMBE. FWIW, a closed source > > PC hosted IMBE vocoder exists now. > > Is this a DVSI licensed and publically available closed source > module or something "unofficial" or not generally available to the world > at large ? It has obviously long been possible to recode some reverse > engineered DSP chip based IMBE implemenation into C++ source code for > Wintel/Unix/BSD use, but this would not be free of license and patent > issues... and could not be made part of an open sourced project or > product without a DVSI deal (and it appears they don't see this as in > their interest). Hello, In the case of the DV Dongle they buy the DVSI chips and designed a USB interface to connect to a PC. DVSI gets paid for their work. It is a neat solution for the problem of providing PC and Network support for D-Star. The open source part is the interface to the CODEC chip. It is similar to the MadWiFi drivers where there is a closed source HAL provided by Atheros and the open source part is the interface of the HAL to the OS. Not the best solution but otherwise there would be nothing. DVSI does make a PC solution for their licensees. I have the APCO P25 Voice Module for my WinRadio G305e and it is keyed to the radio serial number. Because the DV Dongle has a published API I was able to see that it should be possible to run the CODEC at different rates. That is one area of exploration I want to do. I also want to see if the AMBE codec can be used on a IMBE stream. I have seen comments online that they are totally different yet I also see comments from the TIA P25 group that the AMBE codec is an improvement over the IMBE codec and it should be implemented by equipment makers. This seems to indicate that the stream format is the same at least at P25 rates. I find that new products of a company tend to be built on past products of the company. Companies tend not to throw out stuff that works if it still works on the new products. So the improvements could be in the quality of the encoding and decoding rather than changes in stream formats. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rules for clock recovery parameters
Eric Blossom wrote: On Thu, Mar 20, 2008 at 11:19:38AM -0400, George Nychis wrote: Hi all, I was wondering if anyone knows the rules for selecting clock recovery parameters for the gr_clock_recovery_mm_* block. In specific, I'm wondering about the following parameters: mu, gain mu, omega, omega gain, and omega limit I would like to verify the clock recovery parameters chosen by UCLA's 802.15.4 implementation: https://moo.cmcl.cs.cmu.edu/trac/cmu_sdrg/browser/802.15.4/trunk/src/python/ieee802_15_4.py#L100 The reason is that we experience no loss when using file source/sinks but experience loss using coax, which might be due to timing errors introduced by the hardware. I'd greatly appreciate any help. mu specifies the point between two samples that you want the interpolated value of. It's in [0.0, 1.0]. It's the input to the gri_mmse_fir_interpolator. The rest of the parameters are for the control loop. And omega is the nominal samples per symbol. Look at benchmark_rx.py in the digital examples file for a clue to the other parameters. The digital examples now use the mpsk_receiver, but the "mm_" parameters act on the M&M portion of the recovery loop inside. Tom ___ 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- > - Start Original Message - > Sent: Wed, 19 Mar 2008 23:29:57 -0400 > From: "David I. Emery" <[EMAIL PROTECTED]> > To: Rick Parrish <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device > > > On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick Parrish wrote: > > > Jeff Brower wrote: > > > >If you're looking at low bitrate codecs for GNU radio, why use a > > > >hardware (dongle)dependent solution? You might look at MELPe, which > > > >provides 600, 1200, and 2400 bps,and can be implemented as a software > > > >solution. MELPe is a US/NATO standard (STANAG4591). Common > > > >applications are HF radio and L band satellite apps where bandwidth is > > > >very limited. > > > My interest is what is actually being used - which in the case of public > > > safety communications is the P25 variant of IMBE. FWIW, a closed source > > > PC hosted IMBE vocoder exists now. > > > > Is this a DVSI licensed and publically available closed source > > module or something "unofficial" or not generally available to the world > > at large ? It has obviously long been possible to recode some reverse > > engineered DSP chip based IMBE implemenation into C++ source code for > > Wintel/Unix/BSD use, but this would not be free of license and patent > > issues... and could not be made part of an open sourced project or > > product without a DVSI deal (and it appears they don't see this as in > > their interest). > Hello, > > In the case of the DV Dongle they buy the DVSI chips and designed a USB > interface to connect to a PC. DVSI gets paid for their work. It is a > neat solution for the problem of providing PC and Network support for > D-Star. The open source part is the interface to the CODEC chip. It > is similar to the MadWiFi drivers where there is a closed source HAL > provided by Atheros and the open source part is the interface of the > HAL to the OS. Not the best solution but otherwise there would be > nothing. Have you seen one of the IMBE dongle codec chips up close? Is it a TI DSP, maybe something like a TMS320VC5509, or similar? DVSI typically uses TI DSPs. I'm wondering, because IP rights issues for MELPe go away for 2400 bps rate if a TI chip is used; TI will normally waive royalty fees in that case. Maybe a similar approach could be taken for MELPe, it would be cheap and not tied to a radio receiver or other equipment. Just a dongle for GNU radio. -Jeff > DVSI does make a PC solution for their licensees. I have the APCO P25 Voice > Module for my WinRadio G305e and it is keyed to the radio serial number. > > Because the DV Dongle has a published API I was able to see that it should be > possible to run the CODEC at different rates. That is one area of > exploration I want to do. > > I also want to see if the AMBE codec can be used on a IMBE stream. I have > seen comments online that they are totally different yet I also see comments > from the TIA P25 group that the AMBE codec is an improvement over the IMBE > codec and it should be implemented by equipment makers. This seems to > indicate that the stream format is the same at least at P25 rates. I find > that new products of a company tend to be built on past products of the > company. Companies tend not to throw out stuff that works if it still works > on the new products. So the improvements could be in the quality of the > encoding and decoding rather than changes in stream formats. > > 73 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] DV Dongle - AMBE USB Device
Jeff Brower wrote: Eric- - Start Original Message - Sent: Wed, 19 Mar 2008 23:29:57 -0400 From: "David I. Emery" <[EMAIL PROTECTED]> To: Rick Parrish <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick Parrish wrote: Jeff Brower wrote: If you're looking at low bitrate codecs for GNU radio, why use a hardware (dongle)dependent solution? You might look at MELPe, which provides 600, 1200, and 2400 bps,and can be implemented as a software solution. MELPe is a US/NATO standard (STANAG4591). Common applications are HF radio and L band satellite apps where bandwidth is very limited. My interest is what is actually being used - which in the case of public safety communications is the P25 variant of IMBE. FWIW, a closed source PC hosted IMBE vocoder exists now. Is this a DVSI licensed and publically available closed source module or something "unofficial" or not generally available to the world at large ? It has obviously long been possible to recode some reverse engineered DSP chip based IMBE implemenation into C++ source code for Wintel/Unix/BSD use, but this would not be free of license and patent issues... and could not be made part of an open sourced project or product without a DVSI deal (and it appears they don't see this as in their interest). Hello, In the case of the DV Dongle they buy the DVSI chips and designed a USB interface to connect to a PC. DVSI gets paid for their work. It is a neat solution for the problem of providing PC and Network support for D-Star. The open source part is the interface to the CODEC chip. It is similar to the MadWiFi drivers where there is a closed source HAL provided by Atheros and the open source part is the interface of the HAL to the OS. Not the best solution but otherwise there would be nothing. Have you seen one of the IMBE dongle codec chips up close? Is it a TI DSP, maybe something like a TMS320VC5509, or similar? DVSI typically uses TI DSPs. I'm wondering, because IP rights issues for MELPe go away for 2400 bps rate if a TI chip is used; TI will normally waive royalty fees in that case. Maybe a similar approach could be taken for MELPe, it would be cheap and not tied to a radio receiver or other equipment. Just a dongle for GNU radio. -Jeff Hello, 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, However this could be used for another project using a TI DSP for a MELPe dongle. The DV Dongle could be a defacto standard for external CODEC interfacing. 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- > 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, but it's only 100-pin so it's too small for 54x or 54x device, unless much older. My guess is a member of the C24x series, which has onchip ROM or Flash, low-power enough to live off the USB, and some stern security features. > However this could be used for another project using a TI DSP for a > MELPe dongle. The DV Dongle could be a defacto standard for external > CODEC interfacing. The Moetronix board/DSP could not be used, but a similar design with a TI DSP, USB interface, and Flash EEPROM is simple enough. The problem with making it entirely open would be NSA's export restrictions on MELPe. -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
Jeff Brower wrote: 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 specific programming language or processor. The decision as to how to manipulate the bits (C, asm, or FPGA) is up to you. Maybe Eric C. can use his new DV-Dongle to publish some test vectors. :-) -rick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
