Re: DVAP and the DVRPTR boards


 

Comments in line.


On Sun, Jun 9, 2013 at 11:38 AM, Kristoff Bonne <kristoff@...> wrote:
 

John,




On 07-06-13 07:53, John D. Hays wrote:
 
D-STAR is a protocol.  The protocol has an open specification that has been implemented in open source software.  Within D-STAR are sub-protocols and specifications.  The vast majority of D-STAR's protocols and specifications can be implemented in open source.  One of those specifications is the Vocoder for Digital Voice.  That specification calls for a version of AMBE, the most widely used method of vocoding.  When the specification was written there wasn't anything generally available for vocoding that competed with it, which is why it is in APCO25 (Phase 2), DMR, NXDN, etc --.AMBE is proprietary and licensed technology of DVSI, which can be obtained in firmware on a dedicated DSP chip for a few dollars.

CODEC-2 only became generally available in the last year and still requires a significantly powerful processor to run the algorithm.  It does not, at this time, run in realtime on the Raspberry Pi. It might if it was rewritten using fixed point, but the developers have chosen not to do that.  The most likely implementation of CODEC-2 for Raspberry Pi will be a DSP daughter card (much like the AMBE chip) to run the algorithm and provide a radio interface, leaving the Pi to provide the user interface and networking support.
The 1400 bps codec2 encoder (standard sourcecode, so without to much optimalisation) uses about 20 % of the CPU of a Raspi. The GMSK modem (in software on the pi) also uses some 20 % so the combination GMSK + vocoder (like what you would need for D-STAR) is about 40 % of the cpu of the pi.
This gives it enough headroom for all other processes that run on a repeater.


This is good to know. So running 'headless' should be possible in real time?
 
It is true that the pi cannot run FreeDV (read: the fdmdv2 modem), but that is not due to the codec2 vocoder but because of the demodulator.



The argument that ham radio can't use proprietary, licensed,  or closed technology is ridiculous at best.  Let's take the logic and apply it to amateur radio.
Let's say CODEC-2 was optimized sufficiently to run on the Raspberry Pi. If no proprietary, licensed, or closed technology could be used, you couldn't run it on the Raspberry Pi -- which uses a whole bunch of licensed and proprietary technology.  Even the processor itself uses ARM, a licensed and proprietary architecture -- see http://www.arm.com/products/buying-guide/licensing/index.php and some of the drivers have been closed source based on Broadcom NDAs (Non-Disclosure Agreements).   Other subsystems in the Broadcom SOC (System on a Chip) processor in the Raspberry Pi are similarly licensed intellectual property of Broadcom and others.
The main issue -for me- in this discussion is not about being patented or not. It's about the concequences of patented technology. And that comes down to two elements:
- the monopoly for the patent-holder, which limits choice
- the lack of documentation.


The fact that any intellectual property is in your radio, means the patent/copyright holder retains rights and generally extracts some licensing fee, this is not exclusive to the vocoder.  I think IP law has gone too far myself, but that's a political, not a technological issue.

Documentation is a vendor's choice.


 
The issue -for me- is the "single source" problem that comes with the monopolies created by patents.

The difference between the patented technology in the ARM CPUs and the patented technology of DSVI is that the specifications of D-STAR does say "you have to use AMBE" (which is only provided by one single source), while there is no specification that says "you need to use a ARM CPU in your D-STAR equipment".
I can run linux an on number of different CPUs. For unix and linux, there is no "single source" issue. I can run linux on an ARM, a intel, a AMD, a PowerPC derivative, or even on a OpenRISC CPU from the opencores project.


I think I ran across a Russian chip manufacturer who had licensed the rights to manufacture AMBE chips.  I think the situation is that DVSI makes their chips at a competitive price (TI OEM with their algorithm) that would be difficult for another manufacturer to beat.   DVSI does sell source licenses, but perhaps the business case just isn't there for self manufacture when the chip can be obtained cheaply.

This is no different than licensing ARM intellectual property for self manufacture, except there is a business case for manufacturers to do so, since they often extend it with "system on a chip" components like GPU, SATA, USB, GPIO, etc. of their own intellectual property (or licensed from other 3rd parties).

ARM, Intel, AMD, Power Pc, ... are all somebody's proprietary intellectual property.  Pragmatically, you are only going to run Linux on a system with proprietary technology.
 
The availability of documentation is an issue for a different reason: it is mainly used a core argument in the "building a vocoder is so difficult, it costs millions to develop it and only we can do this; so you should be happy you can buy this product from us"-argument.
In the mean time, this argument has been disproven by David Rowe and his thesis we wrote 20 years ago. (And now we have a codec that runs at 1400 bps (instead of AMBE that needs 2400), so we can now run DV in a 2400 bps channel instead of 4800 bps); but the "IP" argument is one of the main arguments to drive up price.

BTW. A certain people from a commercial provider of a certain operating system or an office suite said exactly the same thing and also he got disproven by the "open source" community.


