datac14 - FreeDATA Feature Request 002 for a < 1s, 5 byte signalling mode

[drowe67]

Started with datac13, reduced the payload to 40 bits, used a (128,56) code, with lowered code rate as only 40 payload data bits required, and increased Ts. Tcp a little less at 5ms. Duration 0.69 seconds including pre and post amble. Assuming 16 bits for a checksum, 24 bits (3 bytes) are available for ACK payload.

PER < 0.1 at -2dB MPP:

ofdm_ldpc_tx("test_datac14.raw","datac14",1,-2,"mpp","bursts",100)
ofdm_ldpc_rx("test_datac14.raw","datac14","packetsperburst",1)
Coded PER: 0.0825 Pckts:    97 Perrs:     8 Npre: 90 Npost: 9

But still just above 0.1 at -4dB:

Coded PER: 0.1461 Pckts:    89 Perrs:    13 Npre: 79 Npost: 13

For comparison datac13 hits the same PER about 3dB lower, probably due to it's much longer duration riding over fades.

TODO:

• ofdm_mod/ofdm_demod
• freedv_api
• clipper adjust
• check performance of C port on AWGN and MPP
• peak level test
• README_data.md updates, performance curves
• explore switch in transient, e.g. plot time domain envelope

[drowe67]

@DJ2LS - I'm jumping the gun on Feature Request 002, just 30 minutes work to get the ball rolling. Pls take a look at the waveform design and tell me what you think.

[DJ2LS]

@drowe67 thanks for starting on this.

I'm a bit confused regarding to duration and payload.

So we are using a 128_56 ldpc code, isnt this resulting into 7bytes frame payload, resulting into 7 bytes - 2 bytes CRC = 5 bytes payload? ( I'm just checking this carefully, as I have to check for the ARQ protocol and the required minimum payload with the actual protocol design )

Regarding duration, the Octave plot shows a duration of approximately 1.2s, maybe because preamble and postamble?

Update: Ah, the commit is named correctly, so maybe just a typo for the PR name.

[drowe67]

So we are using a 128_56 ldpc code, isnt this resulting into 7bytes frame payload, resulting into 7 bytes - 2 bytes CRC = 5 bytes payload? ( I'm just checking this carefully, as I have to check for the ARQ protocol and the required minimum payload with the actual protocol design )

Good catch - I forgot about those two extra bytes. Do you think we need a two byte CRC for such a short packet?

Regarding duration, the Octave plot shows a duration of approximately 1.2s, maybe because preamble and postamble?

Yes I imagine so, they would be a larger proportion of the packet time (2/7 modem frames) for such a short packet. I wonder if we need both .... 🤔 there won't be as much advantage with them both so close together in time.

Update: Ah, the commit is named correctly, so maybe just a typo for the PR name.

Thanks, have fixed the PR title - i did this in a bit of a hurry 🙂

[DJ2LS]

I think, a 1 byte CRC might be enough, but on the other hand I think we shouldn't change this for now, because we would then affect the libcodec2 api. For now, every datamode has a 16bit CRC. Adding an 8bit CRC, for example, would cause an additional step of complexity to the api. So I think, for now we should stay at an 16bit CRC for keeping things simple.

In case of FreeDATA - I might be able, reducing the ACK packages down to <= 5 Bytes. So we would be fine with 56bit LDPC.

Regarding preamble - well, it might be enough just sending a preamble. If the preamble is getting lost, there is a high chance, the payload and postamble are not usable anymore as well. So we might be able, reducing some transmission duration here.

[drowe67]

@DJ2LS - there's a first pass C port to the FreeDV API level that's working for me, although I haven't tested performance yet. TODO list at the top shows status.

[DJ2LS]

@drowe67 this was fast! I will change the FreeDATA protocol within the next 7 days and implement the new mode. We then can test it under different circumstances.

[drowe67]

@DJ2LS - I've plotted some PER curves (100 packets), datac14 in black, datac13 in magenta. It looks like datac14 is a few dB worse in performance, probably due to the shorter packet length and shorter codeword. Note that even at 5dB, the datac14 PER is non zero.

These results helped me find an error in the Octave results at the top of the PR, it's PER<0.1 at -2dB SNR MPP, not -5dB. I tried extending the duration to 1 second, but not much difference.

Actually the datac14 PER is kind of flat, less of a knee. Big question, does it provide an overall performance improvement? Might be able to model that with some probability, or a simple simulation.

[DJ2LS]

@drowe67 , a OTC ( over the cable ) test is running fine so far. But it's also showing, that the short burst is sensitive against issues which affect transmission and audio processing.

Next test will be an OTA ( over the air ) test run

[DJ2LS]

@drowe67 I'm running several over the air tests. The mode is working surprisingly well, even if it is that short. I tested it on a -5 to 0dB, MPP, NVIS, channel. From my side it is fine and I'm going to use it in the FreeDATA protocol.

Compared to datac13 we have a higher PER, but in case of ACK we are just repeating the data burst. So it might work.

[drowe67]

Octave clipper adjust notes

1. without clipping:

ofdm_ldpc_tx("test_datac14.raw","datac14",1,-2,"mpp","bursts",100)
Npackets: 1  Nbursts: 100  Peak: 16384.00 RMS: 5261.06 CPAPR: 9.87 clipped:  0.00%
ofdm_ldpc_rx("test_datac14.raw","datac14","packetsperburst",1)
Raw BER..: 0.0493 Tbits: 12544 Terrs:   619 SNR3k: -3.32
Coded BER: 0.0171 Tbits:  3920 Terrs:    67
Coded PER: 0.0918 Pckts:    98 Perrs:     9 Npre: 90 Npost: 9

2. With clipping:

ofdm_ldpc_tx("test_datac14.raw","datac14",1,-2,"mpp","bursts",100,"txclip")
Peak: 16384.00 RMS: 8016.56 CPAPR: 6.21 clipped: 16.18%
ofdm_ldpc_rx("test_datac14.raw","datac14","packetsperburst",1)
Raw BER..: 0.0571 Tbits: 12160 Terrs:   694 SNR3k: -4.40
Coded BER: 0.0253 Tbits:  3800 Terrs:    96
Coded PER: 0.1263 Pckts:    95 Perrs:    12 Npre: 85 Npost: 15

Checking out a few points:

Clip	SNR	CPAPR	CPER
0	-2	9.87	0.0918
1	-2	6.21	0.1263
1	-1	6.21	0.0816

So CPAPR down 3.6dB dB, for a small increase (<1dB) in coded PER, so net improvements with clipping around 3dB.

[drowe67]

Recomputed the PER v SNR curves, after clipping adjustment. Similar to above, good check to make sure performance hasn't changed much. However we can now achieve a few dB higher SNR at the Rx for a given peak Tx power.

[drowe67]

@DJ2LS - I think I've completed all of the agreed tasks:

1. Pls let me know if I've missed something.
2. Pls try a basic functional test just to make sure I haven't messed anything up.

When you give me the OK I'll merge. Thanks.

[DJ2LS]

I was able doing a OTA test, seems to work so far.