On 24 May 2012 15:32, David Rowe <[email protected]> wrote:
>
> 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.
>
Hi David,
I did wonder if there were some inherent characteristics in the codec we
could use for a sync (or backup sync method). Like I've said before for a
full featured VHF/UHF mode we're not trying to beat the system, bandwidth
wise because we have a band plan and channel space has specified
bandwidths. So it's nice to be able to squeeze into low bandwidths on HF.
But, on VHF/UHF especially for hobbyists using existing equipment, we may
as well use the bandwidth we have available. So sync patterns and FEC isn't
wasteful. It's just part of the solution. Of course if we could sync on
every voice frame without a sync pattern. It'd be great. Would it be
reliable all the time though? Silence for example? Unvoiced etc. I don't
know about this. Just raising questions here.
>
> As we get lower Codec bit rates the % sync overhead gets higher so it's
> a shame to waste bits unless we have to.
>
>
Like I say above. I don't think it's as much of an issue on the FM VHF/UHF
channels. I agree totally for when we're using modems with a lower
bitrate/spectral coverage. This is kinda why I was heading toward the 2500
(now 2400) rate for this mode. Just because audio quality is probably worth
more than cutting bandwidth on these bands. Of course a good "DX" mode
would be great too (lots more FEC, lower bitrate). So, you know I'm in two
minds myself.
> 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.
>
>
This would be possible. But I suspect there'd need to be some way of
indicating this (and work between the modem and codec2) to utilize this. As
it is, I was heading toward the D-star like 1000 or so bits/s data channel
using the area used for sync for data, when sync isn't needed. It's just
the simplest way to segment the modem frames.
> 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.
>
>
I think a global encapsulation system would be nice. But, while the jump in
bandwidth between HF and VHF/UHF FM modems is a fair bit. There's limits.
In the bigger more detailed (providing D-star like facilities) I'm working
on. I'm making the data frames have a packet identifier. Such that other
users can make their own packet types for their own uses. So, by default it
resends header detail (callsign and so on) over the data channel, these can
be re-tasked temporarily or permanently to perform other functions. Making
a one size fits all data encapsulation that doesn't waste space, would be
difficult.
What could be done is a similar thing to the RSID. That is, a special
packet format sent before the main header for say 50ms maximum identifying
what is to follow. That's for sure possible.
> 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.
>
>
I'm fairly sure the pre-amble is mainly just to setup timing in the
receiving station. Also, I highly suspect D-star cheats in the same way I'd
suggest we do. That is, when you key the radio, it will send the pre-amble,
and header over the next 200-500ms. Then start encoding audio live (well
with the encoding, frame size and transmission modem delays added in). That
is the first 200ms-500ms of audio after the key is pressed just don't get
sent.
This isn't a problem because most operators press the key, then speak
talking a second or so later. I can't tell you for sure, but I suspect
D-star does this.
Best regards,
Peter.
------------------------------------------------------------------------------
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
