how comes the sync found index could be larger than # (guard bits + sync bits) ?

[sunson29]

Dear friends, 

I got a hard question here. Hope someone help me out. Thank you in advance for your time and help.  

I am using in built example "MT PSK Transceiver (One Shot)". Base on my previous question : https://forums.ni.com/t5/LabVIEW/Hard-Questions-about-sync-index-and-trigger-found-from-labview/m-p/... . I already learned that, sycn found index is counted from end of guard bits. E.g. since a packet is made from guard bits + sync bits + information bits. If # of guard bits is 100, and if the channel (Eb/N0) is  good enough, you should have the sycn found index at beginning of sync bits (in other words, end of guard bits). Hence, the sync found index should be 100.    

Now my question,

If you use the setting below, and make the channel kinda bad @ 0.33dB.

In this case, the length of guard bits is 100, sync bits is 80, how comes the sync found index is 5230 ?  My understanding is that the sync found index should be <=100+80, (Bc it count from guard bits).

339 for BER trigger found index is fine, bc the channel is bad, the correct location takes "longer" to find, then the index is larger.  

Notes: one packet composed by guard bit+ sync bits + information bits.    The length of information bit = 50000 by using PN=5.  PN=5 only can generates 2^5-1 =31 bits, Hence, there is repeating for those 31 bits until reach 50000.(If will cut off some bits, bc 50000 /31 is not integer. )    

Thank you again for your time and help.  

[Shalini.M · Accepted solution]

Hi Sunson29, 

Do you see the sync found index value at 5230 for multiple executions with the same configurations or does that value change around significantly? 

I ran the same example matching your configurations and was seeing values anywhere from 100.0063 to 27735.0049 for sync found index. 

Your math checks out but the issue here is the combination of a really low Eb/N0 and also setting the Expected Sync Location to -1.

A value of -1 searches the entire input complex waveform and ignores the sync location uncertainty (symbols) parameter. With that along with a really bad Eb/N0, as you can see from the constellation plot, it's going to be nearly impossible to identify the different bits without some guidance. 

If you expect to have a signal with low Eb/N0, that's when I would recommend utilizing the sync location uncertainty and expected sync location controls especially since the number of guard bits and sync bits are already defined. This way you can narrow down where in the array to search for the sync bits. 

[sunson29 · Accepted solution]

Dear Shalini ,

First of all, thank you very much for your detail answer.  

1. Do you see the sync found index value at 5230 for multiple executions with the same configurations or does that value change around significantly? 

Ans:  It's just total random number everywhere.  It's not converge or close to some certain number at all. (if the channel is very good, then the number is also fixed).

Gotcha! it search the whole array, instead of just guard bits or sync bits.  Now, allow me to ask following questions.  Still the same case as in the picture.  

2. Lets say the true sync found index is 5230,  then the bit error rate(BER) is counted from index 5230 to the end of array ?  In other words, BER vi is using index from 5230 to 50.000 comparing with reference PN order = 5 array?

I ask this, is because the BER trigger found is true, and shows BER= 0.118. So, I want to know how this BER vi works, it compare input index from 5230 to end VS reference ?    Thank you again, Shalini.  Thanks for your time and help.   

[Shalini.M · Accepted solution]

The best way to determine how the BER VI is functioning would be to click on "detailed help" in context help for the MT Calculate BER VI in the example. The reason I say that is because the answer to your question depends on how the VI is configured. 

As you'll see in the following screenshot, "the BER returns the measured BER as the ratio of erroneous bits to the bits following a trigger in the current input bit stream. The number of bits considered for this measurement depends on the conditions shown in the following table"