Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[K7VE]

There is an economical AMBE-3000 device now at
http://nwdigitalradio.com/category/thumbdv

 



-

John D. Hays K7VE 
PO Box 1223 Edmonds, WA 98020 k7ve.org 

  

--
View this message in context: 
http://gnuradio.4.n7.nabble.com/DV-Dongle-AMBE-USB-Device-tp18281p51701.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Eric Cottrell]

> > 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

Hello,

I guess you did not notice the Somebody Else's Problem (SEP) field generator on 
the board. :)

It is good to know that I am not the only one that was confused.  If you go 
through the "official" link (www.dvdongle.com) then you get a slick website for 
a commercial device marketed for PC based DStar.  If I had clicked on that link 
first then I may have concluded that it was a DStar only device.

The Experimenter's link is:
http://www.moetronix.com/dvdongle/

So to clarify based on my research so far...

GNURadio code would talk to the open source firmware on the DV Dongle which 
deals with the AMBE2000 AMBE Codec.

Windows source code (yes, Source!) for the test application is available at:
http://www.moetronix.com/files/ambetest103.zip

The DV Dongle should work as a general AMBE/AMBE+ CODEC.  It does not support 
AMBE+ 2.

The device uses ASCP protocol over USB developed by Moetronix.  The low-level 
communication portion of SDR-14 example code could be modified and used for 
communications.

My first experiments will be dealing with IMBE decoding. Decoding IMBE would 
make this device useful for APCO Project 25 voice decoding.  Hopefully this 
will resolve the AMBE will not decode IMBE issue.

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

[Jeff Brower]

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

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Eric A. Cottrell]

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 Cottrell]

- 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] DV Dongle - AMBE USB Device

[Jeff Brower]

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] DV Dongle - AMBE USB Device

[Eric Cottrell]

> 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

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Jeff Brower]

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

[Gregory Maxwell]

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

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Jeff Brower]

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

[Jeff Brower]

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 A. Cottrell]

Hello,

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.


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 A. Cottrell]

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 code plus test vectors. I wonder why DVSI has not done 
the same.


Perhaps the APCO and TIA committees did not require it when the 
algorithm was published ten years ago.


-rick


Hello,

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.


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

[Jeff Brower]

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 code plus test vectors. I wonder why DVSI has not done
> > >the same.
> >
> > Perhaps the APCO and TIA committees did not require it when the
> > algorithm was published ten years ago.
> 
> I'm sure there was a bit of negotiation to get the best
> available vocoder technology and still preserve MIT's and DVSI's
> interests.   A full reference implementation in C would have been
> immediately employed by a variety of entities seeking to use the
> technology without the royalties and control DVSI and MIT wanted -
> anything published like that would have been impossible to control.

I agree, however it's very easy to get C source for G729 and other standard, 
widely
used telephony codecs.  Yes, the G729 IP rights holders have battles to fight 
and
have had to take steps, such as consolidating and hiring a manager to handle
licensing and monitor illegal usage (Sipro).  I suspect with the advent of 
Asterisk
and other open source voice software, we're just waiting for a commercial outfit
who's made it big using open source and is handling 100,000s of channels at 
multiple
installations -- but without paying the required $10 per channel -- to get sued 
by
Sipro or their constituents, such as NEC and Siemens.
 
> And history indicates they made a choice that served their
> interests well - radio hobby and hacker and far east clone (read
> "Chinese copy") use of P25 IMBE on a PC or in unlicensed hardware has
> not been a major issue for 10 years, though no doubt more than a few
> versions do exist outside of official DVSI licensees.   It is hard to
> believe this would have been true if the standard came with C source
> code... regardless of its license status and the formal restrictions on
> using it.

All good points.  But that's a path leading to non widespread popularity and
non-adoption into worldwide standardization bodies.

With MELPe, NSA has far more serious concerns than MIT + DVSI, with major 
national
security implications.  NSA has chosen a 2-prong approach:  a) provide access to
voice codec standards but hold the line on encryption, and b) carefully control 
who
has access to C source (approved agencies and commercial organizations within 
NATO
and PfP countries so far).  Unlike DVSI, reference code and test vectors are
important to them because so many disparate entities need to interoperate.

