[WARC] Fwd: Re: work on d-star clone?

[Clare Jarvis]

Yet another opinion.

btw.   Ham Radio Outlet sells a dongle that has the ambre vodec built in.   It 
sells for $200.00~.


73 Clare

----------  Forwarded Message  ----------

Subject: Re: work on d-star clone?
Date: Tuesday 26 August 2008
From: Nate Duehr <nate at natetech.com>
To: Dennis Boone <drb at msu.edu>


On Aug 25, 2008, at 5:51 PM, Dennis Boone wrote:

>> I've not seen anything on D-STAR except ICOM gear.  While the  
>> protocol
>> is open, I understand that the vocoder chip ICOM uses is a  
>> proprietary
>> off the shelf item.  While the chips may be available to the
>> experimenter, I've read of concerns of there not being a second  
>> source
>> for the chips.
>

To throw some sanity in the FUD...

> There are worse concerns than that.  Overloading identification data
> (needed for regulatory reasons) for routing purposes,

What better way to simplify things?  Callsign routing.  Smart.

> extremely limited
> callsigns (if you're an Aussie with a four letter callsign suffix, no
> D-Star for you...),

Yeah that one's dumb.

> one radio per callsign (can you say lots of
> technically illicit club calls under US regs?),

Wrong.  Flat out wrong.  The limitation is that a REPEATER can't have  
the same callsign as a user... which makes sense for a source-routed  
system, kinda.  Maybe bad design, but nowhere near as bad as you're  
claiming.   Every callsign can support 26 radios (A-Z) and directly  
route between them as far as end-user rigs go.

> network size limitations
> that could hail from the 70s,

Source for this comment, please?  It's just a simple few tables in a  
PostgreSQL DB... not sure what you think are the "limitations" of that.

> the undocumented nature of the supporting
> protocol for internet linking and services,

The on-air protocol is public, created by JARL.  The implementation of  
linking between the Gateway servers is Icom-proprietary, but  
infinitely reverse-"engineerable".  Want tcpdump traces?  Are you  
bored?  I have no time for it, but someone will.  Better yet, there  
are some working on open Gateways... but with the momentum behind the  
closed ones, they'd better make sure the open gateways are backward- 
compatible... well over 200 of them and growing at this point in  
time.  Better hurry up, if your goal is open Gateway code.


> no software codecs without
> NDA and $kilobucks, etc.

Icom and JARL started design quite some time ago.  The CODEC is the  
AMBE CODEC from a company called DVSI.  Similar to the APCO folks  
doing APCO Project-25, there simply weren't (and really still aren't)  
any CODECs that were available free-as-in-beer or free-as-in-libre  
that could do these very low data rates with as good voice quality.   
There may be one or two now, but it's debateable whether or not  
they're "good enough" for 2-way radio service in emergency  
situations.  (Actually both AMBE and IMBE from DVSI have come under  
fire for being a bit too aggressive at compression putting emergency  
services personnel -- especially firefighters with respirator and  
other apparatus/equipment running in the background -- at serious risk  
because the background noise/intelligibility is lower.  Federally  
mandated bandwidth limitations notwithstanding, sometimes analog FM  
just works better than a compressed/digitized audio stream.)

Meanwhile... AMBE is available either at a license (expen$ive) or in  
individual chipsets (cheap enough for Amateur/hobby use).  Reality is  
that people that make CODECs want to get paid, and it's not  
"commodity" CODECs were talking about here... these are heavy- 
compression, but-still-maintain-decent-voice-quality CODEC's  
specifically tested and designed for 2-way radio use.  If there's  
people out there who will code them for free/beer or free/libre, they  
haven't shown up in any public limelight that I've seen yet.  Good  
luck finding them...


>  PLEASE WILL THE RF FOLKS GET SOME HELP FROM
> THE DIGITAL FOLKS WHEN DESIGNING THIS STUFF?


That I'll agree with to some extent.  But I'd rather re-phrase it  
to... "If you're going to use Linux for servers, could you please  
consult a real Linux expert before writing the installation  
documentation." -- at least to start with.  Icom does a few typical  
"gaffs" that all ISV's have done when first releasing "products" for  
Linux... but some are Linux's fault...

1. Ask everyone to do a "Full Install plus Developer Tools" and then  
BUILD numerous packages from source.  Yuck.  But... when most distros  
(they chose CentOS as the basis for the documentation) change packages  
as fast as they change underwear, who can blame them?  Unix/Linux has  
always had this problem... you can't "count on" a distro for any  
length of time that's predictable.  (Certainly not Debian... Ubuntu  
perhaps, but Debian has and always will release when it "wants to".)

2. Uses the RedHat/CentOS GUI applications to try to make the  
installation "friendly" instead of just providing a Kickstart file  
that sets sane defaults.

3. Back to that "Everything" install.. um... stripping down what  
packages are NOT needed would be sane...

Probably other stuff... leaving IPv6 on already messed up some people  
(changing hostname through GUI after install, it uses only the IPv6  
loopback address... that's more of a retarded RedHat bug than Icom's  
fault, but they should have tested and/or told folks to turn off  
IPv6)...

Etc etc etc.


> High speed data ain't == D-Star, and I personally hope something
> sensible comes along.

Bandwidth on RF is bandwidth.  D-STAR is already 100 KHz wide to get  
128 Kb/s half-duplex, and the laws of physics aren't changing any time  
soon, or so I hear.  If you have any buddies who will leak the trade  
secrets to code-rotation out in such a way as they can be used without  
Qualcomm suing you into non-existance, maybe you can share some RF  
bandwidth with other devices on a mutual-interference basis, like high  
speed cellular phone networks.  Otherwise, what would you like Icom to  
do about it?

I ain't seeing any of the engineering people who created HSPDA or the  
CDMA variant of high speed (ack, brain fails me.. can't remember  
acronym right now) data handing it out to hobbiests or individuals for  
our use.

It's the Information Age, and ways to move data at higher speeds more  
efficiently are as closely guarded secrets and protected with force,  
as railroad lines were fought over in the late 1800's in the American  
West.

Best thing to do ... don't worry about the FUD and develop and design  
open "stuff" that lays over the TOP of the nicely tested and working  
Icom gear they sell at rediculously low prices (considering that most  
public safety radio systems of similar capability can't do  
international networking with a $200 PC, and the costs for the rigs  
alone is 5-10x the cost of a D-STAR capable Icom Amateur-grade rig.)

The "utopia" of a fully-open digital voice system isn't going to  
happen without a corporate sponsor to build rigs for those who won't.

--
Nate Duehr, WY0X
nate at natetech.com




-- 
To UNSUBSCRIBE, email to debian-hams-REQUEST at lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster at lists.debian.org


-------------------------------------------------------

-- 
Mr. Clare Jarvis
President, Jarvis Computer Software
PO Box 1264
Winona, MN 5598707264

(507) 454-2575