Enable and fix DStar Fast Data

[F4FXL]

Hi Jonathan,

As posted here this is what @dscp46 and me have been working on in the last days.

It has been tested on 3 repeaters with various MMDVM Firmware version (one even running a 5 years old firmware) without any issue either in voice or data communications.

This shall solve #470

73
Geoffrey @F4FXL
Célestine F4HOF @dscp46

[F4FXL]

hi,

The current state breaks slow data decoding and as a matter of fact late RF entry, cannot be merged as is... Working on a fix...
This fast data is actually a real pain in the *ss

[dscp46]

hi,

The current state breaks slow data decoding and as a matter of fact late RF entry, cannot be merged as is... Working on a fix... This fast data is actually a real pain in the *ss

Hi Geoffrey,

The D-Star specification describes a lost frame as the magic value: 9E8D3288261A3F61E8E78476 in section 6.6. Once de-scrambled, that value is EEC2A1C8426E5251C397CBE5. When a frame is lost on an "even" frame, this has an unforeseen consequence: the S-Data miniheader is 0x97, as if the frame was a DV Fast data frame with a 23 bytes payload.

Any frame that matches that value shall be ignored in the slow/fast data processing pipeline.

However, in section 6.2 (Simple data communication), the standard mandates to escape a few characters, such that the pattern E78476 in the data part of a frame, in conjunction of 9E8D3288261A3F61E8 shall never appear, as explicitly told in note 1:

注１: データフレームが “0xE7, 0x84, 0x76” のデータ列となり、かつ音声フレームが無音 パターン“0x9E, 0x8D, 0x32, 0x88, 0x26, 0x1A, 0x3F, 0x61, 0xE8”の場合にパケッ トロスとして扱うため使用できません。(「6.6 パケットロス」を参照).

The way section 6.2 has been written is fragile, since the banned values are a mix of scrambled and unscrambled values: to avoid the appearance of those values, one should ban at least one of the following: 0x97, 0xCB, or 0xE5. I have written an e-mail to the JARL with a request to clarify that last point in section 6.2.

That's one condition I also have yet to handle in my DV Packet Service Gateway.

Best regards,

[dscp46]

As seen together tonight with @F4FXL, we might have a way to reduce DV Fast data false positives on weak/garbled signals:

In a fast data block, the mitigation byte ("軽減" in the standard, at the center of the 9 byte voice frame) is supposed to be set to 0x02 (0x66 when scrambled) in both voice frames. In network captures I've done, I've found sometimes that byte to be set to 0x00 (0x64 when scrambled).

With a check for both those bytes on top of the miniheader, the probability of a false positive, in a garbled frame, would drop from 11% to 6.7ppm, give or take, if my figures are right.

[g4klx]

I've merged it with the new MQTT enabled MMDVM Host, I hope I didn't break anything.

Is there a need to add re-initialisation code to writeEndRF() and writeEndNet() to stop memory leaks and/or ensure that the variables are in a sane state for the next incoming transmission?

[F4FXL]

As @dscp46 mentionned there is still the case on noisy transmission that voice data gets falsely interpreted as fast data. I'll try to implement the mitigation byte recognition to avoid false positive. I might move these to a separate class to handle it.

If the transmission does not stop before the second frame is received, then there will be no memory leak, yet you are right cleaning m_RFdataLookBack and m_NetdataLookBack writeEndRF() and writeEndNet() might be more secure.