File formats for voice + data streams.

[lwvmobile]

I know its listed as TODO in the manual, but can you give me a quick low-down on the voice + data? Is it the same Stream frame setup as 3200 voice, but just use the first 64 bits as 1600 voice w/ 40 ms (320 samples) and the other 64 bit is data? Or the other way around. Or entirely different. I hunter all around your Github presence and couldn't find any clues in any code, so I wasn't sure of the set up for it. Thanks.

[kc1awv]

One of the implementations for 1600 V+D mode in M17 can be found in mvoice, I believe that this may be what you're looking for:

here: https://github.com/n7tae/mvoice/blob/8e0a9fb350f8308d7ee7e07e3cc48e7c33a7be64/AudioManager.cpp#L121
and here: https://github.com/n7tae/mvoice/blob/8e0a9fb350f8308d7ee7e07e3cc48e7c33a7be64/AudioManager.cpp#L332

If not, we can try asking N7TAE and G4KLX about the implementations that they have and adjust the specification accordingly.

[kc1awv]

There's also this snip of code from G4KLX in M17RX.cpp that might be relevant:

		// A valid M17 audio frame
		short audio[CODEC_BLOCK_SIZE];
		if (m_state == RS_RF_AUDIO) {
			m_3200.codec2_decode(audio + 0U,   frame + 2U);
			m_3200.codec2_decode(audio + 160U, frame + 2U + 8U);
		} else {
			m_1600.codec2_decode(audio + 0U,   frame + 2U);
			m_1600.codec2_decode(audio + 160U, frame + 2U + 4U);
			CUtils::dump(1U, "Data Payload", frame + 2U + 8U, 8U);
		}

[lwvmobile]

Okay, that might be enough to go on. If I read the code correctly, it does look like the second half of the 128-bit payload is the data portion, with the first 64-bit being the 1600 voice portion. I've already written the code in, so I guess at this rate, I won't really know for sure whether or not it works properly is if anybody raises an issue and says it does or doesn't. I don't suppose that the M17-Education repo could acquire some 1600 sample .rrc type files for testing purposes, or similar.

[kc1awv]

Wojciech found the missing part in the spec. I'll add it as soon as I can!

[kc1awv]

Ok, we've clarified the idea with some payload examples that seemed to have been lost in the shuffle. I hope this helps!

[lwvmobile]

Okay, sounds great to me. Thanks for the quick turnaround on that data. The good news is, is that I guessed correctly the first time.

A quick followup question, however, one that just occurred to me. When applying encryption (and decryption) via Scrambler and/or AES, does the encryption also apply to the 64 bits of data found in the payload for voice + data, or is running the LFSR required to advance the scrambler seed value to past the second 64 bit data value? Likewise for AES, is enough blocks required to be created to apply to the entire 128 bit payload for the depth of the entire superframe, and also applied to the 64 bit data portion, or do we skip over or discard the blocks that would be used for the second voice that is now data?

I think the wording on that question makes sense. Thanks again.