> And this has no doubt made it easier to collect revenue from the
> hefty fees for licenses... if only because at least some major users
> haven't been as annoyed by hobby software  that scares their law
> enforcement customers away from P25 + IMBE as they no doubt would have
> been if unofficial copies of the C from the standard were available and
> in wide use in PC radio hobby software.  It is at least probably true
> that at least two common VHF/UHF non P25 digital radio systems that
> currently are not supported by readily purchased scanner would be
> readily monitorable by the general public if IMBE source was available,
> even with the  potential patent infringement involved - and I am sure
> this hasn't escaped notice.

Well, without encryption any voice codec is a clear channel if there is strong 
motive
to build a product that can decode.  I have no doubt that a community / group 
effort
could easily and quickly produce C source for IMBE if there were sufficient 
motives
(profit, fame, beat Microsoft, etc).

-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

[David I. Emery]

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 code plus test vectors. I wonder why DVSI has not done 
> >the same.
> 
> Perhaps the APCO and TIA committees did not require it when the 
> algorithm was published ten years ago.

I'm sure there was a bit of negotiation to get the best
available vocoder technology and still preserve MIT's and DVSI's
interests.   A full reference implementation in C would have been
immediately employed by a variety of entities seeking to use the
technology without the royalties and control DVSI and MIT wanted -
anything published like that would have been impossible to control.

And history indicates they made a choice that served their
interests well - radio hobby and hacker and far east clone (read
"Chinese copy") use of P25 IMBE on a PC or in unlicensed hardware has
not been a major issue for 10 years, though no doubt more than a few
versions do exist outside of official DVSI licensees.   It is hard to
believe this would have been true if the standard came with C source
code... regardless of its license status and the formal restrictions on
using it.

And this has no doubt made it easier to collect revenue from the
hefty fees for licenses... if only because at least some major users
haven't been as annoyed by hobby software  that scares their law
enforcement customers away from P25 + IMBE as they no doubt would have
been if unofficial copies of the C from the standard were available and
in wide use in PC radio hobby software.  It is at least probably true
that at least two common VHF/UHF non P25 digital radio systems that
currently are not supported by readily purchased scanner would be
readily monitorable by the general public if IMBE source was available,
even with the  potential patent infringement involved - and I am sure
this hasn't escaped notice.


-- 
  Dave Emery N1PRE/AE, [EMAIL PROTECTED]  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in 
celebration of what could have been, but wasn't and is not to be now either."



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Rick Parrish]

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 code plus test vectors. I wonder why DVSI has not done 
the same.


Perhaps the APCO and TIA committees did not require it when the 
algorithm was published ten years ago.


-rick


___
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]

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 specific
> programming language or processor. The decision as to how to manipulate
> the bits (C, asm, or FPGA) is up to you.

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 code plus test
vectors.  I wonder why DVSI has not done the same.

-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

[Rick Parrish]

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

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Jeff Brower]

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

[Eric A. Cottrell]

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

[Jeff Brower]

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

[Eric Cottrell]

- 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] DV Dongle - AMBE USB Device

[Jeff Brower]

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

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Rick Parrish]

David I. Emery wrote:
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.


One of WinRadio's more recent offerings includes a software codec option 
for P25. It's a $99 download - probably DRM'd to your radio's serial number.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[David I. Emery]

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).




-- 
  Dave Emery N1PRE/AE, [EMAIL PROTECTED]  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in 
celebration of what could have been, but wasn't and is not to be now either."



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

[Rick Parrish]

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.



___
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]

Jared-

> speex is nice.  I've used it as well as the AMBE2000/2020.  I wasn't in love 
> with
> the AMBE.  We ended up doing lots of hacking to make the DVSI AMBE 2000/2020 
> pair
> of DSPs work in our application.  Specs were light and idiosyncrasies were
> numerous.

