Flickering Images on NI-5431

[ChrisFarmerWIS]

Hi,

When outputting our bin files from the NI-5431, we are seeing flashes of flickering colour underneath the lines we are updating from the NI-5431.

We are viewing the composite video off the 'Video Out' BNC terminal. The system is 75 ohm balanced.

We are currently outputting either M-NTSC or Standard PAL footage from the NI-5431, using bin files we compiled from BMPs, at the required format resolution.

The bin files contain a constant background, with icons which fade in and out, along with a time-code which changes every frame.

We update the NI-5431 with a background image on the first frame, then update only the icons which fade in and out, along with the time-code for about 72 frames.

Our ultimate goal was to produce a scrolling time code of the greatest length possible. We were only able to fit 73 Frames of footage into the NI-5431, before it reached its memory limit.

From my personal viewing of the footage, I have seen that on the first frame of the recorded footage, the effect of the flicker underneath the footage seems reduced on the first frame, but every frame after that, it seems constant.

We have tried downloading slightly different lines to the card, and this caused the flickering section to move on the screen.

It seems to move to random spots, like to the top of the screen if you just shift one field lines up by 1.

We have tried different interleaving between odd and even fields, but the combination we have provided is the best solution we could produce.

An example of the VIs are attached..

Thanks!

[JerryAL · Accepted solution]

Hi Christopher

I’m going to start out with some basic video info, to ensure we start at the same place.  Forgive me if it is too basic.  Please refer to the NI Signal Generators Help File   NI Signal Generators Help/ Fundamentals/ Video Signal Fundamentals Help/ Interlaced Scanning.

Without actually seeing the waveform files and the images that they were generated from, I only have one guess at this point.  That the color burst signals are not lining up correctly as the different waveform segments are sequenced together.

As the help file shows, there are two parts to an image frame, the odd and even field that are interlaced.  These are generated at a rate of 29.97 frames per second.  For NTSC, there actually is more to the story, concerning the color burst.  For NTSC, it actually takes two frames for the all the timing signals to loop.  The is a direct relationship between the frame rate, line rate, and the color burst frequency. 

Line frequency = 525 x frame frequency
Color burst frequency = (485 /2 ) x line frequency.

So, think of the frames repeating every two in terms of an odd and even as well.  So we have the following:
Odd Field – Odd Frame
Even Field – Odd Frame
Odd Field – Even Frame
Even Odd Field – Even Frame

This is why NI Video will take a bitmap image and create a waveform file containing two frames worth of data.  You can tell this by looking at the phase of the color burst on the same line in the two frames.  They will be 180 degrees apart.  It takes two frames of time for the sine of the color burst to come back to the same phase.

So, this is why I think this is the issue.  If you are sequencing the waveform subsets in such as way that the color burst phase suddenly changes for the monitor’s PLL loop, you will see a glitch in the screen as the PLL attempts to adjust.  This usually takes a few lines.

So, you must be very careful when attempting to make a “moving” video using NI-Video to create the waveform.  When I did it, I used the following routine.  Even though the frame rate is 29.97, for real video, the “image” is actually moving in real time.  So there actually is a difference in the image every 29.97 / 2, or 59.94 times per second.  So I actually used images that changed at a 59.94 times per second rate.

So, starting from bitmap 0, I would take the frame subset that corresponds to Odd Field : Odd Frame (first quarter of the waveform file),
then bitmap 1 and use even field : odd frame (second quarter of waveform);
bitmap 2 = odd field : even frame (third quarter of waveform);
bitmap 3 = even field : even frame (forth quarter of waveform);
bitmap 4 = odd field : odd frame;
and so on.

This will ensure that the phase of the color burst is continuous.

If you are just taking subsets of lines and want to sequence even smaller sets of waveform data to conserve AWG memory, you have to be very meticulous in ensuring that the color burst phase always remains continuous.  This means that you are getting the right segment from the exact field, and the exact frame required.

For PAL, this gets even more complicated because the color burst phase actually sequences through 4 frames or eight fields.

I hope this helps.

Jerry

[ChrisFarmerWIS]

Hi Jerry,

Thanks for your prompt reply.

It certainly seems that this is what we need to implement.  It will just come down to whether we have the time to do it at this stage.

We'll let you know how it goes if we try it.

Thanks again

[ChrisFarmerWIS]

