Wrong, it's Beebe. If you're going to punk someone out, make sure not to misspell it.

[Rush]
If you choose not to decide, you still have made a choice!
[/Rush]

There's a lot more to being a medical doctor than memorizing symptoms. *facepalm* yourself.

I wrote to Bruce Perens and David Rowe the following email early July 2010. David Rowe responded, understandably, that his primary area of interest and knowledge is really just in the voice codec itself, and he had no specific comment regarding my proposals for modulation and FEC. Bruce Perens never replied to me, which was a disappointment. Perhaps my note never made it past his spam filter.

So, since there is active discussion going on here (with many folks who know much more about signal engineering than me), I am posting the email its entirety, and I sincerely invite comment about my proposals regarding modulation and FEC (particularly to point out anything which is factually incorrect).

Perhaps Bruce would be willing to comment as well.

====== email below ======

Gentlemen,

I am a newly licensed amateur radio operator, and have read with interest in the past weeks about different modes of digital radio. Having read about D-Star, I recognized the need for an open alternative to AMBE, and then was pleasantly surprised to have run across both of your codec2 project sites.

I wanted to share some of my thoughts regarding this project, especially with respect to the longer-term design goals.

-----
VOICE CODEC

I read an old post by David, either on his blog or in a list serve archive, where he asked whether it would be better to (1) release an alpha version of the codec NOW and risk turning people off with poor audio quality or (2) wait for better audio quality before the first release but risk people losing interest and drifting away. I favor early release for the reason that there would be more time for (parallel) development of other softwares around the codec, time to flesh out bugs in the protocol, on-air tests could be conducted, etc. Hardware could even be started in the meantime; the final codec version could later be loaded onto an FPGA.

-----

PROTOCOL DESIGN

Although I certainly see the allure of keeping the existing modem and plugging in a daughterboard to swap AMBE to codec2 (ie, modding existing D*Star HT or mobile), I suggest that a redesign of the protocol altogether may be far more beneficial in the long run.

Presently, as I understand it, D-Star DV allocates its 4800b/s as follows:
+ 2400 AMBE voice
+ 1200 of 2/3 FEC ( actually the voice + FEC are included together in a single frame)
+ 1200 data (no FEC!)
(obviously header/overhead/sync is a part of the 1200 data)
= GMSK modulated it occupies ca 6.25kHz.

I would like to see it done this way instead:
+ header with id, routing?, and _specified division of voice and data_
+ (3200 voice) OR (3200 data) OR ( 2400 voice + 1200 data)
+ 1600 FEC for all of above
= QPSK modulated it could occupy as little as 3kHz bandwidth (at eff 1.6 ; theoretical max for QPSK is 2 = 2.4kHz bw).

-----

OTHER THOUGHTS

1. If we used QPSK modulation with spectral efficiency of 1.6, we could increase the total data rate to 9600bps while maintaing the same occupied bandwidth of ca. 6kHz.

2. My proposed header specifies that the voice rate is [3200] or [2400] (or, if we bump the total rate to 9600, we could have a maximum of 6400 bps voice data rate with 2/3 FEC) ; the receiver would implement the correct decoding. I don't know how tolerant the current algorithms are of changing the codec bitrate midstream (Speex has VBR though, so I suppose it could work).

3. No. 2, above, is important as data could be streamed intermittently, irrespective of whether or not a voice transmission is taking place.

4. With good filters, 9600 bps could still be GMSK modulated and occupy a standard FM channel width of 12.5kHz but I suppose this is dodgy.

5. I am not as familiar with the tradeoffs of GMSK v. QPSK (power efficiency, SNR, complexity?) and I'm sure there is a good reason GMSK was chosen for D-Star.

6. FEC.
    a. D-Star includes no FEC on the header or data frames! The FEC is an integral part of AMBE.
    b. Instead of building FEC into the voice codec, I favor including FEC for the entire packet (to include the voice AND data frame), in contrast to D-Star.
    c. Bruce's site mentions that Turbocodes will be going off patent in a few years, and that France Telecom is happy to license to radio amateurs gratis in the meantime. Although I am not a signals expert, my cursory investigation indicates that LDPC (low density parity check) codes may offer several advantages.
          1. Completely unencumbered. Invented in a 1960 Sc.D thesis by Robert Gallager
          2. More efficient then Turbocodes on slow or low-complexity hardware.
          3. Parallelises well

-----

I recognize this was a long and perhaps poorly-structured ramble, but I am very interested to hear what you both have to say. If you can think of a mailing list or message forum where I might post this to solicit other feedback, please let me know.

Warm regards,
name & call sign redacted
city redacted

REFERENCES
1. Bruce Perens' codec2 vision. http://www.codec2.org/
2. David Rowe's codec2 project page. http://www.rowetel.com/ucasterisk/codec2.html
3. D-Star Protocol Description. http://www.aprs-is.net/downloads/DStar/DSTARUncovered.pdf
4. Low Density Parity Check (LDPC) codes. http://www.ldpc-codes.com/

Interesting theory. I like it and will mull on it.

One possible hole in it that immediately comes to mind is that although the North American continent was populated thousands of years ago, it did not develop (technologically, agriculturally) in the same way that Europe did (until, of course, the arrival of Europeans), despite that it was geographically and climatically similar to Europe.

Just something to think about, should you wish to revise your argument.

I am ALSO a resident physician as well as a computer programmer by profession before medical school.

I hear frmo a lot of my colleagues about how CPRS is offered free of charge, "why don't we use that?" and so forth.

What they don't know is that the free CPRS release does not include a billing module, because it is designed for the VA system. Adding a billing module for your hospital or clinic to CPRS (really CPRS is just the frontend to the backend system called VistA) would literally take $MILLIONS and the programmers who can write good M code (yes, CPRS' backend (VistA) is written in M) are few and far between.