What was the lowest bitrate you used with Speex?  My understanding is that 
Speex's
PESQ scores are below 3 for anything below 3000 bps.

-Jeff

> > Date: Wed, 19 Mar 2008 09:02:46 -0700
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
> > CC: discuss-gnuradio@gnu.org
> >
> > On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote:
> > > Rick-
> > >
> > > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame 
> > > > > converter
> and see
> > > > > if the device can decode P25 as well. This may be a general IMBE and
> > > > > AMBE codec.
> > > > >
> > > >
> > > > I hope so. I looked at this a while back. What concerned me most was the
> > > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility.
> > > > Compare the docs to another DVSI product - the VC55 - to see what I 
> > > > mean.
> > >
> > > 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
> (STANAG
> > > 4591). Common applications are HF radio and L band satellite apps where
> bandwidth is
> > > very limited.
> > >
> > > -Jeff
> >
> > Unless something has changed, MELP is also encumbered. How about a
> > free codec, such as speex? http://www.speex.org/
> >
> > 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

[Jared Jensen]

speex is nice.  I've used it as well as the AMBE2000/2020.  I wasn't in love 
with the AMBE.  We ended up doing lots of hacking to make the DVSI AMBE 
2000/2020 pair of DSPs work in our application.  Specs were light and 
idiosyncrasies were numerous.

j0j

> Date: Wed, 19 Mar 2008 09:02:46 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
> CC: discuss-gnuradio@gnu.org
> 
> On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote:
> > Rick-
> > 
> > > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame 
> > > > converter and see
> > > > if the device can decode P25 as well.  This may be a general IMBE and
> > > > AMBE codec.
> > > >
> > > 
> > > I hope so. I looked at this a while back. What concerned me most was the
> > > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility.
> > > Compare the docs to another DVSI product - the VC55 - to see what I mean.
> > 
> > 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 
> > (STANAG
> > 4591).  Common applications are HF radio and L band satellite apps where 
> > bandwidth is
> > very limited.
> > 
> > -Jeff
> 
> Unless something has changed, MELP is also encumbered.  How about a
> free codec, such as speex?  http://www.speex.org/
> 
> Eric
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_
Connect and share in new ways with Windows Live.
http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_012008___
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 Blossom]

On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff Brower wrote:
> Rick-
> 
> > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame 
> > > converter and see
> > > if the device can decode P25 as well.  This may be a general IMBE and
> > > AMBE codec.
> > >
> > 
> > I hope so. I looked at this a while back. What concerned me most was the
> > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility.
> > Compare the docs to another DVSI product - the VC55 - to see what I mean.
> 
> 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 
> (STANAG
> 4591).  Common applications are HF radio and L band satellite apps where 
> bandwidth is
> very limited.
> 
> -Jeff

Unless something has changed, MELP is also encumbered.  How about a
free codec, such as speex?  http://www.speex.org/

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 Cottrell]

- Start Original Message -
Sent: Wed, 19 Mar 2008 07:02:08 -0600
From: Jeff Brower <[EMAIL PROTECTED]>
To: Rick Parrish <[EMAIL PROTECTED]>
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

> Rick-
> 
> > > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame 
> > > converter and see
> > > if the device can decode P25 as well.  This may be a general IMBE and
> > > AMBE codec.
> > >
> > 
> > I hope so. I looked at this a while back. What concerned me most was the
> > AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility.
> > Compare the docs to another DVSI product - the VC55 - to see what I mean.
> 
> 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 
> (STANAG
> 4591).  Common applications are HF radio and L band satellite apps where 
> bandwidth is
> very limited.
> 
- End Original Message -
Hello,

That would be a good idea if I was doing digital voice from scratch but I am 
trying to decode IMBE and AMBE used in APCO P25 and a number of other systems 
like MA/COM ProVoice and some Inmarsat stuff.

MELPe may be a great solution to get Ham Digital Voice away from IMBE and AMBE. 
 It may be difficult to do in the case of VHF/UHF with older P25 radios being 
