Update rate of NXT screen

[timpattinson]

I learned the screen has a refresh rate of about 50 ms. You might need a wait to display some of the stuff at higher speeds.

10 FPS, hardware limitation.

Has anyone actually tested that? You could try using NeXTScreen at 50ms poll rate with AVI capture, and see how many frames you can see of the line growing:

Code: Select all

//#define POINT

task main()
{
    for(int x = 0; x < 100; x += 5)
    {
#ifdef POINT
        PointOut(x, 32, 1);
#else
        LineOut(0, 32, x, 32, 1);
#endif
        Wait(50);
    }
}

Have now.
2nd latest test release:
With #define commented out:


With #define:


AVI File(with no #define):

nxt_000.zip

(126.86 KiB) Downloaded 280 times

AVI File: (with #define)

nxt_000_2_000.zip

(102.92 KiB) Downloaded 305 times

[muntoo]

Link to original thread.

Actually, thinking about it, my test wouldn't work if what's on the NXT's screen is different from what the NXT thinks is on its screen. (i.e. The hardware screen hasn't been refreshed yet, but the screen memory buffer and/or refresh flag* has changed.)

The only accurate test would be to make a video in real life. (Hint**: With a video camera.)

*Is there a such thing as a refresh flag?
** No, I am not insulting your intelligence.

[mightor]

The 10Hz refresh rate is a limitation by the LCD screen's controller. It was discussed at an MCP meeting last year and confirmed by one of the hardware designers.

- Xander

[afanofosc]

Here's a thread on lugnet that suggests the LCD refresh rate is 60 to 70 hz.

http://news.lugnet.com/robotics/nxt/nxthacking/?n=26

See also this link where Dick Swan refers to changing the frame rate from 76 to 95. Not sure that means refers to the refresh rate or something else.

http://news.lugnet.com/robotics/nxt/nxthacking/?n=36

10hz seems unlikely to me, but I am prepared to be totally wrong. I don't understand how people like Jason Railton or Dick Swan could be unaware of a 10hz limit if that were the case.

John Hansen

[muntoo]

Relevant quotes:

What you’re doing in code is transferring screen data over a serial link to the single-frame buffer held on the LCD driver chip. You’re not controlling the display’s pixels directly. The LCD controller then refreshes the physical screen from that buffer at a rate of around 60Hz or 70Hz. It doesn’t matter how quickly you actually dump data over the serial link, the display only gets refreshed at the rate dictated by the LCD controller.

That’s why small matrix ‘passive’ LCD devices (like calculators, the original Nintendo Game Boy, and the Grapevine PDA on my desk) only have two shades of grey. They flick between two images as fast as possible, but are able to control the delay between refreshes slightly so that one of the frames lasts a little longer than the other, and you get two different shades of grey. They can’t regulate the brightness of individual pixels like more recent ‘active’ colour LCD displays do (TFTs have a discrete transistor for each pixel). [1]

This is also the place to change the frame rate from 76 to 95 as was mentioned in one of the other posts. [2]

[mightor]

I stand corrected

- Xander

[aswin0]

They flick between two images as fast as possible, but are able to control the delay between refreshes slightly so that one of the frames lasts a little longer than the other, and you get two different shades of grey.

This means that, in theory, we could make a grayscale display for the NXT!

[muntoo]

This means that, in theory, we could make a grayscale display for the NXT!

Look at this:

It's from the first link John posted.

[savedcoder]

As far as motion is concerned, I'm not sure a 70hz refresh rate is much better than 10hz, because the pixels respond so slowly. A sprite moving to keep pace with a 70hz refresh will be severely blurred. As Aswin0 said though, that's good for static grayscale.

[nxtboyiii]

That would be nice to see some NXC code of grayscale...