Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
M17 frame description
#21
tl,dr of the DMR protocol, at least as it pertains to us:
  • A time slot is either sending individual packets (they call them Bursts because TDMA), OR that time slot has been established as a voice channel and it's streaming voice data.
  • "individual packets" are called "general data bursts" and are used for meta data transmission, link establishment, parameter negotiation, etc.
  • To start a voice channel, a general data burst called Link Control, or LC, is sent that contains sender, recipient, etc.  (I'm unclear whether this is a REQ/ACK conversation with the other station which matches my use of DMR, or just a preamble to the voice stream which is what the documentation looks like.)
  • During a voice call, each voice burst caries 2x 108bit payloads for CODEC data, plus 48 bits of "sync or embedded signaling" data.  I don't believe there's any FEC in the voice data, or if there is it's specified elsewhere in the document I haven't read yet.
  • The voice payload is just a fixed frame rate of voice data, 2x 108bits per burst/packet, each burst being 27.5ms long, sent every 60ms.  2*108*(1/60ms) = 3600bps of voice payload throughput.
  • However, for the sync/embedded signaling data, voice frames are grouped together 6 bursts at a time into a super frame.  These 6x 48bit frames are used to retransmit the Link Control message that was used to establish the voice link in the first place, re-transmitting things like sender and recipient ID, and some other metadata.  This allows a recipient to pick up a transmission in progress.
  • Encryption is its own link control packet, they call it Privacy, or the Privacy Indicator, PI packet.  It's analogous to the LC packet, sent while establishing the voice channel.  It does NOT look like it is resent during the stream like the LC packet is, so if you miss the PI at the beginning, you are not receiving the rest of the stream.

Obviously, DMR is a whole lot more complex than that.  I'm ignoring all the time slot management, the inter-timeslot signaling, full-duplex, reverse channel, etc, etc.  But assuming we want to distill our protocol down to: "what's the simplest protocol to carry on a half-duplex voice conversation, and to be able to send some small-ish data frames for APRS-like functions, and possibly to support a low bitrate raw data stream"  I think we can use the model described above, or one similar to it:
  • Define a packet switched protocol.  It may be inefficient, but it will be very functional.
  • Use that packet switched protocol to establish a circuit switched stream for carrying voice, or other stream based, data as efficiently as possible.

IMHO, that's what we should build here.  I'll get thinking about the details, how to make this work without too much bloat.
73 de KR6ZY
-Mark
Reply
#22
Do you have a target over-the-air modulation bit rate?  Can we safely get 6400 baud?  9600 baud?  How much RF spectrum does that take?

Looks like CODEC2 supports bit rates from 700 to 3200.  I think M17 should support the best audio quality available, so we should support at least 3200bps payload.

Let's look at the voice stream protocol.  Assume the Link has been established by some packet, I'll borrow the name from DMR and call it Link Control.  We send a Link Control packet that says "Hey, a CODEC2 3200 bps stream is about to start."  We'll figure out those details later.  For now, I want to look at just the voice stream after it's been established.

I'm having a hard time finding anything that specifically says what the frame size is for CODEC2 3200, but assuming it uses the same 20ms frame time the other ones use, that would be a 64 bit frame.  I like powers of two, so lets go with that.  So we need to send a 64bit payload 50 times a second, or once every 20ms.

We don't want to sync with every CODEC frame, that's way too much overhead and I just don't think it's necessary.  DMR sends about 256 bits per 60ms, and the underlying data-link handles the sync with the TDMA timing. So let's say we group four of our 64 bit CODEC2 frames into a single 256bit payload, and send them in a single packet every 80ms.

We don't need to keep sending the 32bit preamble, that's only needed when first setting up an RF transmission.  If we continuously stream data, we don't need to let the amps power up, T/R switches to switch, squelch to open, etc.  That'll be part of the original Link Control packet that setup the voice stream in the first place.

We DO need the SYNC header, however.  In DMR, that's handled by the underlying framing and timing.  I'll include the 32 bits here.

I do like the idea of interleaving the link control message as additional data in the stream rather than inserting an extra packet in the stream which creates jitter, so lets add another 32 bits for a chunk of the Link Control packet.

32 bits for CRC, and 160 bits for FEC make 512 bits total. Can we arbitrarily pick how many FEC bits we use?  Do we really need both CRC and FEC?  Can we instead combine these into a 192 bit FEC?

So, once the voice channel has been setup, I'm seeing a 512 bit frame that looks like: SYNC: 32, Link Control: 32, 4x Voice Frames (64 each): 256, CRC: 32, FEC: 160

So long as we can send one of these 512 bit frames every 80ms, we can keep a voice channel up.  That's a 6400bps modulation rate.

Assuming a Link Control message is no more than 256 bits, it can be completely resent every 8 frames, we'll borrow the super-frame term from DMR.  So a receiver is guaranteed to be able to pick up an in-progress stream within 640ms.

Any thoughts on that?
73 de KR6ZY
-Mark
Reply
#23
@KE0WVA:
Quote:increase symbol rate
I think we can't have that, the symbol rate should be kept constant.

@SmittyHalibut:
I have that ETSI spec printed on paper Smile Smile

Quote:Do you have a target over-the-air modulation bit rate? (...) How much RF spectrum does that take?
No, I don't. 9600 would be great, but I think it has to be a little more than that. Do we have to use the standard values?* We should stick to 12.5kHz channel width.
*edited after reading all of your posts

Quote:I think M17 should support the best audio quality available
We may use different vocoder rates in different frames. It would be nice. You could use 3200 with nothing else in the frame and like 1200 with embedded data.

Quote:what the frame size is for CODEC2 3200
Code:
int codec2_bits_per_frame(struct CODEC2 *c2) {
    if (c2->mode == CODEC2_MODE_3200)
    return 64;
    if (c2->mode == CODEC2_MODE_2400)
    return 48;
    if  (c2->mode == CODEC2_MODE_1600)
    return 64;
    if  (c2->mode == CODEC2_MODE_1400)
    return 56;
    if  (c2->mode == CODEC2_MODE_1300)
    return 52;
    if  (c2->mode == CODEC2_MODE_1200)
    return 48;
    if  (c2->mode == CODEC2_MODE_700)
    return 28;
    if  (c2->mode == CODEC2_MODE_700B)
    return 28;
    if  (c2->mode == CODEC2_MODE_700C)
    return 28;
    //TODO: verify this
    if (c2->mode == CODEC2_MODE_WB)
    return 64;

    return 0; /* shouldn't get here */
}

//fs=8000Hz
int codec2_samples_per_frame(struct CODEC2 *c2) {
    if (c2->mode == CODEC2_MODE_3200)
    return 160;
    if (c2->mode == CODEC2_MODE_2400)
    return 160;
    if  (c2->mode == CODEC2_MODE_1600)
    return 320;
    if  (c2->mode == CODEC2_MODE_1400)
    return 320;
    if  (c2->mode == CODEC2_MODE_1300)
    return 320;
    if  (c2->mode == CODEC2_MODE_1200)
    return 320;
    if  (c2->mode == CODEC2_MODE_700)
    return 320;
    if  (c2->mode == CODEC2_MODE_700B)
    return 320;
    if  (c2->mode == CODEC2_MODE_700C)
    return 320;
    if  (c2->mode == CODEC2_MODE_WB)
    return 160;
    return 0; /* shouldnt get here */
}

Quote:We don't need to keep sending the 32bit preamble, that's only needed when first setting up an RF transmission.
I wonder how to achieve that with Si4463. Like reconfiguring it after sending the first frame.
EDIT: looks like we just have to set this property to 0x00: https://cu-taber.github.io/Si4463-API/#d..._TX_LENGTH

Quote: Do we really need both CRC and FEC
Imagine, that we have received a codeword C with uncorrectable errors and we corrected it to some invalid data. With CRC we can detect it. There's a low chance, that everything gets so corrupted, that even the CRC matches the corrupted data.

Quote:512 bit frame that looks like: SYNC: 32, Link Control: 32, 4x Voice Frames (64 each): 256, CRC: 32, FEC: 160
2/3 rate coding? Systematic code? 160 parity bits? We'd need to block interleave that.

Quote:Assuming a Link Control message is no more than 256 bits, it can be completely resent every 8 frames, we'll borrow the super-frame term from DMR.  So a receiver is guaranteed to be able to pick up an in-progress stream within 640ms.
Brilliant!
Reply
#24
(12-04-2019, 09:08 AM)SP5WWP link Wrote: @KE0WVA:
Quote:increase symbol rate
I think we can't have that, the symbol rate should be kept constant.

I never said use a variable symbol rate. I said increase the overall symbol rate in order to fit more frames in one second.

(12-04-2019, 05:30 AM)SmittyHalibut link Wrote:
  • During a voice call, each voice burst caries 2x 108bit payloads for CODEC data, plus 48 bits of "sync or embedded signaling" data.  I don't believe there's any FEC in the voice data, or if there is it's specified elsewhere in the document I haven't read yet.

DMR voice bursts use a 3/4 trellis code plus interleaving for error correction. See section B.2.4 for details.
Reply
#25
@KE0WVA:
Sorry! I get it now.

We probably need a code with rate 2/3. Any ideas?
Reply
#26
(12-04-2019, 01:39 AM)SmittyHalibut link Wrote: We need to decide whether M17 is:

1) A minimalist streaming protocol for digital voice, like FreeDV which has a 95% efficiency (1375bps CODEC data in 1450bps over-the-air bitrate: https://freedv.org/freedv-specification/), but with the addition of some features like FEC.

2) A full, layered, packet switched network protocol that can carry nearly any arbitrary data payload.