available surplus.

IP issues can be a minefield as the Rembrandt Technologies suit about their 
ATSC patents shows.  I heard that HDTV Grand Alliance made the mistake of not 
having a formal patent pool and there was an informal agreement.  Rembrandt got 
the technology patents from AT&T which was part of the HDTV Grand Alliance and 
decided to play hardball and recover the costs of buying the patents plus make 
a profit.

Having dealt with companies that only release information under NDA, I can 
appreciate that DVSI has their information available so a device like DV Dongle 
can be made.  It is not a good clean open source solution but is like the 
MadWifi driver.

I would like to play with ALE and STANAG protocols someday.  Thanks for the 
information and I will look up more information on it.

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

[Jeff Brower]

Rick-

> > I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter 
> > and see
> > if the device can decode P25 as well.  This may be a general IMBE and
> > AMBE codec.
> >
> 
> I hope so. I looked at this a while back. What concerned me most was the
> AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility.
> Compare the docs to another DVSI product - the VC55 - to see what I mean.

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 
(STANAG
4591).  Common applications are HF radio and L band satellite apps where 
bandwidth is
very limited.

-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 A. Cottrell]

Rick Parrish wrote:
> Eric A. Cottrell wrote:
>> I am also thinking of writing a APCO P25 Voice to AMBE2000 frame
>> converter and see
>> if the device can decode P25 as well.  This may be a general IMBE and
>> AMBE codec.
>>   
>
> I hope so. I looked at this a while back. What concerned me most was
> the AMBE2000/2020 documentation seemed to omit P25 style IMBE
> compatibility. Compare the docs to another DVSI product - the VC55 -
> to see what I mean.
>
Hello,

Looking over the docs the VC55 is a P25 only AMBE+ 2 CODEC that only
supports full rate and the proposed (maybe part of standard now) half
rate.  What is good is the mention that the improvements are still
compatible with the P25 vocoder standard.  The AMBE + 2 part sounds like
further improvements to the CODEC over the AMBE2000.  The future
AMBE3000 will implement AMBE + 2 and it appears compatible with the
AMBE2000 and AMBE1000.

The AMBE2000 is more flexible in the data rates and when I look at the
rate tables on page 29 I see the P25 rate listed with the correct voice
and FEC data rates.  You can do the same rate in AMBE or AMBE+.

So one task will be to figure out how to configure the chip so it will
decode P25.

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

[Rick Parrish]

Eric A. Cottrell wrote:

I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter and 
see
if the device can decode P25 as well.  This may be a general IMBE and
AMBE codec.
  


I hope so. I looked at this a while back. What concerned me most was the 
AMBE2000/2020 documentation seemed to omit P25 style IMBE compatibility. 
Compare the docs to another DVSI product - the VC55 - to see what I mean.



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] DV Dongle - AMBE USB Device

[Eric A. Cottrell]

Hello,

One of the "problems" with DStar and some other digital voice systems is
the Patent and other IP considerations.  DStar uses the AMBE codec which
is owned by DVSI.  Icom uses a DVSI AMBE2020 chip in their DStar
products.  One possible solution is to buy hardware that puts the Patent
and IP into a chip.  This increases the cost of the hardware and you
need to interface it to the PC.

Some chip makers do not make chip information available, but DVSI does. 
The USER Manual is very informative.
http://www.dvsinc.com/products/a2000.htm

A group was able to produce a USB Device that interfaces the AMBE2000
chip to the PC.  The icing on the cake is it is an open source project. 
The API appears similar to the RF Space SDR products.
http://www.moetronix.com/dvdongle/

The DV Dongle is now in production and even has a website,
http://www.dvdongle.com/DV_Dongle/Home.html

So I ordered one for $200 from HRO and hope to get it in a few days.  It
should be possible to add support for it in GNURadio.  I am also
thinking of writing a APCO P25 Voice to AMBE2000 frame converter and see
if the device can decode P25 as well.  This may be a general IMBE and
AMBE codec.

73 Eric


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio