LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What's meaning of sync index? Attached vi. Thank you.

Dear friends, 

 

I posted some related questions about the sync index, but I think I didn't ask clear enough, that's why I still don't get the answer yet.  I attached the vi, which is modified from inbuilt example, "MT PSK Transceiver (One Shot)". In case you cannot run the attached VI, please just use the original "MT PSK Transceiver (One Shot) vi". I just added some indicator, that's it. 

 

In the picture 1, sync found index is 31, why this number can be smaller than guard bits (50)?  How it works? The BER is 7% only, so the BER is compared from which index to which index? please advise me in details.

In the picture 2, sync found index is 306 (much bigger than 50). Because my sync indent = 0, how comes the sync index can be > 50 ? Sounds like my sync bits is in the message sequence?  please advise me in details.

 

Why I am asking this?  

1. the whole package is assembled as (in this case) 50 guard bits, then 40 sync bits, then 500 message bits.  This can be shown as in picture 3. print from "mod_create TX sequence VI" in "mod_PSK transmitter TX ". This means, if the SNR(Eb/N0) is  high enough, the perfect sync found index should be first bits of sync sequence, which counted from beginning of guard bits, should be = 50.  Please try it. 

 

As you seen, my goal is fully understand the meaning of sync found index. I believe the packet is always made as gurad+ sync+ message. If the sync index is not = end of guard bits, Whats meaning of that?  But no one truly answered the question, I know it's hard. Hence, thank you so much for your kindness and time, and help.  

 picture 2picture 2picture 3picture 3picture 1picture 1

 

0 Kudos
Message 1 of 18
(3,299 Views)

What you have not understood is that the sub-vi area that is looking for a sync packet is not looking for the "Exact" sync pattern.  What it does is compare the sync packet to the data stream (starting from the end) and phase shifting it twice.  The sync found location is the area of the data stream the "MOST CLOSELY" resembles the sync packet.

 

The signal you generate has as much in-band noise power as the information (Eb/N0 = 0dB or Eb as Information Power = N0 as Noise Power) so any area in the data is just as likely to resemble the sync packet as any other area of equal size.  (Its a great way to produce a pseudo random number between Data size + sync size  and Data size - sync size)

 

Increase signal strength


"Should be" isn't "Is" -Jay
Message 2 of 18
(3,277 Views)

Dear 

 

 

 

0 Kudos
Message 3 of 18
(3,248 Views)

@sunson29 wrote:

Dear 

 

 

 


Since you are doing best guesses against random noise you get random values.  It is like trying to learn what the declaration of independance means after a set of blindfolded monkey each type a number of charaters and then they are assembled in no particular order (and the typewriters have 256 keys with only a subset meaningful in any language)

 

In other words, up the SNR!  More signal less noise


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 18
(3,242 Views)

Dear Jeff·Þ·Bohrer

 

Thanks for your reply. Allow me to ask.  

1. the sync found location is always the first bits of sync sequence (which is the last guard bit location+1)? Do you agree, Yes or No?  I know there is big noise, hence, in that example, demodulation think the "best index" was 31, instead of 50 (labview first index is 0 not 1).  

2. This is important, since the sync found index is 31(count from beginning of guard bits, if you agree), and BER index is 60 (Yes, I agree with you.). This means, from index 31 to  WHERE  is the end of sync sequence.  maybe 31+ 40 = 71 ?  

3.  The BER found index 60 is counted from where?  I do know, if channel is good enough, this should be counted from first bit of sync sequence (should be 40).

I know the packet is made from guard + sync + message.  But, after the big noise,  this index doesn't make scene anymore. It sounds like the sync bits length is not 40 anymore? It changed somehow? like in the example, picture 1, the packet with noise, please advise me, the index from 1st to where is guard bit, where to where is the sync bits, then where to where will be message sequence. 

 

To answer your question. I cannot make SNR high. Because I am using the example for USRP project. In that project, sometimes, I lose the lock. In other words, the sync index is totally mess up sometimes. I do need to know how it works. Sorry about the questions again and again.  Thank you so much for your kindness again and again.

0 Kudos
Message 5 of 18
(3,228 Views)

