Hi Mike,
On 28-04-12 23:20, Mike Eber wrote:
The other main issue is that D-Star is voice centric. The digital system should be concerned with moving data bits to the correct destination. It shouldn't matter what the application is voice, pictures, GPS ect. That is the main distinction we are making.
Well, having an "network" background, I also had the same opinion.But, with playing around with digital voice, the GMSK sender/receiver (and also software for a FM voice parrot too), I did start to see things differently. One of the way where "voice" and "data" differ is about bit error rate. Digital voice can actually take quite a beating concerning transmission errors and still be understood. That's completely not true for data.
As -in the end-, the ham radio-enviroment can be quite harse (distances over hunderd kilometers on VHF or UHF, shortwave communication with 59+ QRM, ...). In these enviroment, digital voice is not going to be easy, but might still get throu. Data -on the other hand- might simply be impossible; unless you fall back to one of the "keyboard" or -even below that- the "one over per minute" modes.
I'm not that convinced that a "one technology to rule them all" is necessairy the best way for ham communication.
Concerning the "D-STAR is not open source", I agree with the remarks of Matthew. D-STAR does not have to be open source. It needs to be "open specification" and -even with the bad quality of the specs- it does is that.
For the rest, for almost every component of the D-STAR infrastructure that was originally closed-source, there are now open source alternatives; with the exception of the audio-codec. For me, the project that Peter has started, to design a GMSK-based system simular to D-STAR but using the codec2 audio-codec and open algoriths for error-correction and error-detection makes more sence than redesigning everything from scratch.
There is a whole world of D-STAR infrastructure out there, some of them based on the open source code of Jonathan G4KLX. If we stick to GMSK and the D-STAR stream-structure as close as possible, it will be much more easy to incorperate a codec2-based system into this software and -so- in the rest of the G4KLX-based D-STAR repeaters out there.
You can then "plug" this into the data backbone you are working on, but that is a completely different issue.
If there is one thing that kills most new projects; then it is over-engineering and over-planning everything up-front. I prefer the "KISS" principle of keep-it-simple and let things "grow" organically. Open source is quite flexible in incorperating new features; so there is no need to "plan" everything beforehand.
-Mike
Cheerio! 73 - Kristoff
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
