[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

[Rick Parrish]

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.

[Eric A. Cottrell]

Post by Rick Parrish

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

[Jeff Brower]

Rick-

Post by Rick Parrish

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

[Eric Cottrell]

----- Start Original Message -----
Sent: Wed, 19 Mar 2008 07:02:08 -0600
From: Jeff Brower <***@signalogic.com>
To: Rick Parrish <***@swbell.net>
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

Post by Jeff Brower
Rick-

Post by Rick Parrish

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

[Eric Blossom]

Post by Jeff Brower
Rick-

Post by Rick Parrish

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

[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
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

Post by Jeff Brower
Rick-

Post by Rick Parrish

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

[Jeff Brower]

Jared-

Post by 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.

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

Post by Jared Jensen

Date: Wed, 19 Mar 2008 09:02:46 -0700
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

Post by Jeff Brower
Rick-

Post by Rick Parrish

I am also thinking of writing a APCO P25 Voice to AMBE2000 frame converter

and see

Post by Jeff Brower

Post by Rick Parrish

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)

Post by Jeff Brower
dependent solution? You might look at MELPe, which provides 600, 1200, and 2400

bps,

Post by Jeff Brower
and can be implemented as a software solution. MELPe is a US/NATO standard

(STANAG

Post by Jeff Brower
4591). Common applications are HF radio and L band satellite apps where

bandwidth is

Post by Jeff Brower
very limited.
-Jeff

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

[Rick Parrish]

Post by Jeff Brower
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.

[David I. Emery]

Post by Rick Parrish

Post by Jeff Brower
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).

[Rick Parrish]

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.

[Jeff Brower]

Rick-

Post by Rick Parrish

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

[Rick Parrish]

Post by Jeff Brower
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

[Jeff Brower]

Rick

Post by Rick Parrish

Post by Jeff Brower
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

[Rick Parrish]

Post by Jeff Brower
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

[David I. Emery]

Post by Rick Parrish

Post by Jeff Brower
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.

[Jeff Brower]

David-

Post by David I. Emery

Post by Rick Parrish

Post by Jeff Brower
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.

Post by David I. Emery
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.

Post by David I. Emery
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

[Eric A. Cottrell]

Post by Rick Parrish

Post by Jeff Brower
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

[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

[Jeff Brower]

Eric-

Post by Eric A. Cottrell
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

[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

[Jeff Brower]

Eric-

Post by Eric Cottrell

Post by Jeff Brower
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?

Post by Eric Cottrell
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 Cottrell]

----- Start Original Message -----
Sent: Mon, 24 Mar 2008 11:33:26 -0600 (CST)
From: "Jeff Brower" <***@signalogic.com>
To: "Eric Cottrell" <***@runbox.com>
Subject: Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device

Post by Jeff Brower
Eric-

Post by Eric Cottrell

Post by Jeff Brower
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?

[Jeff Brower]

Eric-

Post by Jeff Brower

Post by Eric Cottrell

Post by Jeff Brower
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?