Hi Jerry,

We managed to implement your suggestion in the end, with success!  Here is the fallout:

It made sense why the NTSC files are 2,671,200 bytes ( 2 Frames per File x 525 Lines x 1272 Samples per Line x 2 Bytes per sample = 2671200 bytes), and why the PAL bin files are 6,400,000 bytes. ( 4 Frames per File x 625 Lines x 1280 Samples per Line x 2 Bytes per sample = 6,400,000 bytes)

We have created a few new VIs to make the code more readable from the point of frames and lines in the binary files. Now, all we do is feed in the

• Start Line Frame = 1
• Start Line = 1
• End Line Frame = 1
• End Line = 166

and the VI will provide us the Samples and Offset required to read from the Bin files to create a segment. This VI also allows us to keep track of the number of Bytes used in memory so we can tell how much memory we have used.

Basically now we have created 9 Segments to complete the first 2 frames:

• Segment 1 = Frame 1 Start Line 1 -> Frame 1 End Line 166 = Background Image (BMP Bin File 1 containing "00-00")
• Segment 2 = Frame 1 Start Line 167 -> Frame 1 End Line 204 = Odd TimeCode "00-00" (BMP Bin File 1 containing "00-00")
• Segment 3 = Frame 1 Start Line 205 -> Frame 1 End Line 428 = Background Image (BMP Bin File 1 containing "00-00")
• Segment 4 = Frame 1 Start Line 429 -> Frame 1 End Line 466 = Even TimeCode "00-00" (BMP Bin File 1 containing "00-00")
• Segment 5 = Frame 1 Start Line 467 -> Frame 2 End Line 166 = Background Image (BMP Bin File 1 containing "00-00")
• Segment 6 = Frame 2 Start Line 167 -> Frame 2 End Line 204 = Odd TimeCode "00-01" (BMP Bin File 2 containing "00-01")
• Segment 7 = Frame 2 Start Line 205 -> Frame 2 End Line 428 = Background Image (BMP Bin File 2 containing "00-01")
• Segment 8 = Frame 2 Start Line 429 -> Frame 2 End Line 466 = Even TimeCode "00-01" (BMP Bin File 2 containing "00-01")
• Segment 9 = Frame 2 Start Line 467 -> Frame 2 End Line 525 = Background Image (BMP Bin File 2 containing "00-01")

= 2 Complete Frames (Odd and Even Fields)

We then use the Waveform Handles created by the NI-FGEN VIs to reuse Segments 1, 3, 5, 7, 9 (to save on memory in the NI-5431), while creating new segments for odd and even fields for the updated Time Code Lines from BMP Files 3-64.

We have reduced our number of frames slighly, due to the added number of segments we have to replay (Max. ~294)

Memory in the NI-5431 was not an issue with NTSC.

We have also modified our PAL code to use the 2nd, 3rd and 4th frames in the PAL footage to remove the flicker. We used the same process as the NTSC, except we had frame 3 and frame 4 to handles as well.

Because we had to store and repeat more frames, we ran out of memory (16Mb) on the NI-5431 before reaching the max segments in a loop.

It was an interesting exercise to get into the inner workings of the .Bin files. It would be great if there was a one stop shop .pdf file, which explains the working of the .bin files.

I would like to thank you again Jerry for your insight, it really did help resolve this issue.

Thanks

Chris Farmer.

[JerryAL]

Hi Chris

I'm glad you got it working.  There is only one person who knows the NI 5431 more than I do and he designed the toolkit.  I couldn't think of another reason that could cause your symptoms. 

Unfortunatley, it was a bit of work.  We were able to make the module pretty easy to work with for simple static images, which was the main design goal.  Making images move is a little bit more work.  And also knowing how NTSC and PAL and the Toolkit creates the waveforms works.

As for memory, you can use the NI 5421 to generate video waveforms as well.  The NI 5421 has 4 memory options, 8MB, 32, MB, 256 MB, and 512 MB.  It also has the option of allowing you to create two buffers, continually generating out of one, looping, then while still generating, download a new waveform to the other buffer and switch to the new buffer.  This way you can arbitraily download new image without the video generation stopping and maintain phase continuity for the monitors.  A partner called microLEX sell software to use the NI 5421 for video.  I have a set of "rough" VIs that will work as well.

Good Luck

Jerry