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
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.
Rick P. wrote:
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
----- Start Original Message -----
Sent: Wed, 19 Mar 2008 07:02:08 -0600
From: Jeff B. [email protected]
To: Rick P. [email protected]
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
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
On Wed, Mar 19, 2008 at 07:02:08AM -0600, Jeff B. 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 (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
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
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
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
On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick P. wrote:
Jeff B. 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."
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.
Eric-
provides 600, 1200, and 2400 bps,and can be implemented as a software
engineered DSP chip based IMBE implemenation into C++ source code for
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
----- Start Original Message -----
Sent: Wed, 19 Mar 2008 23:29:57 -0400
From: “David I. Emery” [email protected]
To: Rick P. [email protected]
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
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
Jeff B. wrote:
On Wed, Mar 19, 2008 at 07:38:13PM -0500, Rick P. wrote:
My interest is what is actually being used - which in the case of public
their interest).
nothing.
-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
Jeff B. 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
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
Jeff B. 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
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
On Fri, Mar 21, 2008 at 04:23:00PM -0500, Rick P. wrote:
Jeff B. 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."