Loading ...
Sorry, an error occurred while loading the content.

Re: [Raspberry_Pi_4-Ham_RADIO] DVAP and the DVRPTR boards

Expand Messages
  • Dave B
    ... Remember that those things are anything but low cost, closed source, and your not even legally permitted to reverse engineer the protocol! (Not that it
    Message 1 of 23 , Jun 6, 2013
    • 0 Attachment
      On 6 Jun 2013 at 8:57, Raspberry_Pi_4-Ham_RADIO@yahoogroups.com wrote:

      > ______________________________________________________________________
      > Re: DVAP and the DVRPTR boards
      > Posted by: "John D. Hays" john@... k7ve
      > Date: Wed Jun 5, 2013 4:36 pm ((PDT))
      >
      > DVAP - small "Dongle" type 2m or 70cm radio that you plug into a
      > computer, it transmits at about 10mw and is the popular choice for "in
      > house" access to the D-STAR digital voice network.
      > http://www.dvapdongle.com/DV_Access_Point_Dongle/Home.html
      >
      > DVRPTR V1 - A GMSK modem based on DSP that goes between a computer,
      > attached by USB, and an existing 2-way radio (9600 bps packet ready)
      > to give access to the D-STAR digital vocie network -
      > http://www.dvrptr.net/
      >
      > STARBoard - A GMSK modem based on a dedicated modem chip that goes
      > between a computer, attached by USB, and an existing 2-way radio (9600
      > bps packet ready) to give access to the D-STAR digital vocie network
      > - http://moencomm.com/
      >
      > UDR56k-4 - A new digital radio, 70cm/25 watts, built in DSP modems for
      > D-STAR Digital Voice, D-STAR Digital Data (56kbps+ Ethernet over
      > radio), packet radio from 9600 bps - 56kbps +, and more. Built in
      > computer to run the DSP modems, protocol stacks, and applications on a
      > Linux operating system (Debian / ARM). Open source for experimenters.
      > Gateway or end user radio. http://nwdigitalradio.com (Discount on
      > pre-orders until the 15th).
      > [I am a member of the team creating this radio.]
      >
      > ------------------------------
      > John D. Hays
      > K7VE
      > PO Box 1223, Edmonds, WA 98020-1223
      > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
      > <http://www.facebook.com/john.d.hays>
      >

      Remember that those things are anything but low cost, closed source, and
      your not even legally permitted to reverse engineer the protocol! (Not
      that it stops some...)

      Not great for "Amateur" radio, turning us into "appliance users" nothing
      else.

      There are better and truly "open" audio codec's about, FreeDV being one.
      http://freedv.org/tiki-index.php

      Scroll down to the Links seciton, for a lot more info.

      73.

      Dave G0WBX.
    • John Hays
      Not one of these has a vocoder (AMBE) to do the gateway/hotspot function and all can run using open source. ... Remember that those things are anything but low
      Message 2 of 23 , Jun 6, 2013
      • 0 Attachment
        Not one of these has a vocoder (AMBE) to do the gateway/hotspot function and all can run using open source.






        Sent from Samsung tablet

        Dave B <dave@...> wrote:
         

        On 6 Jun 2013 at 8:57, Raspberry_Pi_4-Ham_RADIO@yahoogroups.com wrote:

        > __________________________________________________________
        > Re: DVAP and the DVRPTR boards
        > Posted by: "John D. Hays" john@... k7ve
        > Date: Wed Jun 5, 2013 4:36 pm ((PDT))
        >
        > DVAP - small "Dongle" type 2m or 70cm radio that you plug into a
        > computer, it transmits at about 10mw and is the popular choice for "in
        > house" access to the D-STAR digital voice network.
        > http://www.dvapdongle.com/DV_Access_Point_Dongle/Home.html
        >
        > DVRPTR V1 - A GMSK modem based on DSP that goes between a computer,
        > attached by USB, and an existing 2-way radio (9600 bps packet ready)
        > to give access to the D-STAR digital vocie network -
        > http://www.dvrptr.net/
        >
        > STARBoard - A GMSK modem based on a dedicated modem chip that goes
        > between a computer, attached by USB, and an existing 2-way radio (9600
        > bps packet ready) to give access to the D-STAR digital vocie network
        > - http://moencomm.com/
        >
        > UDR56k-4 - A new digital radio, 70cm/25 watts, built in DSP modems for
        > D-STAR Digital Voice, D-STAR Digital Data (56kbps+ Ethernet over
        > radio), packet radio from 9600 bps - 56kbps +, and more. Built in
        > computer to run the DSP modems, protocol stacks, and applications on a
        > Linux operating system (Debian / ARM). Open source for experimenters.
        > Gateway or end user radio. http://nwdigitalradio.com (Discount on
        > pre-orders until the 15th).
        > [I am a member of the team creating this radio.]
        >
        > ------------------------------
        > John D. Hays
        > K7VE
        > PO Box 1223, Edmonds, WA 98020-1223
        > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
        > <http://www.facebook.com/john.d.hays>
        >

        Remember that those things are anything but low cost, closed source, and
        your not even legally permitted to reverse engineer the protocol! (Not
        that it stops some...)

        Not great for "Amateur" radio, turning us into "appliance users" nothing
        else.

        There are better and truly "open" audio codec's about, FreeDV being one.
        http://freedv.org/tiki-index.php

        Scroll down to the Links seciton, for a lot more info.

        73.

        Dave G0WBX.

      • Mathison Ott
        D-star isn t even opened source! Were is the codec2 mode for the RPi? 73 Kj6dzb Mathison
        Message 3 of 23 , Jun 6, 2013
        • 0 Attachment
          D-star isn't even opened source!  Were is the codec2 mode for the RPi?

          73 Kj6dzb
          Mathison



          On Thu, Jun 6, 2013 at 7:19 AM, John Hays <john@...> wrote:
           

          Not one of these has a vocoder (AMBE) to do the gateway/hotspot function and all can run using open source.






          Sent from Samsung tablet

          Dave B <dave@...> wrote:
           

          On 6 Jun 2013 at 8:57, Raspberry_Pi_4-Ham_RADIO@yahoogroups.com wrote:

          > __________________________________________________________
          > Re: DVAP and the DVRPTR boards
          > Posted by: "John D. Hays" john@... k7ve
          > Date: Wed Jun 5, 2013 4:36 pm ((PDT))
          >
          > DVAP - small "Dongle" type 2m or 70cm radio that you plug into a
          > computer, it transmits at about 10mw and is the popular choice for "in
          > house" access to the D-STAR digital voice network.
          > http://www.dvapdongle.com/DV_Access_Point_Dongle/Home.html
          >
          > DVRPTR V1 - A GMSK modem based on DSP that goes between a computer,
          > attached by USB, and an existing 2-way radio (9600 bps packet ready)
          > to give access to the D-STAR digital vocie network -
          > http://www.dvrptr.net/
          >
          > STARBoard - A GMSK modem based on a dedicated modem chip that goes
          > between a computer, attached by USB, and an existing 2-way radio (9600
          > bps packet ready) to give access to the D-STAR digital vocie network
          > - http://moencomm.com/
          >
          > UDR56k-4 - A new digital radio, 70cm/25 watts, built in DSP modems for
          > D-STAR Digital Voice, D-STAR Digital Data (56kbps+ Ethernet over
          > radio), packet radio from 9600 bps - 56kbps +, and more. Built in
          > computer to run the DSP modems, protocol stacks, and applications on a
          > Linux operating system (Debian / ARM). Open source for experimenters.
          > Gateway or end user radio. http://nwdigitalradio.com (Discount on
          > pre-orders until the 15th).
          > [I am a member of the team creating this radio.]
          >
          > ------------------------------
          > John D. Hays
          > K7VE
          > PO Box 1223, Edmonds, WA 98020-1223
          > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
          > <http://www.facebook.com/john.d.hays>
          >

          Remember that those things are anything but low cost, closed source, and
          your not even legally permitted to reverse engineer the protocol! (Not
          that it stops some...)

          Not great for "Amateur" radio, turning us into "appliance users" nothing
          else.

          There are better and truly "open" audio codec's about, FreeDV being one.
          http://freedv.org/tiki-index.php

          Scroll down to the Links seciton, for a lot more info.

          73.

          Dave G0WBX.


        • Matthew Pitts
          All of the code I use for my D-Star node, gateway and reflector is, and I m one of the development team on the OpenDV (D-Star Digital Voice) project, as is
          Message 4 of 23 , Jun 6, 2013
          • 0 Attachment

            All of the code I use for my D-Star node, gateway and reflector is, and I'm one of the development team on the OpenDV (D-Star Digital Voice) project, as is John. The only part of the core specification that is closed is the vocoder; Icom's gateway software, DPlus, and the default software for the DVAP-Dongle and DV-Dongle aren't part of the specification.

            As far as Codec2, I would suggest waiting for a hardware module that handles it in firmware as the only functional option right now is more complex than a lot of users on this list would like to use.

            Matthew Pitts
            N8OHU

            Sent from Yahoo! Mail on Android



            From: Mathison Ott <mathisono@...>;
            To: <Raspberry_Pi_4-Ham_RADIO@yahoogroups.com>;
            Subject: Re: Re: [Raspberry_Pi_4-Ham_RADIO] DVAP and the DVRPTR boards
            Sent: Fri, Jun 7, 2013 3:36:47 AM

             

            D-star isn't even opened source!  Were is the codec2 mode for the RPi?

            73 Kj6dzb
            Mathison



            On Thu, Jun 6, 2013 at 7:19 AM, John Hays <john@...> wrote:
             

            Not one of these has a vocoder (AMBE) to do the gateway/hotspot function and all can run using open source.






            Sent from Samsung tablet

            Dave B <dave@...> wrote:
             

            On 6 Jun 2013 at 8:57, Raspberry_Pi_4-Ham_RADIO@yahoogroups.com wrote:

            > __________________________________________________________
            > Re: DVAP and the DVRPTR boards
            > Posted by: "John D. Hays" john@... k7ve
            > Date: Wed Jun 5, 2013 4:36 pm ((PDT))
            >
            > DVAP - small "Dongle" type 2m or 70cm radio that you plug into a
            > computer, it transmits at about 10mw and is the popular choice for "in
            > house" access to the D-STAR digital voice network.
            > http://www.dvapdongle.com/DV_Access_Point_Dongle/Home.html
            >
            > DVRPTR V1 - A GMSK modem based on DSP that goes between a computer,
            > attached by USB, and an existing 2-way radio (9600 bps packet ready)
            > to give access to the D-STAR digital vocie network -
            > http://www.dvrptr.net/
            >
            > STARBoard - A GMSK modem based on a dedicated modem chip that goes
            > between a computer, attached by USB, and an existing 2-way radio (9600
            > bps packet ready) to give access to the D-STAR digital vocie network
            > - http://moencomm.com/
            >
            > UDR56k-4 - A new digital radio, 70cm/25 watts, built in DSP modems for
            > D-STAR Digital Voice, D-STAR Digital Data (56kbps+ Ethernet over
            > radio), packet radio from 9600 bps - 56kbps +, and more. Built in
            > computer to run the DSP modems, protocol stacks, and applications on a
            > Linux operating system (Debian / ARM). Open source for experimenters.
            > Gateway or end user radio. http://nwdigitalradio.com (Discount on
            > pre-orders until the 15th).
            > [I am a member of the team creating this radio.]
            >
            > ------------------------------
            > John D. Hays
            > K7VE
            > PO Box 1223, Edmonds, WA 98020-1223
            > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
            > <http://www.facebook.com/john.d.hays>
            >

            Remember that those things are anything but low cost, closed source, and
            your not even legally permitted to reverse engineer the protocol! (Not
            that it stops some...)

            Not great for "Amateur" radio, turning us into "appliance users" nothing
            else.

            There are better and truly "open" audio codec's about, FreeDV being one.
            http://freedv.org/tiki-index.php

            Scroll down to the Links seciton, for a lot more info.

            73.

            Dave G0WBX.


          • John D. Hays
            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
            Message 5 of 23 , Jun 6, 2013
            • 0 Attachment
              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 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.

              Let's look at other technologies that are (or were) patented and proprietary and used widely in amateur radio.

              Every microprocessor, display, and almost every discrete component in a radio.

              A read of https://en.wikipedia.org/wiki/History_of_radio will show that CW, AM, FM were all patented inventions.


              This is true of almost every aspect of radio telecommunications.

              The original question was around 

              "Can someone recommend a place to buy a raspberry pi board and the correct
              version / part number? I am looking to build a DVDongle - Pi box"

              People simply provided various sources for the Pi, and the below referenced email simply provided additional devices that could be used with the Raspberry Pi  to provide D-STAR connectivity

              All of these are for a gateway/hotspot to allow someone with a D-STAR radio connectivity to the rest of the D-STAR network via the Raspberry Pi.  None of them require the AMBE chip (one has it as an option).

              The arguments express ignorance of the technology and applications -- Amateurs should do better than that, providing technically and logically correct answers.  Leave misinformation and deception to the politicians!

              If you don't like D-STAR, simply state it, but making false arguments doesn't leave much credibility.  It's OK to not like something, but allow others to learn about and make up their own minds about it.



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




              On Thu, Jun 6, 2013 at 8:36 PM, Mathison Ott <mathisono@...> wrote:
               

              D-star isn't even opened source!  Were is the codec2 mode for the RPi?

              73 Kj6dzb
              Mathison



              On Thu, Jun 6, 2013 at 7:19 AM, John Hays <john@...> wrote:
               

              Not one of these has a vocoder (AMBE) to do the gateway/hotspot function and all can run using open source.






              Sent from Samsung tablet

              Dave B <dave@...> wrote:
               

              On 6 Jun 2013 at 8:57, Raspberry_Pi_4-Ham_RADIO@yahoogroups.com wrote:

              > __________________________________________________________
              > Re: DVAP and the DVRPTR boards
              > Posted by: "John D. Hays" john@... k7ve
              > Date: Wed Jun 5, 2013 4:36 pm ((PDT))
              >
              > DVAP - small "Dongle" type 2m or 70cm radio that you plug into a
              > computer, it transmits at about 10mw and is the popular choice for "in
              > house" access to the D-STAR digital voice network.
              > http://www.dvapdongle.com/DV_Access_Point_Dongle/Home.html
              >
              > DVRPTR V1 - A GMSK modem based on DSP that goes between a computer,
              > attached by USB, and an existing 2-way radio (9600 bps packet ready)
              > to give access to the D-STAR digital vocie network -
              > http://www.dvrptr.net/
              >
              > STARBoard - A GMSK modem based on a dedicated modem chip that goes
              > between a computer, attached by USB, and an existing 2-way radio (9600
              > bps packet ready) to give access to the D-STAR digital vocie network
              > - http://moencomm.com/
              >
              > UDR56k-4 - A new digital radio, 70cm/25 watts, built in DSP modems for
              > D-STAR Digital Voice, D-STAR Digital Data (56kbps+ Ethernet over
              > radio), packet radio from 9600 bps - 56kbps +, and more. Built in
              > computer to run the DSP modems, protocol stacks, and applications on a
              > Linux operating system (Debian / ARM). Open source for experimenters.
              > Gateway or end user radio. http://nwdigitalradio.com (Discount on
              > pre-orders until the 15th).
              > [I am a member of the team creating this radio.]
              >
              > ------------------------------
              > John D. Hays
              > K7VE
              > PO Box 1223, Edmonds, WA 98020-1223
              > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
              > <http://www.facebook.com/john.d.hays>
              >

              Remember that those things are anything but low cost, closed source, and
              your not even legally permitted to reverse engineer the protocol! (Not
              that it stops some...)

              Not great for "Amateur" radio, turning us into "appliance users" nothing
              else.

              There are better and truly "open" audio codec's about, FreeDV being one.
              http://freedv.org/tiki-index.php

              Scroll down to the Links seciton, for a lot more info.

              73.

              Dave G0WBX.


            • John Ferrell
              How much is a few dollars? Not that I have the talents to implement one, I am just curious. I have learned in the past that anything that is limited to a
              Message 6 of 23 , Jun 7, 2013
              • 0 Attachment
                How much is a "few dollars?"
                Not that I have the talents to implement one, I am just curious. I have
                learned in the past that anything that is limited to a single source is
                never truly mine. It is subject to the whims of the supplier. Everyone
                has their own threshold for risk. Mine is $20, the same as my personal
                limit on the rare occasion when I visit a Casino.
                I feel that ICOM and Broadcomm are both quality enterprises. The real
                reason that I have not had more interest in D-Star is that there are
                just so many other technical toys to play with at this time!

                On 6/7/2013 1:53 AM, John D. Hays wrote:
                > -.AMBE is proprietary and licensed technology of DVSI, which can be
                > obtained in firmware on a dedicated DSP chip for a few dollars.

                --
                John Ferrell W8CCW
                "The pessimist complains about the wind;
                The optimist expects it to change;
                The realist adjusts the sails."
                William A. Ward
              • Bruce Given
                A few dollars is DVSI Small qty pricing AMBE2020 approx $20.00 Older AMBE codec AMBE3000R approx $30.00 Newer Codec is backwards compatible with D-Star AMBE
                Message 7 of 23 , Jun 7, 2013
                • 0 Attachment
                  A few dollars is

                  DVSI Small qty pricing
                  AMBE2020  approx  $20.00 Older AMBE codec
                  AMBE3000R approx $30.00 Newer Codec is backwards compatible with D-Star AMBE and also contains P25 and DMR Codecs

                  and yes it's "closed" source but so are a lot of things us Amateurs use

                  regards
                  Bruce
                  VE2GZI



                  On Fri, Jun 7, 2013 at 9:15 AM, John Ferrell <jferrell13@...> wrote:
                   

                  How much is a "few dollars?"
                  Not that I have the talents to implement one, I am just curious. I have
                  learned in the past that anything that is limited to a single source is
                  never truly mine. It is subject to the whims of the supplier. Everyone
                  has their own threshold for risk. Mine is $20, the same as my personal
                  limit on the rare occasion when I visit a Casino.
                  I feel that ICOM and Broadcomm are both quality enterprises. The real
                  reason that I have not had more interest in D-Star is that there are
                  just so many other technical toys to play with at this time!



                  On 6/7/2013 1:53 AM, John D. Hays wrote:
                  > -.AMBE is proprietary and licensed technology of DVSI, which can be
                  > obtained in firmware on a dedicated DSP chip for a few dollars.

                  --
                  John Ferrell W8CCW
                  "The pessimist complains about the wind;
                  The optimist expects it to change;
                  The realist adjusts the sails."
                  William A. Ward




                  --
                  I’d rather live in a world full of eccentric thinkers than one full of unthinking consumers.
                • John Ferrell
                  Looks like a good start to me. I will watch a while longer and try to learn more. ... -- John Ferrell W8CCW The pessimist complains about the wind; The
                  Message 8 of 23 , Jun 7, 2013
                  • 0 Attachment
                    Looks like a good start to me. I will watch a while longer and try to learn more.

                    On 6/7/2013 9:42 AM, Bruce Given wrote:
                     
                    A few dollars is

                    DVSI Small qty pricing
                    AMBE2020  approx  $20.00 Older AMBE codec
                    AMBE3000R approx $30.00 Newer Codec is backwards compatible with D-Star AMBE and also contains P25 and DMR Codecs

                    and yes it's "closed" source but so are a lot of things us Amateurs use

                    regards
                    Bruce
                    VE2GZI



                    --
                    John Ferrell W8CCW
                    "The pessimist complains about the wind;
                    The optimist expects it to change;
                    The realist adjusts the sails."
                    William A. Ward




                    --
                    I’d rather live in a world full of eccentric thinkers than one full of unthinking consumers.

                    -- 
                    John Ferrell W8CCW
                    "The pessimist complains about the wind;
                    The optimist expects it to change;
                    The realist adjusts the sails."
                         William A. Ward 
                  • Kristoff Bonne
                    John, ... 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
                    Message 9 of 23 , Jun 9, 2013
                    • 0 Attachment
                      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.

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

                      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.



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


                      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.



                      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.
                       


                      73
                      kristoff - ON1ARF
                    • John D. Hays
                      Comments in line. ... This is good to know. So running headless should be possible in real time? ... The fact that any intellectual property is in your
                      Message 10 of 23 , Jun 9, 2013
                      • 0 Attachment
                        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 
                          



                         
                      • Kristoff Bonne
                        Hi John, ... $ time c2enc 1400 20sec.raw 20sec.c2 real 0m2.723s user 0m2.480s sys 0m0.030s $ time c2dec 1400 20sec.c2 20sec_out.raw real 0m5.349s
                        Message 11 of 23 , Jun 10, 2013
                        • 0 Attachment
                          Hi John,


                          On 10-06-13 00:34, 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?
                          $ time c2enc 1400 20sec.raw 20sec.c2
                          real    0m2.723s
                          user    0m2.480s
                          sys    0m0.030s


                          $ time c2dec  1400 20sec.c2 20sec_out.raw
                          real    0m5.349s
                          user    0m4.860s
                          sys    0m0.050s



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

                          Well, it's exactly this "vendor choice" of not documenting the technology that is the issue if you are interested to playing around with technology. (which is what being a ham is about).





                           
                          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.
                          Well, perhaps except OpenRISC (but then, you will not be able to run codec2 on that). :-)

                          My point was that the IP of the chip-makers is not a limiting factor to write software for DV. The D-STAR specification does not say that I need to run D-STAR software on an ARM CPU. I have the choice to run it on any CPU I like; so there is no "single source" issue.

                          The D-STAR specifications DO however say "you have to use the AMBE vocoder", a product that is only a available from a single vendor.

                          The specifications do however NOT say "if you set that bit, you are free to try out a other vocoder". (in contrast to DMR which does allow a choice of vocoder (three from a list in the specs, a 4th one you can chose yourself).



                           
                          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  

                          Interesting reading. Thanks!



                          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.
                          For the record. My issues with D-STAR is for a very practicle reason: the specifications do not allow experimentation. My interest -as a ham- is to learn about things and to be able to experiment with things.

                          You are correct. The protocol itself is documented; which is better then nothing.
                          On the other hand, if you compair it to -say- the documentation of ETSI DMR, or any ITU specification or an IETF RFC-document, the document is not really up to the standard of what most people would expect of being "an official document".

                          (then again, the documentation of c2gmsk isn't the best neither :-( )


                           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.
                          True! Fair point.

                          It would be nice if the developers of the D-STAR GMSK boards would also implement these modes so that people can experiment with it.


                          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.]
                          Well, this is actually an interesting case because it does show something typical for the D-STAR documentation.

                          I may have missed it, but sofar I have seen, the D-STAR document does
                          - describe the ethernet-over-DSTAR protocol
                          - say that a D-STAR system can concist of "DD on 23 cm at 128 Kbps" or "DV at 2 meter, 70 cm and 23 cm".




                          So ... is DD allowed at 70 cm or 2 meter? And at what bitrate? 128 Kbps or in a 4800 bps stream?


                          This might look like a stupid argument; but let me explain what it means.
                          I once did a simple test. Generate a D-STAR stream, change the header and mark it as "DD" instead of "DV". (that's just a bit in the header) and send it to an i-com radio. The result: the stream (which happen to contain a DV-like content) was played out by the radio.

                          This is one of the reasons why I have up doing experiments on D-STAR.
                          As there is no clear indication in the specification saying "if that bit is set to "1", the stream is DD and should not be played out by a DV-only radio" and not "DD can be used on 2 meter", the author of the firmware (icom) can say "I'm sorry, we are interpreting the specification say that there should only be DV on 2 meter; so the firmware does what the specs say"


                          For me, I did not want to take the risk that -by starting to experiment with the stream-format of D-STAR on the radio- that other hams would get a lot of R2D2 on their radio, because the firmware of their radio interpretes my signal as D-STAR. I think this would be not very ham-like.



                          I think, if the specification of D-STAR would have been of a better quality and clearly point out the responsability of every party in a conversation; that we would have been able to safely experiment with the protocol from within D-STAR.
                          However, this is not the case. The only option is to generate bitstreams that are completely unlike D-STAR, this to avoid interference of D-STAR and other systems.




                          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?
                          Well, I do follow some of the mailing-lists on the net where internet protocols and technologies are discussed while being developed.
                          Look at (say) SIP, XMPP or ogg vorbis and speex, etc.


                          But then, the ham world is just now starting to learn from how things are done "on the net".



                          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.
                          No issues about that. And icom has done a good job there.

                          And, to be honest, my project started by the sourcecode of the GMSK modem that comes from D-STAR repeater software of Jonathan. If D-STAR would not have existed, c2gmsk would probably not have been there neither.

                          And I know a lot of sysops of D-STAR repeaters that have spends a lot of time and money in the system; so all my respect to them.




                          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.
                          For me personally, it's not about "replacing D-STAR". It's about having a tool to learn about digital voice and digital communication and allow other people to experiment with it.


                          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.
                          True. No issue about that.

                          My argument is just that being a "ham" is more then a user.

                          Digital voice is no magic. People should not be afraid to ask "what is really inside my digital voice radio?". Things like software, DSP, SDR, etc. are all part of electronics today. And it is not because something is "hidden" in a chip; that is magic.

                          And, to really understand what digital communcation is, you should have the tools to experiment with it. One of the things I really want to do is convert the c2gmsk API into a module for gnuradio.
                          Because GNUradio, combined with a SDR radio, REALLY allows people to experiment with digital radio. It allows them to ask (e.g.)  "hey, ... if we would now change the interleaving, FEC, encoding or  modulation sceme, what would be the result when trying to decode a Es digital signal on 10 meter or 6 meter?".

                          These are tools that do exist today, that is how electronics is done nowdays.
                          However, the key to that is "open knowledge". Open-source does allow us to do this. D-STAR does so much less. It is a "consumer product".


                           
                          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.
                          A totally agree.

                          Let's keep the discussion technically correct.


                          73
                          kristoff - ON1ARF
                        • Matthew Pitts
                          Kristoff, Any speed between 4k8 and 128k on any band permitted. Also, according the the specification document, Bit 7 of Flag 1 (which immediately follows the
                          Message 12 of 23 , Jun 10, 2013
                          • 0 Attachment
                            Kristoff,

                            Any speed between 4k8 and 128k on any band permitted. Also, according the the specification document, Bit 7 of Flag 1 (which immediately follows the frame sync) is the bit that determines whether a given transmission is supposed to be voice or data. This apparently is ignored by the Icom hardware other than the ID-1, no doubt because they misunderstood the intent of the protocol designers to allow lower speed DD mode on other bands.

                            Matthew Pitts
                            N8OHU




                            I may have missed it, but sofar I have seen, the D-STAR document does
                            - describe the ethernet-over-DSTAR protocol
                            - say that a D-STAR system can concist of "DD on 23 cm at 128 Kbps" or "DV at 2 meter, 70 cm and 23 cm".




                            So ... is DD allowed at 70 cm or 2 meter? And at what bitrate? 128 Kbps or in a 4800 bps stream?


                            This might look like a stupid argument; but let me explain what it means.
                            I once did a simple test. Generate a D-STAR stream, change the header and mark it as "DD" instead of "DV". (that's just a bit in the header) and send it to an i-com radio. The result: the stream (which happen to contain a DV-like content) was played out by the radio.

                            This is one of the reasons why I have up doing experiments on D-STAR.
                            As there is no clear indication in the specification saying "if that bit is set to "1", the stream is DD and should not be played out by a DV-only radio" and not "DD can be used on 2 meter", the author of the firmware (icom) can say "I'm sorry, we are interpreting the specification say that there should only be DV on 2 meter; so the firmware does what the specs say"


                            For me, I did not want to take the risk that -by starting to experiment with the stream-format of D-STAR on the radio- that other hams would get a lot of R2D2 on their radio, because the firmware of their radio interpretes my signal as D-STAR. I think this would be not very ham-like.



                            I think, if the specification of D-STAR would have been of a better quality and clearly point out the responsability of every party in a conversation; that we would have been able to safely experiment with the protocol from within D-STAR.
                            However, this is not the case. The only option is to generate bitstreams that are completely unlike D-STAR, this to avoid interference of D-STAR and other systems.




                            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?
                            Well, I do follow some of the mailing-lists on the net where internet protocols and technologies are discussed while being developed.
                            Look at (say) SIP, XMPP or ogg vorbis and speex, etc.


                            But then, the ham world is just now starting to learn from how things are done "on the net".



                            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.
                            No issues about that. And icom has done a good job there.

                            And, to be honest, my project started by the sourcecode of the GMSK modem that comes from D-STAR repeater software of Jonathan. If D-STAR would not have existed, c2gmsk would probably not have been there neither.

                            And I know a lot of sysops of D-STAR repeaters that have spends a lot of time and money in the system; so all my respect to them.




                            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.
                            For me personally, it's not about "replacing D-STAR". It's about having a tool to learn about digital voice and digital communication and allow other people to experiment with it.


                            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.
                            True. No issue about that.

                            My argument is just that being a "ham" is more then a user.

                            Digital voice is no magic. People should not be afraid to ask "what is really inside my digital voice radio?". Things like software, DSP, SDR, etc. are all part of electronics today. And it is not because something is "hidden" in a chip; that is magic.

                            And, to really understand what digital communcation is, you should have the tools to experiment with it. One of the things I really want to do is convert the c2gmsk API into a module for gnuradio.
                            Because GNUradio, combined with a SDR radio, REALLY allows people to experiment with digital radio. It allows them to ask (e.g.)  "hey, ... if we would now change the interleaving, FEC, encoding or  modulation sceme, what would be the result when trying to decode a Es digital signal on 10 meter or 6 meter?".

                            These are tools that do exist today, that is how electronics is done nowdays.
                            However, the key to that is "open knowledge". Open-source does allow us to do this. D-STAR does so much less. It is a "consumer product".


                             
                            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.
                            A totally agree.

                            Let's keep the discussion technically correct.


                            73
                            kristoff - ON1ARF


                          • Jonathan Naylor
                            ... That is insulting. My D-Star source code has always been open source, repeaters for different hardware and gateway included. Please check your facts before
                            Message 13 of 23 , Jun 27, 2013
                            • 0 Attachment
                              > D-star isn't even opened source! Were is the codec2 mode for the RPi?

                              That is insulting. My D-Star source code has always been open source, repeaters for different hardware and gateway included. Please check your facts before saying such things.

                              > 73 Kj6dzb
                              > Mathison

                              Jonathan G4KLX
                            Your message has been successfully submitted and would be delivered to recipients shortly.