Hi Peter & co.,Can you divide this into layers? As written in your current summary, some of the data is appropriate for all modes and modulations, and some is not. Some transports will assure data integrity, while our usual radio transport won't. So, it seems to me that the header data and user payload belongs in one layer, and the error correction, sync pattern and header repetition belongs at a layer below that. There should be a defined means of de-serializing this layer to extract the header and user payload, and then re-serializing them into a non-redundant packet that would be used on a reliable transport.
This would also provide a means to gateway between different modes and modulations. The over-air packet format might be different for HF and VHF, but the non-redundant version of the packet can be identical for all modes and modulations. One would de-serialize the VHF packet to the non-redundant format, and then re-serialize that to the HF format.
Thanks
Bruce
On 04/18/2012 03:48 PM, Peter wrote:
Just wanted to clarify here. Because I was talking about a few things at the same time. The idea is to send 64 bits of preamble (10 repeated as you mentioned). This I am calling outside of the scope of the encoding design, since it's a generally done thing when sending GMSK data. But I will make it clear it's a requirement in the documentation. After this, the SYNC pattern for data only (4 segments of 24bits data only) will be sent. At which point header data will be sent. What I meant was that the format for the data stream doesn't change for the header data. It still fits in the 4x24 container format. Once the header is sent, the SYNC signal for 1 data + 3 voice segments will be sent, and the voice stream will begin to be sent. In the absence of any other data to send, the header data will be repeated gradually over the 1 data segment in each block. Periodically (right now I am thinking every 32 blocks or so) the SYNC signal will be repeated (such that any loss of sync can be re-attained within a second or so). D-Star repeats the sync much more often, so 32 blocks may be too much. But I guess we'll see what works best. I'm also making the first usable data segment contain a data "Mode ID", which will describe how the following data segments are to be interpreted. By default, we have two modes. Header repetition data, or user data. But, there can be all kinds of mode IDs added, to include controlling repeaters and so on.
<<attachment: bruce.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
