Close

Data link layer

A project log for digital-walkie-talkie

long range, low power, modular

Christoph TackChristoph Tack 04/22/2021 at 18:083 Comments

Packeting

Packet interval

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.

Packet size

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.

  1. Authenticated: 40bytes/packet, 25packets/s -> 8000bps
  2. 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:

  1. SX1278 : FSK : 2.4kbps BR, 4.8kHz freq.dev., 7.8kHz Rx BW.
  2. SX1278 : OOK : 3.0kbps, 5.2kHz Rx BW.

Is there a suitable library for the SI4463?

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).

SI446x potential packet structure

The following settings are used in Zak Kemble's library:

  1. Preamble : 8 bytes (sine wave) : 2.4kbps encoded, not 4.8kbps as the rest of the packet
  2. Sync word : 2 bytes
  3. Field 1 : 1 byte (length of the packet)
  4. CRC-Field 1 : 2 bytes
  5. Field 2 : data bytes (e.g. 6 bytes)
  6. 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.

Recording taken with RSP1A and CubicSDR opened in Audacity

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.

Two 20 byte frames, separated by 7ms of noise (the high amplitude in the middle). See how much time goes into the transmission of the preamble at the start of every frame.

Discussions

Christoph Tack wrote 04/23/2021 at 18:15 point

Hi Simon,  there's no error in Zak's library that makes the message so long.  The message length is simply the result of the configured parameters.  The preamble could be shortened, but that might make it more difficult for the receiver to get the message.  The receiver uses the preamble to synchronize itself to the transmitter.
dPMR as well as SCIP chain lots of messages together in a single stream.  The receiver only needs to synchronize at the start of the stream.  As a result, the overhead of the preamble becomes relatively small with regard to the payload size.
I might have to work like that as well.  It's much more complicated than sending a series of small packages because the FIFO needs to be refilled as the packet is being transmitted.

  Are you sure? yes | no

Simon Merrett wrote 04/24/2021 at 00:25 point

Thanks for the explanation - makes sense but I can see the challenges for audio.

  Are you sure? yes | no

Simon Merrett wrote 04/23/2021 at 08:43 point

Interesting. Why do you think Zak's library takes this long and should it be possible to speed it up? 

  Are you sure? yes | no