David-
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.
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
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
Eric-
the link does not mention firmware source. It is possible the makers
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
Eric-
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
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.
-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[1].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
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 GNURadio
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
On Mon, Mar 24, 2008 at 11:24 AM, Jeff B. [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 GNURadio
perhaps I should be, however).
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
----- Start Original Message -----
Sent: Mon, 24 Mar 2008 11:33:26 -0600 (CST)
From: “Jeff B.” [email protected]
To: “Eric C.” [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/
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
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
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
Gregory M. wrote:
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 GNURadio
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
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
