Hi,
I just uploaded the first version of the VHF modem for codec2 on github: The URL is here: https://github.com/on1arf/gmsk/tree/master/gmskmodem_codec2 I uploaded it on my personal github page instead of putting it on David's page as this is actually an EXTENSION of the gmsk modem I already had (for d-star and raw streams) with support for codec2. As I did already had working code for the other protocols, it was easier to add codec2 to that program, then having to "scrap" code from an existing project, which -in a latter stage- will then be merged again. This is the first version of the modem. I work with the "release soon, release often" principle, so there may be a number of upgrades coming in the next days and weeks. This code implements the ideas that Peter has been working on, for 4800 gmsk on VHF/UHF, using the 1400 bps codec. I did add some things I needed to make an actual impementation. So do NOT concider this (yet) to be a "reference" implementation. As somebody in this group requested to also provide background information on the project of the VHF modem, I'll do a small write up. * how to compile: This is code designed to run on any unix machine. Just download the code and do "make". * The codec2 related code is found in two files: - "s_input_codec2" is the code of the sender (modulator) that reads a codec2 bitstream and converts it into a bitstream to be send over the radio. It relies on "s_input_sal" (sender/input/Source_Abstraction_layer) to read the actual input from file/stdin/TCP/UDP It uses "bufferfill_bits" to queue the bitstream for gmsk encoding (see "s_gmskmodulate") and output ("s_alsaout" or "s_writefile"). As most code in the gmskmodem, this function runs as a standalone thread. It is started by the main program (see "gmskmodem.c"). Other simular code is "s_input_dstar" and "s_input_raw"; which process input in these formats. - "r_processaudio_codec2" is -as the name implies- the module to process the audio of the receiver (demodulator) and turn the RF bitstream back into a .c2 file It reads audio from the buffer-queue that is fed by the "r_capture" function. (the latter function not only reads audio from ALSA, but also from file/standard-in). After doing some calculations on the audio itself (which is used in a latter stage to determine if a signal is present or not), it calls "demodulate" to do GMSK demodulation. After processing the resulting bittrain, it uses "r_output_dal" (receiver/output/Destination_Abstraction_layer) to send the codec2 bittrain to -either- files, standard-out or UDP streaming. Also this function runs as a seperate thread and is started by the main program ("gmskmodem.c"). Other simular code is "r_processaudio_dstar" and "r_processaudio_raw". * implemented features: As already mentioned, this code tries to implement the ideas of that Peter is working on for 4800 bps GMSK using 1400 bps. This is a general overview of the bitstructure, as send over the radio: - a 128 bit "0101..." bit-syncronisation pattern. (the specs mentions "at least 64 bits", so this should be OK). - a fixed 16 bit pattern ("frame syncronisation" pattern) to mark the seperation from the bit-syncronisation to the actual codec2 stream. The bitpattern is "0x0567". - a fixed 3 octet pattern containing the "codec2 version id", send three times. The current versionid is "0x11" (main version 1, sub-version 1). The versionid issend three times for error-correction reasons (to use the "majority of two" rule). (*) After that, the codec2 DV stream is send. It looks like this: - It is based on a 192 bit (40 ms) time-slot - it starts with a fixed 3 octet syncronisation pattern "e7 08 5c" - then it contains a 56 bit (7 octet) codec2-frame, which is repeated three times. Again, this is an error-correction system that allows decoding using a simple "majority of two" rule. - In the last frame of the stream (i.e. where that reading the information from file resulted in less then 7 octets), the syncronisation pattern is reversed per nibble. It then contains 7e 80 c5" (*) - The last frame then repeated two more times, as to give the receiver more changes deal with not detecting the end-frame correctly. (as it has no FEC, the change it it being received wrong is not trivial). (*) Note: everything marked with (*) is not part of Peter's specification. On the receiver/demodulator part, the processing is pretty straightward. One thing that is added is that -if a receiver does not receive a valid "sync-pattern" at the correct place for more then 20 consequative frames, it breaks of the stream. This is probably to short and might require "tuning" in a latter stage. Also note that the code to detect bit-slips (i.e. if the receiver sees that the syncronisation pattern is received one bit to far to the left or to the right) is currently not implemented. It will be added in a later release. Some things to discuss: - the current implementation does not have a header in front of the stream. What should we put in there? What FEC and other error-protection systems should be applied. - in the current implementation, the sync pattern is repeated every frame, which is probably pretty wastfull. What can be put in there? Who comes up with a specification in these. - The current implementation expects the file-format is receives to be 1400 bps codec2; but has no way to verify this. Who comes up with a format-description for a header for the .c2 files, so that clear meta-data is added to these files and in application that process these files, additional error-checking can be done. My goal is to have -first- a stable version of 4800 gmsk working well before starting versions using other bitrates or modulation scemes. * How to use the application: Basic file-based encoding/decoding: For encoding: "../gmskmodem -format c -noreceiver -sif hts2a.c2 -sof hts2a.raw" For decoding "./gmskmodem -format c -nosender -rif hts2a.raw -rof hts2a" (add options "-v", "-v -v", "-d" or "-dd" for more debug information) All other options: "./gmskmodem -h" Note that this version has currently only been tested using files. Other features (direct alsa input/output, PTT swichting, TCP or UDP input, UDP output) are all "to be tested". But, at least, now we have something to start to play around with. :-) 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
