Progress

Functional diagram and critical components selection

Main component of our communicator will be an integrated RF transceiver. We decided on Texas Instruments CC1352P because:

• It can cover the entire 868 - 928 MHz range.
• It has an integrated +20 dBm (100 mW) amplifier so we won't need an external one.
• It supports 4-FSK modulation and so can give us more bits per second for a limited frequency spectrum.

What's better - we have several prototype boards with CC1352P7 (pin-compatible newer generation of CC1352P with more memory and better temperature ratings) from one of the old projects so we can use it to start development right away!

While CC1352P (and CC1352P7) have an ARM-Cortex M4F core and we can use that for MANET protocol handling, we are not sure if processing power will be sufficient for Codec 2 compression and decompression. Also, reference Codec 2 implementation uses floating point arithmetic and CC1352P lacks an FPU.

That's why we decided to play safe and add a dedicated STM32 MCU. STM32U585QI should be more than sufficient as it has an FPU, fast secure AES coprocessor and plenty of SRAM and flash memory.

Audio codec IC is needed to convert voice to digital and vice versa. There are a number of available codecs but Texas Instruments TLV320AIC3206 was an easy choice as we worked with this model before.

For user interface part we would need a keypad (4x4), a small LCD or OLED display, microphone and speaker and a PTT button. Volume control knob with integrated on/off switch will make our communicator look and feel like a regular Two-Way Radio.

Here’s preliminary functional diagram of the communicator:

And preliminary BOM is quite short:

Benchmarking Codec2 implementation performance on STM32

First, we had to confirm that Codec2 can be built for our STM32U585QI microprocessor and will perform compression and decompression in real time leaving some MCU resources to spare. The project is available on GitHub and here’s sample debug UART output demonstrating that we have enough room:

On average, it takes 6ms for encoding or decoding a frame of 20ms with STM32 running @ 160MHz.

Prototyping hardware and firmware on development board

We had a few prototype boards with TI CC1352P7 transceiver from one of our past hardware projects so it was natural to reuse them (with only minor modifications). Just a few photos:

We tested TI CC1352P7 transmission and reception in several modes (2-FSK, 4-FSK) with different bandwidth values. We are now confident that the concept works and can proceed to designing schematic diagram and PCB layout for Revision 1.

MANET protocol research

After reading existing RFCs and draft proposals for MANET routing protocols we realized that straightforward implementation will not work in our case.

RF bandwidth is too limited, packet delivery is not guaranteed, transmitters will interfere with each other and broadcast flooding will make it a mess.

For voice communication we would need real time and guaranteed propagation delay but existing MANET protocols only deal with IP-based general packet delivery.

But rather than reinvent the wheel we decided to borrow useful ideas from:

RFC 7181 Optimized Link State Routing Protocol (OLSRv2): key concept of OLSR is multipoint relays and that's exactly how our mobile network should be organized.

RFC 6130 Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP): we should make use of HELLO messages and Neighbor Graph concepts (Link set, 2-Hop set).

RFC 3561 Ad hoc On-Demand Distance Vector (AODV) Routing: we will take the idea of dynamic routes, Route Request and Route Reply messages.

RFC 5148 Jitter Considerations in Mobile Ad Hoc Networks (MANETs): implementing random transmission jitter will be critical to reduce chances that two nodes transmit at the same time.

All that work resulted in first draft of MANET Voice Network architecture and communication protocol. This work is by no means complete, we aim to refine and update it as we gain more knowledge from testing.

Identifying suitable frequency bands

As our main focus is Europe, we first looked up EU regulations for a suitable frequency range.

In general, 868 MHz band is license-free for SRD (Short Range Devices), provided certain transmit power requirements are met so we can use that.

Specifically, 869.400 - 869.650 MHz band with 250kHz total available spectrum and up to 500mW ERP looked tempting.

There's 10% duty cycle limit requirement that we should eventually meet. This isn't a problem for voice communication as talk sessions are short and nodes transmit only small amount of service packets most of the time. And even for voice transmission each repeater uses only one time-slot.

For the US regulations are much more relaxed, there's 902 - 928 MHz ISM band with up to 1W transmit power allowed.

That means we should select RF components for wider 868 - 928 MHz range, but focus on 869.400 - 869.650 Mhz.

Voice codec selection

We evaluated several modern codecs and, in the end, settled for Codec 2. We needed a low-bitrate codec which is patent free and open-source. Computing requirements should be also reasonable so we could use an inexpensive low power MCU.

Since Codec 2 was specifically designed for amateur radio, it was a natural choice. 3200 or 2400 bit/sec modes seem suitable and we can get down to 1600 and below if bandwidth is an issue.

Another candidate was Google Lyra but while speech quality was very high, codec was way too heavy for a low power STM32 MCU that we have. Still, we may switch to Lyra for next updates.

Bandwidth considerations

Modern voice codecs need only about 3000 bits per second but transmission overhead can easily double that. And since we need some kind of TDMA technique for relaying packets in our mesh network without interference, we have to multiple that by number of available TDMA slots.

Conservative estimates (4 slots) will give us ~25Kbps and more realistic estimates for larger networks (8 slots) should be ~50Kbps.

For narrow frequency spectrum we should consider using advanced modulation techniques, like 4-FSK, so 25 kHz channel width seems possible.

Power requirements

First, we thought about using a rechargeable lithium-ion battery pack but since we want our communicator to work in emergency situations, we decided on using standard off the shelf AA (or maybe AAA) batteries. 4 batteries would give us 6V so we should design our hardware to be powered from at least 5V.