Hi Bruce,

On 01-11-11 22:56, Bruce Perens wrote:
>> I know this is a bit dangerous discussion as there are some people who 
>> think that other (non-D-STAR compatible) DV modes would hinder the 
>> further growth of D-STAR.
> In this case, what's only arguably bad for D-STAR is clearly good for 
> Amateur Radio. We need to be in control of our protocols and codecs.
Well, to be honest. I do understand both sides of the argument.

Anycase, the most important in this is not to turn this into a in a
round of "D-STAR bashing". This is a list for codec2, not against D-STAR.



For me, being a ham is about learning, experimenting and sharing. My
little project now has made me learn a lot, about the D-STAR
radio-protocol, about DSP, about ARM CPUs and how they are designed to
run DSP-code, etc.

Next step will be to find ways to improve the quality of the receiver
process (better syncronisation, dealing with errors, detecting the
beginning and the end of a stream more reliably, reducing power
consumption, etc.).



You know. Go to any ham forum on (say) antennas or radios and ask any
question. You'll probably get 10 answers with all kind of advice.
But ask a question about the internal working of a piece of ham
software, about DSP, about modulation scemes of digital modes, etc. And
you'll get very little to no response. That all seams to be seen as "magic'.

(A bit like some companies said: "making a sub-3000bps voice coder:
that's something very special, requires a lot of patented technology and
is therefor very expensive). :-)


I think this is wrong. Take a question like "how do you receive a gmsk
stream from a radio and do it reliably?".
Even if only 0.1 percent of the hams community has sufficient technical
background to understand this. That would still be thousands of people.
There shouldn't be anything "magical" about this.

Up to now. If you have any problem with (say) receiving a D-STAR signal
with a gmsk modem, the answer usually was "wait for the author to fixed
it, download the new firmware, install it, ... and then check again."
All this knowledge has been locked away in this magical thing called
"the firmware".

Thanks to the open-source projects of some people (especially in the
D-STAR domain), things are changing. Source-code (and knowledge) is
becoming public.
However, I have the impression that the ham community does not yet
understand open-source. They do not understand that open-source means
more then "for free" (as in beer). It actually means that can you
download the software, look at it, learn from it, experiment with it and
co-develop it.

For me, these boards, together with the linux running on them, and the
software taken from the pcrepeatercontroller project of Jonathan, could
be a nice platform to allow everybody to play around with this kind
technology. To allow everybody "make your own gmsk modem" ... or .. why
not ...  "make your own DV system".



So, the whole issue of "D-STAR vs. some-other-version-of-DV" or "AMBE
vs. codec2" is not my problem. For me, this is about being able to learn
and experiment.






>>  So what I want to experiment is creating a DV-mode (NOT D-STAR and 
>> called D-STAR), using roughly the frame-structure of DV D-STAR; but on 
>> purpose NOT compatible with it. (e.g. by inverting all the bits in the 
>> field-check error part of the header or using a different scrambling 
>> system or something like that)
> Please try to figure out a format that D-STAR repeaters and gateways 
> will carry, but which doesn't decode as the stock D-STAR voice. The goal 
> would be for the packets to get to all possible sites, but for those 
> sites to stay silent if they aren't equipped to decode it.
Well, one of the problems with D-STAR is the quality of the specifications.

The public documents out there are no "specification" in the sence of
what you and I know (IETF RFCs or ITU or ETSI specs). They just describe
an implementation of the D-STAR protocol, nothing more. They just say
"how it is implemented", not "how it should be and how a device should
react".

E.g.
- it describes how to calculate the checksum of the radio-header ... but
it does not say what a radio must do if it receives a stream with an
incorrect checksum.
- the same thing for the syncronisation pattern found in the "the
data-part of the first frame, and every consequative 20 frames"
- idem-dito for the "the 3th octet of the header ("flag3", currently
unused and should contain 0").


So, if we descide to broadcast a signal with some other value in these
fields, there is actually still in the specs that say how a (D-STAR)
radio should react to this.

Image that we do do this, and some types of radio do try to decode this
anyway and plays out R2D2.
What do you think the manufactor will say: "not our fault, we followed
the specs!"


Not a very healthy situation. :-(




>      Thanks
>      Bruce
73
Kristoff - ON1ARF

------------------------------------------------------------------------------
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to