Hello list,
Couple of thoughts here:
1/ It's possible to work out the symbol rate with a little DSP, for
example there is often a spectral line in the FFT of the modem signal at
the symbol rate. We use this in FDMDV to work out the symbol timing.
So we could look at the baseband modem signal and work out the symbol
rate, and perhaps determine if it's GSMSK or 4FSK and friends.
2/ Yes the sync pattern is often called a unique word. I have a
slightly crazy idea of how to use knowledge of the Codec 2 payload data
to obtain frame sync with 0 overhead. The LSPs in particular have an
ordering property, the frequencies must be lsp1 < lsp2 < ... < lsp10.
So various frame alignments could be tried, measuring the number of
unordered LSPs at each candidate alignment. I'll write a little code to
try this.
As we get lower Codec bit rates the % sync overhead gets higher so it's
a shame to waste bits unless we have to.
3/ Re a side data channel I like the idea of dropping voice data frames
when we need to send some data. We tell codec2_dec() that the frame is
dropped and it just interpolates. On silence, background noise or
unvoiced frames I doubt anyone would notice. We would effectively get
enough bandwidth for call signs, routing, and even protocol information
for free. There is silence between each syllable when we talk.
4/ Re protocol information, fwd and backward compatibility I think some
one a few years ago mentioned an Internet database for the many digital
data modes which seem to expand daily.
So imagine if in the year 2015 some one comes up with a new mode. As
the person starts talking a data packet is sent that says
"codec2_mode=greatnewMode100;svn_revsion=1056" and the radio goes to the
Internet, downloads the mode information, checks out the latest code
from SVN, or maybe reflashes itself with a new image from some trusted
source. If the Internet is not available, the two radios use data
packets to agree on a mode they both support. Maybe they all support
Kristoffs first basic mode by default.
5/ The sample rate of the sound card (say 48kHz) doesn't have to be an
integer multiple of the symbol rate. For example FDMDV already does
1/160 symbol resolution re-sampling inside.
6/ For FDMDV it proved possible to get fast sync without pre-ambles
(like 0101010... sequences at the start of bursts), this might be
possible with GMSK also, not sure. We did cheat with FDMDV and use a
high energy pilot tone.
Cheers,
David
On Wed, 2012-05-23 at 23:22 +0200, Kristoff Bonne wrote:
> Hi,
>
>
> I am currently working with Peter on defining the format for a VHF
> modem.
>
> There are some things where I would like to get the help of the
> knowledge of the list. It deals with the syncronisation pattern put in
> front of the stream.
>
>
> First some information:
> In a digital communication system that is purely sequencial (like
> GMSK), there is usually a "syncronisation pattern" that is put in
> front of the stream.
> The "what does a D-STAR signal really look like" blog article show a
> bit how it works (1). Scroll down to the part " A close-up of the
> beginning of the stream"
>
> The goal is to allow the receiver to syncronise itself to the stream
> it receives: detect the bitstream, give the FM receiver some time to
> get on that and get the "bit syncronisation" process started.
>
> As a result of David's comment yesterday about autodetecting "audio
> reverse", I was thinking what else we could "autodetect": like
> baudrates or even transmission modes.
>
>
> 1/
> First baudrates:
> - The current gmsk runs at 4800 bps while there has been the
> discussion to support other (lower) bitrates
> - The gmsk receiver actually samples the audio at 48 Khz, which means
> that a bit of information is equivalent to 10 audio-samples.
>
> Option 1:
> - allow lower baud-rates, but only baud-rates where the periode of a
> bit is a multiple of 1/48000 seconds.
> This would allow bitrates like:
> - 4800 bps (10 samples / bit)
> - 3600 bps (15 samples / bit)
> - 3000 bps (16 samples / bit)
> - 2400 bps (20 samples / bit)
> - 1800 bps (30 samples / bit)
> - 1200 bps (40 samples / bit)
>
> (among others)
>
>
>
> Now, enter the issue of the "syncronisation pattern".
> At first, I was only thinking about bitrates that have a period that
> is a multiple of 1/4800 second.
>
> So, specify this:
> "the bit syncronisation stream must be at least 32 time "01", running
> at the bitrate of the codec".
>
> The idea would be this:
> The receiver decodes the stream at the maximum speed: 4800 bps
> Depending on the speed of the sender, the received pattern would be as
> follows:
> - Receiving a 4800 bps stream: "010101010101..."
> - Receiving a 2400 bps stream: "001100110011..."
> - Receiving a 1800 bps stream: "000111000111..."
> - Receiving a 1200 bps stream: "000011110000...."
>
> This would be easy to implement, but would exclude certain bitrates
> (like 3600 bps or 3000 bps).
>
>
> Question:
> Does anybody see a reason to support bitrates other then the four
> available in option 2?
>
>
> P.S. I like the idea of a 1800 bps stream. This would be roughly
> equivalent of a non-protected codec2-stream running at 1400 bps plus
> some overhead for syncronisation.
>
>
>
> 2/
> Modulation systems:
>
> Now, appart of gmsk modulation, there is also the idea of use
> 4FSK/C4FM.
>
> Some background info:
> GMSK -which is nothing more then a variant of 2FSK- has two states per
> symbol ("0": voltage > 0, or "1": voltage < 0). This allows for 1
> bit / symbol/
> C4FM/4FSK allows for 4 states per symbol: -1, -1/3, +1/3 and +1. This
> allows for sending 2 bits / symbol; permitting -either- for twice as
> much bits to be send per channel, or reducing the bandwidth of a
> channel to half (but without 3db S/N gain).
> If a 4FSK signal is decoded with a GMSK demodulator, -1 and -1/3 are
> both decoded as "1". +1/3 and +1 are decoded as "0".
>
>
> By doing some modification of the syncronisation pattern when sending
> a 4FSK/C4FM signal, it should be possible to make the system determine
> if the incoming stream if a GMSK or a C4FM stream.
>
>
> 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").
>
>
>
>
>
> One final remark:
> Do note that we are talking about the SPECIFICATION of the codec2 VHF
> modem. Do not expect all these wissles and bells to be present in the
> first actual implementation of it? This will -in the first stage- be
> simply 4800 bps gmsk.
>
>
> A technical side question:
> Can somebody please explain what is the exact difference (if there is
> one) between 4FSK and C4FM? Most documents either describe C4FM as "a
> special version of 4FSK" or simply equate it.
> Who can explain the exact difference between these two?
>
>
> (1) http://villazeebries.krbonne.net/hamstuff/?p=106
>
>
>
> 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
