Re: work on d-star clone?
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@natetech.com
Reply to: