Questions about Sync bits in wireless communications for labview (attached pictures). Thank you very much!!!

[sunson29]

Dear friends, 

Please give me the answer in details, because I already read the context help. Thank you in advance for your time and help.  

I am using in built example "MT PSK Transceiver (One Shot)" (picture 1). 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 one 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.    

In this Transceiver, we can tell easily that, the sycn is done in demodulation vi, "MT Demodulate PSK VI" . There are 4 synchronization parameter inputs: 1. Expected Sync Location, 2. Sync Sequence, 3. Sync Location Uncertainty, 4. Sync Indent.  

Question 1. In the picture 2,  Sync Indent. It seems that the sync bits can be in the middle or somewhere of information bit?  Yes or No? If yes, however, in this Transceiver example, it's very clear that the packet is made from guard bits + sync bits + information bits. Sync bits part is in the middle (first guard, then sync, last part is information), never cut into somewhere of information bits. (to check this, you need to open "mod_PSK transeiver" then open "mod_create TX sequence"). Please advise me in very detail or make one simple examples. 

Question 1.1  In the picture 1, the sync index 5230 is > length of guard bits 100. Because the channel is bad @0.33dB SNR, and Expected sync location is -1 (search the whole array).  If question 1 is YES. This means, there is another 80 sync bit sequence copied into somewhere of information bits, and this 5230 is counted from very beginning of guard bit, then original sync bits, then part of information bits, then the current first index of sync bits (picture3)??    Yes or NO,    Please advise me in very detail or make one simple examples. 

Question 1.2 There is no input of sync indent in this example. So..... what's meaning of that, what's the default?  

Question 2. How did NI define this sync found index? This example again, lets say the channel is good, but not that super good. I got sync found index = 120. This means 1. it count from guard bit 100, then 20th from the sync bits (in other words, it compare only a part of sync bits from 20th to 80th)?  OR  2. It always compared the full length of sync bits (in other words, the found index is always the first of sync full sequence), but it shift somehow 20 bits, then start the new 80 length? I dont know,  just guess.  Please advise me in very detail or make one simple examples. 

picture 3picture 1picture 2

I do know, my questions are not easy. I do read the toolkit help or context help. But I just dont get it. Thank you again for your time, kindness and help.  

[AgentAstronaut]

I am going to try to rephrase your questions to make sure I understand.

For Question 1:

It seems like you are trying to understand what the Sync Indent parameter does. The source of this confusion is as follows. The helpfile notes that you should have a packet that consists of a guard bit section, then the data section with a sync bit section somewhere within the data section. However, the example shows a packet that has a guard bit section, then a sync bit section, then a data section. You are trying to understand why the example does not have the sync bit section within the data section, instead it has the sync bit section before the data section.

The reason this behavior is occurring is because in mod_PSK Transceiver.vi you are defining the synchronization parameters using the MT Generate Synchronization Parameters VI. One of the inputs to MT Generate Synchronization Parameters VI is sync indent which has a default value of zero. It looks like if you do not specify a sync indent then the sync bits will be between the guard bits and the data bits.

I think this answers question 1.

For Question 1.1, it seems like you are trying to determine why the sync found index does not return the correct value even though a BER trigger has been found.

When you have such a low SNR you cannot reliably get a good lock on your signal. Even though the BER is triggered, it is possibly randomly encountering a sync rather than actually maintaining a lock. You can tell this by looking at the Received Constellation graph which shows a giant blob instead of two distinct groupings of data (for M-PSK 2). Therefore, even though you are randomly receiving a valid BER trigger, it is likely that all of your data is invalid since the sync found index is not the correct value. You can see this more clearly if you set your SNR to around 4dB. With 4dB you will see that a fair amount of the time the BER will trigger but the sync found index will not be correct, and a fair amount of time the BER will trigger and the sync found index will be correct.  In other words, the fact that a sync sequence was found is probably a random occurrence. 

Question 2. I'm not exactly certain what you are asking, but I think you are wondering what exactly the sync found index is returning. I can tell you that it is returning the index of the first symbol of the sync bit. If you have guard bits equal to 100 bits, you are using M-PSK 2, your sync bits are equal to 80 bits, and your sync indent is set to zero 0, then the sync found index should be 100 and it should refer to the first bit of the sync bits. your first data bit should be at index 180. But if your sync found index does not match what you expect then your entire data set is likely incorrect. To further elaborate on this, let me give another case.  If you have guard bits equal to 100 bits, you are using M-PSK 2, your sync bits are equal to 80 bits, and your sync indent is set to 20 then you would expect the sync found index to be 120 with the start of your data occuring at 100. You would then get 20 bits of data, then 80 bits of sync bits, then the rest of your data. 

[sunson29]

Dear @AgentAstronaut,

Thank you so much for your answers. It was in detail, thank you!

The most important question I was asking is question 1. Yes, your translation is exactly what I was asking. However, there is a misunderstanding. Allow me to express this here. I will say the packet (guard+sync+ data) is NOT only defined in  MT Generate Synchronization Parameters VI, I may say it this pattern was defined in mod_create TX sequence VI.  Please check the picture below. You can see exactly the pattern: guard + sync + data.  After this vi, then it is the mod_create TX sequence VI.   This confused me, sounds like there will be 2 parts of sync bits (one made by mod_create TX sequence VI, another made by MT Generate Synchronization Parameters VI). ???  If the indent is 0, those 2 sync sequences will be overlapped ? if the indent is 20 .......  then what...???   Thank you again, sir.  Please advise me in detail. 

I slightly modified mod_create TX sequence VI, I just add some indicators.  

[sunson29]

Sorry about multiple replies. 

In your answer, you said "Therefore, even though you are randomly receiving a valid BER trigger, it is likely that all of your data is invalid since the sync found index is not the correct value."  However, I do observer that the BER could be extremely small or just = 0 when sync found index is NOT exactly =  100 , some numbers bigger than 100, like in the example.     How to explain this?   Thank you again.