10-12-2017 12:28 PM
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.
10-12-2017 01:11 PM
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
10-12-2017 06:45 PM
Dear Jeff·Þ·Bohrer,
Thanks for your answer. But I am not clear at all.
I do know the correlation peak can not be max like with itself. It must be "MOST CLOSELY" as you said. But it doesn't explain the meaning of index much bigger or smaller than # guard bits.
Lets narrow my question and example. I am only talking about sync bit index = 31, BER = 7%. picture 1. Please advise me, yes or no. If not, please advise me in details.
since the sync index is 31, this means, the BER =7% counted from the message sequence index from 71 to the 571 vs the original message pattern? Yes or No ? 71 = 31+40 (because 31 is sync found index, is the first "most likely" synced location, then plus the length of sync, 40. Hence, 31+40=71 is where the demodulation believed beginning of message sequence. 517 is because the length of message is 500, if start at 71, then stop at 71+500)
Thank you again,Jeff·Þ·Bohrer,
10-12-2017 09:51 PM
@sunson29 wrote:
Dear Jeff·Þ·Bohrer,
Thanks for your answer. But I am not clear at all.
I do know the correlation peak can not be max like with itself. It must be "MOST CLOSELY" as you said. But it doesn't explain the meaning of index much bigger or smaller than # guard bits.
Lets narrow my question and example. I am only talking about sync bit index = 31, BER = 7%. picture 1. Please advise me, yes or no. I can discuss that example If not, please advise me in details.
since the sync index is 31, this means, the BER =7% counted from the message sequence index from 71 to the 571 vs the original message pattern? Yes or No ?NO The Bit Error Rate is calculated on all bits after the BER Trigger is observed That is at bit 60 in that example. Again, with an effectively random signal the PN Sequence (Peuedo Random # of Bits) in, this case 5 bits since that is your PN order, is mistakenly observed in the stream of noise at an incorrect location. 71 = 31+40 (because 31 is sync found index, is the first "most likely" Again, in this example the random noise most closely resembles the Sync Pattern staring at bit 31 of the random noise. synced location, then plus the length of sync, 40. Hence, 31+40=71 is where the demodulation believed beginning of message sequence. 517 is because the length of message is 500, if start at 71, then stop at 71+500)
Thank you again,Jeff·Þ·Bohrer,
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
10-13-2017 02:01 AM
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.
10-13-2017 07:19 AM
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.
10-13-2017 11:53 AM
Dear Jeff·Þ·Bohrer,
Thanks for your quick reply again.
When you say " Guard bits, sync bits and message bits never change ". this is including the package at receiver or NOT? In other words, at side of receiver, will the VIs at side of receiver change the size of guard, sync, message ? Yes or No ? (I know the PN length is 2^n-1)
When you say "The index of first section of the received signal that meets the threshold is returned." . This is exactly the question I was asking again and again. This BER trigger index must be after the sync found index. Yes or NO ? I believe sync found is first condition, then BER trigger found. In other words, first you sync is true, then you talk about where is BER trigger found.
When you say ""The signal is too noisy to understand" which seems to be confusing you.". Yes, that's why I am asking. How the VI decides the location, how it works? Just picture 1 case
Dear Jeff·Þ·Bohrer, I do know you have good knowledge. However, I do hope to save your time. hence, could you exactly answer my questions. Especially the questions before this post. This is the best way. Thank you again, Jeff.
10-13-2017 01:49 PM
@sunson29 wrote:
Dear Jeff·Þ·Bohrer,
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
Thanks for your quick reply again.
When you say " Guard bits, sync bits and message bits never change ". this is including the package at receiver or NOT? In other words, at side of receiver, will the VIs at side of receiver change the size of guard, sync, message ? Yes or No ? NO, the bits are all transmitted and received (I know the PN length is 2^n-1)
When you say "The index of first section of the received signal that meets the threshold is returned." . This is exactly the question I was asking again and again. 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 I believe sync found is first condition, then BER trigger found. In other words, first you sync is true, then you talk about where is BER trigger found. Ideally yes, BUT, you don't have a ideal situation because of noise You can use the fact that the indecies found are obviouslt erroneous to determine the received signal is "Junk"
When you say ""The signal is too noisy to understand" which seems to be confusing you.". Yes, that's why I am asking. How the VI decides the location, how it works? Just picture 1 case
Dear Jeff·Þ·Bohrer, I do know you have good knowledge. However, I do hope to save your time. hence, could you exactly answer my questions. Especially the questions before this post. This is the best way. Thank you again, Jeff.
Good?
10-13-2017 03:24 PM
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.
10-13-2017 03:53 PM
@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.