FreeDV gets that efficiency by foregoing voice codec quality and FEC. We could be a lot more lightweight too by going with the 1300bits/sec codec rather than the 3200.

I think the farthest we should go out of "lightweight voice protocol" territory is to offer a "data" frame type, but officially consider data frames to simply be an envelope whose contents are outside the scope of the M17 standard.

I think the goal here should be to kick the proprietary protocols off the airwaves, replace DMR, Fusion, D-Star, etc. To do that, it's not just good enough to be open, it has to be legitimately competitive.  If there are design decisions that result in the standard being noticeably less useful, that kills us before we even get off the ground. There is a ton of great insight into the design of a professional-grade standard to be found in that DMR spec document, I think it's a great idea to use a lot of those design decisions as a starting point.

(12-04-2019, 06:12 PM)SP5WWP link Wrote: We probably need a code with rate 2/3. Any ideas?

A couple options -

* Trellis modulation that maps 4 input bits to 3 output 4fsk symbols
* Take a rate 1/2 LDPC or Turbo code and puncture it down to 2/3 (i.e. throw away 50% of the ECC bits and mark them as known erasures in the decode stage).
Reply
#27
Quote:it's not just good enough to be open, it has to be legitimately competitive.  If there are design decisions that result in the standard being noticeably less useful, that kills us before we even get off the ground.

