There should be some bits identifying the codec, and/or whatever else somebody may want to change. If D-Star had that facility, we could have just changed the ID.
Ihe ID can be done in many ways. Some bits in each frame, some bits every N frame, or even a metadata frame once in a while. Jon LA4RT On 05/24/2012 11:14 AM, Daniel Ankers wrote: > On 23 May 2012 22:22, Kristoff Bonne<krist...@skypro.be> wrote: >> Hi, >> >> I am currently working with Peter on defining the format for a VHF modem. > > Excellent! > I know it's asking a lot, but would you be able to document not only > what does go into the modem, but what you thought about and left out? > I'd love to get an insight into the way a modem is designed, and I'm > sure others would too. > >> >> 2/ >> Modulation systems: >> >> Now, appart of gmsk modulation, there is also the idea of use 4FSK/C4FM. >> >> So, the question is simple: >> Is there a reason to forsee C4FM/4FSK on a codec2 VHF format? >> >> - It can double the bitrate of the bitstream, but concidering the bitrate >> needed by codec2, is that really needed? >> On the other hand, there could be applications like the following: >> -> inter-repeater links carrier multiple streams >> -> pure-data streams >> >> - It can also half the bandwidth of the channel, as this can also be done >> using gmsk at 2400 bps, is there a need for this? >> >> - Perhaps make it optional in this version of the specification? (it can >> become mandatory in a latter stage, if needed). >> >> Does anybody see a reason to add C4FM in this version of the specs? (appart >> from "I want everthing"). >> > > I have no special knowledge here, but I'd say put C4FM in, for two reasons: > 1) The UK licence has the following note: >> The bandwidths of emissions should be such as to ensure the most efficient >> utilisation of >> the spectrum. In general this requires that bandwidths be kept at the lowest >> values which >> technology and the nature of the service permit. > If we can reasonably reduce the bandwidth requirements, we ought to - > or we ought to at least consider it. > > 2) If it is in the specification, then I would hope that would mean > that people implementing the specs would take account of the fact that > they may receive C4FM signals, and if they don't support C4FM would > ensure that their implementation failed gracefully. > > Regards, > Dan MD1CLV > > ------------------------------------------------------------------------------ > 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 > Freetel-codec2@lists.sourceforge.net > 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 Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
