Bruce, If we can demonstrate the system by plugging something into their D-Star transceiver, I think we can get their attention; I'm not so sure about the DMR guys, as they have issues with anything that doesn't have fancy features like text messaging and such included. I have an IC-91A that I can use as a test unit for interface design (yes, I use D-Star and still see the benefits of Codec2). I also feel that we should design an adaptive system that makes use of GPS data to regulate power levels and bandwidth (narrow bandwidth and higher power output farther out and wider bandwidth with lower power closer in or in situations where traditional radios run into problems). We need to show that we can design digital modes that can keep the spirit of the rules as well as the letter. :)
Have we got a documented protocol that we are.going to use yet? I'd like to start working on the repeater controller code changes soon, among the other software projects I'm working on. Matthew Pitts N8OHU ------------------------------ On Sun, May 20, 2012 8:23 PM EDT Bruce Perens wrote: >I think you need to consider why anyone would want codec2 on VHF/UHF. We >have an uphill battle there. It seems to me that a 4800 Baud modem would >not provide much, if any, advantage over D-STAR. Why would the typical >Amateur Radio buyer not just stay with D-STAR? > >A 2400 modem might be able to offer much narrower bandwidth that D-STAR >and better range. You might, indeed, consider a 1400 modem. > >Does adding 1/3 FEC /really /help our VHF/UHF channel, or are we just >/assuming/ that it helps, versus just interpolating or having mild >errors (not squeals, our codec doesn't squeal, but the wrong sound here >or there that your ear and brain correct for). Can you show the effect >with a channel simulator or real-world tests? > >Widening the bandwidth to include more error correction also reduces the >available power for the real data and increases the signal-to-noise. Is >it really the case that the FEC would help us through fades? Or are the >fades too long, and too deep, for any amount of FEC to help us without >introducing seconds of latency to the speech. Might be fine for paging >and broadcasting, but not what we do. > > Thanks > > Bruce > >On 05/20/2012 02:04 PM, Gullik Webjörn wrote: > Granted, a 2400 baud modem would optimise the RF side. > > However, I would cast my vote for 4800, since it could be > possible to turn this into a "2-slotted" data protocol, > and it would make "subrepeaters" possible, i.e. retransmitting > at a frame in the interpacket gap between voice frames > (at somewhat lower than 2400 bd). > > 4800 baud would easily fit available radio. > > There could be many different implementations as time goes by. > > SM6FBD /Gullik > > > On Sun, 2012-05-20 at 16:24 +0200, Kristoff Bonne wrote: > Hi, > > > We are looking into the possibility to create an additional modem for > codec2, but for VHF/UHF frequencies. > > As a first "proof-of-concept", this would be to convert my gmsk modem to > a new format to carry codec2 voice. This would have the advantage that > the hardware requirement to run this would be minimal. > > > > Sofar, I see two options: > - A 2400 bps modem: > This would be quite sufficient to contain codec2 voice (at 1400 bps), > additional syncronication patterns + some additional data and even an > options 2/3 FEC for the voice part. > > - A 4800 bps modem: > This would then give even more headroom, e.g. tu use a 1/3 FEC for voice > (which would make it much more robust) and still have headroom for > syncronisation patterns and some additional data > > > > The 2400 bps modem would have the advantage of the lower bandwidth > (better S/N ratio, better suited for e.g. bands with limited bandwidth: > 10 meter, 4 meter). > The 4800 bps modem would have the advantage of the better FEC. > > > Does anybody have a comments on this? > > > > 73 > Kristoff - ON1ARF > > > ------------------------------------------------------------------------------ > 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 > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
