Hi Bruce,
On 29-11-11 03:12, Bruce Perens wrote: > On 11/28/2011 05:52 PM, n8...@yahoo.com wrote: >> I see a number of potential problems with your VHF/UHF idea, most of which >> are compatibility issues with existing Icom repeater hardware and end-user >> radios; > Hi Matthew, > > D*STAR isn't the way we'd do digital radio today. Although it's possible > to fit Codec2 in a D*STAR packet, and even possible to retrofit the > daughter boards in older ICOM HTs and mobiles, it's not clear that this > would be the best use of effort. There are only about 550 D*STAR > repeaters nationally, and ICOM had to give some of them away to get that > many. It's not taken over VHF and UHF to the extent that we have to be > compatible with it. True and not true. Overall, the total amount of DSTAR users is still zero dot something percent of the ham population, I don't see any other technology taking it over real soon. D-STAR has two things that any other technology does not have: - infrastructure (repeaters, reflectors, ...) - portable radios For me (and I think most of us here), that does not matter as I am a ham because I want to learn from and experiment with technology; however there are a lot of hams who are mostly "users" who have payed a lot of money for the D-STAR radios. Of course, that's no reason not to experiment but let's not get carried away. > A much easier alternative is to gateway Codec2 voice to D*STAR. Just > network together, translating codecs and protocols. Everyone can talk > together that way. One of the reasons I once did the transcoding tests between AMBE and codec was because of this idea. To be honest. Althou the resulting audio is still "intelligable" I don't know if the result was all to good. > We are at the point that HTs can be SDR, removing some of the hardware > limitations. There is a lot of room for us to experiment with FEC and > modulation. We're not tied to narrow-band, spread-spectrum can be tried > as well. That would require a "(re)programmable" HT. It's not because a HT uses SDR internally that the manufactorer has any reason to make that interface available externally. I would expect them to keep that as much "closed in" as possible. Anycase, as -just like Jan- I am also working on a gmsk modem that can "spit out" any stream you want (the difference is that I use ARM development boards while Jan uses a customer board) I would be very interested in an exercise how one would implement a VHF/UHF DV system using codec2 (FEC, implementing scrambling and interleaving, syncronisation recuperation, ...) and I would also like to see a common specification for this. However, I don't know if this would be the best forum for this. There is a "digitalvoice" forum on googlegroups that would probably be better suited for this as the "codec" aspect in this will be minimal. (probably only for its interaction with the FEC layer). > Thanks > Bruce 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
