Hi Peter, Yes I think I see your point. If there is plenty of bandwidth, we might get better system performance using X watts divided up into payload plus FEC, than just X watts on Codec payload data at a lower bit rate. It depends on the coding gain of the FEC code I guess.
It will be fun to test the alternatives, perhaps we can simulate the GMSK+FM + noise channel and compare. Anyway, I have prototyped the LSP sorting based sync method, in unittest/lspsync.c: http://freetel.svn.sourceforge.net/viewvc/freetel/codec2-dev/unittest/lspsync.c?revision=488&view=markup On a 3 second test file it is about 87% reliable, but occasionally detects a false sync position in the bit stream. If combined with one alternating sync bit per frame it would probably be reliable. Further testing would be required to see how it hangs on with bit errors and over different speech signals. BTW I am not actually suggesting we use this, I just felt like looking into the idea :-) Cheers, David On Thu, 2012-05-24 at 16:16 +0100, Peter wrote: > 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 ------------------------------------------------------------------------------ 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
