Hi all,
I have just uploaded the first release of the C2GMSK modem API to github: https://github.com/on1arf/gmsk The goal is to make the VHF/UHF modem more accessable and allow it to be used inside other applications. Possible targets for this are FreeDV, the standalone gmskmodem for embedded linux devices or TheLinkBox. Appart of the basic "API" call, the package also includes some support functions, trying to make live a little bit more easy for the programmer. They mainly deal with creating/initialising certain structures needed by the API and processing the return-messages received from the API. Appart from the modem itself, two test/demo-applications have been added: testapi_modulate and testapi_demodulate. This is the first time I've written an API, so any comments from developer side are more then welcome. There is currently no seperation between the "visible" API-calls and the functions used internally in the package. If you know how to help out on this part, please let me know. The API works like this: * first, create/initialise a "parameter" structure and a "c2gmsk_session". All data related to this particular session is attached to this structure. * For the "modulation" chain, there are 4 API calls: - c2gmsk_mod_start: GMSK stream start (startsync + versionid info) - c2gmsk_mod_voice1400: GMSK frame: 40 ms of codec2 running at 1400 bps - c2gmsk_mod_voice1400_end: 3 GMSK frames of 40 ms indicating the end of a GMSK stream - c2gmsk_mod_flushaudio: flush any audio that might still be in the queue * For the "demodulator" chain, there is only one 1 API call: c2gmsk_demodulate The API calls return two data-elements: - a return value ("OK" or an error indication) - a message-queue containing a number of "messages". Possible types of messages in the queue can be: - data (a 40 ms audio-fragment of encoded audio, a 56 bit 40 ms codec2 frame). - a notification (change of state, average audio-level, c2gmsk stream versionid, FEC statistics, ...) - a stream indications / error message: (end of stream, to many sync-misses received, unsupported versionid stream received, ...) - debug information (a textual streamdump of the raw bitstream as received by the demodulator) In short, an application would look like this: - create and initialisate "parameters" structure + fill it in - create a session, based on these parameters while (more data to process) { call "modulate" or "demodulate" APIcalls, feed data, retrieve message chain repeat { call function to extract information from the message-chain you are interested in process that information (write to file, write to audio-device, ...) } until msgchain is empty. } I would appriciate if somebody with coding-experience would have a look at it and give some comments. From the development side, the next steps to use the are: - create wrapper-code around the API to create an API for FreeDV and get c2gmsk into freeDV - finish the toolkit for the gmskmodem on the raspberry pi (using a modem based on this API), to create a embedded-system based c2gmsk modem - incorperate the 2400 bps modem into the API 73 Kristoff - ON1ARF ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