I couldn't agree more. I'm really happy to see your commitment to the project.

I'm not a pro if it comes to ECC. Puncturing sounds good, i've seen it before in TETRA (as RCPC). How about punctured Golay code? It's 1/2 by itself.
Reply
#28
I agree that it should be an efficient protocol.
But that does not limit it from being a full fletched ethernet compatible protocol as well.
If you look at the data channel code for freedv 2400 modes you will see that you can send full ethernet packets in between voice packets.
It is still primarily a voice protocol, so when speach is exchanged the datarate available is low, but it since each data frame still is a valid ethernet frame all data types are possible.
The protocol just needs to be efficient:
Identification only needs to be done once in a while, not every frame and the senders 48bit mac address (with encoded callsign) is enough.
FPRS position reports only need 184bits (with freedv2400 that means just three 40ms frames of silence)

One idea could be to have only a full header every N frames (e.g. 10) and the other 9 frames only a minimal header that says 'look at the previous full header'. This would keep both header overhead and latency low.
Reply
#29
being able to send any IP packet over the radio would be a useful tool to have. allow pub/sub multicast or unicast data to send over the raio and receive data over the radio with a droid device as the IO.
Reply
#30
Compare this
[Image: IEEE-802.3-Ethernet-Frame-Format.png]

with this
https://teletra.pl/M17/M17_frame_v3.pdf

Address space and its format is the same. Link control gives us alll info we need in probably N=8 frames (256bits), that's 8*80ms=640ms. Length is constant at 0x0100.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)