Guard bits, sync bits and message bits never change.  The PN sequence (Pseudo-random Number sequence) for BER changes length with the Order value (Default 9, example 1 is set to 5) and the way it is generated depends on the type of generator used (the Help explains it well)

 

Sync is determined by "Best fit" to the Signal + noise received so the noisier the signal is, the more likely it is to be identified incorrectly.  BER trigger is based on comparing a "PN sequence" ( to the Signal + noise received with a threshold. The index of first section of the received signal that meets the threshold is returned.  Again, the noisier the signal is, the more likely that the PN sequence will falsely match the noise in the signal. 

 

Because the index values returned in your examples do not make and sense (because the math doesn't support them if you know the number of Guard, sync, and data bits) the only information that can be retrieved from the noisy signal is that : "The signal is too noisy to understand" which seems to be confusing you.

 

The data information is gone, departed, poof! and unrecoverable by the receiver. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 18
(3,216 Views)

Dear 

 

 

 

 

0 Kudos
Message 7 of 18
(3,204 Views)

@sunson29 wrote:

Dear 

Backing up to the previous 

1. the sync found location is always the first bits of sync sequence Yes (which is the last guard bit location+1NO!)? Do you agree, Yes or No?  I know there is big noise, hence, in that example, demodulation think the "best index" was 31, instead of 50 (labview first index is 0 not 1).  repeating the explanation "What you have not understood is that the sub-vi area that is looking for a sync packet is not looking for the "Exact" sync pattern.  What it does is compare the sync packet to the data stream (starting from the end) and phase shifting it twice.  The sync found location is the area of the data stream the "MOST CLOSELY" resembles the sync packet."

2. This is important, since the sync found index is 31(count from beginning of guard bits, if you agree), and BER index is 60 (Yes, I agree with you.). This means, from index 31 to  WHERE  is the end of sync sequence.  maybe 31+ 40 = 71 ? NO! in this exapmle the sync most closely matched a section of received data that include.d a portion of the guard bits (Incorrectly determined Sync due to high noise)

 

3.  The BER found index 60 is counted from where?  I do know, if channel is good enough, this should be counted from first bit of sync sequence (should be 40).No, from the first bit that matched the PN sequence per the threshold setting

  

I know the packet is made from guard + sync + message.  But, after the big noise,  this index doesn't make scene anymore. It sounds like the sync bits length is not 40 anymore? No, The bits are all transmitted but, they are garbled by the noise  It changed somehow? like in the example, picture 1, the packet with noise, please advise me, the index from 1st to where is guard bit, where to where is the sync bits, then where to where will be message sequence.  The bits are all still there! they are impossible to tell if they were a 0 or a 1 at the receiver

 _______________________________________________

Continuing with your latest





 

 

 


Good?


"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 18
(3,193 Views)

Dear Jeff.

 

Yes, very good. Now, I am able to follow your logic.  

I need to do some research base on your answer. I will get back to here very soon. Hope you could give me a hand at that time.  

I do have a quick question here.

1. When you say "This BER trigger index must be after the sync found index. Yes or NO ? NO. It can be anywhere the noise matched the PN Sequence within the tolerance  "  Are you saying, the BER trigger found is NOT depend on the sync found index ?  In other words, there are 2 "sync process", one sync is from sync sequence, another is sync for BER comparison match? Yes or NO ?  

 

Thank you, Jeff. 

0 Kudos
Message 9 of 18
(3,186 Views)

@sunson29 wrote:

Dear Jeff.

 

Yes, very good. Now, I am able to follow your logic.  

I need to do some research base on your answer. I will get back to here very soon. Hope you could give me a hand at that time.  

I do have a quick question here.

1. When you say "This BER trigger index must be after the sync found index. Yes or NO ? NO. It can be anywhere the noise matched the PN Sequence within the tolerance  "  Are you saying, the BER trigger found is NOT depend on the sync found index ?  In other words, there are 2 "sync process", one sync is from sync sequence, another is sync for BER comparison match? Yes or NO ?  

 

Thank you, Jeff. 


YES, Those indices are found in completely different way in completely independent sections of code.  If you have an ideal (noise free) transmission there will be some natural relationship between them because of how an ideal packet is generated.  but in random noise, its ...Random.


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 18
(3,182 Views)