[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: D-STAR experiment on Cubesat

On Mon, Jun 9, 2008 at 7:48 PM, Tony Langdon <vk3jed@gmail.com> wrote:
> At 03:35 AM 6/10/2008, Mark Vandewettering wrote:
>>It is my understanding that it is simple a relabeled Icom radio.  If
>>it really weren't an issue for other manufacturers, one might
>>reasonably ask why we aren't seeing D-Star radios from other
> I believe you are correct there, a rebadged ID-800, according to what
> I've read.
>>manufacturers.  Granted, there could be other reasons, but something
>>is apparently keeping other manufacturers from building these radios.
>>This means that essentially we are in a single source situation, where
> Only the other manufacturers can answer that.  The situation
> certainly hasn't stopped ham experimentation, and there has been at
> least one somewhat D-STAR capable radio built (there were issues, but
> they were related to the specific components chosen).  There is a
> software based D-STAR demodulator
> (http://groups.yahoo.com/group/dstarsoftware) that apparently works
> quite well, when connected to a 9600 bps capable radio.  Of course, a
> DV Dongle is needed to recover the audio, but the software will
> decode the headers and the low speed data stream.  Transmit is just a
> matter of the author getting around to writing that capability.  At
> this stage, he has been focusing on improving the receive performance
> of his demodulator.
>>we can expect D-Star to remain fairly expensive.   Indeed, the codec
>>chip costs $20, but we see the price differential for these radios to
>>be well over $100, even on an HT which is fairly expensive to begin
>>with.  That's a pretty high markup.  (IC-91AD is $524, IC-91A is $408
>>at universal radio).  The UT-118 to do an upgrade is $189.   The DV-
>>Dongle is $200.
> I suspect that will change with time, if (or more likely, when)
>>But I do think there are reasons to be less than fully happy.
>>1. We have committed ourselves to building a system with parts from a
>>single manufacturer.  On this list, we have heard that Kenwood is
>>unable to build new TH-D7As because they can't get a part which is
>>single sourced, only 10 years into its lifetime.  It doesn't seem to
>>me to be good engineering to design our repeater systems around such a
>>part, given our expected longevity for repeaters.  I admit, this
>>concern is largely paranoia, but paranoia pays off occasionally.
> You have a point.  The true single source issue is not ICOM, it is
> really DVSI.  We can fix the ICOM part ourselves over time, with DV
> adapters and surplus FM radios with direct discriminator/modulator
> access.  The controller might be trickier, but not beyond our
> capabilities, given time.
>>2. We are denying ourselves an opportunity: the opportunity to
>>understand, modify, and create new digital voice systems.  If we go to
>>using AMBE, we are stuck: stuck with a technology that we can't extend
>>or expand because of IP property law.  Indeed, we will have invested
>>considerable sums of money in such a system, which will present a
>>serious impediment to future developments, since we will have so much
>>money already invested in the old system.
> We are stuck with AMBE... for now.  Perhaps in the future, there will
> be a way to incorporate other (i.e. open source) vocoders alongside
> AMBE.  However, the developers will also need to push to get the
> vocoder into silicon fairly rapidly, once it's performing acceptably,
> so a manufacturer can produce the chips in the millions for
> installation into radios.  The ideal vocoder will have readily
> available and unencombered software (for running on a PC) and
> hardware (i.e. DSP chip for installing into a radio) implementations.
>>3. Gadgets like the DV-Dongle cost $200, and you hook them to your
>>PC.  Your PC could do _everything_ that the DV-Dongle does in software
>>(obviously, since the AMBE chip is just a low end TI DSP, mask
>>programmed with the AMBE decoder).   Imagine how much higher the
>>deployment of D-Star would be if we could have a freely available open
>>source application that people could run on their Windows, Mac and
>>Linux machines for _zero cost_.   As Gordon Bell once said
>>(paraphrasing from memory) "the cheapest part of a computer are the
>>parts that aren't there".  Replacing a $20 with, well, nothing but
>>electrons is a big deal.
> In an ideal world, yes.  I believe we need to work with what's there
> now, and at the same time push for a better future.
>>Bruce echos most of these issues on his page:
>>         http://codec2.org/
> Unfortunetely, he does get a few critical technical details wrong, if
> he is interesting in writing a vocoder compatible with D-STAR.  Such
> a vocoder needs to (1) compress voice down to 2400 bps (not the
> 5000-6000bps he states for VHF), and (2) provide FEC, as the D-STAR
> protocol itself doesn't provide FEC.  The difference in bit rate
> between 5000 and 2400 bps is a world of difference for
> performance.  Of course, we can always use LPC-10 and sound like Daleks... ;)
> 73 de VK3JED
> http://vkradio.com

I appreciate very much this civilized debate, which helps me
understand the issues involved in this new technology. I, too, find it
frustrating that this protocol has no prospect for an in-software
codec as of yet, but I understand the practical trade-offs that led to
this situation. I wonder if people who are aware of the design could
comment on if LPC-10 could theoretically be put ontop the transport
layer. I'm not sure I'd mind 'sounding like Daleks', at least for the
purpose of operating this cubesat.

Secondly, does anyone know which d-star radios have CAT, and does the
CAT control line conflict with the data line, as it does on the
Kenwood radios? If this were the case, I'd be inclined to stick with
the Dongle approach.
Sent via AMSAT-BB@amsat.org. Opinions expressed are those of the author.
Not an AMSAT-NA member? Join now to support the amateur satellite program!
Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb