Hi list!
With the summer-activities coming to an end, it's again time for the codec2 gmskmodem; especially the issue of the header. I've had a small offlist discussion with Peter on this and this is the proposal we have come up with for the format to be used for the C2-GMSK stream. * General information. - The C2-GMSK stream is structured in "blocks" of 4 "segments". Every segment is 24 bits. At 4800 bps, every block (96 bits) is equivalent is 20 ms. One or multiple blocks are combined to form one "frame". * Voice frame (as currently already implemented) - For 1400 bps codec2 VOICE, two blocks are combined to form 192 bits; structured as followed S D D D D D D D These two blocks take up 40 ms. S = syncronisation segment (fixed, containing signature for "voice") D (7 segments @ 24 bits each) = 168 bits. These 7 segments contain 40 ms of codec2 voice (56 bits, i.e. 40 ms @ 1400 bps) repeated 3 times * Header frame (new) - for the codec2-gmsk stream header, 6 blocks are combined to form one frame, containing the c2-gmsk header. It is structured as follows: S X H H H H H H E H H H H H H H E H H H H H H H S = syncronisation segment X = Header identifier H = header E = Extra segment More info: S: syncronisation segment. A fixed pattern (as defined by the specification), containing a signature for a "header" frame X: header identifier. Contains type/version information of the type of header following; so that the format can be expanded with other header-formats in the future It contains 3 fields: - header-id family (4 bits) - header-id (4 bits) - header-id flags (4 bits) The header-id family + header-id define the type of header following. Currently, one type of header is defined: 1/1. In the future, possible other header formats can be created. One thing we where thinking of is a "reduced" header containing less information; e.g. to be used for 2400 bps c2-gmsk (to reduce the overhead of the header using these lower speeds). That can then be defined as different "versions" of the same header-if family; so using id's 1/2, 1/3, etc. Of the 4 additional header-id flags, currently one is defined: "well-known/private". "well-known" header identification codes are ones defined by some organisation and be documented in "official" c2-gmsk specifications. "private" header identification codes defined by individuals, to be used for experimentation or "private" use. (I like to give people the oportunity to experiment without breaking official specifications). Now, as these fields define how the rest of the header will be processed; a 1/2 FEC is applied; making this a 24 bit pattern that fits nicely in a segment. Currently, the idea is to use gollay codes for this, but if somebody has a better idea; feel free to comment. H: the header itself. Version 1/1 contains the following fields: - my-call: 8 chars + 2 chars (@ 7 bits/char) (1) (2) - your-call: 8 chars + 2 chars (@ 7 bits/char) (1) (2) - repeater: 8 chars (@ 7 bis / char) (1) - mode flags: 8 bits - other flags: 16 bits - checksum: 16 bits Applying a 1/2 FEC (convolution coding); these 236 bits become 472; leaving still 8 bits "spare" inside the 20 "H" segments of the header frame. (3) After convolution, interleaving and scrambling is applied. E: "Extra" segments. This can be used to add information to a header; but is not critical so that does not need protection by the FEC. One option would be to add "regulatory" information in there. E.g. for a station this is holidays in Canada, one of these segment can contain the text "VE2" (if using a reduced characterset of 6 bits / char), be equivalent to a "M0ABC/VE2" If the extra segment does not contain any specific information, it should contain a copy of the syncronisation segment. (1) The size of the callsign have been set to 8 chars, as I have noticed that in some countries, 7 character callsigns are handed out; even for NON special-event stations (I read somewhere that the "novice" license in Australia has the "VKxABCD" format). (2) Concerning the "8 chars + 2 chars" format for the "my-call" and "your-call", the following can be noted concering the two extra characters - The 1st character contains a indication for additional "services" attached to one and the same callsign. The idea is based on callsigns used for APRS, where ON0ABC-1, ON0ABC-2, ... can be used to identify different stations / services. The idea is to provide a means to allow individual hams to create multiple "services", using their own callsign. Some random ideas: - If you make a call to "ON1ARF"; you would be calling a person (i.e. a normal voice call) - if you make a call to "ON1ARF-M", you are connected to a "voice mailbox"; so everything you say will be recorded in a voicemail box - if you make a call to "ON1ARF-W", you are connected to a "weather announcement" service; where the remote side will then call you back with a weather rapport. These kind of services are now also available on networks like D-STAR, but can using special software on repeaters and cannot be routed. The idea is to allow this kind of "service-extensions" on all callsign, so that everybody is able to create these services and experiment with them; using their own callsign; so not be dependent on anybody else. That's also why these callsign extensions are added to both the "my" and the "yr" field. The goal is to have routing (read: ircddb) be done on the full "callsign + service" element. - The second character contains a information for "regulatory" purposes: A = /A P = portable M = mobile, N = Maritime mobile, O = airmobile (3) Concerning convolution coding, I noticed something interested in the source-code of the D-STAR gmsk modem. Before applying convolution on the header, two bits (both containing "0") are added at the end of the header. These two bits are then also run throu the convolution process, generating 4 extra bits to be transmitted. It's a bit strange because, after deconvolution, these 4 bits are simply ignored. Does anybody know why exactly this is done? Is this part of the convolution process? So what is the reason for this? Can somebody comment on this? 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
