Codec2 1200bps has been selected, it needs to be fed 6 bytes every 40ms.
dPMR uses packets that are (Header (80ms) + 4* super frame(320ms) + end (20ms)) = 1.38s long! Using such long packets has the advantage that the overhead is relatively small for the payload. This also implies that the FIFO is refilled as the transmission is ongoing.
SCIP-210, Revision 3.6 §2.1.3 : Transport framing : All frames are split up in 20 byte frames, of which 13 bytes are data.
6 bytes are needed for Codec2, let's assume add encryption later on: 12byte IV(initialization vector), 12 byte authentication data. So that's a 30byte packet.
96bit bit authentication doesn't seem like much (SHA-1 uses 160bits), but we're working with voice data here, so authentication is instantaneous. There's not much time for the attacker to forge the data.
Let's add 10byte for everything we forget now. So we end up using 40byte packets.
- Authenticated: 40bytes/packet, 25packets/s -> 8000bps
- Plain (could be encrypted) : 6bytes/packet, 25packets/s -> 1200bps
We want to keep bandwidth below 10kHz, so 8000bps would require at least 2bits/symbol. So FSK would no longer be an option. This only leaves the SI4463 and AX5043 as options.
For the 1200bps, FSK and OOK are still options:
- SX1278 : FSK : 2.4kbps BR, 4.8kHz freq.dev., 7.8kHz Rx BW.
- SX1278 : OOK : 3.0kbps, 5.2kHz Rx BW.
Is there a suitable library for the SI4463?
- RadioHead library can send 4FSK data (with a suitable config file), but can't receive it.
- The #NPR New Packet Radio project is 2FSK as well as 4FSK, but it might be difficult to strip the radio code from the library.
- Zak Kemble's library was the first one I got working with 4GFSK. But it's interrupt based and many function don't yield a return code.
- The official SiLabs WDS3 tool can create an example project. Unfortunately the header files are nearly unusable. A header file with commands is generated, which is about 3800(!) line long. Then there's also the header file listing the properties. That one is 5800(!) lines long. I spend more time finding the right "define" statement than it would have taken me to write the statement myself based on the HTML-documentation.
So I decided to merge Zak's code and the official WDS3 code into my favorite radio library : RadioLib.
Now with the library working (based on Zak Kemble's code), I noticed that sending the 10byte packes from Zak Kemble's example takes 57ms. That's measured from the end of the 0x31 START_TX command to the falling edge of IRQ that signals a PACKET_SENT. For 1200bps, we need to send 6 bytes every 40ms. If we can't get the TX-time down, we'll have to group codec2 frames in a single wireless packet. Sending 6 bytes takes 51ms (as verified with the logic analyser: time between end of START_TX and falling PACKET_SENT IRQ). This matches with the theoretical limit: 4 bytes less in 6ms = 32 bit/6ms = 5.3kbps. The radio is configured for 2.4ksymbols/s (=4.8kbps for 4GFSK).
The following settings are used in Zak Kemble's library:
- Preamble : 8 bytes (sine wave) : 2.4kbps encoded, not 4.8kbps as the rest of the packet
- Sync word : 2 bytes
- Field 1 : 1 byte (length of the packet)
- CRC-Field 1 : 2 bytes
- Field 2 : data bytes (e.g. 6 bytes)
- CRC-Field 2 : 2 bytes
So we have 15 bytes overhead for our packet. With respect to time, we even have 23 bytes overhead, because the preamble is sent out at half the bit rate.
The selected length in the image is 51ms. The preamble is 27ms long (8 [bytes] * 8 [bits/byte] * 1/2400 [s/bit]).
Repeating 6byte packets every 40ms is not possible. Even if it was possible, it's very inefficient.
A 20 byte frame is 73ms long and thus can be repeated every 80ms. That's a net data rate of 2.0kbps. For 1.2kbps speech, that will suffice. It's still horribly inefficient though.