One comment - the 48 kHz sample rate is only because many PC sound cards can't sample at 8kHz accurately, e.g. we have seen examples of them sampling at 8100Hz.
A spec of 8kHz +/- 500ppm would be fine, as the fdmdv modem has been tested at +/- 2000ppm - David On Thu, 2013-03-07 at 16:24 -0800, Bruce Perens wrote: > It's probably time to write up what you should do to add Codec2/FreeDV > to a commercial product. Please check this out and tell me what you > would add or change. > > Thanks > > Bruce > > As part of making this next step in wireless codecs and modems, we are > asking for a different hardware environment than you might be used to. > > Your proprietary code: If your system has proprietary code that you can > not allow users to access, or if you feel that locked-down code is > required for regulatory type approval, put that code in a separate CPU > from the one where our software will live. > > User programmable in C: Our codec and modems are not standing still, and > our over-the-air protocols change frequently as we innovate. We don't > want them cast in concrete in your product. Thus, we specify a > user-programmable microprocessor as the host of the Codec2 and FreeDV > software. You will find that all of the necessary embedded systems > programming software is available in Open Source form, and we strongly > suggest that you do not use any proprietary software tools at all. Our > low-level code including the codec and modems are written in C, while > applications are in C++ or Java (depending on the platform). GCC and > LLVM are both fine compilers and are already available for the processor > architectures we would have you use. > > Hardware floating point: We appreciate that most of the embedded > wireless world are coding in fixed point on specialized DSP chips. > However, we find that there is a large people-time cost to creating good > fixed-point code over that of its floating-point equivalent. We would > pay this cost in several ways: longer time to develop, fewer programmers > participating, greater complexity of resulting code. People are much > more expensive than microprocessors, and hardware floating-point > processors capable of handling our software are available in chips > costing less than USD$4. Thus, we require hardware floating point. > > Intellectual property: Publicly disclose your programming documentation. > Do not embed a proprietary operating system or other proprietary > software that would create intellectual property hassles when combined > with our Open Source code. Make sure that any headers required for > programming your product are released under a minimally-restrictive Open > Source license such as the BSD license, so that they can be combined > with any software. Libraries should be available in source-code form and > placed under an Open Source license that allows linking with any > software, such as BSD or LGPL3. Don't require developer agreements, Open > Source licensing is easier to deal with than such things. > > DAC and ADC: A 48K sampling rate is required as this is the common speed > on PC sound cards, add as many other optional sampling rates as you > wish. 16 bits minimum per sample are required, more bits are better. At > a minimum we require inputs for microphone and receive audio, outputs > for speaker/headphone and transmit audio. > > CPU Clock Precision: Quartz crystal or better. > > Interfaces: The best FLASH loader would be for your hardware to load a > file from an inserted USB storage device using the VFAT or FAT > filesystem. All relevant host operating systems can deal with that > format, it's most easy for users, and it doesn't require that your > device and the computer be cabled together. The exFAT filesystem is > strongly discouraged due to its actively-enforced patent restrictions. > Other USB protocols are OK as long as Open Source software is provided > to drive them. > > Debugging: serial console terminal, JTAG, and in-system debugging > interfaces are encouraged. All of the modern microprocessors that we > would have you use provide some such interface. Please make them > available on an internal PC board if you can't bring them to an outside > connector. Consider standard pinouts such as the ones given for Cortex-M > at > http://infocenter.arm.com/help/topic/com.arm.doc.faqs/attached/13634/cortex_debug_connectors.pdf > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
