As part of making this next step in wireless codecs and modems, we are asking for a very different hardware environment than you might be used to. So different that some manufacturers will read this and decide not to include FreeDV in their product. Others will realize where the market is going. Our team is currently demonstrating a handheld SDR, so we're going to have a product even if you don't.

Everything we ask for is provided by a development system that costs USD$15 retail, quantity one, at this writing (May 2013).

Consulting Services

You are welcome to staff your development as you like, but we have the necessary competence on our team if you need help:

How we are different

Our basic requirement is that we have the ability to continue to advance our software, including the codec bitstream and the softmodem, bringing already-sold hardware up to date with each new version. We want to do this even if the manufacturer of the hardware is out of business, isn't cooperating, or doesn't have the same timetable as us for releases. Thus, we insist on end-user programmability of the codec and softmodem platform.

Expected CPU Power

We are likely to use the STM32F4DISCOVERY development kit for prototyping. It sells for USD$14.55 plus shipping at Mouser Electronics. If you have sufficient space, as in a base or mobile system, simply including this card in your product would be the fastest development path. We will not use the system's embedded digital microphone (a MEMS device that outputs a PWM signal) due to its low quality.

At this writing, March 2013, an ARM Cortex M4F (the version of Cortex M4 with hardware floating-point) might be a good target system. Here are implementations from various manufacturers:
  • Atmel AT91SAM4E
  • Energy Micro EFM32 Wonder
  • Freescale Kinetis K
  • Infineon XMC4000
  • NXP Semiconductors LPC4000, LPC4300
  • ST Microelectronics STM32 F3, F4
  • Texas Instruments LM4F
Obviously, more powerful ARM systems with hardware floating point are also acceptable. Many of these will support smartphone-equivalent user interfaces and features, which will be a strong selling point.

User programmable in C

Our over-the-air protocols change frequently as we innovate. We don't want them cast in concrete in your product. Thus, we specify an end-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 required

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.

Your proprietary software

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. There are other solutions, but separate processors are the simplest from an intellectual property perspective.

Developer intellectual property

Publish your programming documentation in an unencrypted PDF file, and make it available for free download via the internet. Do not embed in the processor that runs our software any 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, definitions, and data 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:

One or both of 8K or 48K samples per second, additional rates welcome. 16 bits minimum per sample, more is better. Inputs for microphone and receive audio, outputs for speaker/headphone and transmit audio. Maximum ±500ppm timing inaccuracy.

Control I/O

PTT detection input, transmitter key output.

Power Management

Some means of halting the codec/modem when it isn't necessary would minimize the CPU idle power drain. A received-signal interrupt to the CPU might be appropriate for this.

Firmware Update

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, and the user should be granted all necessary documentation and Open Source tools to create that file. All relevant host operating systems can deal with FAT and VFAT, it's most easy for users, and it doesn't require that your device and the computer be cabled together. STMicroelectronics provides a free firmware loader application that meets this need. It's documented at
Other manufacturers provide similar tools.

The exFAT filesystem is strongly discouraged due to its actively-enforced patent restrictions which are incompatible with our Open Source software, so the older VFAT is preferred. Don't require digital signing of firmware loads that contain our software. USB protocols other than VFAT or FAT storage for firmware loading are OK as long as Open Source software is provided to drive them.


Serial console terminal interface, 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 that will be accessable to developers if you can't bring them to an outside connector. Consider standard pinouts such as the ones given for Cortex-M at

User Interface Features

Means of entering and displaying short texts in 7-bit US-ASCII is desirable, as the codec includes a channel that carries station ID and a short text. Our software will convert them to and from Varicode.

Other recommended features:

Watchdog timer. Capability of driving a meter (such as the S-meter) to help the operator adjust levels, etc.