# Can Binary Content alone affect Noise Performance?

Assume we got a transmitter and a receiver. We send a binary stream of let's say 8 bits (the stream length cannot change), using AM-modulation. We have no info on the channel/noise characteristics. Our end-system is triggered whenever a certain binary pattern arrives at the receiver (assume the triggering pattern is 01010101).

Our target is to ensure that our end-system will only be triggered whenever we send the triggering stream of 01010101 and minimize the possibility that this occurs due to noise (let's say when sending 01010100 --> receiver translates it as 01010101 and triggers the system).

Is it possible ONLY by choosing the triggering sequence appropriately to increase noise-performance? For example, to say that I choose pattern 11111111 as my triggering sequence, because it is more resistant than 01010101?

Is it possible ONLY by choosing the triggering sequence appropriately to increase noise-performance?

Yes.

The trick is to ensure that your transmitted sequences are as distant apart as possible from each other. Distant, here, is in terms of Hamming distance. This is the best you can do without more complex forward error correction codes and without any further specification regarding the nature of the noise.

What you do not mention is the nature of your message. What is it that you want to send over this link?

For example, if your application is remote control, then it is likely that you would want to transmit a small set of commands. For example, "on" and "off". This is just 2 source symbols to be encoded in 8-bit words.

A $N = 8$ bit word can describe $2^N = 2^8 = 256$ different words. The maximum (Hamming) distance between them is $8$. This is between the words $00000000$ and $11111111$. Therefore, if you map your 2 source symbols to these two words, you would have created the largest separation possible between them and it would now be difficult to send one and mistake it for the other...within reason.

This would be equivalent to a 1/8 repetition code. In fact, repetition codes that are decoded with majority voting need to be of odd length.

The more source symbols you are trying to cram into this space, the less the distance between them will have to be made and the less error-prone the whole process will be.

Alternatively, you can keep this scheme as suggested and increase your word length to 2 or more bytes in an attempt to increase this inter-codeword distance as much as possible.

Hope this helps.

EDIT:

There is nothing more that you can do to guard against noise at the level of the source message (short of using Forward Error Correction of course).

The only thing that you can do is to select words with large distances.

Now, having said this, your message might have its own statistics. This goes all the way back to the beginning.

In other words, each one of these 256 8-bit words does not have equal chances of appearing. If you were sending some text in english, for example, your most frequent letter would be "e", followed by "t", "a" and so on.

In fact, according to the second table (in the web page linked above), 17 letters of the english alphabet account for 90% of the overall frequency distribution. That is 17 out of 256 possible words have to be transmitted 90% of the times. The majority of words are made up of these letters.

What you have to do now is to select a code sequence for your trigger that is as far as possible from the codes that are used 90% of the times.

In other words, given a distribution of source symbols, the problem becomes one of "code word" mapping.

But, there is another point here that is counter-intuitive. Longer sequences have higher chances of being contaminated by noise than short sequences.

Therefore, you can take this into account during your "mapping process" by using prefix codes. Prefix codes are self-delimited. In other words, they are variable length (e.g. one sequence might be 2 bits and another 8) and no prefix sequence (that is the first N symbols of it) is part of another code. Therefore, the codes are unique and "self-delimited". If you were to see the sequence "1110100110", you know that it contains 3 symbols "111", "010", "0110". None of those is part of the beginning of another one.

Your trigger symbol could be the shortest and your message symbols could be assigned to the rest. In this way, your effective link speed will also increase because you don't have to use all 8 bits for all symbols. In some cases, you might even be able to pack 2 symbols in a byte and within reason this doubles the link speed.

Hope this helps.

• Nice approach! But in my case I am looking for a complete different thing. To make it easier let's assume all 256 possible words are used. I want to find out whether it is better to use ex. 1111-1111 as a triggering sequence compared to 0101-0101. Both streams will be used in the end, the question is whether one can be more noise-resistant than the other in order to select it as triggering sequence – koita_pisw_sou Dec 7 '17 at 12:57
• @koita_pisw_sou Have a look at the edit. There is not much more that you can do without employing FEC. – A_A Dec 7 '17 at 13:57