Re: Re: [Raspberry_Pi_4-Ham_RADIO] DVAP and the DVRPTR boards
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.
Sent from Yahoo! Mail on Android
From: Mathison Ott <mathisono@...>;
Subject: Re: Re: [Raspberry_Pi_4-Ham_RADIO] DVAP and the DVRPTR boards
Sent: Fri, Jun 7, 2013 3:36:47 AMD-star isn't even opened source! Were is the codec2 mode for the RPi?73 Kj6dzbMathison
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.
> 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 -
> 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
> PO Box 1223, Edmonds, WA 98020-1223
> <http://k7ve.org/blog> <http://twitter.com/#!/john_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
There are better and truly "open" audio codec's about, FreeDV being one.
Scroll down to the Links seciton, for a lot more info.
- 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 PittsN8OHU
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.
Well, I do follow some of the mailing-lists on the net where internet protocols and technologies are discussed while being developed.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?
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".
No issues about that. And icom has done a good job there.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.
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.
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.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.
True. No issue about that.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.
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".
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.
A totally agree.
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.
Let's keep the discussion technically correct.
kristoff - ON1ARF
> 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 Kj6dzbJonathan G4KLX