Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
There is an economical AMBE-3000 device now at http://nwdigitalradio.com/category/thumbdv http://gnuradio.4.n7.nabble.com/file/n51701/ThumbDV%E2%84%A2.jpg - 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
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
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- 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
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
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
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
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
- 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
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- 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
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
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
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
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
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 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
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
- 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
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- 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
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
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
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
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
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
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
Re: [Discuss-gnuradio] DV Dongle - AMBE USB Device
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