Agreed. However, the open source equivalents (Unix -> Linux, MicroSoft Office -> Open Office, ...) all either were non-infringing on the IP of the proprietary system or a favorable license was created.   It's a matter of what is patented, many of these open source projects have 'work a like' functionality but are not exact replicas.  In the case of Linux vs Unix, they were definitely different, then through an open standard (e.g. Posix) they became compatible.

It is not as cut and dry as we would like to believe - see http://en.wikipedia.org/wiki/SCO%E2%80%93Linux_controversies  
 


Back to D-STAR. The big problem with D-STAR, is -for me- not the use of AMBE.
The problem is that the fact that the specification have been written in such a way it is impossible to extend it or to experiment with the protocol.
Althou it works great for line-of-sight VHF / UHF operations (mainly used for 99 % for people talking to their local repeater, no questions about that); there is no way D-STAR can be adapted for other kinds of radio-links without breaking the specifications.

This is the crux of the matter, you (and others) do not like the specification even though it is open.  That's OK, but state it that way, don't make inaccurate claims about D-STAR. (Not necessarily you personally, but those making the arguments.) I think many things could be improved or extended, but there is no mechanism to change the specification or modify existing firmware in radios adapted to that specification.  The former is a failing of the JARL, the later of manufacturers who still have the 'proprietary is best' mentality.
 
You cannot change the modulation sceme, you cannot the vocoder, you cannot change the FEC system, you cannot change the scrambler, you cannot change the voice/data ratio in the stream.

True, except modulation.  The specification allows for GMSK, 4FSK, and QPSK.

 
E.g. If you want to use GMSK for (say) 10 meter DX, or NVIS communication on HF, or for satellite links, or as a pure-data pipe, or whatever else somebody wants to try, D-STAR simply does not allow that.

The pure-data pipe can be done, at any data rate, using the 'digital data' protocol (Ethernet encapsulation).  The failure of radios to do that is a failure of the manufacturer(s).  [The UDR56k-4 will allow this.]
 
This has led to some very "stupid" situations, like when you want to send data over D-STAR (and run it over a repeater or reflector), you are limited to around 900 bps (in a 4800 bps datapipe) where 3/4 of the bandwidth is completely unused.


In fact, making a protocol more flexible is not that difficult to do:
In c2gmsk (codec2 GMSK modem), the very first information send after the bit syncronisation pattern is a "versionid". I currently have two different modems (4800/0 and 2400/0) and a new one is going to set started soon. A "raw" modem (providing a pure 2400 or 4800 bps path) is also in the plans. Also, everybody can create a protocol for herself (using versionid "15" to mark it as experimental).

It only requires some specifc wording in the specs on how radios should react when receiving a stream of a unknown format, and 24 bits at the beginning of the stream. That is all. Why couldn't this be in the D-STAR specifications?


Because it wasn't considered?   The creation of the specification was controlled by JARL, you would need to check with them.  It was created under a grant from the Japanese government with a secondary requirement to create an ISDN level, mobile radio data service (ala ID-1 DD mode).
 

I don't know how the D-STAR specification was designed and how much public discussion there has been about this. I have been looking for a public mailing-list where the protocol was discussed by the JARL but sofar I have not found that.
My guess, is that D-STAR was designed without any public input; and that has resulted in this very "closed" protocol.


Codec-2 is not constrained that way, but I haven't seen the creation of a type of open standards body to write a specification yet?  D-STAR is well established and growing. It is by far the leading digital amateur radio voice system and any new system has a lot of ground to make up, at least in the VHF+ infrastructure space. 

By all means create a better system, but D-STAR is set and many of the changes people  propose would break existing systems.  Many groups are dependent on those systems and won't switch for purely 'open systems' arguments.
 

So, I agree, we all use patented technology. No question about that.
As long it does not impact the FREEDOM of the individual hams to learn and experiment with it; that is not an issue. However the combination of the "closed-down" protocol of D-STAR with the single-source issue of the choice of AMBE DO are a problem.
 

D-STAR / AMBE do nothing to prevent individual freedom of choice.   Nobody is requiring the use of D-STAR or AMBE -- for those that do, it is often a pragmatic choice.   

The 'problem' is manufactured, as some have expectations outside of what D-STAR offers.  They are free to use something different, but should not expect others to follow purely on ideological arguments.

My position is that those who make the argument that Amateur Radio requires "open source" are being unrealistic.  Should intellectual and proprietary components be banned, amateur radio would cease to exist.

 

73
kristoff - ON1ARF

__._,_

I think your work and that of the Codec-2 folks is wonderful and I support it -- however, that doesn't mean I can't also support D-STAR.

I was responding to ill informed arguments and logical inconsistencies of arguments.  Certainly there are legitimate arguments why an individual might choose not to adopt any technology, including D-STAR or Codec-2 but let's be accurate about the technical features. 


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



 

Join RaspberryPi-4-HamRadio@groups.io to automatically receive all group messages.