On 19 April 2012 00:06, Bruce Perens <[email protected]> wrote: > 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.
Hi Bruce, It's an idea. I was already breaking it down to three levels. Modulation, Encoding and Vocoder. I was effectively documenting the encoding part specifically, and describing the parameters for the modulation and vocoder (since both already exist). But I guess, if we serialize it more it could be: Modulation -> Header/Data/Voice container specifics for VHF/UHF -> Interleaving (for audio data) -> FEC/Payload -> Vocoder. I understand why this is good. The issue I can see is that the FEC/Payload would likely be different depending on codec bitrate and target bitrate. But, if it's more modular, the relevant parts can I guess be extracted/adjusted and re-used, but still standardized to a certain extent. I'll see what I can do about re-organizing the flow to follow this. Does my suggestion above make sense. More separation, less, different? Well, let me know what you think and I'll see what I can do. Best regards, Peter. ------------------------------------------------------------------------------ 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
