On 24 May 2012 10:14, Daniel Ankers <md1...@md1clv.com> 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.
>
>
At the moment documentation on the voice only stuff is just a layout (or
layouts) of frames with sync patterns and voice data, or voice data and FEC
data. There's nothing flash about the documentation (it was just sent
directly in an email).
I will be putting together a bunch of frame layouts for all the bit rates
being discussed. And I'll make this document available to the list once I
make it. Along with the bigger specification, when I complete the first
draft. Like most of us I have competing priorities bearing down on me. For
sure, from the second week next month I'll likely have a lot more time
available.
> >
> > 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.
>
>
To my knowledge, C4FM/4FSK uses around the same amount of spectrum as does
GMSK for the same bitrate. 6.25 for 4800 and 12.5 for 9600. My problem is
I've not seen any software implementations of C4FM. For me to test/play
with modulations I really need to be able to play with it on my PC first.
Rather than build hardware projects. But for sure, there's no reason in
theory you couldn't use a C4FM/4FSK modem of the same bitrate with the same
standard. I also don't know whether there's a reason to change the sync
pattern. Since presumable a GMSK modem will not get close to decoding 4FSK
and vice-versa.
I guess my point is, that while we should specify a format that should
always be decodable as part of a VHF/UHF standard (for this I was going
with GMSK) there's no reason we can't say that C4FM/4FSK modes can't be
supported.
> 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.
>
>
This is the thing about specifications. If we put in too many possible
variations, most implementations won't work with eachother (which would
negate the point of a specification in the first place). But, if we neglect
the latest or emerging technologies, we get stuck where we were when the
specification was produced. So it's a catch-22. Like I say it's probably
best to make a specific mode (GMSK 4800 using Codec2 2400 in the case of my
bigger spec) be required (and perhaps some lower bitrate options for SNR
bashing), with everything else optional. If that makes sense?
73
Peter - M6DGI.
------------------------------------------------------------------------------
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
