Why does MT Calculate BER.vi (User Defined Pattern) sync to an offset pattern?

[cgiustini1]

I am trying to use the Modulation Toolkit BER calculation vis in my test software. I am experiencing a handful of problems using them, but this one is the most frustrating. When I use the User Defined instance of the polymorphic vi MT Calculate BER.vi, I will get a returned BER of 0.5 half of the time.

In my attached vi, I perform a simple software loopback test. I create a reference byte pattern of 0x170, 0x187, 0x00 (it could be any other patttern) which is converted to a reference bit pattern. I then feed this bit pattern to the User Defined instances of MT Generate Bits.vi and MT Calculate BER.vi. Each of these VIs are in a seperate while loop that is linked by a queue. MT Generate Bits.vi's Reset terminal is always set to false, so it acts as a constant generator of my bit pattern.

If you press "Reset BER" on the front panel multiple times, strange things happen. The indicator Synced Byte Array and the indicator BER are updated when the "Trigger Found" boolean of MT Calculate BER.vi is changed from low to to high, indicating that the BER detector has gone from being unsynced to synced. When this occurs, "Synced Byte Array" rebuilds the first four bytes using the "Trigger Index" and the input bitstream. When "Reset BER" is pressed multiple on the front panel, the "Synced Byte Pattern" is sometimes the original byte pattern, but it sometimes an offset version of the "Synced Byte Pattern". "BER" is 0 when "Synced Byte Pattern" is the original byte pattern, but it is around 0.5 when there is an offset (which makes sense if you do a bit wise comparison of the original and returned synced patterns when they are respectively 0x170, 0x187, 0x00 and 0x187, 0x00, 0x170). Why is the first returned BER value greater than the trigger threshold, which is always set 0.1? Is this is a bug? From my understanding, the returned BER should never exceed the trigger threshold when looking for a trigger. Am I using this vi wrong or is there a bug?

I would also like to point out that there are numerous typos/inconsistencies in the documentation for MT Calculate BER.vi, which makes it hard to use in the first place 😞 . For instance, it refers to PN orders in the description of the user defined instance of this vi. 

[dbell0971]

Hi cgiustini1,

From your post, I discerned these two questions:

1)  Why is the first returned BER value greater than the trigger threshold?

2)  Why is the VI synching to an offset pattern?

To your first question: according to the help file:

According to this file, on the first call and any subsequent Reset calls, the value of BER is set to 1 for that call of the VI if a trigger is not detected.  I saw this behavior in your VI after several resets.

To your second question: why am I synching to a pattern that is offset from the reference stream?  I found that this behavior stems from the number of generated or "transmitted" bits not being multiple of the number of bits in the reference stream.  For example, if I set the number of bits for each transmission to 24 bits (3 I8's = 24 bits) as seen below, I get a 0 BER.  However, if I set it to something that is not a multiple of 24 bits, 25 for example, what is being transmitted changes after each iteration.  To see this behavior, please check the attached VI and follow the instructions on the front panel.

Therefore, to solve this problem, make sure that the number of bits being transmitted is a multiple of your reference stream.

I also have one other recommendation that may be useful: it seems that the timeout for the dequeue function is set to 0; this means that if data is not available in the queue, the top consumer while loop will continue to execute on an empty array.  Instead, I would recommend setting the timeout to by -1; this will cause the top loop to wait until data is available from the bottom producer loop.  There is only one issue with setting the timeout to -1: if the producer loop stops, the dequeue VI in the consumer loop will sit and wait for data forever.  To rectify this issue, I would recommend adding a "Release Queue" VI after the producer loop.  If the producer loop stops, it will then release the queue, then the dequeue function will error out, stopping the consumer loop:

I also noticed that you had created a service request for a similar issue with one of our Applications Engineers here.  Feel free to give us a call at 866-ASK-MYNI (866-275-6964) to create a new service request or to work on an existing service request.

Thanks and good luck,

David B

National Instruments

Applications Engineer

[JÞB]

in addition to the good info David provided I want to make you aware of the IIR filter down deap in the toolkit.  on "Reset" you will get an artificial impulse while the filter stabilizes.